Hey Saimon,
I hope you feel better. Thanks for clarifying few details and thanks
for generating this healthy discussion.
Since we are talking about the core localization, we obviously have to
talk about it's internationalization.
I have a problem when we use real language strings as translation
keys. If you don't mind I'd like to discuss this issue.
Let's say we use English strings as base for localization and out
string looks like: 'There were problems with the following fields:'.
The string itself becomes the translation key or translation reference
if you will. Each language will use this string as reference. The
obvious problem occurs when the English is modified. If the string
becomes: 'There were problems with the following fields' or "A problem
occurred with the following fields:'then all the translations are
broken.
(in globalize, I believe the recommended way is to create a dummy
language and to use it base language)
Which leads me to another question: should the Core be language
agnostic? We could certainly use translation keys linked to no
specific languages. For instance:
active_record_default_error_messages.
We already have something quite similar in AR. In this specific case
we have a class variable containing a hash using symbols to reference
each message:
Module ActiveRecord
# Active Record validation is reported to and from this object,
which is used by Base#save to
# determine whether the object in a valid state to be saved. See
usage example in Validations.
class Errors
include Enumerable
@@default_error_messages = {
:inclusion => "is not included in the list",
:exclusion => "is reserved",
:invalid => "is invalid",
:confirmation => "doesn't match confirmation",
:accepted => "must be accepted",
:empty => "can't be empty",
:blank => "can't be blank",
:too_long => "is too long (maximum is %d characters)",
:too_short => "is too short (minimum is %d characters)",
:wrong_length => "is the wrong length (should be %d
characters)",
:taken => "has already been taken",
:not_a_number => "is not a number",
:greater_than => "must be greater than %d",
:greater_than_or_equal_to => "must be greater than or equal to
%d",
:equal_to => "must be equal to %d",
:less_than => "must be less than %d",
:less_than_or_equal_to => "must be less than or equal to %d",
:odd => "must be odd",
:even => "must be even"
}
It makes things really clean and easy to change and/or overwrite.
To help people understand better the challenge, here is the list of
all the hardcoded English strings that need to be overwritten to use
Rails in a different language:
http://globalite.googlecode.com/svn/trunk/lang/rails/en-US.yml
Not a big deal really, but the problem is that we all have to monkey
patch many core classes to translate the hardcoded strings. (it's not
always cleanly done as in ActiveRecord Errors.
The advantage of using such as format is that you can create your own
namespacing by
1/ using class variables.
2/ using constants (please don't)
3/ namespacing your key: active_record_errors_key
My other concern is that if we do our job properly, I *think* we
should be able to release a Rails version (without any required
plugins) where "ONLY" the core should be available in multiple
languages.
During last RailsConf I had a discussion with David Heinemeier Hansson
regarding the very same issue. If I remember correctly, the agreement
was that the core team should only be responsible for the English
localization of the Core, the rest would be up to the community as
it's the case at the moment.
Why not making this API a bit more useful and provide for the needs of
80% of the foreign users out there and making the core dead simple to
localize. I'm not talking about anything complicated, just drop/
overwrite/load a file in Rails and all the core strings are now in
your language.
Anything else can be handle by 3rd party plugins, UI localization/
internationalization, database content, anything else than the core is
up to the developer to deal with. But when it comes to the core, a
simple file should be sufficient. (I'm not talking about supporting
multiple languages at the same time)
If you think about it, most Rails developers (I would guess above 98%)
only use Rails in one language. It might be English, Spanish, French,
Chinese or Swahili, their app is only in one language. I believe this
is what we should focus on: how to make their life easier. Let's not
focus our energy on the 2% managing content in multiple languages at
the same time, let's keep things as simple as possible.
My suggested way of doing that is to push any hardcoded English
strings into a class or a yaml file and load it at runtime. That's
exactly the concept behind Simple localization (
http://simple-localization.arkanis.de/
), GlobaLite ( http://code.google.com/p/globalite/ ) and gibberish
( http://errtheblog.com/post/4396 ). Dead simple, already done by many
plugins and not 'too' obtrusive.
I'd be interested in knowing what you guys think of that suggestion
and the key vs English string issue.
-Matt
p.s: if you are a developer using Rails in a different language than
English, please let us what you would expect when it comes to having
Rails 'speak' your language.
On Oct 2, 3:48 am, saimon <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Sorry for my delayed response (I was feeling a bit under the weather).
>
> I'm very happy that our patch is receiving this kind of attention as
> it shows that a lot of people are seriously interested in i18n hooks
> appearing in rails core.
>
> Also the main reason we decided to add the patch (in it's current
> state) was to generate just exactly this kind of discussion which is
> great as this is exactly what is happening. Whatever api eventually
> does get in to rails core, it should be one that has the blessing of
> all developers directly involved in i18n rails development.
>
> Here are my views on what has been said (I'm including things
> mentioned in trac)
>
> - In the current patch, the translation method has been added to
> String, Date, DateTime & Time.
>
> - The reason we decided to use String#t rather than String#translate
> was mainly one of convenience and readability. As this method will
> need to be added to many fixed strings throughout the rails core
> codebase we opted for something short and sweet which wouldn't add to
> much baggage to the rails code itself. I think that String#t can
> quickly become a symbol that every rails developer associates with
> translation. Saying that I'm not really bothered either way. A
> String#translate method (with aliasing as required) would also be
> acceptable to me but I think we should get a consensus on this between
> all interested parties. I don't think the api itself should do any
> aliasing. i.e. If the hook method is translate, any aliasing should be
> done by the api implementors and the rails core code itself should use
> the unaliased method.
>
> - The issue of pluralization is a tricky one. In order for a string to
> be translatable the entire string needs to be passed to String#t.
>
> i.e. consider the following (from action_view/helpers/
> active_record_helper.rb):
>
> #134 header_message = "#{pluralize(count, 'error')} prohibited this
> #{(options[:object_name] || params.first).to_s.gsub('_', ' ')} from
> being saved"
>
> There are two ways of ensuring that this string is translatable:
>
> 1. header_message = "#{pluralize(count, 'error')} prohibited this
> #{(options[:object_name] || params.first).to_s.gsub('_', ' ')} from
> being saved".t
>
> 2. header_message = "%d errors prohibited this
> #{(options[:object_name] || params.first).to_s.gsub('_', ' ')} from
> being saved".t(count)
>
> Version 1 just passes the entire string to String#t (noop) and assumes
> the api implementer can handle the translation of this string.
>
> Version 2 modifies the string making it clear that the string has a
> plural that has a dynamic value making it easy for api implementers
> to handle the pluralization of this string in other languages. Yes,
> this isn't a noop but it's of very little cost and provides a
> significant advantage over version 1.
>
> - Simple strings that don't require pluralization, in the this patch,
> are just returned as is (i.e. noop)
>
> - The patch currently provides for simple/multiple interpolation
> (again another non-noop) but this by no means is required to be done
> by the String#t method for any string, rather it's mainly used when a
> string has a plural and avoiding the noop is not possible.
>
> - The issue of namespacing is again another topic that is best to be
> discussed about up front which is partly the reason why we introduced
> the assumption in the patch. Namespacing of translatable strings has
> many obvious advantages. But it seems to me that a big win for them is
> their use in exactly the situation we're in. i.e. Making fixed strings
> in a framework translatable. It seems logical to me, that all fixed
> strings in rails core be automatically (and silently) added to a
> particular namespace in order to avoid clashing.
>
> In fact, the default implementation does not even have to physically
> add these strings to any particular namespace, it can just be assumed
> that for the api all rails core strings should be added to the 'rails'
> namespace by any implementors (Thus reducing clutter in rails core).
>
> As far as, the actual syntax for namespaces is concerned, we like
> the idea of using a Symbol (or Array of symbols for nested namespaces)
> to denote the namespace but again this is definitely open for
> discussion. We like the idea of the following mapping of arguments to
> String#t:
>
> String -> Interpolated value
> Integer -> Plural value
> Symbol -> Namespace
>
> But it's true that other i18n implementations use Symbol as the key
> for translations so we should agree on some common ground.
> IMO, a translatable string is already a key, in the same regard as
> using a symbol for this purpose. You can always provide a distinct
> 'translation' in the language it's written it.
>
> I also think it's beneficial that the API be flexible enough to
> allow the use of Strings and/or Symbols as the translation key. Saying
> this, I don't see how this clashes with the use of Symbol as an
> argument to #t/#translate
>
> As I just mentioned, the handling of namespaces (which I think is an
> integral part of any i18n lib) could be left completely up to the
> implementor but I think it's a good idea that the api forces a
> particular syntax otherwise you end up with lot's of different types
> of syntax for namespaces making it less flexible for users when
> switching between implementations. Again, let's discuss this further.
>
> - I don't see any particular reason why this API should have to
> 'purposefully' wait until after rails 2.0 though in fact, I assumed
> this to be the case given the lateness of it's appearance and the time
> required to get a consensus between interested parties and a clean
> usable patch against the entire rails codebase.
>
> But I do think this is something to be pushed along as quickly as
> possible to perhaps make it in for an inevitable 2.0.x rails release.
> Josh and I, will certainly be promoting this.
>
> Just to reiterate that this patch is meant for people to play with and
> discuss over and NOT as a proposed real patch. i.e. We don't consider
> it by no means +1able yet.
>
> Finally, let me add my voice to the call for other prominent i18n/core
> rails developers to voice their opinions on this issue so we can get
> to a consensus as soon as possible.
>
> Regards,
>
> Saimon
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
