TYPO3 Core

Hey.

Some thoughts on this.

I'm rather strongly against having some global 'extensionName' within fluid apart from the existing extbase magic, especially if you just want to make f:translate resolve label files magically as is possible with extbase magic.

As a background, I think we're much better off when the majority of f:translate usages either supplies the full LLL:EXT string to specify the exact location, or uses the shortcut combination key="my.label" plus extension="my_extension" to resolve to locallang.xlf files. This make things specific and for instance allows checking for unused labels relatively easily - more explicit, less magic. In fact I even don't like the key+extension combination much which triggers this "oh, the dev probably meant my_extension/Resources/Private/locallang.xlf:my.label" magic. However, I accept that it's much more convenient to not have the lengthy LLL:EXT string in all template files, so fine with me. I remember we already talked about this details in early v12, you agreed this is an acceptable solution and said you'd then just regex this away in your projects easily. Did this change?

If you're still annoyed by having extensionName in your f:translate extension templates, you could also simply create the StandaloneView yourselfs (similar to the code you pointed out in https://forge.typo3.org/issues/100759#note-11 ), turn your request into an extbase request and hand it to RenderingContext. If your extensionName is set up correctly, f:translate (and other VH's like f:form and the uri builders) will switch to the extbase variant, and you can skip that extensionName attribute again. However, I think, we should not put this into the core, nor create different additional state to transfer the extension name information.

What do you think?

Summary after a meeting between Christian an me:

a) For StandaloneView cases it is possible to create an ExtbaseRequest manually, then the context for f:translate is correct
b) For FLUIDTEMPLATE cases it is necessary to adjust the viewhelper usage and add `extensionName="MyExtensionName"` accordingly. An according documentation will be added to v12, which outlines this in detail.

Rationale for a)
If PHP code is already there that used f:translate in the shortest form already in the past, there has always been some initialization that made this possible. It is straight forward to adjust this and set the necessary ExtbaseRequest

Rationale for b)
It would require to heavily restructure how the Fluid view is set up. (It is also not desirable to re-create the ExtbaseContext in this content object just for this, as this would also cause other side effects once Fluid is switched into "extbase mode".)

This means we can close this issue, as the documentation part will be taken care of with #100758 (most probably).