Bug #87101
closed
in TYPO3 v9.5 user defined locales can not be added by an extension any more
Added by Sebastian Mazza almost 6 years ago.
Updated over 5 years ago.
Description
At least in TYPO3 v. 7.x ist was possible for an extension to add a new local definition to the the TYPO3 localisation system.
This was posible by adding
$GLOBALS['TYPO3_CONF_VARS']['SYS']['localization']['locales']['user']['en'] = 'English';
to the ext_localconf.php
of an extension.
(See: https://docs.typo3.org/typo3cms/CoreApiReference/latest/ApiOverview/Internationalization/ManagingTranslations.html#custom-languages)
In TYPO3 v9.5 this does not work any more because the method
typo3/sysext/core/Classes/Localization/Locales.php::initialize()
which inizaliazes all the locales,
is called from typo3/sysext/core/Classes/Core/Bootstrap.php
in line 123 but the ext_localconf.php
are included after that in line 138 of the Bootstrap.php::init()
method.
- Status changed from New to Under Review
Loading order is an important here, and can likely break.
TBH, looking at Code in TYPO3 v7.6 it is exactly at the same place as in v9. AFTER AdditionalConfiguration and BEFORE ext_localconf inclusion. This means _ if _ we change something here (like "initializing Locales AFTER ext_localconf.php) this is a breaking change. because ANY extension could depend on Locales being already initialized.
In docs I did not find any place where ext_localconf.php is mentioned to add user-defined locales - in our projects we always place it in AdditionalConfiguration.php or LocalConfiguration.php, as it is project-specific.
So there are two ways to solve this:
- Re-initialize Locales after ext_localconf.php (but keep it before as well to maintain backwards compatibility) with a note to remove the first initialize() call in v10.0 (= breaking) - this has a little bit of performance drawbacks (because it is instantiated at every call).
- Call Locales::initialize() in your extensions' ext_localconf.php after adding the user-defined locales
When the order of AdditionalConfiguration
and ext_localconf.php
inclusion in TYPO3 v7.6 was the same as in v9.5. How was it possible to use xlf files for e.g. "en" by adding $GLOBALS['TYPO3_CONF_VARS']['SYS']['localization']['locales']['user']['en'] = 'English';
to the ext_localconf.php
of an extension?
I think the answer is: In TYPO3 v7.6 the Locales::initialize
method is called a second time from the TypoScriptFrontendController
.
Call stack of the first execution:
Classes/Localization/Locales.php.TYPO3\CMS\Core\Localization\Locales::initialize:143
Classes/Core/Bootstrap.php.TYPO3\CMS\Core\Core\Bootstrap->initializeL10nLocales:649
Classes/Core/Bootstrap.php.TYPO3\CMS\Core\Core\Bootstrap->loadConfigurationAndInitialize:405
Classes/Core/Bootstrap.php.TYPO3\CMS\Core\Core\Bootstrap->configure:171
Classes/Http/Application.php.TYPO3\CMS\Frontend\Http\Application->__construct:67
www/index.php.{closure:XXXXX/typo3_src-7.6.30/index.php:31-34}:33
www/index.php.{main}:34
Call stack of the second execution:
Classes/Localization/Locales.php.TYPO3\CMS\Core\Localization\Locales::initialize:143
Classes/Controller/TypoScriptFrontendController.php.TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->initLLvars:4612
Classes/Controller/TypoScriptFrontendController.php.TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->settingLanguage:2694
Classes/Http/RequestHandler.php.TYPO3\CMS\Frontend\Http\RequestHandler->handleRequest:187
Classes/Core/Bootstrap.php.TYPO3\CMS\Core\Core\Bootstrap->handleRequest:308
Classes/Http/Application.php.TYPO3\CMS\Frontend\Http\Application->run:78
www/index.php.{closure:XXXXX/typo3_src-7.6.30/index.php:31-34}:33
www/index.php.{main}:34
In TYPO3 v9.5 the Locales::initialize()
method is only called once.
Call Stack:
Classes/Localization/Locales.php.TYPO3\CMS\Core\Localization\Locales::initialize:139
Classes/Core/Bootstrap.php.TYPO3\CMS\Core\Core\Bootstrap::init:123
index.php.{closure:XXXX/TYPO3.CMS/index.php:21-25}:24
index.php.{main}:25
I think that makes sense to implement that again at the TypoScriptFrontendController. Presumably this is there, because in TypoScript also languages can be overwritten?
Benni: What do you say to that?
Guido Schmechel wrote:
I think that makes sense to implement that again at the TypoScriptFrontendController. Presumably this is there, because in TypoScript also languages can be overwritten?
Benni: What do you say to that?
Thanks for further information!
Just rechecked, seems like v8 worked the same way as v7. In order to fix this, we should add this again into v9/master at the same place, with a note why this is done.
However, we should then create a followup patch to add this AFTER ext_localconf.php in the bootstrap for master later on as a breaking change.
Benni Mack wrote:
Just rechecked, seems like v8 worked the same way as v7. In order to fix this, we should add this again into v9/master at the same place, with a note why this is done.
However, we should then create a followup patch to add this AFTER ext_localconf.php in the bootstrap for master later on as a breaking change.
I think this is a good approach.
I will edit the current patch und build then a follow-up patch. Thanks for your feedback!
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF