as the recommended way of localizing UI texts in the scene is using the “Localize” button on TextMeshPro, which creates a LocalizeStringEvent, I was thinking of creating several subclasses of LocalizeStringEvent for my needs.
However, when using a subclass of LocalizeStringEvent, it seems that the editor no longer picks up on changes to the language (i.e. I can’t preview languages with the Localization Scene Controls).
Is this supposed to work? If not, could it be made to work? I think subclassing LocalizeStringEvent would be a great way to deal with added string resolution logic.
Use Localize in the dropdown of a TextMeshPro Text, a LocalizeStringEvent was added. I add a new table entry, add a translation, and voila, I can switch the Active Locale to see the different localization values in the scene view.
I then remove the LocalizeStringEvent, and add a new script which is a subclass of LocalizeStringEvent, set the table entry again, and — nope, when I switch the Active Locale, the text in the editor does not reflect that.
The subclass is currently just this (planning to add methods and fields of course):
Thanks. In addition to your screenshot, to get it working in the editor, instead of “Runtime Only”, the value “Editor and Runtime” needs to be selected.
Thanks again, as always, for your detailed answer and fast reaction. It’s really great to see this level of support for the l10n framework.
I’ll take a look at LocalizedMonoBehaviour next and the driven properties, thanks for the heads up!