I forgot to add the "default argument" against "default as keys" as another pro/contra pair: keys can easily get out of sync. If it's hard for a developer to come up with a good key for a translation (while focussing on development) then it's even harder to come up with the final English message at this point: there's a good chance for it to change, so one has to propagate that change to translation files. (Again, depending on your setup and environment that might be more or less hassle.)
Btw having default translations in your code, no matter how clean or cluttered that seems to anybody, will fight one of the major original points that brought up this discussion: separation of roles (dev vs editors vs marketing vs translators etc.) On 26.04.2009, at 20:31, Hongli Lai wrote: > > (Note: I'm biased towards the Gettext approach, after having used it > to translate desktop applications) > > After reading all the replies I think the issue boils down to "default > translations as key" vs "symbols as keys". > > "default transactions as key": > 1. Pro: lots of existing, mature Gettext tools for creating > translations, detecting stale/outdated translations, generating > translation statistics, etc. > For example non-tech savvy translators can use Poedit to create the > translations, which should be the most fool-proof thing after a web > interface. > 2. Pro: can easily fallback to the default translation. > This is a huge benefit if you don't have a reliable translation > team, i.e. not all translations are always kept up-to-date. This way > the user interface can at least fallback to an English string, which > is still better than presenting the user with an empty string, a > symbol or an error message. This is > the case for many open source projects, but probably not so for > enterprise > developers. > 3. Pro: the default translation makes the code easier to understand. > Symbols are usually a lot more opaque. > 4. Con: it's not 100% straightforward. Developers who implement a > localization framework themselves for the first time would probably > use the symbol approach. Developers need some training in order to get > used to Gettext's workflow of marking strings for translation, > extracting them with tools, editing the translation files and > compiling the translation files. > 5. Con: not possible for translators to change the default text > without editing the source code. > 6. Con: Ruby-related Gettext tools still suck. For example Ruby- > Gettext Rails plugin cannot extract strings from Haml templates. I've > seen someone reinvent his own localization framework based on symbols > because of this. > > "symbols as keys": > 7. Pro: easy to understand for new developers. Most people who > implement a localization framework for the first time would probably > use this approach. > 8. Pro: possible for translators to change the default text without > editing the source code. > 9. Pro: allows falling back to a related string, e.g. > "errors.article.invalid" => "errors.model.invalid". > 10. Con: very limited tool support, even worse than Ruby-Gettext. > 11. Con: makes code more opaque; the meaning of a symbol is not always > immediately obvious until the programmer sees the associated string. > > It's arguable whether 9 really is a pro. Has there even been any need > for this feature? I figure that in most applications, most symbols > have no related fallback symbol, and so a missing translation usually > results in an error. Gettext falls back to the default string which is > usually English, which is still better than presenting the user with > the symbol or with an empty string. > > 4 is pretty awkward for developers who are just getting into > localization, but I blame it on documentation. There shouldn't be any > problems if the documentation is good. The need to manually > compile .po files to .mo files can be solved with the right code. > Rails could, for example, auto-compile modified .po files during > startup, or someone could write a .po parser and load .po files > directly. > > 6 and 10 can be fixed given enough effort. > > So this leaves 5/8 and 3/11 as the only fundamental issues, which are > also mutually exclusive: the ability to change the default string > without letting translators to mess with the source code (Rails I18n), > and whether embedding default strings in the source code makes it > easier to understand than using symbols (Gettext). > 3/11 might be arguable, I'm sure there are developers out there who > don't think that using symbols makes their code more opaque. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
