Language Codes and Locales
When choosing the source and target language codes, there are a few things to keep in mind.
Transifex currently supports over 450 language locales. Different language codes for the same languages are used in Transifex because they have to do with different frameworks that our customers use.
There are some languages that vary depending on which region it is spoken in: for example, English in the US is not the same as English in Australia, or French in France is different from French in Canada.
So our first suggestion would be to be as precise as possible and use a full locale property (e.g. “fr_FR”) instead of just a generic language (e.g. “fr”). It supports alternate spellings, date formats and other differences between two countries with a shared language.
It is especially relevant for languages like Spanish, French and Portuguese that have a distinct locale difference (Spanish in Spain vs. Spanish in Latin America, French in France vs. in Canada, Portuguese in Portugal vs. Brazil).
If you know that you’re targeting the European market at this time, it probably would make sense to set “es_ES” as a target language. There is a high chance that your company will grow and you’ll expand into the Latin American market, so down the road you would need a new language to be added to your Transifex projects, specifically for the Latam Spanish (“es_419”).
So if you have clear distinction from the beginning, it will be easier both for your internal teams and also translators/vendors to always know which language dialect they’re translating into.
Make sure that you and your team that will be managing content in Transifex stay consistent with the choice of languages, as it is linked to important features in Transifex - such as Translation Memory and Glossary.
Transifex treats language codes “en” and “en_US” as different languages, so you need to make sure that you choose one (e.g. “en_US”) and use it as a source language across all projects.
The same applies to choosing a target language: if you chose “es_ES” for European Spanish, stick to it and use it across all projects; don’t use generic “es” in one of the projects.
Following these two simple guidelines will help you keep things organized and manageable. What we're trying to avoid is the situation when you'll have to explain to your internal teams and/or translators: Look, in our iOS project, although it says “es”, it’s actually LatAm Spanish; while in the Android project, there is a separate "es_419" target language - this one is for LatAm Spanish and then there is also “es” but that one is for European Spanish.
Be precise and consistent and it will be easy to manage your languages and translations!