ISO locales
Cellard opened this issue · 12 comments
- Lang Publisher Version: 12.2.1
- Laravel Version: 8.83.1
- PHP Version: 8.0.1
Some projects uses iso locales, for example en_US, ca_ES or even en_GB.utf8 (don't ask) etc. For such locales publisher provides empty files...
May be it should fallback to the known locale?
The publisher relies on standard localizations ISO-639-1 and ISO-15897.
Technically, we can use localizations for territories. But we don't know yet who will translate them.
For example, we already have localizations like de_CH, pt_BR, sr_Cyrl, sr_Latn, sr_Latn_ME and other.
And we can add a new localization code like en_GB.
The only thing to consider is that we cannot change the default localization of Laravel - en, and it will always be en.
I mean the opposite.
The publisher has locale ca. The application uses locale ca_ES.utf8.
At first, the publisher tries to find ca_ES.utf8 translations and fails.
Next, it cut off utf8 and tries to find ca_ES and fails again.
At last, the publisher cut off ES and successfully finds ca locale.
In the the end, it publishes ca translation files into lang/ca_ES.utf8 folder of application.
The publisher does not check the conformity of files, if the project from which it publishes files has two folders: ca and ca_ES, then when installing localizations (php artisan lang:add ca ca_ES), both will be installed.
At the same time, Laravel itself only works with two localizations: locale and locale_fallback
If you explicitly specify a call to a custom localization, for example, __('foo', locale: 'ca_ES'), then if there is none, the value from the fallback version will always be taken.
See documentation.
This means that if you install ca_ES and ca localizations in your application, then you will need to choose which one to use. This is a feature of working with localizations of the framework itself.
At the same time, we cannot specify localizations with encoding, as this contradicts ISO-15897.
Laravel explicitly defines only two locales, but application itself may works with many.
app()->setLocale(
$request->getPreferredLanguage(
['en_GB', 'en_US', 'es_ES', 'ca_ES']
)
);So I just don't understand how to use publisher to keep all required translations up to date )
Ok, I understand. For very specific cases I may update lang files manually.
Laravel support to ISO-15897 and we do it together.
Technically, we can use any localization option, but the problems start with the fact that there is no one to support them. Our team is not that big.
By the way, we can add ca_ES and en_GB localization.
@Cellard, so what did we decide? What localization codes do you need for your project?
No, thnx. Current translations is enough. I just tried to solve my little problem, but it creates a big one for you... Excuse me.
In fact, adding localizations with division by territories is not a technical problem for us. This is easy to do.
The problem will be in the support of translation files. There are few people in our team.
In terms of localization naming, we cannot use names of the form ca_ES.utf8, as they are against the ISO-15897 and ISO-639-1 standards. But we can use the ca_ES and en_GB variants and the like.
I understand.
But I was suggesting to fallback into more general localization if the package doesn't have the exact one.
For example. The package has only en translation. Application requires en_GB and en_US translations. Currently the package couldn't provide the translations, because there are no such directories. But with suggested patch it could provide en translations for both requested en_GB and en_US (as you can see, even utf8 suffix is not a problem to fallback to standard locale, provided by the package).
That was my idea.
Probably, you and I did not understand each other well enough because of the language barrier, but I think I understand you.
We can add en_GB and en_US localizations. It's not a problem.
Laravel uses the en localization by default, but this does not mean that your application must use it. Alternatively, in the application, you can change the configuration to the following:
// config/app.php
return [
// ...
'locale' => 'en_GB',
'fallback_locale' => 'en_US',
];That is, technically, nothing limits you in using one or another localization.
At the moment, I see the problem only in the fact that we adhere to the standards adopted in Laravel for using localizations. But, again, codes such as en_GB and en_US comply with these standards. This means that we can add them.
But if you just add two new directories en_GB and en_US — they would be almost (or completely) identical to en. It doesn't look right.
Just an idea: no simplify supporting of translations, en_GB with en_US might just extend en, overriding only few definitions...
Anyway, thank you very much. You already help me enough — I do solve my application localization issues even better way.
You're welcome 🙂