Bug #64085
closed
locallangXMLOverride not reliable working
Added by Heiko Kromm almost 10 years ago.
Updated almost 10 years ago.
Description
It seems that locallangXMLOverride is not working reliable.
I have overwritten some labels of a locallang.xlf with another locallang.xlf inside my own extension.
Mostly the label is overwritten, but sometimes not. I made some tests to figure this out.
I have a label on every page, which is overwritten with locallangXMLOverride. If I clear the cache and open the page the label is overwritten.
But if I open a page which does not exist (404) and open the page where the label is on afterwards, the label is not overwritten.
I suspect, that the override is not triggered if I open a 404 page and there is a caching for the locallang which is not filled correctly in this case.
Can you please provide clear testing instructions?
I have overwritten some labels of a locallang.xlf with another locallang.xlf inside my own extension.
How do you do that?
Hi Marcus,
I have an extension which I call my skin_base.
There I have a locallang.xlf file located in Resources/Private/Language
Therefore I want to use fluid templates I initialize an extbase plugin it in my setup.
page.10 = USER
page.10 {
userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run
pluginName = BasePagelayout
extensionName = SkinBase
controller = Page
vendorName = Vendor
action = index
view {
templateRootPaths.100 = {$plugin.tx_skin_base.view.templateRootPath}
partialRootPaths.100 = {$plugin.tx_skin_base.view.partialRootPath}
layoutRootPaths.100 = {$plugin.tx_skin_base.view.layoutRootPath}
}
}
In my fluid-Templates I use labels from the locallang.xlf with
<f:translate key="label1" />
In my second extension (lets call it skin_special) i override the locallang.xlf in ext_tables.php with:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['EXT:skin_base/Resources/Private/Language/locallang.xlf'][] = 'EXT:skin_special/Resources/Private/Language/locallang.xlf';
Hope this helps to reproduce behaviour.
Alright, now I'm on the same track. ;-)
This is for sure not extbase related. I'm even not sure if it is cache related (at least not language cache).
We need to find the trace to where the 404 error is triggered, so we can find out whether language handling is evaluated properly.
What is the exact message you see when accessing the non-existing page, which triggers the 404?
What is your configuration for TYPO3_CONF_VARS['FE']['pageNotFound_handling']?
I use pagenotfoundhandling extension for 404 error handling. Therefore I'm redirected to an existing page in the pagetree.
$TYPO3_CONF_VARS['FE']['pageNotFound_handling'] = 'USER_FUNCTION:Tx_Pagenotfoundhandling_Controller_PagenotfoundController->main';
If I disable the extension I get this error "Page Not Found Reason: Segment "sdfsdf" was not a keyword for a postVarSet as expected on page with id=1.". I think this is produced by realurl.
TYPO3_CONF_VARS['FE']['pageNotFound_handling'] is empty in this case, but the error still occurs.
I guess you've to debug that.
I don't have suitable setup to test this currently, sorry.
If you need help on the debugging just ask here.
TYPO3 Core has a lot of files. Any hints on where to start debugging?
Ah sure, here are some hints.
start with
\TYPO3\CMS\Core\Localization\LocalizationFactory::getParsedData()
and
\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::getPageAndRootline()
The first one fetches the languages and takes care of the overrides and the second one triggers the 404.
There must be some difference in the execution path for the cases you mentioned.
Thanks for the hint where to start from.
I think I found something. $GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride'] is empty if it is set in ext_tables.php. If I set it in ext_localconf.php it works.
I don't know if this is the right place, because the examples I found place it in ext_tables.php (see sysext/core/ext_tables.php). But if ext_localconf.php is the right place I think it should be documented here: http://docs.typo3.org/typo3cms/CoreApiReference/6.2/Internationalization/Translation/
I already suspected something like this yesterday, but thought it should be ok because of the usages in the core.
From my gut feeling I'd say it should be in the ext_localconf.
- Status changed from New to Needs Feedback
I checked the Core usages now. The ext_tables usage in the Core is fine as the labels are only needed in BE.
If you need them in FE too, you need to define that in ext_localconf.
You can help to update the documentation by simply using the "Edit me on Github" button. Thanks!
If this information is enough for you, I'd close this issue.
I updated the documentation.
You can close this ticket.
- Status changed from Needs Feedback to Closed
Also available in: Atom
PDF