Project

General

Profile

Actions

Bug #91104

closed

LocalizationUtility:translate() behaves differently when entering lowercase extension key

Added by Thomas Pronold about 4 years ago. Updated about 2 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Localization
Target version:
-
Start date:
2020-04-18
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
easy
Is Regression:
Sprint Focus:

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

translate_bug.zip (11.8 KB) translate_bug.zip Thomas Pronold, 2020-04-18 10:54

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #100759: f:translate does not take overrides of labels in TypoScript into account anymoreResolved2023-04-26

Actions
Actions #1

Updated by Gerrit Code Review about 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

Actions #2

Updated by Thomas Pronold about 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".

Actions #3

Updated by Gerrit Code Review about 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

Actions #4

Updated by Gerrit Code Review about 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

Actions #5

Updated by Christian Kuhn 8 months ago

  • Related to Bug #100759: f:translate does not take overrides of labels in TypoScript into account anymore added
Actions #6

Updated by Markus Klein 2 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.

Actions #7

Updated by Christian Kuhn about 2 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.

Actions

Also available in: Atom PDF