I don’t really expect a fix just wanted to let you know .
2022.3.39f1
This is the line on which it crashes on zh-cn language
这个{科学}是如何运作的？
and spanish
No quiero que tú {…}
I assume its because its clashing because of { } which are for parsing. Im using ai for translating and working solo so I cannot really mentain all other languages but it was literally hard locking my game because of localization bug so I assume youd probably want to know about this also so you can do some protection or just ignore it lmao
I used this line
IList<StringTable>
var localized = assetTable.GetEntryFromReference(key)?.GetLocalizedString();
or this liine
var ret =LocalizationSettings.StringDatabase.GetLocalizedString(x,y);
I cannot tell you for sure which as this was reported to me after the fact and only know about this as someone sent me partial crash log.
i have no idea how new Odin localization tables work but thanks to it i can confirm that when clicking on the table entry it throws an error that was thrown previously in builds, While in the old localization tables, it’s not possible. On the other hand, there is no way to change the field when the error is thrown on an entry as the entire table crashes. While unity localization talbes you can. The table crashes when selecting the entry.
I’m pretty sure the bug is not related to Odin at all just wanted to let you know.
I modified the entry and the odin tables don’t crash therefore the localization in the build probably isn’t either.
For the future, I wrapped it in try-catch in case there are other entries like that.
Action execution for '' threw an exception: Value was either too large or too small for an unsigned byte.
at System.Convert.ThrowByteOverflowException () [0x00000] in <c0b7b90d34a54066a7234dad69255116>:0
at System.Convert.ToByte (System.Char value) [0x00008] in <c0b7b90d34a54066a7234dad69255116>:0
at UnityEngine.Localization.SmartFormat.Core.Parsing.Parser.ParseFormat (System.String format, System.Collections.Generic.IList`1[T] formatterExtensionNames) [0x0072c] in .\Library\PackageCache\com.unity.localization@1.5.2\Runtime\Smart Format\Core\Parsing\Parser.cs:415
at
Ps. I appreciate the answers on other localization threads as I’ve seen you at it all the time on it and it was a big help when I’ve had problems. Keep up the good work!
Is No quiero que tú {…} a smart string?
The 3 dots (…) are not a valid selector so will produce an error.
If you wanted them to be literal you should use double brackets like this: No quiero que tú {{…}} or turn of smart formatting on the string.
I suspect that 这个{科学}是如何运作的 is also not a valid string, maybe you wanted 这个{{科学}}是如何运作的?
Maybe the AI translation has gotten confused with your placeholders?
I mean the ai translation translated it wrongly for sure. I also understand that this is because {…} is not a valid thing.
My script also picked it up wrongly which marks the strings as smart strings, or rather it did it’s job on a badly translated string.
Yet it is not exactly my point. MTL translation will become even more common.
Since when people like me are translating 140k words + and they have one word that will throw in every language in the build itself hardlocking the story.
There is no way to know before building if the text contains something that will throw in the player.
It will become quite an unpleasant experience to work with this localization.
Isn’t there something that should be done? Like even a single error in the editor would help to protect against this irritation.
The error you are getting is because the string is wrong.
We could detect some issues during import with the placeholders such as the 3 dots but we can not detect if AI translated placeholders are correct, we dont have the context to know if the placeholder is correct or not until you try to use it and provide the source data. You should be able to tell the AI to not translate any values inside of { } brackets.
I get that. The ai doesn’t matter here. Those few wrong smart strings will not just be ignored and shown as empty like other not matching strings. It will throw.
Any protection in the editor against building a player with something that throws should be notified to the dev before that build happens. The only thing similar to this right now is selecting the entry in the Odin localization table. Although selecting every entry there is madness. Otherwise, there is no way to know without investigating every single string carefully or writing another custom tool to detect this. Who has time for that while the editor is supposed to be ‘out of the box experience’?
I like the tool what it is right now but it is a bit irritating so just wanted to let you guys know.
Either way, keep up the good work.
1 Like
I see. The behaviour can be configured in the localization settings under smart format. See the Format and Parse error actions. You can disable the throwing. Localization Settings | Localization | 1.4.5
It was already on ‘maintain tokens’. Neither of them is on ‘throws error’ setting.
That seems like a bug then. Could you please file a bug report?