Alternative workflow

Unity Engine
,
1

Hello,

I tried a bit the package a year ago, and started playing again with it recently. The version was 0.6 at the time and is now 0.11 so I had to deal with some changes in the api.

The current package workflow is to add a component next to any component you want to localize (using the “Localize” right click shortcut). Then set the localization table entry using the localization component, or using the localization table editor window then set up the link in the component.
And this really tedious.

That also mean you can’t localize string within ScriptableObject. You can duplicate the ScriptableObject for each locale and use them as localized assets. But it implies manual updates, which is tedious as well.

Also not sure it allows to reuse stuff like prefabs from a project to another, as it would break all addressable links so you have to set up the localization again almost from the start. It is still work in progress, but here is a view of its current state (for text mesh pro components) :

7066714--839749--upload_2021-4-22_17-9-53.png
7066714--839749--upload_2021-4-22_17-9-53.png1292×717 66 KB

First a shortcut to change the application current locale, that trigger a refresh (reload) of any localized stuff. I also made it working in editor (for both play or editor).

The second element is a unity event connected on the locale change.

The third element is a list of target and reference. Target is the unity component I want to localize. Reference is the localization package LocalizedReference class instance.

Fourth are buttons that applies on the previous element collection, for the current locale : LoadAll to refresh all component (so read the addressable database) and save to overwrite all component values.
It allows to save the changes after scene/prefab modification.

Next is the roots list. They are the gameobjects whose hierarchy will be scan to find all TextMeshPro components and will populate the following list.

Sixth if the preset list, populated from the root list when the scan button is pressed.
A preset is a candidat entry for the third element (list of Component/LocalizedReference). This is an editor authoring tool which let you previsualize what can ba added to the reference list. The preset element are the target component, a rootType (enum scene or prefab), the addressable table it will be added and the keyname it would have.
The table name format is “[RootType][SceneName][ComponentType]”.
The Keyname is a concat of the scene name and all gameobject name to from the scene root to the component.
There are also 2 booleans : exists (true if the table/entry already exists in the addressables) and duplicate (true if the same table/entry pair is at least twice in the preset list).
You can remove line, or click on any component to rename it (to get another keyname) and regenerate the list.

Lastly the scan button, already explained before. The apply button that will populate the reference list with the preset list (and create missing tables and entries accordingly) and the clear button that just clear the preset list.

I am open to any feedback about that flow and hope unity will do something similar in the future.

As I played a bit with the API :

  • I had to make different code according the context (editor/edit, editor/play, runtime) with some #IF UNITY_EDITOR and Application.IsPlaying. It should probably be on unity side. Providing single entry point for all context would be nicer.
  • I did not rework the assets support a lot yet, but it seems assets and strings api are differents. As they actually seems both to handle strings as value they probably could become an unified api as well.
  • I used UnityEditorInternal.ReorderableList and had a lot of trouble to make a custom inspector, actually extending the editor in a nightmare but I more or less succeed to have something “showable”. Hoewever I still have trouble to manage the LocalizedReference width in my reference list, any advice about that element ? Will it change ?
2

You would localize a scriptable object by using the LocalizedString (https://docs.unity3d.com/Packages/com.unity.localization@0.11/api/UnityEngine.Localization.LocalizedString.html) class. This is a class that can be used in any script and provides the editor features for adding/removing and editing. Its what you see in the component you can attach.

public class MyClass : ScriptableObject
{
    public LocalizedString myString;
}

Components don’t store addressable links. They store a table name either as a string or guid and the entry as a string or id. This means you can move tables and components to different projects.

You create a TMP object, add the component and either link it to an existing entry or add a new one. Once that is done you dont need to change it. You can use the table editor to change text entries.
Im not sure how your approach is better. It looks brittle as you are assuming the objects you find and setup wont be deleted, moved or instantiated during runtime. Having the component on the same gameObject means we dont have to deal with this issue.
The component based workflow is there for people to localize without writing any scripts however we do have a full scripting API and recommend the LocalizedString class for those who want to do more such as having multiple items controlled from 1 component. We do have an alternative workflow called Localized Property variants, it was shown during our December webinar https://discussions.unity.com/t/819171
The idea for this approach is to allow you to work with components like you would normally, making changed directly to the component and just changing the active language.

3

Thanks for your feedbacks,

I am using the LocalizedString (the right part of the second list). I started by using generic code so I used LocalizedReference at first but finally used the real type directly (or I would need to write a different customEditor/property drawer for each supported type).

Can I actually just copy/paste the localized table assets from a project to another without anything breaking ?
If I am using the table/key names, is the system using the guid internally ? Is there a chance of guid conflict ?

My approach is actually about rebuilding the localization tables and set them up much quicker by using scan/apply buttons.

If a component in scene is removed, you will see it in the target list (as the component will be null).
I will add a security checks to send a warning in the console.

For the gameobject instantiated in runtime (prefabs), they would have their own localization gameobject.

I don’t know about the property variants, I will check that.

4

Yes that should work. If you set the value through the inspector then it will be using the guid.
Theres a very low probability of the guid being duplicated in the other project, as much as any other asset guid. Its using the same guid system that Unity assets use.

Localized property variants are not available yet but should be soon. They let you configure other properties such as the Font, font settings(character size etc), Rect transform and any other serializable property.