Validation & requests

The package registers Rule::coordinates(), which checks that a value is a coordinate pair within valid latitude and longitude ranges:

use Illuminate\Validation\Rule;

$request->validate([
    'point' => ['required', Rule::coordinates()],   // "lat,lng", [lat, lng], or ['latitude'=>…, 'longitude'=>…]
]);

Accepted input shapes:

// Each of these passes Rule::coordinates():
'48.1486,17.1077';                                // "lat,lng" string
[48.1486, 17.1077];                               // indexed pair
['latitude' => 48.1486, 'longitude' => 17.1077];  // named keys
['lat' => 48.1486, 'lng' => 17.1077];             // short keys (lon is accepted too)

The rule checks latitude in [-90, 90] and longitude in [-180, 180]. The class is RoundlyConsulting\Geolocation\Rules\CoordinatesRule if you prefer new CoordinatesRule.

Translated messages

Both failures — a value that isn’t a recognisable pair and one out of range — use one translated message, key geolocation::validation.coordinates. It follows the app locale, and :attribute becomes the field’s display name (home_location reads “home location”) or your validation.attributes entry, as with Laravel’s own rules. English and Slovak ship with the package:

To change the wording or add a language, publish the files and edit them in lang/vendor/geolocation:

php artisan vendor:publish --tag="geolocation-translations"

When you call the rule’s validate() directly, your closure receives the message already translated, with :attribute still in it.

Request macro

Every request gets a location() macro that resolves the client’s Location from its IP through the manager — so it honours your pipeline, cache and the test fake:

$location = $request->location();   // resolves the client's Location from its IP, or null

It returns null when the request has no IP.