For everybody coming in from the various Rails blogs, we're glad to
have you here. I18n support in Rails is a pretty big change, and it
was tough to decide how to structure it. We'd love to hear lots of
feedback from everybody, so that we can tweak the code for the next
Rails release.
Please feel free to suggest changes and ask questions.
On Jul 20, 7:47 am, "jos...@gmail.com" <jos...@gmail.com> wrote:
> For everybody coming in from the various Rails blogs, we're glad to
> have you here. I18n support in Rails is a pretty big change, and it
> was tough to decide how to structure it. We'd love to hear lots of
> feedback from everybody, so that we can tweak the code for the next
> Rails release.
I'm very excited about i18n support in Rails core, but I'm not quite
sure how to take advantage of it in practice. From my (very basic)
understanding, the new stuff in core is more foundational than
functional. Is another plugin necessary in order to provide
translations of text in views and flash messages for an app, or is
that something which can be accomplished in some simple way with the
features now available in core?
I have an open-source application that a few people have started to
work on localized versions of, and I'm hoping to leverage the i18n
stuff in core to make adding different languages possible. Is there a
tutorial that might point me on the right track? Perhaps an example
application? I think something like this would be very helpful for
other people like me who aren't much into core contributions or plugin
authorship - end users, if you will :)
Thanks for the questions, Trevor. The code we added to Rails is intended to be foundational, like you said. The included "simple" backend was designed to allow the rails code to work in en-US with the i18n gem, and to allow easy override of the built-in messages, and no more. To be able to actually i18nize your app, you'll probably need a plugin that will make use of this new API.
I know we at Globalize are planning to work right away on a new version of our plugin to make use of the finalized Rail API, and I expected other i18n plugin devs to do the same. So it was important to us to get this API finalized and in the Rails core so that everybody will have a stable interface to work off of. This group might also be a good place for people to outline what they need in an i18n plugin, for the benefit of the plugin developers.
What you can do in your apps already with Rails edge, is build in i18n support via the new translation helpers and methods, so that when those first plugins do come out, you'll be ready for them.
On Sun, Jul 20, 2008 at 8:01 PM, Trevor Turk <trevort...@gmail.com> wrote:
> On Jul 20, 7:47 am, "jos...@gmail.com" <jos...@gmail.com> wrote: > > For everybody coming in from the various Rails blogs, we're glad to > > have you here. I18n support in Rails is a pretty big change, and it > > was tough to decide how to structure it. We'd love to hear lots of > > feedback from everybody, so that we can tweak the code for the next > > Rails release.
> I'm very excited about i18n support in Rails core, but I'm not quite > sure how to take advantage of it in practice. From my (very basic) > understanding, the new stuff in core is more foundational than > functional. Is another plugin necessary in order to provide > translations of text in views and flash messages for an app, or is > that something which can be accomplished in some simple way with the > features now available in core?
> I have an open-source application that a few people have started to > work on localized versions of, and I'm hoping to leverage the i18n > stuff in core to make adding different languages possible. Is there a > tutorial that might point me on the right track? Perhaps an example > application? I think something like this would be very helpful for > other people like me who aren't much into core contributions or plugin > authorship - end users, if you will :)
On Jul 20, 12:22 pm, "Joshua Harvey" <jos...@gmail.com> wrote:
> This group might also be a good place for people
> to outline what they need in an i18n plugin, for the benefit of the plugin
> developers.
I think that the only things necessary for my app would be a way to
provide localized versions of strings found in the view, including
flash messages. So, where it says "you are not logged in" or "post
created successfully" I would like to allow for translations of those
messages.
The plugins I've seen looked like they accomplished this by allowing a
key to be associated with a message (e.g. "you are not logged
in"[:not_logged_in]), a YAML file of translations associated with
those keys, and a way to choose between the YAML files to load (e.g.
choose between the different languages available).
> What you can do in your apps already with Rails edge, is build in i18n
> support via the new translation helpers and methods, so that when those
> first plugins do come out, you'll be ready for them.
My apologies, but I don't quite understand what you mean here. Perhaps
it would make sense for me to wait until there is a useable plugin out
so that I could just dive in and figure out how to use it? I don't
mean to be a bother, I'm just excited at the prospect.
You can do pretty much everything you mentioned with the I18n#t method and the "t" view helper (<%= t :key %>). Note that you'll just use symbols instead of messages in your code, and leave the actual textual messages (including in your base language, say English) for the translators. So in your code, instead of writing "you are not logged in", you'd do something like <%=t :not_logged_in %>. You'll need some kind of translation front end, or you'll have to edit YAML files, depending on the plugin.
The reason we didn't want to put strings right in the code is that if you decide to change the message text in the base language, that messes up the messages in the translated languages, and the message will no longer be translated correctly.
On Sun, Jul 20, 2008 at 8:52 PM, Trevor Turk <trevort...@gmail.com> wrote:
> On Jul 20, 12:22 pm, "Joshua Harvey" <jos...@gmail.com> wrote: > > This group might also be a good place for people > > to outline what they need in an i18n plugin, for the benefit of the plugin > > developers.
> I think that the only things necessary for my app would be a way to > provide localized versions of strings found in the view, including > flash messages. So, where it says "you are not logged in" or "post > created successfully" I would like to allow for translations of those > messages.
> The plugins I've seen looked like they accomplished this by allowing a > key to be associated with a message (e.g. "you are not logged > in"[:not_logged_in]), a YAML file of translations associated with > those keys, and a way to choose between the YAML files to load (e.g. > choose between the different languages available).
> > What you can do in your apps already with Rails edge, is build in i18n > > support via the new translation helpers and methods, so that when those > > first plugins do come out, you'll be ready for them.
> My apologies, but I don't quite understand what you mean here. Perhaps > it would make sense for me to wait until there is a useable plugin out > so that I could just dive in and figure out how to use it? I don't > mean to be a bother, I'm just excited at the prospect.
> You can do pretty much everything you mentioned with the I18n#t method
> and the "t" view helper (<%= t :key %>). Note that you'll just use
> symbols instead of messages in your code, and leave the actual textual
> messages (including in your base language, say English) for the
> translators. So in your code, instead of writing "you are not logged
> in", you'd do something like <%=t :not_logged_in %>. You'll need some
> kind of translation front end, or you'll have to edit YAML files,
> depending on the plugin.
> The reason we didn't want to put strings right in the code is that if
> you decide to change the message text in the base language, that
> messes up the messages in the translated languages, and the message
> will no longer be translated correctly.
One might add that
"you are not logged in"[:not_logged_in]
would translate to
<%= t :not_logged_in, :default => "you are not logged in" %>
in a view, or
I18n.t :not_logged_in, :default => "you are not logged in"
somewhere else, where Rails' TranslationHelper is not present ... if
you want to use default strings.
That does not mean though that plugins can't add different flavors of
syntax of course. E.g. on my blog someone suggested :not_logged_in.t
which is something we finally abstained from and left it up to plugin
devs.
> On Sun, Jul 20, 2008 at 8:52 PM, Trevor Turk <trevort...@gmail.com>
> wrote:
>> On Jul 20, 12:22 pm, "Joshua Harvey" <jos...@gmail.com> wrote:
>>> This group might also be a good place for people
>>> to outline what they need in an i18n plugin, for the benefit of
>>> the plugin
>>> developers.
>> I think that the only things necessary for my app would be a way to
>> provide localized versions of strings found in the view, including
>> flash messages. So, where it says "you are not logged in" or "post
>> created successfully" I would like to allow for translations of those
>> messages.
>> The plugins I've seen looked like they accomplished this by
>> allowing a
>> key to be associated with a message (e.g. "you are not logged
>> in"[:not_logged_in]), a YAML file of translations associated with
>> those keys, and a way to choose between the YAML files to load (e.g.
>> choose between the different languages available).
>>> What you can do in your apps already with Rails edge, is build in
>>> i18n
>>> support via the new translation helpers and methods, so that when
>>> those
>>> first plugins do come out, you'll be ready for them.
>> My apologies, but I don't quite understand what you mean here.
>> Perhaps
>> it would make sense for me to wait until there is a useable plugin
>> out
>> so that I could just dive in and figure out how to use it? I don't
>> mean to be a bother, I'm just excited at the prospect.
On Jul 20, 1:34 pm, "Joshua Harvey" <jos...@gmail.com> wrote:
> You can do pretty much everything you mentioned with the I18n#t method
> and the "t" view helper (<%= t :key %>)...
> You'll need some
> kind of translation front end, or you'll have to edit YAML files,
> depending on the plugin.
After rereading Sven's article, it sounds like I might even be able to
avoid using a plugin for my simple case. If I followed the same
technique covered in Sven's article under the "Populating the
translations storage" heading, I should be able to store the locale in
memory, which would then be accessible to the "t" helper. Taking a
quick look through the Rails source, it seems that a way to choose
from a list of available localizations to load (and to load the one
chosen) is all that is missing to meet my needs. Maybe I'm missing
something, though...
> On Jul 20, 1:34 pm, "Joshua Harvey" <jos...@gmail.com> wrote: >> You can do pretty much everything you mentioned with the I18n#t >> method >> and the "t" view helper (<%= t :key %>)... >> You'll need some >> kind of translation front end, or you'll have to edit YAML files, >> depending on the plugin.
> After rereading Sven's article, it sounds like I might even be able to > avoid using a plugin for my simple case.
Yes, I think that might work.
> If I followed the same > technique covered in Sven's article under the "Populating the > translations storage" heading, I should be able to store the locale in > memory, which would then be accessible to the "t" helper.
Yes.
> Taking a > quick look through the Rails source, it seems that a way to choose > from a list of available localizations to load (and to load the one > chosen) is all that is missing to meet my needs.
Yes, that's a feature we didn't add to the Simple backend.
Maybe the way to go might be that you'd just re-open the Simple backend and add that method yourself? I.e. your own mini-plugin for this purpose. Should be super easy to do.
> Maybe I'm missing something, though...
I don't think so :) If your app is simple that might be everything you need.
One thing to keep an eye on might me more nifty pluralization rules. That of course depends on the languages you need to support. The Simple backend (purposely) does not provide any means to customize the pluralization algorithm for now. Again, this is easy to extend though:
module MyPluralizationBackend include SimpleBackend def pluralize(*args) # your pluralization logic end end
I18n.backend = MyPluralizationBackend
HTH :)
If you succeed with this it would be mega awesome if you could write a short howto-style blog post about what it took to use the Rails I18n api for your app, cause that's something really missing right now.
On Jul 20, 3:29 pm, Sven Fuchs <svenfu...@artweb-design.de> wrote:
> Maybe the way to go might be that you'd just re-open the Simple
> backend and add that method yourself? I.e. your own mini-plugin for
> this purpose. Should be super easy to do.
I'm going to try this out, starting with just storing the default en-
US messages I have hard coded in the app separately. Then maybe I
could make a "pirate" localization or something like that to figure
out how to switch between localizations with an option and
before_filter.
> If you succeed with this it would be mega awesome if you could write a
> short howto-style blog post about what it took to use the Rails I18n
> api for your app, cause that's something really missing right now.
I'll start a branch in my app now and see what I can do. I've got
about 5 hours until I'm going to see the new Batman movie, but maybe I
can accomplish something before then :) I agree, having a short how-to
for adding simple localization capabilities to a Rails app would
probably help a lot of people - I'll give it a shot!
On Jul 20, 3:40 pm, Trevor Turk <trevort...@gmail.com> wrote:
> I'll start a branch in my app now and see what I can do. I've got
> about 5 hours until I'm going to see the new Batman movie, but maybe I
> can accomplish something before then :)
So, I'm having some problems getting up to edge in my app:
It's actually better this way, because it's so simple - you can really
see what's going on. I'm going to try and get flash messages working
now, but you can see the basics of what I did (and a little git noise)
in this commit:
If anybody knows a better way accomplish this, I'm all ears. I think
this could be a good way to show people the basic ways to use the new
i18n stuff, but maybe a blog post going through a "hello world" app
would be nice? In any case, I'm really liking what I see so far!
So, I guess that's about it for my basic needs. If anybody knows of a
better way to accomplish this same stuff, please let me know. I'm no
expert, but I'd be happy to do a quick write-up of the results with
sample code if this technique looks OK.
On Sun, Jul 20, 2008 at 4:47 PM, jos...@gmail.com <jos...@gmail.com> wrote: > Please feel free to suggest changes and ask questions.
First of all, it is really great that Rails gets some kind of i18n support, big step forward, thanks to all guys that made the push possible. My question is regarding better "conditional translations" support, if I can say so. One of biggest advantages of having i18n support in the Rails core is to avoid monkeypatching, and I still need monkeypatching right now to support Russian datetime translations, for example [1].
Is there any chance of adding some kind of lambda translations in the core?
Also, Sven suggested we may have a wiki for discussing stuff like that -- i.e. what other languages need from i18n that is not supported / well done right now, may be github project wiki will do?
> My question is regarding better "conditional translations" support, > if I can say so. One of biggest advantages of having i18n support in > the Rails core is to avoid monkeypatching, and I still need > monkeypatching right now to support Russian datetime translations, > for example [1].
I think you're right that this is one of the things not immediately supported by the api.
Sticking to the terminology of the api I'd say that what you want to do is *pluralize* the month names when localizing a date? Is that correct?
If so, do you probably additionally need pluralization algorithms for this purpose? Or are they the same as the pluralization rules for month names in general?
> Is there any chance of adding some kind of lambda translations in > the core?
I think that's unlikely at this point. I agree it's (although more theoretically) an edge case. But one can always replace the Simple backend by something more powerful.
I'd suggest you'd do exactly that: implement a backend that can cope with this sort of case, look for languages that have the same kind of requirement and publish it in some way. We could then, in our next "round", again cherrypick solutions (e.g. you're extension) and discuss whether they should go into core.
This approach forces us to first experiment with the api in our plugins (or extensions, custom backends, whatever) instead of just committing stuff to Rails - I believe this is an important point about the progress. (E.g.: the solution to Russian datetimes might not work for another language which might need only slightly different tweaks to the same stuff. This would become visible when you publish your solution. So you'd be able to fix that before it would go into core.)
> Also, Sven suggested we may have a wiki for discussing stuff like > that -- i.e. what other languages need from i18n that is not > supported / well done right now, may be github project wiki will do?
Yeah, maybe. Although I've rarely seen really useful GitHub wikis so far. Maybe the code repository is just not the place where people work actively with this sort of stuff.
I'm also planning to set up a site for this group at http://rails-i18n.org maybe including a wiki but that's not ready, yet.
On Mon, Jul 21, 2008 at 3:12 PM, Sven Fuchs <svenfu...@artweb-design.de>wrote:
> > My question is regarding better "conditional translations" support, > > if I can say so. One of biggest advantages of having i18n support in > > the Rails core is to avoid monkeypatching, and I still need > > monkeypatching right now to support Russian datetime translations, > > for example [1].
> I think you're right that this is one of the things not immediately > supported by the api.
> Sticking to the terminology of the api I'd say that what you want to > do is *pluralize* the month names when localizing a date? Is that > correct?
We need month name inflection; we need to inflect month names if we are displaying month name with a date -- you can see the logic here, http://rutils.rubyforge.org/svn/trunk/lib/datetime/datetime.rb Notice how RU_INFLECTED_MONTHNAMES constant is used in strftime. We need that in select_month as well.
> > Also, Sven suggested we may have a wiki for discussing stuff like > > that -- i.e. what other languages need from i18n that is not > > supported / well done right now, may be github project wiki will do?
> Yeah, maybe. Although I've rarely seen really useful GitHub wikis so > far.
So, I finally did some work on my blog again. I have made a short
introduction on i18n for beginners. I will add some more parts later
to cover more ground.
> For everybody coming in from the various Rails blogs, we're glad to
> have you here. I18n support in Rails is a pretty big change, and it
> was tough to decide how to structure it. We'd love to hear lots of
> feedback from everybody, so that we can tweak the code for the next
> Rails release.
> Please feel free to suggest changes and ask questions.
On Sat, Aug 9, 2008 at 12:05 AM, iain <i...@iain.nl> wrote:
> So, I finally did some work on my blog again. I have made a short > introduction on i18n for beginners. I will add some more parts later > to cover more ground.
> On Jul 20, 2:47 pm, "jos...@gmail.com" <jos...@gmail.com> wrote: > > For everybody coming in from the various Rails blogs, we're glad to > > have you here. I18n support in Rails is a pretty big change, and it > > was tough to decide how to structure it. We'd love to hear lots of > > feedback from everybody, so that we can tweak the code for the next > > Rails release.
> > Please feel free to suggest changes and ask questions.
> On Mon, Jul 21, 2008 at 3:12 PM, Sven Fuchs <svenfu...@artweb-design.de > > wrote: > I think you're right that this is one of the things not immediately > supported by the api.
> Sticking to the terminology of the api I'd say that what you want to > do is *pluralize* the month names when localizing a date? Is that > correct?
On 05.08.2008, at 17:23, Yaroslav Markin wrote:
> We need month name inflection; we need to inflect month names if we > are displaying month name with a date -- you can see the logic here, http://rutils.rubyforge.org/svn/trunk/lib/datetime/datetime.rb > Notice how RU_INFLECTED_MONTHNAMES constant is used in strftime. We > need that in select_month as well.
I going to use that example in my talk. Also, I think I really need to better understand what's happening here.
Stupidly, Mail.app does not let me paste those Russian month names to this email.
On Sat, Aug 9, 2008 at 12:43, Sven Fuchs <svenfu...@artweb-design.de> wrote:
> > On Mon, Jul 21, 2008 at 3:12 PM, Sven Fuchs <svenfu...@artweb-design.de
> > > wrote:
> > I think you're right that this is one of the things not immediately
> > supported by the api.
> > Sticking to the terminology of the api I'd say that what you want to
> > do is *pluralize* the month names when localizing a date? Is that
> > correct?
> On 05.08.2008, at 17:23, Yaroslav Markin wrote:
> > We need month name inflection; we need to inflect month names if we
> > are displaying month name with a date -- you can see the logic here,
> http://rutils.rubyforge.org/svn/trunk/lib/datetime/datetime.rb > > Notice how RU_INFLECTED_MONTHNAMES constant is used in strftime. We
> > need that in select_month as well.
> I going to use that example in my talk. Also, I think I really need to
> better understand what's happening here.
> Stupidly, Mail.app does not let me paste those Russian month names to
> this email.
So, am I right guessing that these month names are Nominative and
Genitive Singulars following to the "first declension"? That seems to
make sense to me.
> On Sat, Aug 9, 2008 at 12:43, Sven Fuchs <svenfuchs@artweb- > design.de> wrote:
> > On Mon, Jul 21, 2008 at 3:12 PM, Sven Fuchs <svenfu...@artweb-design.de
> > > wrote:
> > I think you're right that this is one of the things not immediately
> > supported by the api.
> > Sticking to the terminology of the api I'd say that what you want to
> > do is *pluralize* the month names when localizing a date? Is that
> > correct?
> On 05.08.2008, at 17:23, Yaroslav Markin wrote:
> > We need month name inflection; we need to inflect month names if we
> > are displaying month name with a date -- you can see the logic
> here, http://rutils.rubyforge.org/svn/trunk/lib/datetime/datetime.rb > > Notice how RU_INFLECTED_MONTHNAMES constant is used in strftime. We
> > need that in select_month as well.
> I going to use that example in my talk. Also, I think I really need to
> better understand what's happening here.
> Stupidly, Mail.app does not let me paste those Russian month names to
> this email.
On Sat, Aug 9, 2008 at 11:43 AM, Sven Fuchs <svenfu...@artweb-design.de> wrote:
>> On Mon, Jul 21, 2008 at 3:12 PM, Sven Fuchs <svenfu...@artweb-design.de >> > wrote:
>> I think you're right that this is one of the things not immediately >> supported by the api.
>> Sticking to the terminology of the api I'd say that what you want to >> do is *pluralize* the month names when localizing a date? Is that >> correct?
> On 05.08.2008, at 17:23, Yaroslav Markin wrote: >> We need month name inflection; we need to inflect month names if we >> are displaying month name with a date -- you can see the logic here, http://rutils.rubyforge.org/svn/trunk/lib/datetime/datetime.rb >> Notice how RU_INFLECTED_MONTHNAMES constant is used in strftime. We >> need that in select_month as well.
> I going to use that example in my talk. Also, I think I really need to > better understand what's happening here.
> Stupidly, Mail.app does not let me paste those Russian month names to > this email.
> So, am I right guessing that these month names are Nominative and > Genitive Singulars following to the "first declension"? That seems to > make sense to me.
> So, am I right guessing that these month names are Nominative and > Genitive Singulars following to the "first declension"? That seems to > make sense to me.
> Now I just need to learn how to pronounce them so I can read them in > my RailsConf Eu talk :D
> > On Sat, Aug 9, 2008 at 12:43, Sven Fuchs <svenfuchs@artweb- > > design.de> wrote:
> > > On Mon, Jul 21, 2008 at 3:12 PM, Sven Fuchs <svenfu...@artweb-design.de > > > > wrote:
> > > I think you're right that this is one of the things not immediately > > > supported by the api.
> > > Sticking to the terminology of the api I'd say that what you want to > > > do is *pluralize* the month names when localizing a date? Is that > > > correct?
> > On 05.08.2008, at 17:23, Yaroslav Markin wrote: > > > We need month name inflection; we need to inflect month names if we > > > are displaying month name with a date -- you can see the logic > > here, http://rutils.rubyforge.org/svn/trunk/lib/datetime/datetime.rb > > > Notice how RU_INFLECTED_MONTHNAMES constant is used in strftime. We > > > need that in select_month as well.
> > I going to use that example in my talk. Also, I think I really need to > > better understand what's happening here.
> > Stupidly, Mail.app does not let me paste those Russian month names to > > this email.
>> So, am I right guessing that these month names are Nominative and
>> Genitive Singulars following to the "first declension"? That seems to
>> make sense to me.
>> So, am I right guessing that these month names are Nominative and
>> Genitive Singulars following to the "first declension"? That seems to
>> make sense to me.
>> Now I just need to learn how to pronounce them so I can read them in
>> my RailsConf Eu talk :D
>>> On Sat, Aug 9, 2008 at 12:43, Sven Fuchs <svenfuchs@artweb-
>>> design.de> wrote:
>>>> On Mon, Jul 21, 2008 at 3:12 PM, Sven Fuchs <svenfu...@artweb-design.de
>>>>> wrote:
>>>> I think you're right that this is one of the things not immediately
>>>> supported by the api.
>>>> Sticking to the terminology of the api I'd say that what you want
>>>> to
>>>> do is *pluralize* the month names when localizing a date? Is that
>>>> correct?
>>> On 05.08.2008, at 17:23, Yaroslav Markin wrote:
>>>> We need month name inflection; we need to inflect month names if we
>>>> are displaying month name with a date -- you can see the logic
>>> here, http://rutils.rubyforge.org/svn/trunk/lib/datetime/datetime.rb >>>> Notice how RU_INFLECTED_MONTHNAMES constant is used in strftime. We
>>>> need that in select_month as well.
>>> I going to use that example in my talk. Also, I think I really
>>> need to
>>> better understand what's happening here.
>>> Stupidly, Mail.app does not let me paste those Russian month names
>>> to
>>> this email.
So, is there any way in near future to apply this http://gist.github.com/3436 ? Today we realized that writing a backend for russian language (for example) is not really a big deal, but you won't be able to do multi-language application using it. You won't be able to use pluralization, for example -- russian language needs an array of three as <tt>entry</tt> parameter.
Defining labmdas in translation table as a strftime format or as a pluralization rule for a language would be a problem solver. Same probably goes for capitalization in danish language?
Sven, could you please comment what is wrong with http://gist.github.com/3436 or with Clemens' plugin? What is the work to be done so this functionality can be merged into core, how can we help?
|
