I've created a values-he folder with strings.xml file identical to the default strings.xml with translated string values, but running the app both on a Hebrew selected real device and on a Hebrew selected AVD still shows the default English texts. Any ideas why?
EDIT: this was answered - in some cases, Hebrew included, some android devices support deprecated language codes. For Hebrew the old 'iw' code is still supported on some devices instead of 'he'.
This is known to be the case in some other languages.
From the Android Locale class it's said:
Note that Java uses several deprecated two-letter codes. The Hebrew ("he") language code is rewritten as "iw", Indonesian ("id") as "in", and Yiddish ("yi") as "ji". This rewriting happens even if you construct your own Locale object, not just for instances returned by the various lookup methods. Also some devices use he for hebrews too so to be compatible with use both values-iw and values-he
Starting Summer 2021 Google now requires you to upload the bundle (.aab) instead of the .apk file. With that change, if your device does not support a specific language, it will not be downloaded from the Play Store.
Check the solution here.
Related
When you want to add locale-specific resources in Android, you have to add the lowercase ISO-3166-1 code of the language to the resource folder's name. So far so good.
Now I want to add Catalan and Basque strings to my application. According to the ISO list, I would have to add values-ca and values-eu. But will that work, actually?
Edit: With a custom language chooser in your app, you can provide support for languages even when they're not in the device's settings menu. I've made the library that I use for this available on GitHub:
https://github.com/delight-im/Android-Languages
I don't know if Android supports all ISO codes and if these "minor" languages will be displayed at all. If Android is not available in these languages, perhaps the device will not even recognize this language as its default locale and just use es for Spanish.
Can someone help?
Many devices ship with a limited selection of languages in the settings menu, but can actually be set to any system locale using an app such as LocaleSwitch.
It should be pretty easy to test whether Basque is supported by adding a custom locale in LocaleSwitch and then adding the resource folder to see if the system loads the resources from this folder automatically.
Finally, Gingerbread 'support' for Catalan may only reference the inclusion of android.R values since 2.3, though I can't see them in the framework repository.
Actually not all languages are documented at Android docs and many brands did your custom version of Android which may change its list, but be sure that if a device has Catalan and/or Basque suports it will use ISO standard, and the values will got rigth as it is converted with string comparision.
Maybe it would be a good choice to put a handed changer if you got that most devices do not have this support on your tests.
The thing is, if the language is not listed in the language selection list on the device, the resources can never be used as the device can never be put in this configuration by the user.
On the other hand, if the device allows you to select Basque, it will be using this format, and your resources will be used.
We can now create our "values-eu-rES" folder and have our app in Basque, Android Lollipop has made it.
We can create a folder
Basque strings ->
value-eu [Basque]
another folder
Catalan strings ->
value-ca [Catalan]
Adding a new language in LocaleSwitch, you need to type the ISO 639-1 code. For instance, if you want to switch to basque you need to enter "eu". Afterwards, you will see the new locale as "vasco".
That makes me think that basque locale is supported by android.
Not picking up values from values-de-rCH/strings.xml but from values-de/strings.xml.
My device locale is set to de-CH and the same is confirmed when I debug the code at some place for loading a JSON based URL config file for other purposes...
Android has different resolution scheme for string file prior to 7.0 and after.
You can find the reference at Android developer website
Language and locale resolution .
Also if your app support different language (not same language but different country) it is better to create folder with language code only. e.g. values-de.
For detail description of naming directories explained at Support different languages and cultures.
https://blog.egorand.me/a-curious-case-of-multiple-locales/
https://developer.android.com/studio/build/shrink-code
According to the above 2 links, it asked me to mention my new region-specific locales e.g de-rCH, to the resConfigs, or set the resConfigs itself as auto. In both cases, it worked for me. I was kind of stuck in this for almost over a week now.
Thanks for your help guys...
I'm working on localizing an Android app.
For arguments sake, let's say the app will support English, Albanian, and Bengali.
Currently all English strings are listed in the "default value" column of the translations editor:
Apps on the app store generally state what locales they support.
I'm assuming when you submit an app that either a person or machine verifies your claims... so...
Is it necessary to explicitly add English (en) locale/column in addition to the default values (just as Albanian and Bengali have been added in the photo) in order for the app to be considered to officially "support" English?
You do not have to add English locale to have it in Supported Language menu. Check documentations out.
When your Java code refers to strings, the system would load strings from the default (en_US) resource file, even if the app has Spanish resources localized under es_ES. This is because when the system cannot find an exact match, it continues to look for resources by stripping the country code off the locale. Finally, if no match is found, the system falls back to the default, which is en_US.
The system would also default to en_US if the user chose a language that the app didn't support at all, like French.
Default locale is en_US.
No.
Apps on the app store generally state what locales they support.
If you are talking about Apple's App Store, Google Play won't list the supported languages in similar fashion.
However, you can localize the store listing page. According to play console help, If a user's language preference matches the translation languages you've added, they'll see your app's translated version. You can also add localized graphic assets for your store listing pages. See this for more. This feature is similar to App Store's metadata localization.
There is an easy solution to your problem.
Just find the path in your project:
res/
and add a folder named:
values-en
Then add a file named:
strings.xml
Finally, it will look like this:
res/values-en/strings.xml
And the resources in it will show when the user's language setting is English.
I'm working on an application that has localized strings for the UK, specified in res/values-en-rGB/strings.xml. My default string implementations, for the US, are in res/values/strings.xml.
Now, I'm adding additional localizations for Canada in res/values-en-rCA/strings.xml. I would like the application to behave as follows: If a user's device is localized to Canada (or their language is set to English(Canada) or French(Canada)), check if we have a string in en-rCA, and if not, fallback to the string in my default strings.xml file. However, my application currently fallbacks to strings from en-rGB when the device is set to a Canadian locale and the string is not found in en-rCA. Therefore, I have two questions:
How can I configure my app such that a device with a Canadian locale searches for a string in en-rCA and then, if it cannot find it, defaults to the string in my default values folder rather than en-rGB?
How can I ensure that a device whose language is set to French (Canada) defaults to en-rCA rather than my default values, as it currently does?
I would be happy to provide an example if it would be helpful. Thanks!
Finale Update:
After opening a bug report on Google Incorrect resource resolution strategy above Android N, defaulting to en_GB and not default strings.xml, they mentioned that this in the intended behaviour for Android N above. en_UK is considered "a representative of International English". The strings will fall back to "International English" strings or its representative before going to default en strings. I'm quoting their reply here:
Starting in N, all English locales (except for US and US territories like Puerto Rico and American Samoa) fall back to some International English variant if such a locale is available.
So for en-CA, we would try these locales first, before falling back on en-GB (which is considered a representative of International English if there is no better International English locale): en-rCA (Canadian English), b+en+001 (International English), en (English).
If you don't want en-GB strings to be picked up for en-CA, you should put resources in one of those three directories, as they would be considered a better match for en-CA.
Update 1:
It seems this is not just limited to en_CA. There is another similar question for other English locales : Android 7.0 Nougat picks up default strings when device language is en_US. Looks like a platform bug at this stage.
Original Answer:
Not sure if its a bug or a feature. From API level 24 (Android 7.0), they've updated how Android resolves strings as mentioned Improvements to Resource-Resolution Strategy
. Taking an example from the documentation below:
Before Android 7.0:
Lets say if the user has settings of fr_CH and following are the resources available in the app i.e de_DE, es_ES, fr_FR, it_IT. For older API's before Android 7.0, Android tried to find an exact match and if an exact match isn't found it defaults to the values/strings.xml, i.e en. So for en_CA case, if a string is not found in res/values-en-rCA/strings.xml, we can expect it to default to en.
After Android 7.0
However now in Android 7.0 and above, for the situation of fr_CH, it will fall back to the closest parent dialect i.e fr_FR.
Applying the same logic to the situation of en_CA and en_GB present in the app, I'm thinking that Android thinks that en_GB is the closest dialect to en_CA and is falling back to it instead of the default en first. I am facing the issue in my app and that's the only plausible explanation I can come up with of why this issue happens only on newer API versions and not on the ones before Android N.
Should happen automatically, without you doing anything. If you have values/strings.xml, values-en-rGB/strings.xml and values-en-rCA/strings.xml with the GB and CA versions containing only those strings that differ from the baseline (values/strings.xml) and if the user has his locale as en-CA, the system will load strings from values-en-rCA/strings.xml if not found, it'll fall back to values/strings.xml, the GB version wouldn't come in the picture.
For this you'll have to locally change your app locale. Basically you get the current locale, if it is fr-CA, you manually set the locale to en-CA
Locale enCALocale = new Locale("en", "CA");
Locale.setDefault(enCALocale);
Configuration config = new Configuration();
config.locale = enCALocale;
getBaseContext().getResources().updateConfiguration(config, getBaseContext().getResources().getDisplayMetrics());
Update
As Shobhit mentioned, starting Android N, you can now have a list of locales selected in the setting and you can decide their priority:
In the above case the system will try and look for en-rCA/strings, if not found it'll look into en-rGB/strings instead of baseline, something that happened before N.
If I added Slovak (SK) language (values-sk-rSK and values-sk) to the Android Wear 1.5 apks (framework-res.apk also), language wasn't set to SK automatically even I had SK on the phone.. so for change language on the Wear watches is needed to translate also Wear app on the phone to SK lang..? Or why my translation wasn't loaded on the watches..?
I have a lot of experiences with adding translation into the Android ROM for phones, but seems it works differently on Android Wear...
Thank you for any help...
As stated in this Localization Tips: Design your application to work in any locale documentation, if your application is missing even one default resource, it will not run on a device that is set to an unsupported locale.
For example, the res/values/strings.xml default file might lack one string that the application needs: When the application runs in an unsupported locale and attempts to load res/values/strings.xml, the user will see an error message and a Force Close button.
You may also check this link which explains challenges in resolving Language resources. Be noted that when your Java code refers to strings, the system would load strings from the default (en_US) resource file, even if the app has Spanish resources localized under es_ES. This is because when the system cannot find an exact match, it continues to look for resources by stripping the country code off the locale. Finally, if no match is found, the system falls back to the default, which is en_US.
Here's a related SO thread which might help.