Separating localization databases

[alexander]

Hello all,

I just finished reading the localization documentation and noticed that all localization strings are contained within the same database.

This, obviously, comes with a large memory overhead which might be irrelevant on a desktop system but can pose an issue on mobile devices given a large dialogue based data set.

Is it possible to separate these into separate assets and use the addressable system to swap language sets on the fly in order to only have a single string database loaded to memory instead of all, all the time?

Regards
Alexander

[Tony Li]

Hi Alexander,

Before you go to the effort, judge whether it's necessary. Text is small. A typical dialogue database takes the same amount of memory as a couple of textures.

If you do determine that it's necessary to separate databases, use DialogueManager.RemoveDatabase() and DialogueManager.AddDatabase() to swap out databases.

A database is just a ScriptableObject asset. If you mark it as addressable, you can load it using Addressables.LoadAssetAsync().

Your first instinct might be to write your content in one database asset , then duplicate that asset and set the duplicate's Dialogue Text fields to localized translations. Don't do that. Over time, it's easy for these assets to get out of sync.

You can maintain a master database asset containing all translations. When you deploy, duplicate this asset for each language. Delete all translations but the translation for that language. You could do it in the Dialogue Editor's Templates page or in a custom editor script.

Or you can use i2 Localization, but only for managing editor-time translations. Manage your content in a master database asset. Maintain separate databases for each language. To update a language's database, edit it in the Dialogue Editor. In the Database page, merge the master database into it. This will add any new content from the master database. Then use the DSToI2 window to export the language database's fields into i2 Localization. After updating translations in i2, use the DSToI2 window to import the translations back into the language database.

[alexander]

Thank you for your insights.

[Tony Li]

Glad to help!

[alexander]

A quick follow up question. The text tables are not usable with the dialogue database but merely for UI purposes, is that correct? I ask this because we'd prefer a single method of localizing the app trying to avoid having multiple ways of localizing text and I am currently looking for a way to generate these databases from our localization system.

[Tony Li]

Hi,

That's correct. Text tables are primarily used to localize UIs, or whatever non-dialogue content you want to localize. They're a general localization system separate from the localization in dialogue databases.

If you're using i2 Localization, the DSToI2 window can export/import between i2 and a set of Text Table + Dialogue Database.

[alexander]

Thank you for the hint. We don't use the I2 localization system, but the Unity Localization preview package. I will try and figure out a way how to synchronize these two.

[Tony Li]

Sounds good!

The i2 integration has an optional component that uses a script with an OnConversationLine() method to get the translation from i2 at runtime. You could do something similar with Unity's Localization package.

What do you think of Unity's Localization package? I'm considering adding integration at some point, but early feedback on the Localization package was that it needs more time to develop.

[alexander]

Thanks for the quick follow up. The Unity Localization Package might still need some UI tweeks, but the overall architecture is sound. The main reason we picked it, addressing my original question, was that it fully supports the Addressable Asset System, only loading into memory what is actually being used. As you correctly stated, text alone is not the biggest issue memory wise, this changes dramatically when we talk about audio, images or even videos.

You should, however, not build something for it while it is still in preview mode, simply because they regularly change things up in that stage. Class names get altered, method signatures change frequently.

I am currently trying to just access the localization system from code which is hard for there is no documentation yet.

[Tony Li]

Thanks! That's the impression I got when I looked at it a while ago. I'll continue waiting until there's an actual release version.