Resource Localization

The Basic Rule

Unreal Engine 3 supports text localization with respective ini files for each language in the "Localization" folders. For binary data, localization is based on providing different versions of the same packages for each supported languages. Each language has its three letter code, and a package file for a certain language has to postfix its filename with the code. When the engine loads a package, it first looks for a path extended with the current language code. If not found, it falls back to the one with _INT postfix and then the intact path. For example, if the engine wants to load A.upk and are running Japanese, it will try A_JPN.upk , A_INT.upk, and A.upk in turn. You can use this rule for most of resources, but when it comes to cooking, things get more complicated.

Notes you should make the resources in localized packages corresponding to others. If you have a resource in a package for a certain language, you should have corresponding resources in other language's. This is because only one version for a given package name is loaded by the engine at the same time. So separating localized and non-localized resources into different packages is a good practice. Otherwise, you have to make sure the consistence of the same non-localized resources in different localized packages.

Cooking Multi-language Versions

If you just want to build respective versions for each supported language, you can cook with the option of "languageforcooking" and specify a language code to cook. The engine loads and cooks packages with the forementioned rule, so resources for the other languages will not in the cooked content.

If you want to build a version for multiple languages, you have to use the option of "multilanguagecook". However, localization kind of does the opposite against cooking. Cooking seekfree packages requires merging referenced resources into cooked packages, so they can be seek-free. Nevertheless, localization requires different localized resources in respective packages for each supported language, so they can't be seek-free.

Localization of Seekfree Packages

During cooking, referenced resources are duplicated in seekfree packages except localized resources. The localized resources are duplicated in auto-generated localized packages postfixed with _LOC_ and a language code. However, only Font and SoundNodeWave with subtitles or in subfolders named by a language code in a "Sounds" folder are considered as localized resources by the engine. If you make a localized material by the forementioned basic rule, it will work in editor but won't after being cooked. However, you can override UObject::IsLocalizedResource() to make the cooker reconsider a certain resource type is localized.

Conforming Localized Packages

There is one more thing you have to do before localized cooking: conforming localized packages. This is required by the cooker. Conforming a package to antoher is to synchronize their GUIDs and name tables. If you have more than two language to localize, you have to conform these packages in a chain like conforming "CHN" to "INT", then "JPN" to "CHN".

There is a commandlet for conforming packages. Its syntax of command line is:

gamename.exe conform <to_package> <from_package>