Localization Package Feedback/Usecase

Unity Engine
, , ,
1

I just wanted to write-up our use-case in case it helps feedback into the package at all.

Our game is typical - we have a bunch of UI populated with text. Things like “Settings” or “Thing unlocked!” etc.

When making the game, what we want to do is quickly enter the English/native-for-us text and have a static UID associated with it so that later it can all be localized. In our use-case, string reuse is very rare in general, thus the flow of using the existing property drawer:
→ Choose table
→ Add Entry
→ Think of a key and set it
→ Set the text

… has a lot of friction. Not to mention the space occupied in the inspector. In our case we also don’t make any use of the local variables feature.

So we’ve taken a different approach and I’m sharing it in case any part is interesting to consider. It’s far from a perfect solution.

This is our current UI for LocalizedString. Thus our new flow is:

→ Choose Table
→ Type text - done.

image
image883×97 2.06 KB

In code:

public class MyBehaviour : MonoBehaviour, IComponentUID
{
       // A ReadOnly unique hash created once for the asset
       [SerializeField, ReadOnly]
       string _uid = System.Guid.NewGuid().ToString("N");
       public string EditorGenerateNewUID() => _uid = System.Guid.NewGuid().ToString("N");
       public string UID => _uid;

       [LocalizedStringID("title")]
       public LocalizedString title;
}

Obviously subclassed however and the same for ScriptableObjects. Essentially with this workflow every Component/Prefab/SO has a persistent uid then the attribute’s value is used in composition with the uid as the key into the Localization tables. The property drawer takes care of some of the heavy lifting of removing empty records, changing tables etc.

There are downsides here obviously - an asset processor to check for duplicate UIDs, a wasted indirection of another id, an editor tool that deletes unused entries plus generally some fragility. I don’t love it. However, it has massively increased our productivity and for the most part works well for us.

2

Interesting.

We do already have a unique id generator which we use for the keys ids, you could also use this for the Keys as well. It should not generate any conflicts.
https://docs.unity3d.com/Packages/com.unity.localization@1.5/manual/TableEntryKeys.html#distributed-id-generator

To use it you can do something like this:

var stringTableCollection = LocalizationEditorSettings.GetStringTableCollection("My Game Text");
var id = stringTableCollection.SharedData.KeyGenerator.GetNextKey();
stringTableCollection.SharedData.AddKey(id.ToString(), id);

We do have plans to redesign the LocalizeString property drawer in the future to make it simpler for use cases such as this.

Thanks for the feedback!