RFC: Site package as the default package for f:translate when rendering via TypoScript

Creating Neos & Flow Code
1

Using the <f:translate> view helper in a site package without a package argument will use TYPO3.Neos for the current package.

That means all translate helpers in custom templates for node types will look like:

{f:translate(id: 'my.funny.label', value: 'Translate me', package: 'Vendor.MySite')}

This makes templates harder to read and maintain and is not consistent with the behavior in Flow (because no site author thinks about having TYPO3.Neos as the context). We should think about using the site package (or owning package that defines the TypoScript?) as the default for the package argument when rendering Fluid via TypoScript.

3 Likes
2

Hey Christopher,

totally fine for me to do it that way :smile:

All the best,
Sebastian

3

I would like that, but I am pretty sure that we had it like that around 1.0 and it had some nasty side effects why we changed it to be Neos. So we need to carefully check what the problems could be.

4

One thing is consistency. While the current handling may not be intuitive, it is consistent. If f:translate now uses the site package as default, will people the resource VHs expect to also do that? Where is the point this stops?

5

Obviously it would have to work for everything in a Fluid template.

6

I wonder where you want to override the behavior? We have a custom translate ViewHelper for the Neos backend (which IMO is unfortunate btw) but it would be odd if this has different defaults.

Originally we thought about being able to override default values for all VH arguments via TypoScript (so that you could set the width argument of the image VH to a certain value in the side bar for example).
But with the flexibility of the current architecture of Neos that feature was never really needed…

An alternative to using Fluid VHs for localization could be some labels-Variable that could be available in all TS templates {labels.my_funny_label}. Or a post-processor that replaces placeholders… Just a thought that popped up right now

7

Why not add a neos:translate ViewHelper to neos that defaults to the current site-package. Fluid itself does’nt know neos and site-packages so to me it would make sense to use a derived viewHelper for that.

8

Yes, that could work well. We need to consider the case that I’m using the view helper in a template of a different package though (e.g. rendering some TS object with template of a Blog plugin). So instead of using the current site package we should rather have the owning package of the template as the default package.

9

IMO it’s a technical depth to have too many custom VH in the neos package especially for content element template as it makes it more complex to use them.
We already have a <neos:backend.translate />ViewHelper that behaves like the original one, but not just.

Unfortunately I don’t have a better solution but I would greatly favor a generic approach. Maybe by tinkering ViewHelperVariableContainervia TS and then some minor adjustments to the original VH, like:

if ($locale === NULL && $this->viewHelperVariableContainer->exists(TranslateViewHelper::class, 'defaultLocale')) {
	$locale = $this->viewHelperVariableContainer->get(TranslateViewHelper::class, 'defaultLocale');
}
1 Like
10

So maybe we can find a way to set a more clever current package key in the context of TypoScript and Neos. So we could basically use your suggestion and keep everything BC (mostly, unless you needed the Neos package for labels which doesn’t make a lot of sense until 2.0).

11

Is there even a nice way to change the default package used in the f:translate view helper? It’s using the request to determine the package and that’s not something we can change to e.g. the site. Hence I’d suggest that if we were to make this easier a new Neos translate view helper would be the best approach. Don’t see much of a problem in having multiple ones with slight differences, as long as they are clear and documented. I wouldn’t recommend doing anything smart about plugin packages though, they should include their package key in the usage of the view helpers in it’s distributed templates. That also makes it a lot easier to copy and paste the template to adjust it, since you don’t need to add the package key for every time that is done.

12

I think for plugins it should already work by using f:translate since the plugin request should have the correct package key set (even if you override the template with a Views.yaml).

13

I think, it’s a major problem to be honest.
We spent a lot of energy into making Content Element templates as similar to the “usual fluid templating” as possible (by removing the need of wrapping everything in a content element ViewHelper for example).
Having three different ways to create localized labels withing a fluid template makes its usage more complex - even if it’s documented.

I absolutely agree, that we shouldn’t be too smart about it, but IMO the suggested solution is not too “magic” and at least worth a try:
Make it possible to read/write to the ViewHelperVariableContainer from TypoScript.
That would allow the ViewHelpers to fall back to different defaults if an argument is not specified.
We’d have to be careful of where to implement this, but possible features include:

  • default width/height of images depending on the context (e.g. sidebar, footer, …)
  • default translation package
  • default locale (would replace the backend.translate ViewHelper)
  • …

The respective ViewHelper must support that of course

14

Sounds feasible to me, however that’s not something we can do for 2.0 as I see it. My point was more that if we had to use s.th. like AOP for it I would be against it. Also using view helpers from other packages became easier since the full namespace can now always be used without having to import it first.

1 Like