1. Search starts with place slugs
When a user types into the main search dialog, WFY24 debounces the query and calls the internal /api/places/search route with the active locale. Results are displayed with localized names when available, plus region breadcrumb context and a country flag when the country code exists.
Selecting a result routes the user to the canonical place URL under /{locale}/weather/{slug}. That keeps every place page anchored to a stable slug rather than a temporary free-text query.
2. Reverse geocoding prefers the nearest known place
For auto-location experiences, WFY24 does not stop at raw coordinates. After obtaining approximate coordinates, the frontend calls /api/geo/reverse, which proxies the nearest-place lookup and returns a place object with localized breadcrumb information.
This extra step matters because users do not think in latitude and longitude. They think in places, regions and countries, and the product is designed around those canonical entities.
3. GPS is not auto-requested on page load
The homepage local weather card is intentionally conservative with permissions. On first load it tries self-hosted IP geolocation first. GPS is only requested after explicit user interaction, which avoids surprise prompts and keeps the initial page experience lighter.
Once a place is resolved, WFY24 fetches weather using the resolved place coordinates rather than rough IP coordinates so the homepage card stays aligned with the canonical city or place page.
4. Privacy and real-world limits
The codebase also shows a one-time session observation flow that can report a granted GPS fix to improve the self-hosted IP geolocation system. That is a product-quality loop, not a requirement for browsing weather pages.
Search quality still depends on the underlying place database, place types, translated names and administrative hierarchies. Remote settlements, disputed areas or recently changed boundaries may require data corrections over time.