Bug #100760
closed
f:translate: Provide possibility to set a default extensionName
0%
Description
In non-extbase usages of f:translate it is cumbersome to repeat the current extensionName for every label usage.
It makes the templates harder to read and requires manual migration of all templates for v12 without any benefit.
It must be possible to set the current extensionName again centrally so f:translate can use it.
Idea: Use a new attribute on the request?
Updated by Christian Kuhn 12 months ago
- Related to Bug #100758: Viewhelpers and other things do not work outside of extbase context added
Updated by Christian Kuhn 12 months 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 Christian Kuhn 8 months ago
- Status changed from New to Needs Feedback
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?
Updated by Markus Klein 8 months ago
Hey,
thanks for your heads up here.
The key+extname combination is more doable than the full LLL stuff. Both solutions clutter the Fluid code a lot, IMO.
But I'd like to separate this into two fields of application: a) FLUIDTEMPLATE and b) extensions using StandaloneView
a) I did not try yet, if things are initialized there so I can keep using f:translate(id:'some.key.from.my.sitesetup'). If this works, all is good.
b) Your suggestion on initializing StandaloneView properly is fully ok. One had to do this anyways already in the past.
In general I agree on you in regards of magic and stuff, but I learned over time that some conventions (implying magic) are better than having everything explicit.
"Usage search" of labels is still pretty easy when normal translate-vh syntax is used, the whole xliff-key is there already.
(Side note: Having labels spread over multiple xlf files never worked conveniently in the past anyways, so there is hardly any extension I know of, which uses more than the locallang.xlf for the view rendering)
The main point for me here is simply, that the Core changes potentially cause many many dev hours, which do not cause a real benefit. Neither for the code's readability, nor for performance, nor for the customers budget.
Not all devs are skilled RegEx geeks, so some manual cumbersome diff-review is needed.
To drop a number: Our three largest extensions alone (Resources folder; 2x extbase, 1x pibase with StandaloneViews) make a total of 1898 f:translate usages as of now. And that's not counting all the customized extension templates used in the various customer instances then.
Updated by Markus Klein 8 months ago
- Status changed from Needs Feedback to Closed
- Priority changed from Must have to Won't have this time
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).