Bug #91104
closedLocalizationUtility:translate() behaves differently when entering lowercase extension key
0%
Description
I tracked down an inconsequent behavior of 'LocalizationUtility::translate()' in version 9.5.15
I want to translate an extension doing the TypoScript _LOCAL_LANG config:
plugin.tx_translationtest._LOCAL_LANG.default { message = My translation }
When you do a call to 'LocalizationUtility::translate()' and provide a lowercase extensionKey as 2nd parameter like this:
LocalizationUtility:translate('message', 'translation_test');
The translation set by _LOCAL_LANG will only be used when:
a) the extension_key has no _ underscore (translationtest2)
b) you do enter the extensionName (TranslationTest)
c) when the extension_key has _ underscore, but there exists a cached version caused by b) from a call before.
I think the fact that a lot of core code almost never is an underscore extension this bug has not appeared yet. Besides that, if you are lucky and your extension is doing it right once and all subsequent calls can use the caches data, you will never know either.
extension_key usage as 2nd parameter in core is all over the place, even though documentation states, that extensionName should be used as a parameter.
LocalizationUtility::translate('LLL:EXT:beuser/Resources/Private/Language/locallang_mod_permission.xlf:WorkspaceWarning', 'beuser'),
This could easily be fixed, when 'LocalizationUtility::translate()' converts an extensionKey silently to uppercamelcase extensionName. I would happily create the patch, just tell me.
If there is a certain reason, why extensionName only should be used, then it might be time to update all core code not to use an extension_key as a parameter to comply with the function declaration.
Attached zip with 2 extensions, which can be used to see the bug. Just install the extensions, include static templates, view the site.
Go to TranslationController of translation_test and comment lines to see the difference.
Files