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
Updated by Gerrit Code Review over 4 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64227
Updated by Thomas Pronold over 4 years ago
I put a little bit more thought into this thing, and I think the function should not accept lowercase extension keys at all. This would probably affect a couple of thousand core lines where this is happening. The underlying problem with this is, that in the ConfigurationManager, AbstractConfigurationManager classes, etc. is a lot of strtowlower() stuff going on, which works when "Core" becomes "core" but does not work with MyExt and my_ext, the result is ofc different. myext and my_ext...
Even the current tests are written with "core" as a parameter and do fail when using "Core".
Updated by Gerrit Code Review over 4 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64227
Updated by Gerrit Code Review over 4 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64227
Updated by Christian Kuhn 12 months ago
- Related to Bug #100759: f:translate does not take overrides of labels in TypoScript into account anymore added
Updated by Markus Klein 6 months ago
- Status changed from Under Review to Needs Feedback
I trend to close this issue.
The parameter description clearly states "extensionName", so does the argument description of the f:translate VH.
Updated by Christian Kuhn 6 months ago
- Status changed from Needs Feedback to Closed
I agree we should close here for now: The apparent mess with underscore vs. lower camel case vs. upper camel case (especially in extbase magic) can probably only be resolved if we entirely ditch the 'extension name' approach, switch to composer package names instead, and use them throughout the system. This is far beyond the scope of this issue.