Language headers are not parsed about gettext.net

[andy-noisyduck]

Our use case is loading Catalog objects via a stream and this covers our scenario.

For full context we make games. We parse a folder full of .mo files to know what languages we have translations for, and then display the known options in a language menu so that the user can easily switch language.

Right now we are manually extracting the language header and reading it. It works fine, but it feels like it should have been part of the GetText library.

Thanks for your great work.

[perpetualKid]

this is now fixed/updated in code.
A new package version (> 0.9.8) will be out in the next couple days

[perpetualKid]

this is all based on the original NGetText code and I never looked into it, but can clearly see that using CultureInfo.CurrentUICulture certainly is not really a good idea.
I'll need to dig bit deeper to see if there are any side effects when changing this, but clearly should be changed.

[perpetualKid]

looking further, I could see two issues here:

• typically the culture is set in the application, and the appropriate catalog loaded i.e.

System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo(fr-FR);
ICatalog catalog = new Catalog("myCatalog");

or alternatively

ICatalog catalog = new Catalog("myCatalog", new CultureInfo(fr-FR));

in that case, the catalog would try to load the catalog matching the given or current culture, so the CultureInfo of the catalog should match that. However, if a catalog for the exact culture ("fr-FR") is not found, it will lookup the hierarchy, and i.e. find a catalog matching "fr" only. In that case, the CultureInfo property of the catalog would still be "fr-FR" instead of "fr", which needs to be updated.

• the other case is if you're pointing directly to a file (stream) or ILoader interface. In that case, your application CultureInfo.CurrentUICulture may be i.e. en-US, but you may open a catalog from stream

ICatalog catalog = new Catalog(new Catalog(new FileStream("catalog_fr-FR.mo"));

so the catalog's CultureInfo will be en-US instead of fr-FR which is wrong obviously.

I'll update both cases. Could you just confirm this is covering your scenario, or is there something else I haven't seen yet?

[perpetualKid]

reasonable to expect the CultureInfo property set out of the loaded catalog, I'll work on that.

just for curiousity, how are the *.mo files named?
In most cases I've seen and used, either the mo-files where using the language code as filename (fr-FR.mo), or in a respective folder structure (fr-FR\catalog.mo)

[andy-noisyduck]

just for curiousity, how are the *.mo files named?

In our case we also use the locale as the filename. Normally just the neutral locale (e.g. fr.mo) unless we have some region specific translations.

This does mean we could have fallen back to the filename to also know the catalog's locale, or to know available locales without actually parsing them, but when you have a bunch of files being generated by external tooling its quite easy to copy the wrong file or name it incorrectly. It's safer to validate against the language header.

[perpetualKid]

https://www.nuget.org/packages/GetText.NET/0.9.9

[andy-noisyduck]

Perfect. Thanks for the quick update.