Setting the supported locales dynamically

[jbroadway]

First, I'm very happy I found this today! I implemented i18n support in my project in under an hour :)

I'm wondering if there's a reason the supported locales is a private property? It looks like we have to modify the source file every time we add a new supported language, but it would be nice to be able to leave the original code as is and modify the list dynamically.

[GabLeRoux]

I agree with you, this should be at least protected so we can extend and add new languages on the go. I really like this library too and I found it very handy combined with weblate as the translation backend.

I suppose you could send a PR but I don't know if this is still maintained. It did not change in two years but I offer my help here and will definitely look into this and review changes.

I'm using it in unity but I've copied the files directly in my projects instead of actually using it as a dependency to fit my needs. I didn't want my team to mess with submodules ;)

[camsjams]

I still support this library, and would be happy to discuss this improvement.

As @GabLeRoux says (and same as how we use it) we just copy this file directly into projects as it just works a little easier that way.

That being said, changing this to a protected property seems perfectly logical.

[jbroadway]

Thanks for the quick replies! For myself, I prefer subclassing over modifying directly in case an update comes out and another dev on our team copies that updates into our project without realizing they've overwritten our previous modifications.

I've submitted a PR that makes the changes needed and tested that subclassing works to override the locales for me. Here's what I needed to do:

namespace MyApp {
	public class I18n : Mgl.I18n {
		protected static readonly I18n instance = new I18n();
		
		protected static string[] locales = new string[] { "en-US", "fr-FR", "es-ES", "de-DE" };
		
		public static I18n Instance {
			get {
				return instance;
			}
		}
	}
}

Now I just have to replace using Mgl with using MyApp and I've added a new locale.

[GabLeRoux]

Awesome, I'll update the readme tonight with the instructions you provided. Definitely makes it easier to use and update.

[camsjams]

Looks good! Thanks you two!

[GabLeRoux]

@jbroadway I know it's been a while, but I worked with this today, and I realized that overriding locales here doesn't work as expected. locales is static so the above example doesn't exactly override the locales inside base class. In other words, static belongs to the class and not the object so above code is only hiding it, oups!

When I tested this, it worked by coincidence as I used fr_FR + en_US, but I tried with fr_CA instead and now it's failing with Missing: locale [fr_CA] not found in supported list where fr_CA comes from my own class, but locales contains base class values.

Quick workaround is still to edit base class directly which is easier, but it doesn't feel right, I'll see if I can do something about it, I should have tested this a bit more, sorry.

[lux]

Ah you're right! Hmm... What about a SetLocales(locales) method, or adding a locales option to I18n.Configure()?