Feature #103887
open
Site config / Site language based language file handling for FRONTEND required since deprecation of "typo3Language" - controlling it by locale only is not enough in every use case
0%
Description
With the deprecation of the SiteLanguage property "typo3Language" in 12LTS it became impossible to have different language files for site languages with the same "locale".
One quick example from our work with various big companies.
Lets say company X has different websites for different countries in the same TYPO3 instance and every page has an english variant (site language).
So lets say:
Website Germany (Site Config "site_germany")- English for Germany (in 11LTS "locale" -> "en_GB" and "typo3Language" -> "en_DE")
- German ("locale" and "typo3Language" -> "de_DE")
- English for Hungary (in 11LTS "locale" -> "en_GB" and "typo3Language" -> "en_HR")
- Hungarian ("locale" and "typo3Language" -> "hr_HR")
In this case not every label for "en_DE" has the same translation like for "en_HR". Most of the time they are the same but in nuances they often vary. So one single "locallang.xlf" for english is not enough.
With 11LTS it was possible to just keep the locale at "en_GB" but control the chosen language files by adding custom languages ("en_HR", "en_DE" etc.) which was possible by the "custom language" feature found here https://docs.typo3.org/m/typo3/reference-coreapi/11.5/en-us/ApiOverview/Localization/ManagingTranslations.html#xliff-translating-languages and setting this custom language in the "typo3Language" of the site language. So in the end you had a "locallang.xlf" for the labels and variations of it by "en_DE.locallang.xlf" or "en_HR.locallang.xlf".
In 12LTS "typo3Language" is getting deprecated now (https://docs.typo3.org/m/typo3/reference-coreapi/12.4/en-us/ApiOverview/SiteHandling/AddLanguages.html#confval-sitehandling-addinglanguages-typo3language) and the language files are getting controlled only by the "locale" property.
This means that the use case above is no longer possible to implement.
For sure you could set an invented locale like "en_DE" for the "locale" property but this would first render e.g. every locale based formatting useless. And second it would spam the logs with "Locale en_DE not found." error messages coming from "\TYPO3\CMS\Core\Localization\Locales::setLocale".
In the end we need this dropped feature back since custom languages are now only usable in the backend but no longer in the frontend.
In a lengthy discussion in the TYPO3 slack right here https://typo3.slack.com/archives/C025BQLFA/p1716372529432749 Stefan Bürk came up with the idea of site identifier based language files like "locallang_db.site-identifier.de-DE.xliff". (https://typo3.slack.com/archives/C025BQLFA/p1716463354137249?thread_ts=1716372529.432749&cid=C025BQLFA)
I think we would even need a site-language based approach since you can have websites that have multiple english variants in the same site config that share the same locale (e.g. "en_GB") but need different language files.
Updated by Denis Mir 19 days ago
Another approach would be to just fix (I mentioned the problem here -> https://typo3.slack.com/archives/C05D7UF1L8M/p1716532632852119) the documented (https://docs.typo3.org/m/typo3/reference-coreapi/12.4/en-us/ApiOverview/SiteHandling/AddLanguages.html#confval-sitehandling-addinglanguages-locale) behavior of the locale property and allow multiple comma separated locales.
So for our example in the forge ticket we could do something like:
"locale: en_DE,en_GB"
Language file loaded would be the first that the system can find. So it checks for en_DE.locallang.xlf and then it checks for en_GB.locallang.xlf and then the rest of the XLF fallback train.
Locale wise it would do the $locale = setlocale(LC_COLLATE, ...$availableLocales); like it already is in \TYPO3\CMS\Core\Localization\Locales::setLocale. So in the end it would load the locale en_GB when en_DE is not available.
Even for the hreflang it would just set the first from the comma separated list. (theoretically the hreflang property wouldn't even be necessary anymore as well)
So all in all this would make everything possible with just one locale property.
Updated by Andreas Kießling 18 days ago
I totally agree that this needs to be reverted or somehow "officially allowed" again. I have systems with invalid locale setups, so e.g. multiple English versions for country specific websites in multisite setups, but also some sites that target GB, US etc. Sooner or later you end up having custom languages for in the system..
This config has worked for years and is already causing trouble with the update to 12.4 since the xlf filenames are constructed differently and need to be renamed to be found again
Updated by Benni Mack 9 days ago
Here are my 2 cents...
OK, I guess the only "short-termin" solution for v12 in my opinion is to keep the option without deprecating it (I would still use it as "if empty, the value from "locale" is used instead).
In the long term, we should not rely on setlocale() anymore, as it relies on the system locale. So we need to also migrate money_format etc away, so it is not used anymore. setlocale() technically can undertand "de_EN" if you create the locales on the system yourself (it in fact is a valid locale), but that's tedious and not an option here I assume.