(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 -~----------~----~----~----~------~----~------~--~---
