This is my problem. I have this simplified chinese and spanish translations that I am about to add to my application. When adding these localizations to my app I am presented with a list of locales like
Simplified Chinese China
Simplified Chinese Macau
Simplified Chinese Hong Kong
Simplified Chinese Singapure
Traditional Chinese China
Traditional Chinese Macau
Traditional Chinese Hong Kong
Traditional Chinese Singapure
and I have also an option that is just Chinese.
The same happens to spanish, a lot of specific spanish options plus just spanish.
How does this work? I mean, is this option Chinese a kind of "wild card" that will work for all people speaking chinese, independently if their devices are set for tradidional or simplified in any country speaking chinese?
You can read all about the variations of Chinese here: Varieties of Chinese. Bottom line is that different variants relate to geography and geopolitics, so be careful and make sure the translation you are getting is one you want.
The situation is similar with Spanish. Plain ("es") is presumed to be European Spanish. See Spanish Dialects and Varieties for more info.
To your question, "ES" is generic, in the sense that it will be the fallback Spanish language on the device. If you only have a localization for ES, then that localization will be chosen whether you select "Spanish" or "Spanish (Mexico)". From linguistic standpoint, the common meaning for "ES" is European Spanish.
With Chinese, the story is a bit different. There is no generic Chinese to fall back to. If you intend to target mainland China, go for Chinese (Simplified). If you want to target Chinese population outside China, simplest choice is Chinese (Traditional).
Related
I have been trying to implement Latin America Spanish language support and I am not supporting the Spanish variant of Spain. How do I separate these two? I thought, es is for Spain variant and es-419 for Latin America Variant. so I added es-419 but my localised string is showing up for es variant as well.
According to https://en.wikipedia.org/wiki/Language_code
es – Spanish, as shortest ISO 639 code.
es-419 – Spanish appropriate for the Latin America and Caribbean region, using the UN M.49 region code
I can't reproduce any issue.
Here's how I tested. I localized my app for English (the base) and for Spanish (Latin America), aka "es-419". I have a Localizable.strings file, and it exists in both localizations.
So:
if I run under English, I get my English string
if I run under Spanish (Latin America), I get my Spanish string
if I run under Spanish, I get my English string — and that is what I expect, as I am not localized for that dialect
So it seems to me that this works as expected. I'm not reproducing any issue as described by the OP.
I don't know about iOS localization but I think I can help clarify the problem
you see, the code es alone just refers to the Spanish language in general, it doesn't specify any variants.
the code for Spain variant of Spanish is es-es,
where the second "es" means Spain
so maybe you can see if your localised string is showing up for the es-es variant? if it doesn't then maybe the problem is solved :)
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?).
I'm currently in the process of localising my iOS application. When I go to my project, under the localisation menu when I click the + button, I get a list of languages to pick from, for example French (fr). Also, at the bottom of that menu there is a sub menu titled "other", that menu has loads more languages to pick from, but they are all like French Belgium (fr-BE) and English Canada (en-CA). Can someone please explain how this works and what the difference is between French (fr) and French Belgium (fr-BE) ?
Thanks.
In such a locale string, the first two letters describe the language, the second two letters describe the region.
The same language may be spoken differently in different regions. I'll assume from your username that you are most familiar with the English language. In English, there are significant differences between the same language as used in different regions. Some of those are:
vocabulary: in en-GB "boot" is the storage room in the back of your car, in en-US, it's something you put on your foot, the car thing is called "trunk"; in en-GB, "football" is a sport where you play a ball with your foot, in en-US, it's a sport where you play an egg with your hand.
spelling: color–colour, favorite–favourite, program–programme, …
pronunciation: in en-GB, aluminium is pronounced aluminium, in en-US, it's pronounced aluminum.
Localization is also about much more than just the language. It's also about currency (pound vs. dollar), date formats, number formatting, phone number formatting, address formatting, collation, etc. All of those depend much more on the region than on the language. In fact, in regions with multiple languages (e.g. Switzerland, Belgium), they will usually be the same across languages.
Now, since you asked specifically about Belgium: Belgium is a tri-lingual country, and even though there is a sharp divide between the three regions, the languages influence each other. So, the French spoken and written in Belgium is heavily influenced mostly by the Dutch spoken and written in Belgium, which the French spoken in France isn't. The French spoken in Canada, because of the great distance to France, has developed independently of it, and is in some ways closer to what was spoken in Revolutionary France than today. Ergo, it makes sense to distinguish French as spoken in Canada, France, Belgium both from each other as well from "French in general".
They are different versions of French. The English you hear in the UK is different from the one you hear in USA or in Canada. Apple gives you the possibility to be as precise as possible with localizing a language.
I am doing R & D on this Topic. How can I change any language of my application from English?
For example, My Application is in English and now I want to change it in to any local language like Hindi, Gujarati, Sanskrit. So is it possible with iPhone/iPad. If yes then please give me brief idea. I know the localization but don't know it support other languages or not?
The list of supported languages is listed here:
http://www.apple.com/iphone/specs.html
English (U.S.), English (UK), French (France), German, Traditional
Chinese, Simplified Chinese, Dutch, Italian, Spanish, Portuguese
(Brazil), Portuguese (Portugal), Danish, Swedish, Finnish, Norwegian,
Korean, Japanese, Russian, Polish, Turkish, Ukrainian, Hungarian,
Arabic, Thai, Czech, Greek, Hebrew, Indonesian, Malay, Romanian,
Slovak, Croatian, Catalan, and Vietnamese
Although this list changes with new OS releases.
For more information about localising an app, you should take a look at the Apple documentation:
http://developer.apple.com/library/ios/#documentation/MacOSX/Conceptual/BPInternational/BPInternational.html
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).