Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Backend translation helper in Fusion #3638

Closed
mhsdesign opened this issue Mar 16, 2022 · 8 comments · Fixed by #3939
Closed

Feature: Backend translation helper in Fusion #3638

mhsdesign opened this issue Mar 16, 2022 · 8 comments · Fixed by #3939

Comments

@mhsdesign
Copy link
Member

mhsdesign commented Mar 16, 2022

we discussed, that we want to modernize the backend modules with fusion and also this task #3261 is in need to translate in the language of the current backend user. - This language can differ from the language of the general content.

there a two main ways to archive this:

1 - build a BackendTranslationHelper that 'uses' the normal TranslationHelper
2 - build a BackendUserLanguageHelper or have another way to access the user language with fusion, and composite it together yourself.

  • option 1 would lead to lots of dirty code inheritance stuff (like how fluid archived the <neos:backend.translate>

    ) or when using composition lots of duplication, and one might be wondering if the api is the same like for the normal translationhelper.

  • option 2 would be much more understandable and transparent, as we just composite ourselfs the functionality and know how the Translation helper works:

${Translation.id('someId').locale(Neos.BackendUserLanguageHelper.get())}

but the constant duplication of locale(Neos.BackendUserLanguageHelper.get()) will get tiring

can/should we introduce a prototype for this or simplify this?

@mficzel
Copy link
Member

mficzel commented Mar 16, 2022

Hmm how about doing this:

translation = ${Translation.package('Neos.Flow').source('main')}
renderer = afx`
   {props.translation.id("example")} - {props.translation.id("other-example").arguments({number:12})}
`

Would require to make the methods in the TranlationParameterToken immutable and add some more functions to the TranslationHelper.

@mhsdesign
Copy link
Member Author

mhsdesign commented Mar 16, 2022

i approve your general idea, but isnt your example missing out on the language part?

i think in general the Translation Helper is due for a refactor - i dont like fx. that we have polymorphism for the method Translation.translate()

one can either pass in a single argument - a shorthand string or fully qualify all arguments - what seems not so cool i think. Those should be seperate methods IMO.

@mficzel
Copy link
Member

mficzel commented Mar 16, 2022

Agree that the translation helper needs a brushover alone since it currently does not support immutability. I do not get the language problem you mentioned. Usually the translation service already knows the language or otherwise one would.

translation = ${Translation.package('Neos.Flow').source('main')}
renderer = afx{props.translation.id("example").locale('fr')} - {props.translation.id("other-example").locale('en')}

I agree that the translate method on the TranslationParameter token is obsolete and redundant.

@mhsdesign
Copy link
Member Author

mhsdesign commented Mar 16, 2022

i mean the locale(Neos.BackendUserLanguageHelper.get()) part and if the constant duplication is okay - which i think, since one can re use the helper:

translation = ${Translation.package('Neos.Flow').source('main').locale(Neos.BackendUserLanguageHelper.get())}
renderer = afx`{props.translation.id("example")} - {props.translation.id("other-example")}`

(btw in the current case one needs to call the final translate method on the TranslationParameterToken - but this can also be solved maybe with some __toString magic ...)

@mficzel
Copy link
Member

mficzel commented Mar 16, 2022

Totally agree that the translation helper needs additions and a method to get the current language makes sense to me.

The __toString magic is already in place but sometimes code does not like that yet. We could support string|stringable in eel helpers and fusion where possible.

@mhsdesign
Copy link
Member Author

jop sometimes __toString doenst work - maybe fusion could check after evaluating a path, if the result is stringable and then call toString ?

@mhsdesign
Copy link
Member Author

@mficzel oops i used in my demos above language instead of locale - is corrected.

@mhsdesign
Copy link
Member Author

So i think we need a Neos.BackendUser.getCurrentUserLanguage() eel helper that can be used as argument in ${Translation.package('Neos.Flow').source('main').locale(Neos.BackendUser.getCurrentUserLanguage()).id('foo-bar')}

Instead of mimicking the way fluid did it - which is creating a whole new translation view helper instead of using composition and reusing the "normal" translation helper.

@mhsdesign mhsdesign changed the title Backend translation in Fusion Feature: Backend translation helper in Fusion Oct 26, 2022
mhsdesign added a commit to mhsdesign/neos-development-collection that referenced this issue Oct 27, 2022
closes neos#3638
implemented as discussed in neos#3638

yes you are correct - the `implements ProtectedContextAwareInterface` would not be needed in this case as we rely on ObjectAccess::getProperty, but i implemented it so that in the future `Neos.BackendUser.getInterfaceLanguage()` is still disallowed as one should use `Neos.BackendUser.interfaceLanguage`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants