Asset Localization

Asset localization allows you to completely replace one Asset with another on a per-culture basis.

Localized Assets exist in per-culture folders under the "L10N" folder within your project Content folder. So if you have an Asset named /Game/MyFolder/MyAsset and you want to localize the Asset for French ("fr"), then the localized Asset would be /Game/L10N/fr/MyFolder/MyAsset.

The Content Browser has options to help you manage localized Assets. These can be found under the Asset Localization sub-menu. To create or manage localized Assets using the Content Browser options, you must have LocRes files available for the cultures you are localizing for. Localized Assets are hidden by default in the Content Browser. Click Settings > Show Localized Content to view them.

Localized Assets are not hot-reloaded if the culture is changed at runtime, as content hot-reloading is only available in the Editor. If you plan to support dynamic culture changing at runtime, you might need to restart your game for those changes to take effect. Restarting the game purges and reloads the localized Assets.

Assets containing bytecode (such as Blueprints) cannot be localized, as these can be nativized into C++. These Assets cannot be replaced at runtime.

Localizing Fonts

Font localization can happen in one of two ways:

• You can use composite fonts to produce a single font Asset that works for all cultures.

• You can use Asset localization to produce separate font Assets for each culture.

The second option is only recommended if your project doesn't support dynamic culture changing at runtime, and doesn't display any unrestricted user-defined text (such as player names, or a chat window). In all other cases the first option will provide a better result.

Localizing Dialogue

Dialogue localization is centered around the Dialogue Wave Asset type, which allows you to define spoken text (and optional subtitle overrides) that are gathered through the standard localization pipeline gather step.

Dialogue Waves themselves are not a full dialogue or conversation system. They simply provide a way to say "Line X is spoken from person A to persons B, C, or D", using a designated Sound Wave for each combination. The number of unique Sound Waves that you need for each language might vary, depending on the rules of the language. However, that concern is encapsulated within the Dialogue Wave. As a result, you only need to play it with the correct context, and you'll get the accurately localized result.

Unreal Engine (UE) also provides a series of utilities to aid in the recording and management of localized dialogue. You do not have to use these utilities to localize dialogue in UE, but they do automate a lot of the work.

If you use these utilities, the utilities will generate an extra per-culture file in the content folder of your localization target, called {TargetName}Dialogue.csv. Dialogue Sheets are custom CSV files that contain the per-culture lines of dialogue gathered from your Assets by the localization pipeline. They are generated by the localization export script step, and are re-imported into the archives by the localization import script step.

Keep in mind the following information about Dialogue Sheets:

• The SpokenDialogue field can be copy-edited during recording and re-imported as the current translation.

• The AudioFileName field defines the per-culture WAV file that the recorded audio for the line of dialogue should have (see below).

Once audio has been recorded from these Dialogue Sheets, the audio file should be named as defined by the AudioFileName field, and placed into a culture sub-folder (for example, MyRecordedAudio/fr). This can then be imported into UE using the import dialogue step, to produce the correct Dialogue and Sound Wave Assets (this can be done iteratively as new audio becomes available).

The default dialogue filename format guarantees uniqueness, but is not very readable by users. This can be changed using the Dialogue Filename Format setting under the Audio section of your Project Settings. The filename format you use should be decided before starting to record any audio, because it will be difficult to change later.

Due to the relatively high cost of translating dialogue compared to translating text, it is expected that dialogue localization will only begin once the script is finalized, and will follow this workflow.

1. Native dialogue is set for a line of dialogue.

2. Native dialogue is recorded and potentially copy-edited (potentially with several iterations). If copy-edited, the edited native dialogue is re-imported ready for translation.

3. Native dialogue is translated as text, ready for producing localized dialogue.

4. Localized dialogue is recorded and potentially copy-edited (potentially with several iterations). If copy-edited, localized dialogue is re-imported to ensure accurate subtitles.

Any native text changed during this process is expected to restart the workflow from step 1.

Creating Asset Groups

Asset groups allow you to create sets of Asset classes that can be assigned a different culture than the rest of your project.

A common use-case of this would be allowing the player to choose to have audio in one language, with everything else in another language. To do this, define a new Asset group called Audio and set it to use the audio classes for your project (this would typically go inside DefaultGame.ini):

	[Internationalization.AssetGroupClasses]
	+Audio=SoundWave
	+Audio=DialogueWave
Copy full snippet

[Internationalization.AssetGroupClasses] +Audio=SoundWave +Audio=DialogueWave

Now you can assign a unique culture to this Asset group, without affecting the rest of your project. See the Managing the Active Culture page for more information.