Welcome Rails Developers
jos...@gmail.com
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.
-- Josh Harvey
Trevor Turk
> 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.
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 :)
Here's my app, in case you are interested: http://github.com/trevorturk/el-dorado/tree/master
Thanks again for all of your hard work!
- Trevor
Joshua Harvey
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.
-- Josh
Trevor Turk
> 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.
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.
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.
Thanks again,
- Trevor
Joshua Harvey
methods on his blog:
http://www.artweb-design.de/2008/7/18/the-ruby-on-rails-i18n-core-api
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.
-- Josh
Sven Fuchs
On 20.07.2008, at 20:34, Joshua Harvey wrote:
> Trevor, Sven wrote up a good intro to what's in the new Rails i18n
> methods on his blog:
>
> http://www.artweb-design.de/2008/7/18/the-ruby-on-rails-i18n-core-api
>
> 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.
"you are not logged in"[:not_logged_in]
<%= 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.
sven fuchs sven...@artweb-design.de
artweb design http://www.artweb-design.de
grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone)
d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)
Trevor Turk
> You can do pretty much everything you mentioned with the I18n#t method
> kind of translation front end, or you'll have to edit YAML files,
> depending on the plugin.
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...
- Trevor
Sven Fuchs
On 20.07.2008, at 22:16, Trevor Turk wrote:
> 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.
Trevor Turk
> 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.
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.
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!
Thanks again,
- Trevor
Trevor Turk
> 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 :)
http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/664-rescue_from-changes-causing-issues
But I started up a new app on Edge and made a little Hello World
thing:
http://github.com/trevorturk/rails-2.2-i18n-example/tree/master
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:
http://github.com/trevorturk/rails-2.2-i18n-example/commit/38ccdc5d4a44d7bedc61fd53f5107ec1749c3d16
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!
- Trevor
Trevor Turk
> I'm going to try and get flash messages working now...
Well... that was easy...
http://github.com/trevorturk/rails-2.2-i18n-example/commit/5bd4546c846d49cfa5d74cd7e4ab810b9ce6936f
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.
Thanks again!
- Trevor
Yaroslav Markin
Please feel free to suggest changes and ask questions.
--
Yaroslav Markin
Sven Fuchs
Thanks for chiming in.
On 21.07.2008, at 05:30, Yaroslav Markin 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?
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.
Yaroslav Markin
> My question is regarding better "conditional translations" support,I think you're right that this is one of the things not immediately
> 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].
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?
> Also, Sven suggested we may have a wiki for discussing stuff like> that -- i.e. what other languages need from i18n that is notYeah, maybe. Although I've rarely seen really useful GitHub wikis so
> supported / well done right now, may be github project wiki will do?
far.
--
Yaroslav Markin
pietro
> "you are not logged in"[:not_logged_in]
> <%= t :not_logged_in, :default => "you are not logged in" %>
pietro
so "Foo"[:foo] will return I18n.t(:foo, :default => "Foo").
module StringExt
def brackets_with_translation(*args)
args = [underscore.tr(' ', '_').to_sym] if args.empty?
return brackets_without_translation(*args) unless args.first.is_a?
Symbol
I18n.translate(args.first, :default => self)
end
def self.included(base)
base.class_eval do
alias :brackets :[]
alias_method_chain :brackets, :translation
alias :[] :brackets
end
end
end
String.send :include, StringExt
iain
introduction on i18n for beginners. I will add some more parts later
to cover more ground.
You can find it here: http://iain.nl/2008/08/finally-rails-goes-i18n/
Enjoy your weekend,
Iain
Joshua Harvey
-- Josh
Sven Fuchs
> > 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: http://pastie.org/private/zztlgee76slerozan0oqq
I'd like to learn what kind of Inflection is happening here. Can you
point me to some wikipedia page about that or something?
> Uh hum Prototype wiki?
Prototype wiki?
Vladimir
You can find more about it in wikipedia: http://en.wikipedia.org/wiki/Declension
Much of Russian grammar is at http://en.wikipedia.org/wiki/Russian_grammar
Sven Fuchs
> This is definetely not a plural. It's declension.
>
> You can find more about it in wikipedia: http://en.wikipedia.org/wiki/Declension
>
> Much of Russian grammar is at http://en.wikipedia.org/wiki/Russian_grammar
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.
январь # Nominative Singular
января # Genitive Singular
http://en.wikipedia.org/wiki/Russian_grammar#First_declension_-_masculine_nouns
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-
Lugovoi Nikolai
names for use in different contexts:
sample from cldr/main/pl.xml:
<calendar type="gregorian">
<months>
<monthContext type="format">
<monthWidth type="wide">
<month type="1">stycznia</month>
<month type="2">lutego</month>
<month type="3">marca</month>
<month type="4">kwietnia</month>
<month type="5">maja</month>
<month type="6">czerwca</month>
<month type="7">lipca</month>
<month type="8">sierpnia</month>
<month type="9">września</month>
<month type="10">października</month>
<month type="11">listopada</month>
<month type="12">grudnia</month>
</monthWidth>
</monthContext>
<monthContext type="stand-alone">
<monthWidth type="wide">
<month type="1">styczeń</month>
<month type="2">luty</month>
<month type="3">marzec</month>
<month type="4">kwiecień</month>
<month type="5">maj</month>
<month type="6">czerwiec</month>
<month type="7">lipiec</month>
<month type="8">sierpień</month>
<month type="9">wrzesień</month>
<month type="10">październik</month>
<month type="11">listopad</month>
<month type="12">grudzień</month>
</monthWidth>
</monthContext>
</months>
Vladimir
> Genitive Singulars following to the "first declension"? That seems to
> make sense to me.
>
> январь # Nominative Singular
> января # Genitive Singular
> http://en.wikipedia.org/wiki/Russian_grammar#First_declension_-_masculine_nouns
Yes.
> Now I just need to learn how to pronounce them so I can read them in
> my RailsConf Eu talk :D
You can start with listening a sample here:
http://en.wiktionary.org/wiki/%D1%8F%D0%BD%D0%B2%D0%B0%D1%80%D1%8C :)
Sven Fuchs
Thanks :)
On 09.08.2008, at 11:48, Vladimir wrote:
>> 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.
>>
>> январь # Nominative Singular
>> января # Genitive Singular
>> http://en.wikipedia.org/wiki/Russian_grammar#First_declension_-_masculine_nouns
>
> Yes.
>
>> Now I just need to learn how to pronounce them so I can read them in
>> my RailsConf Eu talk :D
>
> You can start with listening a sample here:
> http://en.wiktionary.org/wiki/%D1%8F%D0%BD%D0%B2%D0%B0%D1%80%D1%8C :)
>
Yaroslav Markin
--
Yaroslav Markin
Sven Fuchs
On 09.08.2008, at 16:19, Yaroslav Markin wrote:
> So, is there any way in near future to apply this http://gist.github.com/3436
> ?
personally I still think this is a good idea because it sort of
(further) unifies the API.
I'd like to hear some more opinions ideally :)
> 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.
The pluralization algorithm (which maps the :count to the translation
to pick) would need to be stored externally/dynamically per locale,
right?
That could either work with passing lambdas, defining dynamic methods
for it, even eval'ing code snippets stored in the db (or CLDR data) ...
> 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?
I guess you mean Dutch :) Yes, most probably.
> 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?
Well, so far this code is not actually working because we'd need to
figure out how/where to raise and catch exceptions in the right way so
that all the combinations work the way we'd expect them to. Much of
this should be covered by the test already, I think.
So if you'd want to help here (which would be awesome), maybe the best
starting point is just replacing the current code with that gist
snippet and see what tests break. Then figure out what tests are
missing. And then fix everything :)
jos...@gmail.com
storage medium, lambdas are problematic. Pluralization shouldn't be a
problem, since the plugins will handle that separately, possibly using
CLDR data. I still don't understand the Russian date problem, I'll
have to look into that further. We'll have to see if we can come up
with a general solution to problems like that.
-- Josh
On Aug 9, 5:40 pm, Sven Fuchs <svenfu...@artweb-design.de> wrote:
> Hey Yaroslav,
>
> On 09.08.2008, at 16:19, Yaroslav Markin wrote:
>
>
> personally I still think this is a good idea because it sort of
> (further) unifies the API.
>
> I'd like to hear some more opinions ideally :)
>
> > 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.
>
> The pluralization algorithm (which maps the :count to the translation
> to pick) would need to be stored externally/dynamically per locale,
> right?
>
> That could either work with passing lambdas, defining dynamic methods
> for it, even eval'ing code snippets stored in the db (or CLDR data) ...
>
> > 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?
>
> I guess you mean Dutch :) Yes, most probably.
>
> > functionality can be merged into core, how can we help?
>
> Well, so far this code is not actually working because we'd need to
> figure out how/where to raise and catch exceptions in the right way so
> that all the combinations work the way we'd expect them to. Much of
> this should be covered by the test already, I think.
>
> So if you'd want to help here (which would be awesome), maybe the best
> starting point is just replacing the current code with that gist
> snippet and see what tests break. Then figure out what tests are
> missing. And then fix everything :)
>
> --
Yaroslav Markin
Yaroslav Markin
Sven Fuchs
Maybe it makes most sense to implement this as an independent library
that could be used anywhere else, too. Something like a ruby-cldr gem.
As for the future dev process.
I believe our last dev cycle was quite successful all in all.
What we did was: we had lots of plugins solving particular problems.
We collected them, looked at them, discussed what we could extract
from them to a common solution and/or Rails patch. Then implement
these and propose them.
What we want to do is: rinse + repeat.
So, even though it might feel annoying to still need to monkeypatch
anything in Rails this might be the way to go right now for everything
else than trivial stuff and obvious errors and fixes.
With whatever we develop from now on lets try to use the API and
implement everything in plugins, custom backends etc. Publish these
and find others to use them. Then after a couple of months, collect
everything, look at it, discuss it and merge it to more common
solutions.
The reason why we thing this is the way to go is that improvements to
date/time/number/currency formattings as well as the corresponding
Rails helpers really make most sense when looked at in context.
Something that works for one culture might not be sufficient for
another. Because there are lots of tiny things to take into account a
process where we submit tiny patches to Rails core all the time
doesn't work well. (We already have a bit of a mess with
inconsistencies in method signatures in the various helpers.)
Please let me know what you think!
Save The Vinyls
Gibberish has the prettiest syntax ever!
iain
guide to translating ActiveRecord.
You can find it here: http://iain.nl/2008/09/translating-activerecord/
On Aug 9, 12:40 am, "Joshua Harvey" <jos...@gmail.com> wrote:
> Awesome post, Iain! I'm looking forward to the next installments.
>
> -- Josh
>