Nils' argument is one of the main reasons why I switched to message keys. So +1 for message keys from me.
- Dennis 2011/2/21 Nils Adermann <[email protected]> > 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/9523sometime >> 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 > -- 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
