multilang calagator
Pierre Spring
i am evaluating calagator for a usage in switzerland.
now, as you might have heard of, our tiny little country speaks 4
languages.
my questions are the following:
1. how much work would it take to internationalize the whole stack? it
is very hard for me to evaluate, as i never touched ROR before. could
a person do it in a month or two?
2. i am a rather experienced PHP developer. do you think that learning
ROR while internationalizing calagator makes sense?
yours.
pierre
Igal Koshevoy
> i am evaluating calagator for a usage in switzerland.
>
> my questions are the following:
>
> 1. how much work would it take to internationalize the whole stack? it
> is very hard for me to evaluate, as i never touched ROR before. could
> a person do it in a month or two?
>
> 2. i am a rather experienced PHP developer. do you think that learning
> ROR while internationalizing calagator makes sense?
I think that a translation could be built fairly rapidly and your
experience with PHP will be extremely helpful if you've used a framework
like CakePHP, CodeIgniter, Symfony, etc. A great way to get started with
Ruby on Rails is the "Rails Guides":
http://guides.rubyonrails.org/index.html
If you decide to internationalize Calagator, please coordinate your
efforts with us so we can include your code as an official part of
Calagator so others can make use of your valuable work.
Internationalization in the current Ruby on Rails is quite good. We've
nearly finished upgrading Calagator to 2.3 and hope to switch the master
branch to it in the next few days. So if someone wants to play around,
start by creating a blank Rails 2.3 project and get familiar with
internationalization there first, rather than using the Rails 2.1
version of Calagator that we'll be retiring soon.
To do internationalization, one would need to:
1. Setup infrastructure, such as a mechanism to track the current
language, let the user choose their language, and store translated
strings, localize dates, etc.
2. Translate the text and localize dates, which will require finding
every place where text/dates/times are emitted and wrapping them in
special method calls.
The setup and translation processes are well-documented:
1. Video and text showing how to internationalize a Rails application,
these can give you a clear idea of what's involved in a few minutes:
http://railscasts.com/episodes/138-i18n
http://asciicasts.com/episodes/138-i18n
2. Detailed guide to internationalizing Rails applications:
http://guides.rubyonrails.org/i18n.html
3. Listing of internationalization-related Rails resources:
http://rails-i18n.org/wiki
The biggest coding challenge is that Calagator uses themes so different
sites running the software can have a different look, text, etc. The
ideal internationalization solution would provide a generic translation
that all sites can use (e.g., translation of "event" will generally be
the same), but allow individual theme owners the ability to use a custom
translation for their theme, thus overriding the generic translation.
This may need to be added early on to the software.
The other big challenge will be version control logistics. The
internationalization process will likely require changes to every view
and controller, which will make merging tricky. For example, let's say
you begin internationalizing the homepage in your fork of the code, but
then I make a change to the homepage and push to the master branch, then
you pull from master and get a git collision because we've both modified
the same page. Dealing with these collisions will be annoying and tricky
at times. The quicker the internationalization can be done, the more
closely we can cooperate on doing it, and the sooner we can merge
internationalization into the main code base, the less pain there will
be with these collisions.
Does this answer your questions?
-igal
Amy K. Farrell
> The other big challenge will be version control logistics. The
> internationalization process will likely require changes to every view
> and controller, which will make merging tricky. For example, let's say
> you begin internationalizing the homepage in your fork of the code, but
> then I make a change to the homepage and push to the master branch, then
> you pull from master and get a git collision because we've both modified
> the same page. Dealing with these collisions will be annoying and tricky
> at times. The quicker the internationalization can be done, the more
> closely we can cooperate on doing it, and the sooner we can merge
> internationalization into the main code base, the less pain there will
> be with these collisions.
This sounds to me like an excellent project for a code sprint,
particularly for sprinters like me who aren't intimately familiar with
the project or with RoR.
Here's what I'm thinking: it sounds as if conceptually similar work will
be needed throughout the versions and controllers. Prior to a sprint,
someone could do this work in one area (one view, perhaps) and jot down
some guidelines. This could be presented as an example at the sprint,
and then participants could split up the remaining work. It might be
possible to get a fair bit of the work done and limit the merging to a
shorter period of time this way.
For newbies, this would eliminate the problem of coming to a sprint and
not having a good sense of what to work on or where to begin.
What do the maintainers think?
- Amy
Igal Koshevoy
I've also realized that there's an optimization that we can use to make
work even easier: doing the conversion and translation separately.
The conversion work is about making changes to the code. E.g., you'd
take non-internationalized code like:
flash[:success] = 'Event created'
and convert it into internationalized code like:
flash[:success] = t('events.create.success_message')
and move the 'Event created' text into a language bundle.
The translation work could be done later by a different group, which
would just focus on translating strings like 'Event created' and update
the language bundle.
Having a bunch of coders cooperate would let us convert the entire app
in a single sprint. After this work is done, folks like Pierre in
Switzerland organize a sprint to translate the text, without needing to
make changes to any Ruby or Rails logic.
Thoughts?
-igal
Sam Goldstein
The conversion work is about making changes to the code. E.g., you'd
take non-internationalized code like:
flash[:success] = 'Event created'
and convert it into internationalized code like:
flash[:success] = t('events.create.success_message')
and move the 'Event created' text into a language bundle.
Jeff Schwaber
The translation work could be done later by a different group, which
would just focus on translating strings like 'Event created' and update
the language bundle.
There was a talk about Transifex: http://transifex.org/ at DjangoCon. A Fedora Project guy was talking about its being better for them than previous efforts, because there's a community of translators and software to make tracking translations easy.
Jeff
Pierre Spring
i was amazed by the amount of responses this thread got! calagator
really seems like an amazing community!
> 1. Setup infrastructure, such as a mechanism to track the current
> language, let the user choose their language, and store translated
> strings, localize dates, etc.
> 2. Translate the text and localize dates, which will require finding
> every place where text/dates/times are emitted and wrapping them in
> special method calls.
Thought the discussion, focus was put on one important part of a
multilingual project:
1. Localization of the application
==================================
This simply means to replace strings by keys and have i18nized string
DBs. It can be done in several hours and there are well known ways to
do this. Especially, as it seems using Rails.
And it seems that there is an interest within the calagator community
to do this. This is great! And i will gladly translate the i18n
strings into german and french!
Yet there is another, often more fundamental problem to solve in a
truly multilingual site:
2. Multilingual Content
=======================
Once an application has undergone localization, the simplest way to
achieve a multilingual site, is to have several instances of the
application running. This is often done with a single instance of
source-code but multiple configuration files and DBs.
Yet, this is not the real deal. Content metatdata has to be maintained
multiple times. There is no real link between identical content in the
different language.
In my eyes, this is where the big challenge lies. Now the question
coming from a person who is not quite able to read and understand
active record models: do you think that such a refactoring is possible
and realistic?
Would there be an interest in such development?
What are your thoughts?
Yours.
Pierre.
Igal Koshevoy
it'd be necessary to localize the user interface (e.g., buttons with
text in English, French, etc) and also localized the content (e.g.,
event title and description in English, French, etc).
A possible way to deal with this would be to connect each "item" (e.g.,
an event with ID 123 at venue 456 at a certain time) to "payloads" which
contain localized text (e.g., event title and description for event ID
123 in French).
The website's user interface would let the user
list/show/create/edit/update the localized payload for an item. The
website's user interface would display the closest match based on the
user's locale (e.g., show a Swiss French (fr_CH) payload for a user
using a French (fr_FR) locale), or fall back to English or whatever the
one available language payload is if no matching localized content is
available. The feeds and exports would also need to be locale aware.
...
The more we discuss this, the more involved localization seems, and the
greater the amount of work needed before it can produce something of
value. We're talking about changing every page and almost every
controller action, making significant changes to models, adding many new
UI elements and controls, etc. It's much easier for me to, say, give up
a day to get something done -- but much harder to volunteer for larger
amounts of time for ongoing mentoring and development.
There are many simpler and more valuable improvements our existing users
are requesting, and that I and our other volunteer developers want to
prioritize work on. Given how slow development is progressing, I don't
expect we'll be able to complete the localization work any time soon.
If we could find developers that were specifically interested in doing
most of this localization work and supporting it once it's ready, or
find sponsors that could pay existing developers to add and support
these features, I think that there'd be a much higher probability that
this would get done.
Any suggestions for where we can find these developers or sponsors?
-igal