Localization Language Feature

[gdotdesign]

This PR adds language features for handling localizations: https://github.com/mint-lang/mint/blob/locales/documentation/Language/Locale.md

[farism]

A couple of localization thoughts just from experience with it in our prod app:

1. There can potentially be hundreds/thousands of lines of text in a large application, multiplied by 10+ languages can easily add up to hundreds of kilobytes in your bundle. It would be nice from an optimization standpoint if each there was an option to have each locale code split out and loaded on demand. We do this in our app React apps by having translations live in separate .json files and using using dynamic import().
2. When using a localization service (Phrase, Smartling, and other services like this) they generally expect to be working with some standardized data exchange format like .yaml or .json. Something to think about from a workflow perspective.
3. Packages may need to ship with their own translations, and whatever system Mint goes with should have seamless integration between the package and the app. I think having the locale scope be open solves this issue? But not entirely sure if there are some other nuances.

[Sija]

I like the approach of making the translations a first class citizen. I believe though that the implementation should handle the pluralization, loading data from files and the other points raised by @farism.

[gdotdesign]

I like the approach of making the translations a first class citizen. I believe though that the implementation should handle the pluralization, loading data from files and the other points raised by @farism.

I agree on all parts, but it needs to be a multi-stage process, we can't implement everything in one PR.

1. I'm currently refactoring the compiler to allow dynamic imports, which will include locales.
2. This is the hardest part to implement, since I presume everyone has its own format, so we either need to decide which format to use or we keep it as is and build the tooling around importing / exporting formats.
3. The locale definitions are open, and if packages use namespaces it shouldn't be a big issue. The only thing we might need is to allow overriding a specific key but I wouldn't implement this until we run into the need in production.
4. Pluralization and the whole translation logic is so wide (date-time, currencies, etc...) is that I fear that having them as language features are not really feasible.

[jansul]

I would generally agree with @gdotdesign, there doesn't seem to be anything about this design that would prevent implementing most of the features mentioned.

The only awkward thing might be:

2. When using a localization service (Phrase, Smartling, and other services like this) they generally expect to be working with some standardized data exchange format like .yaml or .json. Something to think about from a workflow perspective.

However I don't think it's worth giving up the flexibility of the values being expressions to support these services. Hopefully we could find a nice way of importing/exporting locales in a way that works with them.