One format that's currently accepted is:
1°23'45.6789" 1°23'45.6789"
I propose to also accept partly incomplete inputs for convenience:
1°23'45.6789 1°23'45.6789
1°23'45 1°23'45
1°23 1°23
1°23.45 1°23.45
All these can only have a single meaning, as far as I'm aware of.
Not sure about these:
1°23'456789 1°23'456789
1°2345 1°2345
The problem here is that these can have several meanings.
Version: master
Severity: normal
Whiteboard: u=dev c=backend p=0
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Jdlrobson | T78430 [Epic] Getting Wikidata to render nicely on mobile web | |||
| Open | None | T158181 Aim for workflow equivalence for MediaWiki on desktop and mobile web | |||
| Open | None | T95878 [Story] Make Wikidata editable on mobile web | |||
| Open | None | T95649 Create and document a stable framework for extending the Wikibase UI | |||
| Stalled | None | T40968 Keyboard-navigability of the repo UI | |||
| Open | None | T54136 [Epic] Redesign Item UI for Wikidata repo | |||
| Open | None | T103834 [Epic] Improve input elements for complex datatypes | |||
| Resolved | adrianheine | T109455 [Story] Simplify input for geocoordinates | |||
| Open | None | T68651 Make last character optional in globe/geo/lat-long parsers |
I'm a big fan of parsers that do their very best to figure out what the user means. The examples provided here and not unambiguous, as far as I can tell, and can not lead to problematic edge cases. Personally I would be willing to work on this any time when approved by PM.