Re: no one cares about i18n (was [OT]: Asking questions on t

Do most others in the community agree with this statement? It seems to
me
that i18n is:

  1. Actually important to many people
  2. Not really the difficult to implement in concept
  3. Something that people like to point out about Rails to say it’s not
    ready foir “Enterprise”

It seems to be that a big part of Rails is encouraging people to do
things
the “Right Way”, yet none of the Rails books/articles I have read
(AWDwR,
Rails Recipes, etc.) even discuss how to do i18n, let alone encourage
it.
Why?

On 5/2/06, Paul B. [email protected] wrote:

Rails Recipes, etc.) even discuss how to do i18n, let alone encourage it.
Why?

My point was that compared to the number of people who read this list,
its a relatively small number who actually know enough about i18n with
Rails to answer his questions faster than he answered them himself.

I agree with what you’re saying here.

– James

In my opinion Globalize has this covered, at least until m17n support
rolls out with Ruby 2.0.
http://www.globalize-rails.org/wiki/

In Peak Obsession someone did
ask the question again: What is the current best solution for I18N?

I did add these links to that very same page:

Gloablize (http://wiki.globalize-rails.org/wiki/)
Localize
(http://dev.rubyonrails.org/svn/rails/plugins/localization/README)
GLoc (http://rubyforge.org/projects/gloc/)
Multilingual
(https://opensvn.csie.org/traccgi/multi_lingual_rails/trac.cgi/)

A very brief feature comparision for the first three plugins is listed
here: http://www.agilewebdevelopment.com/plugins/category/8

And then there’s the old important thread from end of last year (“Rails
core going multiligual…ever?”): Rails core going multiligual...ever? - Rails - Ruby-Forum

BTW - Where’s the place to DRY up all this information and keep it up to
date?

I’d be most grateful if you wiki’d this. As well, it may be
appropriate to set up a list specifically for these issues since many
on this list don’t care/need these features. i’d be happy to join. i
for one drown in traffic from this list and probably miss half the
mail i should read despite browsing it regularly.

pt.

On 5/11/06, Martin Bernd S. [email protected] wrote:

(https://opensvn.csie.org/traccgi/multi_lingual_rails/trac.cgi/)


Posted via http://www.ruby-forum.com/.


Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


Parker T.
http://www.parkert.com/
510.541.0125

Hi,

i18n means:
(1) Message Catalogs (Translate strings)
(2) Formatting Date, Time, Currency and others.
(3) String handling

Now, I mention (1) because this discussion about (1).

IMO, the most important things for (1) are:
(a) Maintenance-ability
* Extract strings from .rb/rhtml/ActiveRecord to a file
automatically.
* Merge the old(translated) file and new one easily.
(b) Multi-textdomains
* Rails, Rails application, Plugins, Other libraries
should have their own message catalogs.
(c) Plural/Singler messages
(d) Auto finding client locale correctly
(e) Translate Rails messages

Now, Ruby-GetText-Package has already supported all of important these
features.
I checked other localized libraries/plugins, but they haven’t have
enough features yet.

And it’s already supported 11 languages for Rails.
http://www.yotabanana.com/hiki/ruby-gettext-screenshot.html

Of course, usually I welcome other language translators.

So, I highly recommand to try Ruby-GetText-Package once.

There is a tutorial for Ruby on Rails and Ruby-GetText-Package.
http://www.yotabanana.com/hiki/ruby-gettext-howto-rails.html

HTH,

On Tue, 2 May 2006 17:15:51 -0400

Thanks for the answers. Since I have to make a decision either for a
plugin or as someone (more experienced in this field) recommended to
re-invent the wheel using a gettext approach, I’ll do some evaluation
and put the results somewhere.

Since my time is limited (we need a decision ASAP) I’ll probably just
scratch the evaluation of the option. Anyways, I hope we can start a
discussion and a separate forum / mailing list is a good idea (at least
for us 5.7 billion non US Rails people :wink: ).

I am also very interested in localization,

This goes for database content, rhtml-content (including names of
columns of tables), mail-content etc. All that is shown to the user.

In my experience table names, and table column names in the database are
best done in english. In the nearly 20 years I have been involved with
developing database solutions I have never had a database with swedish
names of tables and fields.

This is also because it you some day want to distribute your solution
abroad, you wouldn´t want the names to be in Swedish anyway.

When Rails uses “column.human_name”, I would like to be able to choose
another language (Swedish). Now I get the database english names. To me
‘human_name’ is not what the database columns are called, they are
rarely human name at all, since different customers of ours call the
same object by different names in their context. To us developers it is
the same, but not to the cusomers.

So a feature with Meta-names of the columns would be a nice feature.
(Crystal Reports Server that we use for reporting has this: a layer of
Meta names (human names) that are used in customer interaction, but the
database names are something else.

SO I would like a clean separation of what is shown in the view, from
what things are called in the model.

Per-Olof H.

PS I am new to RoR, Just been reading up till now, and just started to
do some experimentary solutions on my desktop,

Hi,

On Fri, 12 May 2006 12:05:21 +0200
Per-Olof H. [email protected] wrote:

This is also because it you some day want to distribute your solution
(Crystal Reports Server that we use for reporting has this: a layer of
Meta names (human names) that are used in customer interaction, but the
database names are something else.

SO I would like a clean separation of what is shown in the view, from
what things are called in the model.

Already Ruby-GetText-Package supports ActiveRecord translation.
(It overrides column.human_name as you think.)
The table/column names are extracted as the target messages.
And they are translated correctly … you don’t need to touch your
models by hand.

As you say, sometimes the table/column names are not human readable.
Ruby-GetText-Package can use for English people to
translate table/column names to human readable name.

Anyway, I recommand you try Ruby-GetText-Package once.

Installation:
http://www.yotabanana.com/hiki/ruby-gettext.html#Install
HOWTO for Ruby on Rails:
http://www.yotabanana.com/hiki/ruby-gettext-howto-rails.html

HTH,

Masao M. wrote:

Anyway, I recommand you try Ruby-GetText-Package once.

Installation:
http://www.yotabanana.com/hiki/ruby-gettext.html#Install
HOWTO for Ruby on Rails:
http://www.yotabanana.com/hiki/ruby-gettext-howto-rails.html

HTH,

Thanks, I´ll have a look,

Per-Olof

Hi all,

please have a look at this posting in the new rails internationalization
mailing list

http://www.ruby-forum.com/topic/65659

Two things:

I asked Andreas, the Forum (Email Gateway) Maintainer to create a
Mailing List / Forum (no answer yet)

I created a Rails Wiki page:
http://wiki.rubyonrails.com/rails/pages/InternationalizationComparision

Don’t know how far I can contribute, one of our requirements is to use
Oracle, so Globalize (and maybe all other plugins) may not do it for us.

Please look at this page und the references on it (especially the I18n
mailing list / forum):
http://wiki.rubyonrails.com/rails/pages/InternationalizationComparison

Your problem may or may not be related to either setting the

  • http header to the correct mime type / encoding
  • having a wrong oracle server or client setting

Guys, I’ve been struggling with a similar, but simpler problem. I just
want to be able to CRUD Swedish characters in Oracle 10g tables.

I know I’ve got the Oracle end set up properly since I can enter,
retrieve and display
these characters from isqlplus, but when I use a RoR generated web
form I get “?” stored in my tables.

If you’ve work out how to do this, I’d be very grateful if you would
tell me how you did this.

Before I’d found this tread, I posted a few times and got some good
input back, but nothing got me quite to where I need to be.

Bealach

What do you guys think of 99translations.com?

It seems like a big step towards better translation management.

Fernando P. wrote:
[…]

Actually it is a bit painful to implement, as it means removing all the
text from views and putting it?.. well I don’t really know.

This is why I use gettext (or faster_gettext): the phrases themselves
are the keys, so the views look like

_(‘Welcome to the site, %{user}!’) % {:user => user}

rather than

get_message(:site_welcome_message, user)

This way, the view files stay legible, and the application is usable
even if no locale is set. The translations go in .po files, which are
an industry standard, and so translators and CAT software can be
expected to know what to do with them.

The yaml files are okay for short sentences, but how do you handle
localizing big chunks of html?
[…]

PO files are meant to deal with arbitrarily long strings of text.
Again, the gettext solution is best here.

Best,

Marnen Laibow-Koser
[email protected]
http://www.marnen.org

Paul B. wrote:

Do most others in the community agree with this statement? It seems to
me
that i18n is:

  1. Actually important to many people
  2. Not really the difficult to implement in concept

Actually it is a bit painful to implement, as it means removing all the
text from views and putting it?.. well I don’t really know.

The yaml files are okay for short sentences, but how do you handle
localizing big chunks of html? I don’t feel it fits nicely in the yaml
files. You lose the syntax highlighting.

How do you do that?