I am trying to localise strings to es_US (Spanish in US).
I have string resources in folder values-es-rUS and language on device is set to Español (Estados Unidos), Locale.getDefault() returns es_US.
Even when everything seems to be correct, app doesn't pick up strings from values-es-rUS but it falls to values.
Did someone make it work?
EDIT: Solved. Can't mark my answer as accepted now.
Problem was in gradle build file configuration. I use resConfigs "en", "es" so build can exclude other resources. It seems that "es" excludes also "es_US".
When I changed it to resConfigs "en", "es_US" it started to work
Folder should be placed in res/values-es_rUS
strings.xml files must have same names in all strings localized
*
From here (table 2 - section 2)
Language and region
The language is defined by a two-letter ISO 639-1 language code, optionally followed by a two letter ISO 3166-1-alpha-2 region code (preceded by lowercase "r").
The codes are not case-sensitive; the r prefix is used to distinguish the region portion. You cannot specify a region alone.
This can change during the life of your application if the user changes his or her language in the system settings. See Handling Runtime Changes for information about how this can affect your application during runtime.
See Localization for a complete guide to localizing your application for other languages.
Also see the locale configuration field, which indicates the current locale.
http://developer.android.com/guide/topics/resources/localization.html
I'm sure you've looked at this, but it has everything you need on it. I followed the instructions step by step and was able to localize my strings.
Perhaps you named your values folder incorrectly? That would be my guess
Related
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 would like to know the difference between the following
values-b+de
and
values-de
These both folders are used for localization. The way that you have implemented both values folder will be select the country code of the "de" language.
In values-b+de folder you are passing the language code as null so it will select the default language code and in values-de you are the call for default language code.
Creating the directory, the format is as below.
<resource type>-b+<language code>[+<country code>]
For more details, you can go to this link
Actually there is not difference between them as you write them.
The values-b convention was introduced in Android 7 (API level 24) in order to Improve the resource-resolution strategy as mentioned here:
https://developer.android.com/guide/topics/resources/multilingual-support.html#postN
And here also:
https://developer.android.com/training/basics/supporting-devices/languages.html#CreateDirs
Example:
For Spanish in general you will have resources in values-b+es folder.
But if you want these resources to make influence only for Spanish in Latin america you will have to place you're resources in values-b+es+419 (which was values-es-rUS in the old convention).
App i am working on supports Indonesian locale, I do have
"values-in"
"values-in-rID"
resource folders.Both contains strings only.
I didn't find any info regarding "values-in-rID". i can see its getting used here too in android sdk
values-in means Indonesian Locale, and in all regions.
values-in-rID means Indonesian Locale, but applies only in the region of Indonesia. The r here means region.
The following screenshot should make things clear.
These are language and locale codes. For example, French in France is not entirely the same as French in Canada, so you might see fr-FR and fr-CA used to differentiate them instead of just using fr.
Android has a resource fallback mechanism that uses this folder naming pattern. Imagine your app has language resources for French(France) in a folder values-fr-rFR, resources for French(Switzerland) in a folder values-fr-rCH and resources that are the same for France and Switzerland in a folder values-fr. For the app locale French(Switzerland) Android will first attempt to load resources from the values-fr-rCH folder and then fall back to values-fr. See here for further details.
So, the folder values-in-rID contains resources for usage in Indonesian as spoken/written in Indonesia. Whether this approach makes sense for Indonesian or not I don't know: it certainly does if a variant of Indonesian is used outside of Indonesia. Anyway, make sure to provide a set of default resources as well as your Indonesian resources, as described here.
I am trying to localize my app and have a few doubts. i have translate strings in spanish language and i am trying to be very specific with Region codes, so I named the folders as values-es_rES, values-es_rUS and values-es_rMX. Now there are more countries and users who like to use spanish language so i created a generic values-es folder.
I am wondering can android automatically push all mexico, US and Spain users to respective languages under their region codes and can others like chile, peru will be shown values-es language rather than my default US English?
You have two options
Use the language-region locale (ie. es_ES for Spanish/Spain or es_PE for Spanish/Peru)
Use MNC/MCC codes in your resource folders, which will take presence over the locale ones.
The way you have described it, all users with a defined locale of es_XX (any region) will go to your "values-es" folder, but the US user will not, unless the US user has configured "es_US" as their locale.
Take a look at Table 2 at
http://developer.android.com/guide/topics/resources/providing-resources.html
Remember that if an asset is missing from "es_ES" it will get it from "es", so only change those that are different.
I would like to provide support for the Flemish language in my Android app, but as per ISO 639-1 there is no separate code for this language. How can I then do this?
Bear in mind that the resource qualifier can combine language and country. Although Dutch and Flemish are both ISO 639-1 nl, you can attach a region qualifier as well to further specify the region.
The documentation provides an example for British English:
Also, you might not need to create alternative text for every string. For example, assume the following:
Your application's default language is American English. Every string that the application uses is defined, using American English spellings, in res/values/strings.xml.
For a few important phrases, you want to provide British English spelling. You want these alternative strings to be used when your application runs on a device in the United Kingdom.
To do this, you could create a small file called res/values-en-rGB/strings.xml that includes only the strings that should be different when the application runs in the U.K.
Similarly, you could provide this for Flemish by specifying the resource directory values-nl-rBE.
If the language got no code, then you got rather no other way to "hijack" the code of other language or write own localization engine (or use something existing, but not the framework's one). As for hijacking the existing code, simply pick up that one that your user are most unlikely to face in real life and put your translation there.
using nl-rBE (dutch as used in Belgium) worked for me.
(r is required per the Android localization reference--the r denotes "region".)
http://www.localeplanet.com/icu/nl-BE/index.html