ReverseGeocoding for localizing towns and country names
Standard text localization
When you create apps for the Apple ecosystem, you may need to support multiple languages. This is a key part of what is known as localization. It comes down to creating an English version of text strings – say the label of a “Submit” button -, and providing translations of “Submit” to other languages.
The idea is to use a base string like “Submit” in the code, and keep translations in separate tables that are used in runtime to replace “Submit” by its translation.
This creates a process separation between the code development and the text translation with certain benefits:
- Translations can be outsourced to a specialist who doesn’t need to understand coding.
- Translations can be done at a later point in time when the UI is considered more stable.
- Additional translations can be added later without changing the code.
Conceivably the translator could test a draft translation together with a test version of the software without requiring an extra build. But I doubt if iOS or MacOS apps easily support dynamic loading of the localization data files.
Geographic names
If you, for example, write an app related to the Channel Tunnel between the United Kingdom and France, you can obviously localize a small number of hard-coded strings like “France” or “Paris” just like any other strings. But this assumes that strings like “Paris” are hard-coded into the software.
If the location is typed in by the user as “Parijs” (NL), you may not need to translate the text string. But may have to interpret “Parijs” to show it on a map. This can be done using the MapKit GeoLocation API to turn a textual address into GPS coordinates.
Reverse geocoding
But there are scenarios where you need to actually translate “Parijs” into “Paris” or vice versa for locations that cannot be predicted at development time. This happens when the original string is not from the source code, but from an outside source like a form’s input field. Other examples of data sources that you don’t control could be database or json files.
Examples:
- The user enters a GPS coordinate (by selecting a location on a map, or reading the GPS coordinates embedded in some photos) and the location needs to be shown (e.g. as Town, Country) in the local language.
This is straightforward to solve: Apple’s Core Location reverseGeocodeLocation API can convert GPS coordinates into a structured address. The address will be localized to the language being used by the app (but you can specify a different language). This means that Paris will show up as “Paris” in English or in French, but as “Parijs” in Dutch. Localization thus impacts the locality (town/city) and country fields, assuming that Apple’s online data set has the necessary translations (I have seen missing translations in China).
- You may receive Paris from your online list of say airports, but want to show “Parijs” instead.
Again, if the list is not too large and you control the list, you could ensure that it also contains translations into all languages that you need. But this doesn’t scale well for many locations and many languages. So here the trick is find a list containing GPS coordinates. And use MapKit to translate into the required language. You will need those GPS coordinates anyway if you want to display the location on a map using MapKit.
- User types in name of a city, and you need to do a lookup for more data via an online service. The user may type “Parijs”, and you may need to look up to find “Paris” to see what airports for Paris are called.
This would require using geocoding to convert the (full or partial) address into GPS coordinates, followed by reverse geocoding to convert the received GPS coordinates into another language.
Note that may be some ambiguity in the process because hierarchical addresses themselves are somewhat ambiguous. The country property should be pretty well defined because the list is short, well-standardised, and has many implications. But if your GPS coordinates are in New York City, will locality return “New York City”, “New York” or “Manhattan”? In some countries the outcome of text > coordinates > text may thus not give you the same answer as a classic text > text translation. But any answer should still be pretty correct from a human perspective.