search

forrestguice / SuntimesWidget

Android app (and widget collection) that displays sunlight and moonlight times.
GNU General Public License v3.0
339 stars 61 forks source link

improve language resource resolution (BCP 47 language tags) #147

Open forrestguice opened 6 years ago

forrestguice commented 6 years ago

First couple paragraphs of https://developer.android.com/guide/topics/resources/multilingual-support.html describes the problem. Consider a device w/ system locale es_US or es_MX (while the app only provides translation es_ES). When trying to resolve the language first es_ES is tried, then es, and then it finally falls back to default en_US (failing to resolve to spanish).

A quick fix would be to move the es_ES translations into es, but this is less than ideal - suppose es_UY is added later - in this case which version belongs in the fallback es (Castilian vs Latin American Spanish), and which should use the full qualifier (arbitrary choice). Or should the es_ES resources just be copied into es (ugly duplication).

Android 24+ purports to fix this situation w/ improved resolution using BCP 47 language tags.

forrestguice commented 6 years ago

...in the meantime, I think the existing option to manually override the locale provides an effective stopgap.

verdulo commented 6 years ago

Please don't remove it! It's the only way to display the application in Esperanto!

forrestguice commented 6 years ago

Don't worry, no plans to remove the existing feature, or even touch the way most of the translations are handled. ..really just saying the existing override feature already provides a solid workaround, so not really feeling rushed to "fix" language resolution using bcp47.

The idea would be to move some files from one directory structure into another. I think Spanish is the only language where this really needs to be done.

forrestguice commented 6 years ago

...might be related. Tested on a Samsung Galaxy 7 running Android 7.0.

The app fails to override the locale to Spanish. It is working correctly for the other locales. It is also working correctly when I test it on my api19, and api15 devices. The log shows es_ES incorrectly resolving to "" (while other locales resolve correctly).