Recently a colleague and I worked on an issue where a displayed URL was intended for another region entirely, but all the strings were seemingly in the correct XMLs. This was… very odd, yet the eventual solution does make sense!

  1. The app exists in a single market, e.g. the UK, which has all URLs etc in values/strings.xml. They display fine.
  2. The app expands into a non-English market, e.g. France, and has all new strings in /values-fr/strings.xml. They display fine.
  3. The app expands into another English market, e.g. Ireland, and has a few new strings in /values-en-rIE/strings.xml. They display fine.
  4. Uh oh, the app’s URLs in the original market, the UK, have been replaced by Irish strings (see banner)!

Our first clue was the issue didn’t occur on our emulators (set to default en-US), but did apply on our physical devices. Our next clue was strings in /values-en-rGB/strings.xml that duplicated /values/strings.xml.

The problem was the physical device’s locale being en-rGB. When Android tried to find the most relevant strings, it found en-rIE. This was the correct language, so it used those! This highlighted a faulty assumption: That a strings file for a specific region will only be used for that region. Instead, if Android cannot find a better match, a region’s strings will be used for any region in that language.

The solution was that second clue from earlier: If defining region-specific strings, make sure they are all defined for all regions, or there is one for the language itself!

Below is a screenshot of the final setup, there’s also a proof of concept repository:

Further reading / resources: