ISO 15897 format of country specific locales
bjoerne2 opened this issue · comments
On https://laravel.com/docs/7.x/localization it says:
For languages that differ by territory, you should name the language directories according to the ISO 15897. For example, "en_GB" should be used for British English rather than "en-gb".
Wouldn't it be better to rename the country specific folders, e.g. de-CH -> de_CH?
Good idea, we need to do a new major version ( v7 ), because we brake directory names...
Can you do a pull request ?
I created a PR: #1276
Can I have references for language names ? As sr_Cyrl
My problem is for sr_Cyrl, sr_Latn, uz_Cyrl and uz_Latn.
Either I read the technical documentation poorly, or in the description of the ISO 15897:1998 standard there is no mention of the rules for naming language localizations.
Standard ISO 15897:2011 is paid ($168...) 😐
I may be wrong, but I want to propose to call it this way:
de_CH
pt_BR
...
sr_Cyrillic
sr_Latin
uz_Cyrillic
uz_Latin
done
Thank you
If you list the php Intl locales, we have a specific list of locales and the naming should be followed.
collect(ResourceBundle::getLocales(''))->filter(fn($i) => Str::startsWith($i, 'sr'))
=> Illuminate\Support\Collection {#3268
all: [
672 => "sr",
673 => "sr_Cyrl",
674 => "sr_Cyrl_BA",
675 => "sr_Cyrl_ME",
676 => "sr_Cyrl_RS",
677 => "sr_Cyrl_XK",
678 => "sr_Latn",
679 => "sr_Latn_BA",
680 => "sr_Latn_ME",
681 => "sr_Latn_RS",
682 => "sr_Latn_XK",
],
}Meaning that sr_Latin, me, etc; locale folders you have are invalid.
Note, I am from Montenegro and I use sr_Latn_ME nomenclature, when I develop.
@caouecs, Since the ISO 15897:2011 standard does not regulate the naming of these localizations, I think @milose's proposal is reasonable.
no problem for me
no problem for me
I created a PR #1453, but @LukaLatkovic must review, since he is referent for the sr_* languages.
So, that means that me folder should be renamed to sr_Latn_ME
@caouecs, Since the
ISO 15897:2011standard does not regulate the naming of these localizations, I think @milose's proposal is reasonable.
This proposal is done by Unicode standard(International Components for Unicode), so maybe we can do locales based on that standard List of all locales by Unicode, Simple search since Php Intl is based on that
@caouecs, @andrey-helldar what do you think?
We are web developers here and this is a Laravel oriented package. With this I mean to say that the directory of the locale should be named in a way so it can be consumed app()->getLocale() method.
Laravel workflow is:
- you set the
'locale'inapp.php - you use the
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">to set the language contained in your HTML output (important for search engines, automatic translations, screen readers etc. - you consume other packages with the correct locales like Carbon (their Lang folder) with ease.
Introducing other names, that are not standardised on the web means we need to "translate" locale names for other packages, html attributes etc. This is not ideal and the correct nomenclature should be used.
BTW, the translation for Montenegrin language is atrocious. I will make a pull request for the correct translation after this is resolved.
@caouecs, Since the
ISO 15897:2011standard does not regulate the naming of these localizations, I think @milose's proposal is reasonable.This proposal is done by Unicode standard(International Components for Unicode), so maybe we can do locales based on that standard List of all locales by Unicode, Simple search since Php Intl is based on that
@caouecs, @andrey-helldar what do you think?
Taylor introduced the ISO 15897:2011 standard into the framework and I think we don't need to violate it.
If proposals for adjustments do not contradict him, then they can be considered.
Taylor introduced the
ISO 15897:2011standard into the framework and I think we don't need to violate it.
Sauce, please? @andrey-helldar
Taylor introduced the
ISO 15897:2011standard into the framework and I think we don't need to violate it.Sauce, please? @andrey-helldar
You mean proof?
And my PR: #1453
Thanks @andrey-helldar I missed that.