On 21.02.2011, at 11:54, Bernhard Schussek wrote:
> Hi all,
>
> I would like to propose changing the best practices for translations.
> Right now, we use English texts as originals and refer to these texts
> in translation files, for example:
>
> {{ trans "This field is required" }}
> "This field is required": "Dieses Feld muss ausgefüllt werden"
>
> This approach has various advantages and drawbacks. A post by
> Christian summed them up very nicely[1]:
>
> + No abstract thinking involved when creating templates, the
> additional effort is almost zero.
> + The templates are understandable by all developers and designers
> + If you i18n:extract your translation files they will be easy to
> translate without visiting the application
> + Your application will work even without translation files
>
> - Can very easy mislead you to maintain the texts within your
> templates rather than the translation files
> - Can be confusing to find the source of a text as both keys and
> translations are very similar
> - Ugly escaping when quotes are part of your keys
> - Missing translations are not immediately recognisable and so keys
> can “go live” instead of the correct translations
>
> One more drawback, added by me:
>
> - Long term maintenance becomes difficult. Even making small changes
> to original texts (typos, wording) breaks all translation files.
>
> Apart from that, I see a major drawback from the framework-developer
> POV: We can't change the default translations provided with the
> framework. Imagine that at some point we realize that we want to be
> nice and change the default message to "Please fill out this field".
> It's impossible, because it breaks BC.
>
> I would like to change this practice to using message keys by default.
> The above example would become:
>
> {{ trans field.required }}
> field.required: "This field is required"
>
> Again, Christian's pros and cons:
>
> + Easily groupable (Separation of Concerns again) to focus on buttons,
> captures, titles etc..
> + Easy to spot missing translations as these kind of key on a website
> stick out visually
> + Easy to grep in both templates and i18n files
> + Translations are always in the appropriate files
>
> - Needs a well documented convention how to define the keys
> - Too abstract, it can be hard to understand what a key “says” when
> your convention is not good enough
> - Hard to maintain translation files without looking at the rendered
> templates to get a sense of context
>
> Another benefit I see:
>
> + Copywriters can change texts independently of template designers
>
> To quote his conclusion:
>
> "In the short run using abstract keys might be a little more effort.
> On the long tail however you separated your transaltions (wordings)
> from your templates which makes it easy to maintain."
>
> I understand that using real language keys the framework is easier to
> learn for beginners. The problem is that once people realize the
> imposed maintenance problems, it's impossible or very difficult to
> gracefully change to using message keys. Doing that late requires that
> your developers, designers, copywriters AND translators learn
> completely new practices, which is a lot of effort.
>
> I also understand that by using message keys in the framework, all
> components with internationalization support (e.g. Validator) would
> require the Translator as dependency. On the other hand, this is a
> very philosophical drawback that IMO doesn't outweigh the advantages
> of message keys at all.
>
> What are your thoughts on this?
>
> Bernhard
>
>
> [1] http://test.ical.ly/2010/04/13/i18n-best-practices-for-symfony-templates/
I am looking at fixing http://trac.symfony-project.org/ticket/9523 sometime
this week.
At this point you will know what messages are safe to be shown to the user, but
it will still be a nightmare for users to determine the actual possible strings
they will need to provide translation for. If we would use translation keys
with a specific format one could at least grep for this.
Then again all Security Exceptions extend from a common class, one could of
course just list the possible strings as class constants.
Not really sure what the best approach is, but for my own projects I certainly
favor message keys. One solution could of course be to set both an english text
and a message key. Dunno what is really feasible.
regards,
Lukas Kahwe Smith
[email protected]
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
