TYPO3 Core

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.

@Christian Kuhn this should still work in Extbase context in v12, and is thus considered a bug IMHO. Will check it out

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

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.

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.

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.

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.

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?

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>
  )
}

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

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

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

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

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

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