Localization, Locales, and XLIFF files

Localization works by having two folders under StreamingAssets: CSV and XLIFF.

• The CSV folder contains .csv files for each supported locale.
• The XLIFF folder contains folders for each supported locale. Each folder contains a bunch of .xliff files, each containing the strings for each LocalizationTable as defined in Unity Editor.
• Two exceptions: English (en) and German (de) lack the *.OriginalStrings.*.xliff files. These files contain mission, cutscene, credits, intro, tour crawls, etc. texts that come built-in with the original data files in the English and German editions of the games. Only locales other than en and de have OriginalStrings .xliff files to provide these texts translated.

Use Case A: How to add a new localizable string that is ONLY used from the C# code

1. Choose an existing .xliff file in the English (en) folder that makes sense for that string. (Notice some of them have an game-dependant version, only loaded for that game).
2. Create a new <unit> element at the end of the file, but inside the <file> and <group> elements. That is, a sibling of the last <unit> element. It's simplest to copy/paste an existing <unit> just after.
3. Set the id attribute to a uniquely identifiable localization key that you will reference from the C# code.
4. Set both the <source> and <target> contents to the text in English for this string. Read the documentation for SmartStrings if you need the string to have variables, be declensed or matched in genre or number, etc. (Remember that you shouldn't play Legos with strings in code to form sentences even if it'd make sense in English, because other languages need the parts of the sentence in different order, etc). Yes, both the <source> and <target> elements must have exactly the same repeated text.
5. Copy that new <unit> you have created and paste it after all the existing units of the same file for all other locales. If you are nice, you will translate the <target> element's content to that language. Or you can leave it in English. But then remember to notify the translator of that language that this file now has some more units to translate at the end of the file! Keep the <source> element's text in English. It is to be there as reference. Only the <target> element's content is to be translated.
6. Now, you can make use of it in the C# code by using the functions from LocalizationManager that let you select a table and a key. As table, use the one matching the file name. As key use the id you used for the <unit>.

Use Case B: How to add a new localizable string that is ONLY used from a UI widget

You must follow these instructions if you are adding a string that is to be placed on a button on the UI, and that text is not altered by any C# code. It is just sitting there, but should be localized.

1. Open the Window/Assets Managemenr/Localization Tables editor in the Unity Editor.
2. Select a table that makes sense to contain that string.
3. Add a new entry, give it a good key name.
4. Give it an English text box content. It can be a palceholder one for now or even be left empty. The definitive text will come from the .xliff file, not from here. You can ignore the German text box in this interface.
5. In the UI widget (button, label, etc), use a LocalizeStringEvent component to make that widget's text automatically pick the text from that LocalizedString. You will need to select the table and key you used in the Editor.
6. Then, you must now follow the same steps as in Use Case A, but the .xliff file to choose is the one that matches the table where you added the string in the Editor. And the <unit>'s id attribute must match exactly the entry name you wrote in the Editor.