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
Comments
Hmm how about doing this:
Would require to make the methods in the TranlationParameterToken immutable and add some more functions to the TranslationHelper. |
i approve your general idea, but isnt your example missing out on the language part? i think in general the 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. |
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')} I agree that the translate method on the TranslationParameter token is obsolete and redundant. |
i mean the
(btw in the current case one needs to call the final |
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. |
jop sometimes |
@mficzel oops i used in my demos above |
So i think we need a 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. |
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`
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 TranslationHelper2 - 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>
neos-development-collection/Neos.Neos/Classes/ViewHelpers/Backend/TranslateViewHelper.php
Line 94 in ddf0b3f
option 2 would be much more understandable and transparent, as we just composite ourselfs the functionality and know how the Translation helper works:
but the constant duplication of
locale(Neos.BackendUserLanguageHelper.get())
will get tiringcan/should we introduce a prototype for this or simplify this?
The text was updated successfully, but these errors were encountered: