I agree that message keys have significant advantages and I would prefer
they were used. Another reason in favour of them is that short english
strings might actually have different meanings depending on their
context. If you use something like {{ trans "post" }} in your template
in multiple places, the correct german translation might be "Beitrag" or
"absenden" depending on how it is used. With message keys you could use
{{ trans post-item }} and {{ trans post-action }} which both translate
to "post" in English but to "Beitrag and "absenden" respectively in German.
Nils
On 02/21/2011 01:19 PM, Lukas Kahwe Smith wrote:
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
