Very important point, this annoys me with language as source.
On Mon, 21 Feb 2011 13:31:40 +0100, Nils Adermann <[email protected]>
wrote:
> 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
