Hi,
= Executive summary ;-)
the most important question is, whether the core team would sacrifice
*some* parts of humanize, pluralize and other string concatenation
voodoo, especially in ActiveRecord to allow for 100% linguistically
correct translations and smooth, enterprise-ready localization
workflow.
This, together with other improvements, would make broader adoption
of Rails in a more traditional environment, outside start-ups,
possible.
Currently we have to put a lot of effort into monkey patching to work
around the opinionated decisions baked in into Rails. My hope was
that Rails3 is planned to become a more of general purpose
web framework.
Other questions are only technical details, supporting such
a decision.
= Details
Regarding default human readable string as a key Hongli Lai listed
some pros and cons, let me turn the three remaining cons to pros
and we get a solution, that has only advantages ;-)
> 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.
I've found the gettext workflow easy to grasp for new developers
in every team I have worked with so far.
For self-didacts high quality documentation (to be written) should
be enough.
> 5. Con: not possible for translators to change the default text
> without editing the source code.
Missing possibility of changing the default string has never been an
issue,
neither in my personal decade of writing international applications
(different open source platforms, Microsoft.net and pre-dot-net) nor
for big
open source projects with longer history. For commercial grade
applications the marketing department or release team is going to
translate
our hacker- English to marketing-conform English anyway. BTW,
separately
for every English speaking country to account for cultural
differences,
e.g. translations differ between UK and South-Africa.
The case with a typo in the default message can be handled the same
way as a typo in the symbol-name - as a bug, it can be corrected
in all the relevant files. There is even some tool support in gettext
for this - fuzzy matching and checking for missing translations.
> 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.
Masao is currently rewriting ruby-gettext. I personally currently
prefer
the fast_gettext - not because it is fast, but because it has a more
straightforward implementation. As opposite to ruby-gettext it does
not make attempts to monkey-patch the Rails.
Regarding the parsing of Haml templates - the implementation will
likely be up to the Haml users. It can be based on ruby-gettext
typical
parsing of source code for string literals.
Sven Fuchs wrote:
> It turned out
> that this implementation seems to work for (as you say) 95% of all
> usecases which is much more than we expected.
So this solution does not qualify for any serious enterprise or
governmental (European Union) application. 100% linguistically correct
translations are required. 95% is much less that is expected from us.
> 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.
All the kinds of hierarchically organized scopes (computed keys)
and (optional) translation inheritance do not work in environment
with role separation. Inheritance and method overriding
work in OOP. But it does not work for translations.
A translation agency needs a comprehensive and flat list
of strings to be translated. To be able to make a
decision about to override or not to override or where to override
they would need to analyse the application source code. Only manually
created and obligatory translation scope makes sense. This is a kind
of message from developer to the translation team. The gettext
convention is to use the pipe character.
_("Search|I'm feeling lucky")
_("Mood poll|I'm feeling lucky")
> 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.)
And since then adapted for 20 different programming languages.
Bindings
for dynamic language, e.g. Python are very nice. Same API can be used
for Ruby too.
> 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. ?
Sounds complicated...
BTW,
* pluralization rules are different for different languages,
gettext uses a formula in a programming language per language for
that
* some languages have 3 or 5 plural forms as opposite to 2 in English
and German
* only complete sentence can be pluralized, not a single word
Gettext accounts for all that - in code and in the tool chain,
Rails I18n - not. So before spending much more time and effort on yet
another I18n implementation, we should focus on integrating a
perfectly
solid solution that is known to work. Fixing and patching and hoping
for
a >95% solution won't get Rails where many would like to see it in the
near future, i.e. in bigger enterprise-y environments.
The question remains, whether this really is the direction towards
Rails
is heading. If so, we would contribute a solid Gettext based I18n
implementation that addresses the aforementioned issues. This however
requires some breaking changes within the Rails core and a consensus
about the necessity of them being addressed.
Best Regards,
Vladimir
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
