+1 from me. The same is used in Rails[1]. Its easier to group your translations by Controller/View this way.
For myself, I don't want to write the correct text myself. I find myself doing "text stubbing" while developing. And, when a grammar error appears all translations needs to be changed. [1] http://guides.rubyonrails.org/i18n.html#internationalizing-your-application -----Original Message----- From: "Bernhard Schussek" <[email protected]> Sent: Monday, 21 February, 2011 11:54 To: "symfony developers" <[email protected]> Subject: [symfony-devs] [Symfony2] RFC - Changing translation sources to message keys 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/ -- 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
