Hi Hongli,
cool, that's a great writeup! Thanks for turning this discussion
towards more practical points :)
Perhaps it helps when I also add some disclaimer about myself. I'm not
biased towards or against Gettext in any way, too. I've used it a lot
a quite some years ago. In fact it was me who repeatedly tried to get
Gettext people on board while we worked on Rails I18n. I do think
though that the API in fact is the best bread of all solutions for
Rails we had previously, including ruby-gettext. That of course
doesn't mean it can not be improved, but to me it means we should not
go back to a less flexible API.
In your list I'd suggest that 9.) is just an example of a more
abstract point: "Symbols as keys" makes it possible to compute keys.
You can not compute default translations. Rails itself leverages that
for validation messages, I've seen people using it for "resourceful
controllers" (e.g. flash messages) and there are tons of other
situations where this is useful. Computing keys allows you to define a
generic translation that works for most of the situations and
overwrite that for particular situations where you need something
special - thus effectively reducing the amout of repetition a lot. You
can also react to contexts (e.g. pick a particular translation
depending on the type of an object) flexibly where you'd otherwise
need to use generic translations/messages. Thus, I believe that
"Symbols as keys" allow for a more abstract way of coding.
I'd also suggest to add another pair of pro/con arguments to the list.
Using "defaults as keys" usually means that you have the actual
translations cluttered throughout your code. Of course, Gettext allows
you to "announce" translated strings through gettext_noop when you
want to collect messages at a central place but that requirement
really feels much more like jumping through hoops than just using
Symbols in the first place.
(Also, I'd like to remind of the motivations that lead to such
solutions as Gibberish, Globalite (not Globalize) and
SimpleLocalization. People wanted a simple and clean API, they
explicitely did not want to mess with Gettext which was designed,
let's face it, in 1994 for C. It feels old and awkward to many.)
I really wonder though if both approaches actually are mutually
exclusive, or mutually exclusive in all areas (Rails core, plugin
land, user/dev/app land).
Imagine a helper like this:
def _(msg)
I18n.t(msg, :default => msg)
end
For pluralization there could be a similar helper. This should work
for all messages that do not contain a dot. I wonder if we can get rid
of this limitation. Approaches that come to my mind:
1. Make the scope separator (dot) configurable. That might mean that
Rails core should not continue using dots as separators (but instead
just use Arrays for scopes).
2. Escape/unescape dots in the helper.
3. ?
Btw. re "Gettext falls back to the default string which is usually
English" - you can do the same thing easily with Rails I18n. It just
wasn't part of our original requirements ("the simple backend works
for English") so we left locale fallbacks to the plugin land.
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
-~----------~----~----~----~------~----~------~--~---
