[pfeerick]

Summary

The 3.0 counterpart of #7794 by @RobertoD91, which carries the same changes against 2.12.

Fixes #7787. The GPS model locator encoded its QR code as geo:0,0?q=lat,lon, an Android-specific search form that iOS does not handle. The default is now a strictly RFC 5870-compliant geo:lat,lon, with a selector for alternative map targets.

Changes

From #7794:

• default to RFC 5870 geo:lat,lon
• add a URI type selector, remembered for the current power session
• regenerate the QR code when the selection changes
• preserve full GPS precision using integer formatting instead of %f
• drop a stale static TelemetryItem& that bound to the first page's sensor index permanently
• resize and reposition the QR so it cannot overlap the coordinate label or the Refresh button — on 480x272 the old centred, fixed-size QR overlapped both

Added on top:

• Translatable selector labels. The labels were a hardcoded English array commented as app names; "Standard" is not an app name, and "(web)"/"(app)" are English qualifiers, so the control was the only untranslated text on the page. It is now a STR_GPS_URI_TYPES array following the same STRARRAY pattern as other Choice value lists. Two entries are exposed to translators — TR_GPS_URI_STANDARD and TR_GPS_URI_APPLE_MAPS; "Android", "Google Maps", "CoMaps" and "Guru Maps" stay as literals in the aggregate macro in translation_def.h, as TR_CYC_VSRCRAW already does, so nobody is invited to localise a product name.
• One Google Maps entry instead of two. comgooglemaps:// is the iOS-only scheme and has no Android handler, but the entry was labelled "Google Maps (app)", which reads as platform-neutral — an Android user would reasonably pick it and get a QR their phone cannot open. The Maps URLs API form replaces both entries: it opens the native app on iOS and Android when installed and falls back to the browser.
• An Apple Maps entry, which the original list lacked despite the issue being iOS-specific.
• Silenced a new -Wformat-truncation warning in the coordinate formatter. abs() returns int, so the compiler only knew the arguments were in [0, INT_MAX] and warned that the two directives could write up to 23 bytes into char[16]. Unsigned division and modulo by literal constants give it provable bounds instead. Output is identical across the whole ±180° range and at the int32 extremes.

URI types

Label	URI
Standard	geo:lat,lon
Android	geo:0,0?q=lat,lon
Google Maps	https://www.google.com/maps/search/?api=1&query=lat,lon
Apple Maps	https://maps.apple.com/place?coordinate=lat,lon
CoMaps	cm://map?ll=lat,lon
Guru Maps	guru://show?place=lat,lon

Testing

Jumper T18H7, ELRS receiver with GPS.

Entry	iOS	Android
Standard	opens Maps	opens Maps (pans, no pin)
Android	—	opens Maps with a pin
Google Maps	opens app	opens app with a pin, zoomed in closer
Apple Maps	opens app, place card for the location	opens Apple Maps on the web with a pin

Not device-tested: CoMaps and Guru Maps. Those schemes were checked against vendor documentation only (CoMaps API, Guru Maps API). Confirmation from anyone with those apps installed would be welcome.

Notes for reviewers

• "Standard" pans without dropping a pin on Android, deliberately. That is what a bare geo:lat,lon does, and it is the form that makes the QR work on iOS. A query parameter such as ?z= or ?q= would add zoom or a pin, but RFC 5870's grammar is geo-path = coordinates p with p being ;-delimited parameters — there is no ? query component, so appending one would stop this entry being the standards-compliant option it exists to be. The "Android" entry covers the pin case.
• Apple Maps uses the unified /place path, which requires iOS 18.4 / macOS 15.4. The floor excludes less than it sounds: the oldest hardware pinned to the iOS 18 line (iPhone XR/XS) runs well past 18.4. Being an https URL it degrades to Apple Maps on the web rather than failing like a custom scheme would, and "Standard" covers anything older.
• coordinate= places a pin without a &name=, verified with coordinates far from any saved place. Omitting the name is intentional: it lets Apple resolve and title the locality itself rather than stamping a fixed label on every pin.
• "Apple Maps" is translatable, the other app names are not. Apple ships localised names for Maps — Karten, Plans, Mappe, Mapas — so that entry follows Apple's lead and can match what the user sees on their own home screen. Google, CoMaps and Guru Maps do not localise their names, and "Android" never changes. Translators: please use Apple's official name for your locale rather than a literal translation of "maps"; both strings currently ship as English awaiting translation.
• QR density. The two longest URIs (Google Maps 73 bytes, Apple Maps 65 at the coordinate extremes) encode as QR version 5, 37 modules, at the ECC MEDIUM level lvgl hardcodes. That leaves a scale factor of 3 at the smallest QR size the layout produces and 5 at the largest, so lv_qrcode_update never hits its scale <= 0 bail-out. The URI buffer is sized 96 for a 73-byte worst case.