Bug #46525
closed
locallangXMLOverride not working with all expected paths
0%
Description
The locallangXMLOverride makes it possible to override any translation in TYPO3. Having worked on real case, I found out that it worked only if the localization file was located inside an extension.
The following works:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['fr']['EXT:lang/locallang_general.xlf'][] = 'EXT:custom_config/Resources/Private/Language/fr.locallang_general_override.xlf'; $GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['fr']['EXT:lang/locallang_general.xlf'][] = PATH_typo3conf . 'custom_config/Resources/Private/Language/fr.locallang_general_override.xlf';
but that doesn't:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['fr']['EXT:lang/locallang_general.xlf'][] = 'fileadmin/custom/fr.locallang_general_override.xlf'; $GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['fr']['EXT:lang/locallang_general.xlf'][] = PATH_typo3conf . 'l10n/custom/fr.locallang_general_override.xlf';
I couldn't track where this goes wrong. The l10n code is somewhat convoluted, calling itself recursively (with flags to prevent that), so I gave up after a while.
Updated by Andreas Kiessling about 11 years ago
Have you tried overriding with a locallang.xml instead of an xlf file?
This could be related to http://forum.typo3.org/index.php?t=msg&goto=677062 and thus #31806
Updated by Mathias Schreiber over 9 years ago
- Status changed from New to Needs Feedback
- Assignee set to Mathias Schreiber
- Is Regression set to No
is this still the case?
Markus did some good stuff in this field
Updated by Francois Suter over 9 years ago
I'll try to find some time to test again in the near future. Thanks for bumping up the topic.
Updated by Marcus Schwemer about 9 years ago
Hi,
I can confirm that this issue still exists in TYPO3 6.2.9. The first path notation with "EXT:<extname>" works. The latter with "fileadmin" does not.
Kind regards,
Marcus
Updated by Vitoandre D'Oria almost 9 years ago
At least fileadmin works (other paths probably too) for me using XML files instead XLF.
XLF support is not only useless (see various tickets on forge) in its current state but also a syntax mess :-/
The "XLF outside folders" is also a known problem - see important box here:
A working alternative (not tested with folders other than fileadmin):
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['EXT:lang/locallang_general.xlf'][] = 'fileadmin/custom_config/Resources/Private/Language/locallang_general.xml';
Because XML files hold translations for multiple languages you just create 1 xml. TYPO3 will correctly select the translation then and it works outside a extension.
Furthermore i don't understand why this weird syntax was choosen:
// Default language $GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['EXT:lang/locallang_general.xlf'][] = .. // FR Translation $GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['fr']['EXT:lang/locallang_general.xlf'][] = ..
Why do we have standardized file names but use 2 different syntax here? Wouldn't it be more logical to use this syntax:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['EXT:lang/locallang_general.fr.xlf'][] = ...
or just:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['EXT:lang/locallang_general.xlf'][] = ...
like with XML files one declaration for all translations? The "translated" names are obvious locallang_general.xlf becomes locallang_general.fr.xlf. Why are we even supposed to handle this? The translation classes should imho do that internally or is that syntax performance related?
or even:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['default']['EXT:lang/locallang_general.xlf'][] = ... $GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['fr']['EXT:lang/locallang_general.xlf'][] = ...
It really feels dirty to use XML files these days but with that very limited XLF support there is not much besides forcing people to create a Extensions to override a translation in another Extension which is imho exaggerated.
That and the knowledge that the Core team wants or already made the /typo3conf/extTables.php deprecated is beyond my understandings...
Gaining all the knowledge about this did cost me hours because the translation docu (see link above) was at that time broken as well :-/
Only managed to get a clue about that after finding the files on github:
Sincerely a frustrated Language Override user :D
Updated by Alexander Opitz almost 9 years ago
- Status changed from Needs Feedback to New
Updated by Riccardo De Contardi over 3 years ago
- Status changed from New to Needs Feedback
This issue seems solved on 9.5.19
this is the test I performed on a fresh 9.5.19 (composer installation) with a "local" frontend package extension EXT:bhsiteconf
1) I downloaded the core language pack for Italian language
2) I changed the backend language to italian for the admin user
3) I used for test the label EXT:extensionmanager/Resources/Private/Language/locallang.xlf:installedExtensions :
<trans-unit id="installedExtensions" resname="installedExtensions">
<source>Installed Extensions</source>
</trans-unit>
4) I searched for the corresponding file it.locallang.xlf and found it on var/labels/it/extensionmanager/Resources/Private/Language/it.locallang.xlf
5) I copied the file it.locallang.xlf inside /fileadmin/ and modified the label:
<trans-unit id="installedExtensions" resname="installedExtensions" approved="yes">
<source>Installed Extensions</source>
<target state="translated">Estensioni installate xoxoxo</target>
</trans-unit>
6) I edited EXT:bhsiteconf/ext_localconf.php as per the documentation: https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Internationalization/ManagingTranslations.html#custom-translations. with the line:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['it']['EXT:extensionmanager/Resources/Private/Language/locallang.xlf'][] = 'fileadmin/it.locallang.xlf';
7) Flushed all the caches
Result¶
The extension manager interface show the label "Estensioni installate xoxoxo"
Apart from the "ugliness" of the override syntax (yes, it is ugly), is this test sufficient or a different one should be performed?
Updated by Christian Kuhn over 2 years ago
- Status changed from Needs Feedback to Closed
Closing due to lack of further feedback. Please re-open or create a fresh issue if this is still an issue.