LocalizedString field generation

Hello,
I have :

• a table name as string,
• an entry key as string,
• a table guid from a table found or created from the table name string
• a entry id (uint) found or created from the entry key string for the table mentionned above

How can I instanciate a LocalizedString by script and bind it correctly from those ?

 

Actually figured it out, have simply to use the implicit operators

Code (CSharp):

1. LocalizedString locString = new LocalizedString();
2. locString.TableReference = guid.Value;
3. locString.TableEntryReference = keyId;

... and not to forget to set the class field with it...

 

However if I replace the KeyId by the key (string), the binding seems not to works.
My LocalizedString is binded to the table but not to the entry, thus it can't resolve the bind (the root string in the inspector stays as "None (String)". :/

 

Something is odd here...
I am adding the entry in the table (from a string table name and string entry name), then send back the table guid and entry uint key to set up my LocalizedString. Then I am trying to save the text value using the LocalizedString.
The LocalizedString seems to be set up correctly but

table.ContainsKey(key_id)

returns false.
I see 2 possibilities:
First the creation is an async operation and thus the entry don't exists yet when querying (doing it all in the same frame).
Second I am modifying the table on disk and querying the one in memory, or the opposite
?

 

I am creating a LocalizedString by setting up the guid and keyid

Code (CSharp):

1. Debug.Log($"creating LocalizedString : guid.Value = {guid.Value} keyId = {keyId}");
2. LocalizedString locString = new LocalizedString();
3. locString.TableReference = guid.Value;
4. locString.TableEntryReference = keyId;

Then I am using the LocalizedString bind right after (in the same frame) to set up a string value to that table/entry.

Code (CSharp):

1. private static void SetLocalizedText(LocalizedTable localized_table, uint key_id, string value, bool override_if_exists)
2. {
3.   Debug.Log($"Set Text with LocalizedString : table guid = {localized_table.SharedData.TableNameGuid} keyId = {key_id}");
4.   StringTable table = (StringTable)localized_table;
5.   if (table.ContainsKey(key_id))
6.   {
7.     StringTableEntry entry = table[key_id];
8.     if (override_if_exists && entry.Value != value)
9.     {
10.       Debug.Log($"Localization: {localized_table.TableName}/{localized_table.SharedData.GetKey(key_id)}_{table.LocaleIdentifier.CultureInfo} : {entry.Value} => {value}");
11.       entry.Value = value;
12.     }
13.   }
14.   else
15.   {
16.     Debug.Log($"Localization: no keyId \"{key_id}\" found in LocalizedTable \"{localized_table.TableName}\". (SharedData.TableNameGuid: {localized_table.SharedData.TableNameGuid})");
17.   }
18. }

But when testing it, the ContainsKey returns false


However, if the entry was created before (creation and querying on 2 differents frames using UI buttons), its works.

 

I noticed that creating by script entries in a collection sharedData table won't create them in the associated LocalizedTable.
That leads

StringTable.GetEntry(uint key)

to returns null while the entry seems to be created in the editor interface, which is very misleading.
I think creating an entry in SharedData should be reflected in all LocalizedTable behind the scene, and AddEntry() on a LocalizedTable should be redirected to creating the entry in the SharedData to ensure consistency

 

How to fix this " public LocalizedString aaa;" not work in editor ？ It's not same like document.
But I create in a new project The " public LocalizedString aaa;" is work.

 

Thank you . It be modifying by Odin indeed.

 

Wanted to add to this to help people searching for it.

LocalizedString variables (in my case, with scriptable objects) can have an error where it shows a null IVariable and empty key in the inspector. I was working through Unity's Open Project where there are selectable string tables string tables. The problem was indeed Odin Serializer; updating to the most recent version fixed the issue.

Whew, thanks Karl!