The TranslateViewHelper is meant to be used for message translation in Fluid Templates.It has two modes of work:
- 'originalLabel' - the source label is used as a key, for which translated label is searched
- 'id' - key ID is given in order to find translation
<f:translate mode="originalLabel" source="main">Untranslated label</f:translate> <f:translate mode="id" source="main">user.unregistered</f:translate>
This ViewHelper supports plural forms, and parameters (values) substitution and formating. It is a wrapper for \F3\FLOW3\I18n\Translator class.
Updated by Karol Gusak over 11 years ago
- Status changed from Accepted to Needs Feedback
- % Done changed from 0 to 50
I just committed the TranslateViewHelper. I didn't write the v4 version as don't have knowledge in this (particularly I use a class that is only in FLOW3).
Please comment what do you think about this helper and it's usage.
Updated by Bastian Waidelich over 11 years ago
thanks for your work on the translate ViewHelper for v5!
I didn't test it yet, but some personal considerations anyways:
1. We're trying to avoid magic strings (a parameter that is expected to contain a certain string).
In this case I'm not really happy with the $mode parameter, that is only allowed to be "originalLabel" or "id".
2. If the specified locale identifier is invalid, you currently return the default label. This seems a bit error-prone. Instead I'd re-throw the exception here so we can handle it depending on the context (e.g. display an error in Development mode, silently skip value in production context)
3. Wouldn't it make sense to specify a default value for the $source argument (e.g. "main")? So you could omit it by default.
4. In the v4 translation ViewHelper we have a $htmlEscape parameter that you can set to FALSE if your translation contains HTML. I guess, this is deprecated in v5 so we probably don't have to support this.
And last but not least: The current behavior and signature of the translation ViewHelper differs greatly from the v4 implementation. It would make migrations much easier, if it would be more compatible.
public function render($source, $mode = 'originalLabel', array $values = array(), $quantity = NULL, $locale = NULL)
The render method signature could be:
public function render($key = NULL, $default = NULL, array $arguments = NULL, $source = 'main', $quantity = NULL, $locale = NULL)
Please have a look at attached patch. It's just an untested, unfinished suggestion. What do you think of it?
Updated by Karol Gusak about 11 years ago
I had a feeling about the magic strings ;-). But it's not in FLOW3 CGL AFAIK.
I didn't set the default source's name as I didn't feel I should decide the name by myself :-). But I wrote on my blog that it should be done, and I think the "main" name is most appropriate.
I agree with the exception when locale is invalid, it makes more sense.
I applied the patch and updated unit test.
Thank you for your help!
Updated by Sebastian Kurfuerst about 11 years ago
thanks for putting so much effort into the GSOC Project -- it's really cool to see your progress!
Just an idea: What about creating two different ViewHelpers -- one for translating by ID, one for translating by source string?
@Bastian, what do you think about that?
Updated by Bastian Waidelich about 11 years ago
Sebastian Kurfuerst wrote:
Just an idea: What about creating two different ViewHelpers --
one for translating by ID, one for translating by source string?
Yes no yes.. I'm not sure about this one ;)
If I got it right, translation by original label is a new feature:
Would output "Users" as long as there is no translation in the current locale for the string "Users".
Translating by id would be similar to the v4 approach:
Would output "Users" as long as there is no translation in the current locale for the id/key "userLabel".
Is that correct?
What would be the suggested way - using id or original labels as source?
BTW: the default source name could be "default" as well (instead of "main") ;)