Regional and scripts specific locals

[sabify]

Is there any way to define and use regional and script specific locals?

For example:

├── locales
│   ├── en-US.json
│   ├── en-GB.json
│   └── en-latn-US-Valencia.json

Comprehensive langid/locale handling: https://unicode-org.github.io/icu4x/rustdoc/icu/locale/struct.LanguageIdentifier.html / https://docs.rs/icu/latest/icu/locid/struct.Locale.html

[Baptistemontan]

Technically, there should be no problem for en-US or en-GB, I'm pretty sure it should work out of the box, but en-latn-US-Valencia would be morre tricky due to

leptos_i18n/leptos_i18n_macro/src/load_locales/mod.rs

Line 331 in f0b2a78

quote!(const #ident: &l_i18n_crate::reexports::icu::locid::Locale = &l_i18n_crate::reexports::icu::locid::locale!(#locale);)

as stated by the locale! doc:

Note: The macro cannot produce locales with more than one variant or multiple extensions (only single keyword unicode extension is supported) due to const limitations (see Heap Allocations in Constants):

[Baptistemontan]

We could instead of having a constant, use a lazy initialized static and parse the locale on first access, if you want to make that change I'm open for a PR

[Baptistemontan]

The real question would probably be about translations duplication, if for example en-US could just override some keys of en

[Baptistemontan]

Wait I missread the docs, en-latn-US-Valencia has a single variant and no extension, I just tried and it works fine

[Baptistemontan]

The Locale enum variant for en-latn-US-Valencia will be Locale::en_latn_US_Valencia

[sabify]

Amazing! Thanks for your prompt attention.

So we may want to wait for niche use cases of locale to change the behavior of the initialization?

[Baptistemontan]

yep we can wait, until someone with "sl-IT-rozaj-biske-1994" or other obscure locales open an issue, I consider it working

[Baptistemontan]

But I'll look into extending / overriding / de-duplicate other locales translations

[Baptistemontan]

The logic is feasible, the question is how complicated it gets, technically it was done for defaulted values before the rewrite for the dynamic loading, but now that static strings are regrouped it gets more complicated so I skipped it, might want to re-introduced it

[Baptistemontan]

Most of the work has been done in #206 , now it's just a matter of how to define defaults, something like

[package.metadata.leptos-i18n]
default = "en"
locales = ["en", "fr", "en-GB", "fr-CA"]
extends = { fr-CA = "fr" }

Not sure about the name tho

[sabify]

@Baptistemontan Shouldn't that be done automatically? We can detect the language with LanguageIdentifier's language field and default any region related to that language if the base language exists.

- en-GB, en-US will be defaulted to en if exists, or the global default locale, and the en will be defaulted to the global locale.

- fr-CA will be defaulted to fr if exists, or the global default locale, and the fr will be defaulted to the global locale.

This logic is clear and will not also introduce circular dependencies.

IMHO, with the logic introduced in #206 it makes it much harder to maintain the translations and the default logic behind it...

[Baptistemontan]

#206 did not introduce any new logic for the user, nothing changed other than how default values are handled and their observable behavior is exactly the same as before

[Baptistemontan]

my comment above is just a proposition, and yes your comment make sense, but I prefer to minimize implicit behavior and allow customization when it's really easy to introduce. If the user wants en_US to extend en_GB that itself extend en then I'll let him do that
And tbh circular defaults aren't a problem, as they will be a chain, and the default locale will be the last one, so even if you have

extends = { fr-CA = "fr", fr = "fr-CA" }

if a key is missing in both, default to en. It's just not very not interesting to do it from the user perspective, mostly every user will have well defined and not ambiguous depedencies.

Can you elaborate on how this would make translations harder to maintain ?

[sabify]

Sorry for my bad understanding of your PR comments.

I'm not against having a feature to control the inheritance of locales. I've proposed a global common-sense logic on the inheritance which it doesn't require configuring it by hand.

In other cases that a user needs to change the order of inheritance, they can do it by your proposed extends keyword.

About naming your feature, I think inherits keyword be meaningful here?

inherits = { fr-CA = "fr" } means fr-CA inherits from fr.

[Baptistemontan]

Tbh both can be implemented, and both make sense, but introducing your proposition will need a major version bump as it will implicitly change some behavior. I'm not against it, but for now I'll go with the inheritance, and adding an implicit default to the base locale will be almost trivial in the future