Say you have a localized resource that is in en.lproj and Base.lproj. If someone runs the app in, say, Spanish, is the Base.proj resource loaded over the en.lproj one?
Generally, what happens when an resource for the user's preferred language is not found, and when does the system fall back to Base resources?
Base is used whenever the translation for the user language is not define. Including if you have done 99% of string transition to "French", and you should display one of this 1% left on a French iPhone => the base will be use.
I like to have base = english. If a user did not have is natural language translated, he will se the english version.
Some people think different. We all have our reason ;-)
They said, use "code" for base, if you miss to translate you will see code instead of english. Easy to "debug" missing translation.
I said, if you miss to translate a string, the user will see the english version. He will probably said "Oh no ! again this english ! This soft is not well translate !". I already be in that situation 1000 times may be more. Nethertheless, I was able to translate the english sentence to my natural language... not sure to be able to translate a "code"...
If none of your defined languages is not equal to the one which the user has its phone language, then the Base takes place.
Suppose you have 3 localizations, english, spanish and french, and of course you have your based localize. If french or spanish or english are not the phone language, then the base specified by you will be set.
Related
I have an application that currently support 'en' and 'fr' locales, and maintain one language file for each locale i.e. 'en.json' and 'fr.json'
Now for the user from USA, locale comes in as "en_US", Canada 'en_CA', British 'en_UK' etc.
So now as a best practice, is it recommended that I maintain different files for different English Locales or I treat all English locales (en_CA, en_US, en_UK) as 'en' locale and refer to one file for all?
As usual, it depends.
Typically, you will only have one English file, containing English-international messages. In this case, you won't maintain separate files for each version, but instead you will fall back to English international (having a request for en-US, en-CA, etc. you will serve messages from en.json).
Judging by your nickname, you probably know that sometimes it is better to maintain separate messages for some specific cultures for which English-US messages (typically used as international English) might be simply way too direct.
If there is a request for separate locale version (i.e. en-IN), you would serve messages from the specific file (i.e. en-IN.json), but fall back to en for each other language (en-GB, en-AU, etc.).
Resource fall-back (which is the term specialists use for what I described above) could be quite painful to implement. Sure, usually you would fall back to base language (en for any en-XX), but there are some corner cases which you need to know: Portuguese/Brazilian Portuguese, Norwegian and Chinese. In case of Portuguese you should use pt-BR (i.e. pt-BR.json) and for requests to pt or pt-XX fall back to pt-BR, as Brazilian Portuguese is now the standard one. Obviously, it could be easily done by simply creating one file pt.json and let anything fall back to pt.
This is not the case for neither Norwegian nor Chinese.
There are two versions of Norwegian language:
Norwegian Nynorsk (locale nn-NO)
Norwegian Bokmål (locale nb-NO)
There is also so-called macro language (locale no).
Unless you maintain two separate versions of Norwegian (which is unlikely), you should use one resource file (i.e. no.json <- sounds funny, isn't it?) and fall back to it for any requests for nn-NO, nb-NO, nb, nn and no-NO (I believe simply no will be covered).
The Chinese is even more complicated. You may have heard about Chinese Simplified (locale zh-Hans) and Chinese Traditional (zh-Hant). If you'll ever need to localize into Chinese, it make sense to maintain two separate Chinese files (i.e. zh-Hans.json and zh-Hant.json) and fall back any requests as follows:
zh, zh-CN and zh-SG to zh-Hans
zh-HG, zh-MO and zh-TW to zh-Hant
I hope it gives you better understanding. It is worth to consider future localization plans to implement the resource fall-back mechanism as simple as it could be done (but no simpler). If you'll ever need to support languages like English, French, Italian, German and Spanish, there is no point in implementing complex rules - simply check if xx-XX.json exists and serve it if it does, if not check if xx.json exists (serve it...) or fall-back to default application language (en.json, I guess?).
Lately I have been trying many different keywords in an attempt to find a good search niche for a new game project I've taken on. Running out of ideas, I've started trying seriously random words. Occasionally I forget to update all of the localizations at once, and only update the UK English localization, and this has led to odd behavior.
Currently, I do not have an "English" localization for this game, but I do have a UK English localization which is set at the "Default". However, the UK English localization's keywords are not being used in the US app store, even though the UK English localization's description is used.
I can tell because I tried a few keywords completely unrelated to my app, words not used in my description, or app title, and completely unrelated to my game but when I changed the UK Localization to remove them about a week later, I forgot to change the many other localizations. The other localizations include French, German, Italian, Japanese, Korean, Russian, Simplified Chinese, Spanish, Thai and Traditional Chinese.
This leads me to believe that the keywords and descriptions of localizations are handled very differently by the app store search engine.
I can think of three possibilities for when you lack a certain localization:
• Keywords from all localizations are used for the store that doesn't have a localization. (This doesn't seem likely, I don't rank for "的朋友" for example even though it is a keyword in my Chinese localization)
• Keyword list is chosen at random from available localization (Also doesn't seem programmatically likely)
• Keyword list is chosen from first list in alphabetically sorted localizations list (Possible, as French is the first localization alphabetically and did still hold these unrelated keywords)
Has anyone seen similar behavior, or could maybe shed some light on what's going on here?
OK so I have been working on an app that will be available in multiple languages.
I have managed to get it working in the main languages, such as French, German, Spanish and English.
I have also now managed to get the app to use different regions within a language such as en_GB, en_US etc etc so all is good - thanks to this guide:
http://hamishrickerby.com/2010/07/23/iphone-ipad-localizations-regions/
One of the most important languages for me is Welsh. Apple allows me to set my iPhone to welsh by choosing British English as my language and region format as Welsh (United Kingdom).
I have created the Welsh language localisation within my app and translated my bits but I don't seem to be able to apply it.
My idea was that if the users language was set to British English that I could have a button on the main view that would allow the user to chose Welsh. Is this possible and what would be the best way to implement it.
Ideally if the user has already set their language to British english and has the region format to welsh they will get the welsh language version of the app just like the french would automatically get the french language version and the spanish will get the spanish version of the app etc but as most welsh speaking users will have their phone set to United Kingdom as they are not aware of the Welsh Region setting in iOS.
I would like the app to detect if the current language is British English and display a button on the home screen where the user can switch to Welsh Language. I have managed to display this button (only if user language is British English) but have no idea how to link it to change the language?
Anyone have any ideas or maybe a suggestion on the best way to implement my goal.
Thanks in advance.
Unfortunately, as you've identified, Welsh isn't a fully supported language on iOS. Until Apple supports it properly, you'll have to implement a bit of a workaround.
It seems as though the main solution is to have both English and Welsh .strings files (like you would with other languages), but manually load the required language, using
[[NSBundle mainBundle] localizedStringForKey:yourString value:#"" table:#"Welsh"];
#"Welsh" could be another language there, depending on what you want to load. You'll have to implement some control within your app so that users can change the language themselves. Check out the example project linked to in this blog post by translation company Applingua - it shows one way of encapsulating this code into a language provider class.
I am uploading a new App which is localized in 10 languages to the Apple AppStore.
Apple offers several languages with country specific options such as
Canadian French
Mexican Spanish
Brazilian Portuguese
We have set up localizations for French, Spanish and Portuguese.
On the iPhone, an App defaults to the closest language available. For example, an iPhone set to "Brazilian Portuguese" will use the regular Portuguese localization instead of the English default localization.
Is it the same on the AppStore? Do we need to also set "Mexican Spanish" or will customers from Mexico default to Spanish (instead of the defaulting to English)?
edit:
To clarify, this is not about whether we should localize to these dialects (we already decided against that when making the app), but whether the store page shown to the customer will be displayed in the closest dialect or english.
For example, will a Mexican user automatically see the Spanish version (the closest language) or the default language (English)?
I can confirm that the closest available language is selected by the App Store.
For example in the Mexican App Store if you have Spanish set up but not Mexican Spanish, Spanish will show up. This app has Spanish activated on iTunes but not Mexican Spanish and everything is in Spanish on the Mexican App Store.
https://itunes.apple.com/mx/app/id502222888
The language that is displayed on the App Store depends also on the user's language settings since they set the language query parameter. The URL format used by Apple with the language query parameter is:
https://itunes.apple.com/tw/app/id502222888?l=zh where tw is Taiwan and l=zh is the Chinese language.
The language query parameter is not always used.
For example in Germany, even if you set the another language via the query parameter it will be ignored and the German language will show up since it is the only language for that location:
https://itunes.apple.com/de/app/id502222888?l=fr
While in Canada that has both English or French, you can use the language query parameter:
https://itunes.apple.com/ca/app/id502222888?l=fr
To answer my own question: No, Apple does not automatically choose the closest language on the AppStore.
Here is an example of the Mexican AppStore using English despite standard Spanish being present:
Let's start with Spanish. As far as I know Spanish (Mexico) is considered International Spanish, which is fairly similar to English (USA).
I don't know about French, so I might be wrong here but I believe French (France) would be perfectly understandable by the Canadians.
As for Portuguese... Well, in this case you did something that I believe should be the other way round. I read on the Internet that Portuguese government (?) recently pass a reform so that regular Portuguese would be similar in terms of grammar with Brazilian Portuguese. You see as Brazil is much bigger country, Brazilian version is much more common. Therefore I don't think it is OK to use regular Portuguese in Brazil (there might be some problems) but it is probably just about right to use Brazilian Portuguese in Portugal.
There is also the case of Chinese. As in Simplified vs Traditional. If you ever going to localize your application into Chinese (not the easiest thing to do), Traditional is the one to be used in Hong Kong, Taiwan and Macao whereas Simplified is the one they use in China (mainland) as well as in Singapore.
It would be very inappropriate to confuse them (i.e. try to sell Simplified version to the Taiwanese).
I'm creating an English translation for a program written in German (i.e. all strings within tr("...") are German). Users who are in a non-English non-German locale will probably want to see the English translation, but with the program as it is now they will see German.
There are some ways to solve this problem:
Check if it's a German locale and force to English otherwise.
Present an option to the user.
Make the programmers change their source code to English.
What is considered best-practice for internationalizing where the source code is not in English?
These are two separate questions.
The best practice is to not use any kind of hard-coded string in the sources.
Strings should be stored in external files and loaded by ID.
But what you have there does not sound like the best practice. Might be too much work to get it there.
What you describe (the tr("...") stuff) sounds like gettext (or something similar).
That approach for gettext (and similar libraries) is that "the stuff in the sources is the ultimate fallback", used if the strings for the desired language are not present.
In this case I would go with "Present an option to the user."
You can't assume the user knows English.
Real example: in Switzerland the official languages are Italian, German, French and Romansh. If I ask for French and it is not present, then the next best option is probably German, not English. I Canada the official languages are French and English, so if I as for French and is not available, the next best option is probably English.
I think the best option is asking the user (during installation probably).
Change the source to English is too costly and not worth it. I live in Brazil, we have tons of codes in Portuguese and translating to English wan't necessary one time (we do make software to english speakers). Unless you have a client that requires you to do so (usually when you are selling the source also).
Hope it helps
OK, so I guess the three options are:
Recompile the program with translated strings.
This is fraught with danger as you'll end up with two copies of the source. Bug-fixes in one will need to be done in the other. And then, what happens if you need French? Italian? Spanish? The only advantage of this approach is that it's feasible for a non-developer to do the work. (Just about.)
Resource out the strings, and automatically check what the UI locale is on load.
Here the strings are replaced with GetResource("key") or similar. On load the program automatically translates to the user's culture. This might work, but I know plenty of German-speakers who have English-language culture installed on their PCs but who would prefer German language programs at some points.
Resource out the strings and give the user the choice on load
In general it's always best to give the user control. This might be a prompt on load, although if the application is used often this can be an annoyance. Perhaps a balance is to ask the user during installation for their preference and then give then an option in a dialog to later change this setting.
Note, by the way, that translation is not localisation. For instance: number formats are quite different in Germany (e.g. 1.233,44) from English (e.g. 1,233.44). Icons and suchlike often have national characteristics.