Bug #100759
closedf:translate does not take overrides of labels in TypoScript into account anymore
Added by Markus Klein over 1 year ago. Updated about 1 month ago.
100%
Description
This is a crucial feature for integrators, who need to adjust a label from an extension.
Expected behaviour:
Overriding labels via Template should work for extbase and non-extbase extensions. Specifically using Fluid.
plugin.tx_myext_pi1._LOCAL_LANG.de.shop\.checkout = Jetzt bestellen!
<button type="submit">{f:translate(id:'shop.checkout')}</button>
Updated by Christian Kuhn over 1 year ago
- Related to Bug #100758: Viewhelpers and other things do not work outside of extbase context added
Updated by Christian Kuhn over 1 year ago
all three issue were planned as such. they're not bugs.
if changed again, they need proper decision, impact and analysis before. just stating different than before is not good enough.
Updated by Benni Mack over 1 year ago
@Christian Kuhn this should still work in Extbase context in v12, and is thus considered a bug IMHO. Will check it out
Updated by Markus Klein over 1 year ago
In order to have things more precise:
- TS label override should work for f:translate() within extbase extensions
- TS label override should work for f:translate() within non-extbase extensions
I'll update the ticket description
Updated by Benni Mack over 1 year ago
Markus Klein wrote in #note-4:
In order to have things more precise:
- TS label override should work for f:translate() within extbase extensions
- TS label override should work for f:translate() within non-extbase extensions
I'll update the ticket description
Just to be clear:
Tested this in a v12.4.1 installation:
plugin.tx_blog._LOCAL_LANG.de.list\.no_posts\.title = Hier gibt es keine Posts, nochmal suchen! <f:translate key="list.no_posts.title" extensionName="blog" />
Works as expected with EXT:blog (a small fork, but not touching the translate viewhelper).
for pi_based plugins using the pi-base API (inside abstract plugin) should work without problems. Using pi-based plugins with Fluid and translate ViewHelper - tbh, that is ugly. Using <f:translate> in e.g. your Page Template does not use the TypoScript yet, however could be achieved by using the `frontend.typoscript` attribute from the $request and use the same overloading technique as used in LocalizationUtility.
Updated by Jo Hasenau over 1 year ago
Benni Mack wrote in #note-8:
Works as expected with EXT:blog (a small fork, but not touching the translate viewhelper).
for pi_based plugins using the pi-base API (inside abstract plugin) should work without problems. Using pi-based plugins with Fluid and translate ViewHelper - tbh, that is ugly.
Just for clarification: There is not only Extbase or pi-base but extensions like i.e. Gridelements, that don't use any kind of xxx-base, but core API methods and Fluid templates. Still Gridelements is not a good example for this case though, because it is not touched by this bug, since it does not provide predefined labels for the FE output, but lots of other extensions do.
For them this is a breaking change, that was introduced by removing the Extbase request from Fluid - which is good - while keeping the dependency on Extbase in some viewhelpers that are used quite a lot - which is bad, since it renders the concept of StandaloneFluid useless.
So the question is, if it is possible to remove the Extbase dependency from those viewhelpers too, while still providing the same TypoScript mechanics that would have been there with Extbase.
Updated by Markus Klein over 1 year ago
Using pi-based plugins with Fluid and translate ViewHelper - tbh, that is ugly
I disagree on this as well. Fluid should not be bound to Extbase. Yes, you needed to initialize the StandaloneView correctly in the past, but then this worked flawlessly. f:translate, f:form, everything.
Updated by Markus Klein over 1 year ago
Here is our code to initialize the view within our non-extbase extension:
protected function getFluidTemplate(string $partialName = ''): StandaloneView
{
/** @var StandaloneView $view */
$view = GeneralUtility::makeInstance(StandaloneView::class);
$uriBuilder = FrontendUtility::getFrontendUriBuilder();
$request = $uriBuilder->getRequest();
$request->setPluginName($this->parent->getPluginName());
$request->setControllerExtensionName('Comot');
$request->setControllerName($this->name);
$request->setControllerActionName($this->action);
$controllerContext = GeneralUtility::makeInstance(ControllerContext::class);
$controllerContext->setRequest($request);
$controllerContext->setUriBuilder($uriBuilder);
$view->setControllerContext($controllerContext);
$view->getRenderingContext()->getViewHelperVariableContainer()->add('comot', 'context', new ComotViewContext($this->errorFields));
$view->setLayoutRootPaths($this->parent->getConfigurationByPath('view./layouts.'));
$view->setPartialRootPaths($this->parent->getConfigurationByPath('view./partials.'));
...
}
Pretty easy and straight forward.
Updated by Christian Kuhn 12 months ago
Ok, I tried working on this with https://review.typo3.org/c/Packages/TYPO3.CMS/+/80732 - current patch set 4 basically just adds test cases for current extbase behavior, my idea was to implement the non-extbase version and have the same behavior.
However, extbase itself is inconsistent: There is issue https://forge.typo3.org/issues/58960 (which actually may be fixed meanwhile, but I'm not sure), and there is issue https://forge.typo3.org/issues/91104 (which my current patch set shows is still a thing?).
So in extbase, we at least have the "underscore" problematic, and I stumbled upon this:
Works:
plugin.tx_testtranslate._LOCAL_LANG.de-DE.localized\.to\.de = TypoScript de label
Does not work:
plugin.tx_testtranslate._LOCAL_LANG.de.localized\.to\.de = TypoScript de label
It seems since v12 "de-DE" instead of "de" needs to be used? This is probably from https://review.typo3.org/c/Packages/TYPO3.CMS/+/77399 ? TSref documents "de" should work in https://docs.typo3.org/m/typo3/reference-typoscript/main/en-us/TopLevelObjects/Plugin.html#local-lang-lang-key-label-key
I'm currently a bit unsure on how to proceed here for a potential non-extbase implementation (which uses the typoscript request attribute), when the extbase implementation is so funny ...
Other detail: We should be able to retrieve the "extension key" - either from the LLL string, or from the extensionName argument. A lookup like "plugin.tx_my_extension._LOCAL_LANG" will then work. But we won't have the "pluginName" so "plugin.tx_my_extension_pi1" won't be possible (which seems be possible in the current extbase variant).
@Benni Mack you stated in https://forge.typo3.org/issues/100759#note-8 that "de" worked for you. Could you recheck? Reading the code, it uses LU::getLanguageKey(), which uses $siteLanguage->getTypo3Language(), which is the "language_COUNTRY" combination and there is no further fallback for "language" only? Did I miss something or is my patch test setup broken?
Updated by Christian Kuhn 12 months ago
- Related to Bug #91104: LocalizationUtility:translate() behaves differently when entering lowercase extension key added
Updated by Christian Kuhn 12 months ago
- Related to Bug #58960: Localization overwrite with multiple plugins from the same extension added
Updated by Christian Kuhn 12 months ago
- Related to Task #99559: Allow to override labels in LanguageService added
Updated by Gerrit Code Review 12 months ago
- Status changed from New to Under Review
Patch set 5 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80732
Updated by Astrid Haubold 10 months ago
- Related to Story #101565: Frontend related translation issues added
Updated by Jonas Eberle 9 months ago
Here is a little MRE (avoiding de-DE etc.) that used to work in v11.
plugin.tx_felogin._LOCAL_LANG { default { username = overwriting username my = new key } } page = PAGE page.1 = FLUIDTEMPLATE page.1 { template = TEXT template.value ( key="username": <f:translate key="username" extensionName="felogin" /> <br> key="my" : <f:translate key="my" extensionName="felogin" /> <br> ) }
Updated by Christian Kuhn 9 months ago
- Related to Bug #101710: Translate ViewHelper does not accept custom languageKey in non-extbase context added
Updated by Garvin Hicking 9 months ago
- Related to Bug #102579: typo3Language Site Configuration set to a full locale instead of language key added
Updated by Gerrit Code Review 9 months ago
Patch set 6 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80732
Updated by Gerrit Code Review 9 months ago
Patch set 7 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80732
Updated by Gerrit Code Review 9 months ago
Patch set 8 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80732
Updated by Gerrit Code Review 9 months ago
Patch set 1 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82023
Updated by Christian Kuhn 9 months ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset ed503f9019e4dc7e7fe842a17fceeb90197422cc.
Updated by Gerrit Code Review 9 months ago
- Status changed from Resolved to Under Review
Patch set 2 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82023
Updated by Gerrit Code Review 9 months ago
Patch set 3 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82023
Updated by Gerrit Code Review 9 months ago
Patch set 4 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/82023
Updated by Christian Kuhn 9 months ago
- Status changed from Under Review to Resolved
Applied in changeset 490f12697b840257d1694b741e02834bad02e6e8.
Updated by Christian Kuhn 7 months ago
- Related to Bug #102638: #1666513645 RuntimeException Setup array has not been initialized. This happens in cached Frontend scope where full TypoScript is not needed by the system. added