Project

General

Profile

Actions

Bug #64085

closed

locallangXMLOverride not reliable working

Added by Heiko Kromm almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Localization
Target version:
-
Start date:
2015-01-02
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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.

Actions #1

Updated by Markus Klein almost 10 years ago

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?

Actions #2

Updated by Heiko Kromm almost 10 years ago

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.

Actions #3

Updated by Markus Klein almost 10 years ago

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']?

Actions #4

Updated by Heiko Kromm almost 10 years ago

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.

Actions #5

Updated by Markus Klein almost 10 years ago

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.

Actions #6

Updated by Heiko Kromm almost 10 years ago

TYPO3 Core has a lot of files. Any hints on where to start debugging?

Actions #7

Updated by Markus Klein almost 10 years ago

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.

Actions #8

Updated by Heiko Kromm almost 10 years ago

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/

Actions #9

Updated by Markus Klein almost 10 years ago

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.

Actions #10

Updated by Markus Klein almost 10 years ago

  • 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.

Actions #11

Updated by Heiko Kromm almost 10 years ago

I updated the documentation.
You can close this ticket.

Actions #12

Updated by Markus Klein almost 10 years ago

  • Status changed from Needs Feedback to Closed

Thanks a lot!

Actions

Also available in: Atom PDF