Resonite Translation Message Formatter Doesnt Format If The localcode Doesnt Match An Actual Existing Locale

[LegendaryGeek]

Describe the bug?

when making language files, if the localecode used doesnt exist as an actual code, the formatter for things like the audio percentages on the settings screen, just shows the ERROR!!! text. the log claims "Culture name en-uwu is not supported"

To Reproduce

1.) create a new language file

2.) copy everything from the en file over

3.) change the locale code to something like en-uwu

Expected behavior

i expected the formatter to format strings correctly, showing a percent on the audio settings

Screenshots

Resonite Version Number

2024.4.3.1170

What Platforms does this occur on?

Windows

What headset if any do you use?

Index

Log Files

K3NZC0SRAM - 2024.4.3.1170 - 2024-04-12 05_56_54.log

Additional Context

dont think it matters, but i had to update my lang file after the game launched in the log file

Reporters

Me

• Resonite: K3nzC0
• Discord: kenzco

[JackTheFoxOtter]

Actually, try renaming that file to en-x-uwu.json and see if that works. That would be the proper name for a custom locale. (See https://en.wikipedia.org/wiki/IETF_language_tag)

[LegendaryGeek]

just tried, still shows the same in-game and log says the same things, but with the edited locale code

[JackTheFoxOtter]

All right, was worth a shot. This is probably a problem we'll run into as well then once we split German up into two locale files. (One for formal)

[JackTheFoxOtter]

You might want to append your custom locale to this issue though so it can be tested with.

[LegendaryGeek]

en_uwu.json Here is the file, just over half uwu-ified everything.

[Banane9]

This isn't "really" an issue with Resonite, but with the localization string library, if anything.

When formatting something, it uses the standard library method CultureInfo.GetCultureInfo(locale), which throws an Exception for locales the OS doesn't know about - which en-uwu definitely falls under. I suppose this could potentially be fixed by checking if the locale exists as a CultureInfo first and then using fallbacks for that too.

[Frooxius]

This isn't exactly a bug - to format the messages the system needs to know which culture to use to format the values - if it doesn't exist, it can't format them.

To make this work, we'd need to add a mechanism to specify which existing culture needs to be used to format the messages somehow - e.g. using fallback or specifying it in the file.

But given that this is for a joke, I'm not sure if we'd prioritize that soon.

[JackTheFoxOtter]

There is a very real use-case for splitting the German locale up into two files. I was actually planning to make a separate GitHub issue for make sure this works. I already did some tests (https://github.com/Yellow-Dog-Man/Locale/issues/6#issuecomment-1746837638) confirming this already seems to work on a surface level, and I though the only thing required to get this to fully work was adding the name of the custom locale in the old selection screen, but I suppose this is also going to be a problem for that use-case.

[JackTheFoxOtter]

Just verified again, I can create a custom extension to de.json by just creating de-x-formal.json, and it already seems to automatically inherit keys that aren't overwritten from the de.json file, so the localization system itself seems to already be capable of handling custom locales with inheritance, only issue being the UI lacking a nice name for the locale button, and the exception thrown by strings that require formatting (but only if those are from the custom locale file, inherited strings with formatting still work as expected).

Should I create a new ticket for this or will this one suffice?

[Banane9]

Got it to work by prefixing some code to the Elements.Assets.LocaleResource.LoadDataAdditively(LocaleData) method - it's not super pretty and I'm sure it could be done differently, but it works. It's free for the taking if Froox wants any of it lol

            var localeCode = data.LocaleCode;
            var index = -1;

            do
            {
                try
                {
                    if (CultureInfo.GetCultureInfo(localeCode) is not null)
                    {
                        data.LocaleCode = localeCode;
                        break;
                    }
                }
                catch (Exception)
                {
                    index = localeCode.LastIndexOf('-');
                }
            }
            while (index > 0 && (localeCode = localeCode.Remove(index)).Length > 0);

[LegendaryGeek]

this issue was fixed with the settings update and havent noticed any issues with custom locale since. figured i'd give the update.

[Banane9]

this issue was fixed with the settings update and havent noticed any issues with custom locale since. figured i'd give the update.

It wasn't actually fixed (@shiftyscales), it's just not immediately obvious anymore because the settings screen is full of ERROR!!! labels. Here's two examples:

Anything where a numeric value is culturally formatted into a message throws an error. Some UI "gets around this" by inserting an already OS-culture formatted string into the message, such as when creating an audio stream. This also means that those values don't respect the set locale's formatting (set to English locale):