Localization (L10n) and Internationalization (i18n)

3 views
Skip to first unread message

knowtheory

unread,
Nov 14, 2008, 6:28:14 PM11/14/08
to merb
Hi all,

There has been a lot of discussion struck up in #merb on freenode
regarding merb's approach to internationalization and Localization.
It's worth it to put together a thread as the jumping off point for
some organization since a lot of people appear to be interested in
this and appear to be hacking up solutions independently.

Background info:
Merb has some localization hooks built in (http://github.com/wycats/
merb/tree/master/merb-helpers/spec/numeric_extlib_spec.rb ), but
otherwise localization is left as an exercise for the developer. Full
support for internationalization and unicode is a target for merb 2.0,
along with ruby 1.9 support which i've heard rumors is targeted for a
less than 12mo release cycle atm.

Existing libs:

Mattetti has done some work on localization and has started in on a
library called merb_babel, which you can find at:
http://github.com/mattetti/merb_babel/tree/master . The solution he's
used is to tie merb_babel together with another lib he's got for merb
that was extracted from ActiveSupport's unicode support (http://
github.com/mattetti/multibyte/tree/master).

Antifuchs in #merb also pointed out the merb_global lib as well (which
i haven't checked out) at http://github.com/myabc/merb_global/tree/master

So, what else do people want to know? What are the requirements for
localization that people have for their apps?

(we can fire up a wiki page for this based on what comes out of this
thread)

Kyle Drake

unread,
Nov 14, 2008, 6:38:28 PM11/14/08
to me...@googlegroups.com
I would like to ask a clarification question. I'm working on a project
with Merb+AR right now that needs unicode. Basically, I just need to
save UTF8 when people enter it in text fields on forms.

As I understand it now, UTF8 will go through just fine as long as
$KCODE is set to 'u' (which it is in merb-core by default). The only
caveats are that you need to make sure the database is configured for
UTF8, and you have to avoid some String methods that don't support it.
Is this correct? Or will I not be able to pass UTF8 over to the
database through my forms in Merb?

Thanks!

-Kyle

Matt Aimonetti

unread,
Nov 14, 2008, 6:48:57 PM11/14/08
to me...@googlegroups.com
Thanks Kyle for your question.

You are totally correct. String methods like capitalize, reverse etc.. won't work properly without an extra library.  Also you won't have any transliteration features unless you use multibyte (the lib I extracted from AS).

So, as long as you don't want to manipulate your unicode strings, you are good to go :D

-Matt

p.s: since you use AR you might already load ActiveSupport and you might use it directly to handle unicode strings.

Andreas Fuchs

unread,
Nov 19, 2008, 6:19:30 PM11/19/08
to merb
On Nov 14, 11:28 pm, knowtheory <nothe...@gmail.com> wrote:
> So, what else do people want to know? What are the requirements for
> localization that people have for their apps?

One of the most important things for us right now (and that is already
being done mostly OK by merb_global) is the ability to use gettext as
a translation store backend: It has loads of interfaces for
translators, and making a new one for any ad-hoc representation is not
possible given our time constraints.

As for other requirements, we usually need something to represent
localized dates, and to get translations of strings for different
plural forms. What works pretty well for us right now is the gettext
support for pluralization: <http://www.gnu.org/software/automake/
manual/gettext/Plural-forms.html>.

So, I think the whole point of my list is to let people use gettext
(-:

Cheers,
Andreas.
Reply all
Reply to author
Forward
0 new messages