Question Usage of Smart.Format for arbitrary plural strings in Japanese fails?

Hello, I'm currently evaluating the use of Smart.Format as a means to localize strings that are downloaded remotely (not in any built-in localization database). I'm attempting to follow the scripting guide for plurals here https://docs.unity.cn/Packages/com.unity.localization@1.0/manual/Smart/Plural-Formatter.html but this for Japanese.

Here is the test code, placed in the Start() function of a MonoBehavior in the scene:

Code (CSharp):

1.         var strEN = "(en) I have {0:plural(en):an apple|{} apples}";
2.         var strJA = "(ja) I have {0:plural(ja):{} ringo}";
3.         for (int i = -3; i < 10; i++)
4.         {
5.             var output = Smart.Format(strEN, i);
6.             Debug.Log(output);
7.             output = Smart.Format(strJA, i);
8.             Debug.Log(output);
9.         }

The force english string prints to console, but the force japanese string emits this exception:

Code (csharp):

1.  
2. FormattingException: Error parsing format string: No suitable Formatter could be found at 26
3. (ja) I have {0:plural(ja):{} ringo}
4. --------------------------^
5.  

What have I missed in this example? Why do I receive this exception? Japanese should only have an "other" and therefore only require a single entry according to the Unicode language plural rules https://www.unicode.org/cldr/cldr-aux/charts/29/supplemental/language_plural_rules.html


Thusfar I've tested the format for English, German, Russian, and Japanese and only Japanese fails. Even Russian correctly uses the one|few|many format.

 

Hi Karl, this does work though it's a little irregular in that it means we cannot explicitly specify a language override. That said, this shouldn't be a problem in this situation. It may seem unnecessary, but supporting explicit single definitions might make the examples less conusing. Alternatively the documentation could be updated more explicitly to reflect that languages like Japanese can be used as though they were normal format strings and that this is by design.

 

Thank you Karl! Testing out the SmartFormat library from nuget it seems like this is a bug upstream too with the same "fix" on the user end