Hello everyone,
i’m building a multi-lingual webapp with i18n from the ground up, and
while i myself can deal with an army of yml files, the languages i
speak are ( very ) limited, and would eventually like to ask for
outside help.
I’d like to know if anyone here is using a UI plugin/gem ( not unlike
django-rosetta on django ) to deal with multiple translators, some of
them unwilling or unable to mess with 100+ files in a repository,
working on language data.
thanks ®ards,
Andras
On 06 Sep 2010, at 14:09, andras wrote:
i’m building a multi-lingual webapp with i18n from the ground up, and
while i myself can deal with an army of yml files, the languages i
speak are ( very ) limited, and would eventually like to ask for
outside help.I’d like to know if anyone here is using a UI plugin/gem ( not unlike
django-rosetta on django ) to deal with multiple translators, some of
them unwilling or unable to mess with 100+ files in a repository,
working on language data.
This seems to fit the bill: http://github.com/newsdesk/translate
I haven’t used it yet though. Maybe someone else can share their
experiences or you can just try it out (doesn’t look like that much
work to implement and just use a separate git branch to experiment on).
Best regards
Peter De Berdt
On Tue, Sep 7, 2010 at 6:54 AM, Peter De Berdt
[email protected] wrote:
I’d like to know if anyone here is using a UI plugin/gem ( not unlike
django-rosetta on django ) to deal with multiple translators, some of
them unwilling or unable to mess with 100+ files in a repository,
working on language data.This seems to fit the bill: http://github.com/newsdesk/translate
I haven’t used it yet though. Maybe someone else can share their experiences
or you can just try it out (doesn’t look like that much work to implement
and just use a separate git branch to experiment on).
We’re using a slightly modified version of it on the Kete application
(GitHub - kete/kete: Kete was developed by Horowhenua Library Trust and Katipo Communications Ltd. to build a digital library of Horowhenua material. and our version of the plugin at
GitHub - kete/translate: A Ruby on Rails plugin with a web interface for translating I18n texts). It’s good for a whole site’s UI
translation. We have some guides that we point our translators at
here:
Note that we have added some other things so that one translation (say
a common noun or verb in the UI) can be reused in other translations
to make the process quicker for the “base” UI elements.
You may also want to consider adding support for Right-to-Left
languages (Arabic, Hebrew) in your CSS. See this branch for some
commits that allow for that:
Now, a thing to keep in mind is that this is only for the default
“static” user interface text defined in your templates. It won’t work
with translating content (i.e. stuff that gets pulled from you
database). Globalize2 is the longest running plugin for that sort of
work.
However with Kete, we found that the working assumptions weren’t
compatible with how we handling versioning of content so we decided to
go our own way. We’re working on a new gem called mongo_translatable
(GitHub - kete/mongo_translatable: Rails specific I18n model localization, ala Globalize2, backed by MongoDB rather than an RDBMS. May include UI elements, too.) that uses MongoDB as a
backend for translation lookup. It’s an engine and includes a
built-in UI for translation that is centered around the piece of
content being translated. It’s basically done, but I need to bundle
it up for release. Feel free to fork and contribute back to it.
If you are writing an app that is going with MongoDB generally, you
should check out the all MongoDB plugin for translation here:
Cheers,
Walter
andras wrote:
Hello everyone,
i’m building a multi-lingual webapp with i18n from the ground up, and
while i myself can deal with an army of yml files, the languages i
speak are ( very ) limited, and would eventually like to ask for
outside help.I’d like to know if anyone here is using a UI plugin/gem ( not unlike
django-rosetta on django ) to deal with multiple translators, some of
them unwilling or unable to mess with 100+ files in a repository,
working on language data.
I recommend not using an army of YAML files. Instead, install
fast_gettext, which adopts the GNU gettext approach of using PO files.
The advantages here are:
If you’re looking for a Facebook-style community translation interface,
that Translate plugin certainly looks promising (though I’ve never used
it either).
thanks ®ards,
Andras
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Walter McGinnis wrote:
On Wed, Sep 8, 2010 at 2:43 AM, Marnen Laibow-Koser
[email protected] wrote:I recommend not using an army of YAML files. �Instead, install
fast_gettext, which adopts the GNU gettext approach of using PO files.
The advantages here are:
- Readable string keys instead of weird symbolic ones
- Since PO files have been widely used in software localization for some
time, there’s lots of translation tool support for PO files, and many
translators already know how to work with them.It’s pretty easy to take YAML and transcode them to other types of
files (and vice versa) with rake tasks.
I suppose it is, but why bother?
We haven’t done it for PO
files, but we have for CSV and XML files to be imported to Excel for
translators and then take their Excel XML schema output and pull it
back to YAML files.
That seems like a lot of work…
The advantage of the YAML stuff is interpolation for reuse of
translation. I.e. each translated string becomes a potential building
block for other string translations, e.g.base:
foo: foo
bar: bar
new: new
new_foo: “{{t.base.new}} {{t.base.foo}}”
new_bar: “{{t.base.new}} {{t.base.bar}}”Then when I create a new locale’s translation I can either replace the
base value for “new” in one place or (if grammatically necessary) edit
“new_foo” and “new_bar”. It’s a potential big time saver for larger
systems and it helps ensure UI consistency of nouns and verbs.
I think that if you are finding this to be a major advantage, then you
may not be structuring your translatable strings properly. Also, due to
differing grammar, reuse that’s possible in one language may not be
possible in another – and it’s the translator’s job to know that, not
yours. How do you deal with this?
If you don’t expect to do this sort of sophisticated reuse of
translations, then Marmen may be right.
(Please note correct spelling of my name.)
It’s simplest to go with the
translation industry’s standard PO files.If you’re looking for a Facebook-style community translation interface,
that Translate plugin certainly looks promising (though I’ve never used
it either).The Translate plugin ISN’T really suitable for a Facebook-style
community translation interface, at least without significant work.
It is geared towards privileged users adding whole site translations.You might be able to fork and hack it to be more community oriented,
but it wouldn’t be trivial work.
OK. Sorry for the misunderstanding.
Cheers,
Walter
Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Sent from my iPhone
On Wed, Sep 8, 2010 at 2:43 AM, Marnen Laibow-Koser
[email protected] wrote:
I recommend not using an army of YAML files. Instead, install
fast_gettext, which adopts the GNU gettext approach of using PO files.
The advantages here are:
- Readable string keys instead of weird symbolic ones
- Since PO files have been widely used in software localization for some
time, there’s lots of translation tool support for PO files, and many
translators already know how to work with them.
It’s pretty easy to take YAML and transcode them to other types of
files (and vice versa) with rake tasks. We haven’t done it for PO
files, but we have for CSV and XML files to be imported to Excel for
translators and then take their Excel XML schema output and pull it
back to YAML files.
The advantage of the YAML stuff is interpolation for reuse of
translation. I.e. each translated string becomes a potential building
block for other string translations, e.g.
base:
foo: foo
bar: bar
new: new
new_foo: “{{t.base.new}} {{t.base.foo}}”
new_bar: “{{t.base.new}} {{t.base.bar}}”
Then when I create a new locale’s translation I can either replace the
base value for “new” in one place or (if grammatically necessary) edit
“new_foo” and “new_bar”. It’s a potential big time saver for larger
systems and it helps ensure UI consistency of nouns and verbs.
If you don’t expect to do this sort of sophisticated reuse of
translations, then Marmen may be right. It’s simplest to go with the
translation industry’s standard PO files.
If you’re looking for a Facebook-style community translation interface,
that Translate plugin certainly looks promising (though I’ve never used
it either).
The Translate plugin ISN’T really suitable for a Facebook-style
community translation interface, at least without significant work.
It is geared towards privileged users adding whole site translations.
You might be able to fork and hack it to be more community oriented,
but it wouldn’t be trivial work.
Cheers,
Walter
Hi Marnen,
On Thu, Sep 9, 2010 at 12:44 AM, Marnen Laibow-Koser
[email protected] wrote:
translators already know how to work with them.
That seems like a lot of work…
It really depends on the set up of you translation community. Are
they going to be using the web interface rather than industry tools?
Then the primary storage is not really that much of concern.
 new_bar: “{{t.base.new}} {{t.base.bar}}”
Then when I create a new locale’s translation I can either replace the
base value for “new” in one place or (if grammatically necessary) edit
“new_foo” and “new_bar”. Â It’s a potential big time saver for larger
systems and it helps ensure UI consistency of nouns and verbs.I think that if you are finding this to be a major advantage, then you
may not be structuring your translatable strings properly.
That’s a pretty big statement, so it’s impossible to answer. You are
welcome to review and comment on the master branch at
http://github.com/kete/kete.
 Also, due to
differing grammar, reuse that’s possible in one language may not be
possible in another – and it’s the translator’s job to know that, not
yours. Â How do you deal with this?
In my example new_foo, if another locale grammatically (or in subtle
meaning difference) can’t reuse the “building block” nouns and verbs,
then new_foo can have a totally independent value that doesn’t use the
substitution.
It’s a bit of convention over configuration. It can be overridden
when necessary, but for those where it “just works” then they get the
benefit of it.
In other words, we don’t assume it will be right for all locales, but
we do provide it for those that can take advantage of it.
If you don’t expect to do this sort of sophisticated reuse of
translations, then Marmen may be right.(Please note correct spelling of my name.)
Sorry about that.
Cheers,
Walter
Walter McGinnis wrote:
Hi Marnen,
On Thu, Sep 9, 2010 at 12:44 AM, Marnen Laibow-Koser
[email protected] wrote:translators already know how to work with them.
That seems like a lot of work…
It really depends on the set up of you translation community.
Certainly.
Are
they going to be using the web interface rather than industry tools?
Then the primary storage is not really that much of concern.
A Web interface such as most people would design is only going to be
good at people submitting an occasional translation or two. If a
professional or serious volunteer translator is going to translate the
whole UI – particularly if CAT tools are involved – then PO is
probably the way to go.
 new_bar: “{{t.base.new}} {{t.base.bar}}”
Then when I create a new locale’s translation I can either replace the
base value for “new” in one place or (if grammatically necessary) edit
“new_foo” and “new_bar”. Â It’s a potential big time saver for larger
systems and it helps ensure UI consistency of nouns and verbs.I think that if you are finding this to be a major advantage, then you
may not be structuring your translatable strings properly.That’s a pretty big statement, so it’s impossible to answer. You are
welcome to review and comment on the master branch at
http://github.com/kete/kete.
I’ll take a look when I have a chance (whenever that is – I’m quite
busy at the moment). I also like the fact that the string keys in PO
files make the views easy to read, and provide a sensible default when
there is no translation yet.
 Also, due to
differing grammar, reuse that’s possible in one language may not be
possible in another – and it’s the translator’s job to know that, not
yours. Â How do you deal with this?In my example new_foo, if another locale grammatically (or in subtle
meaning difference) can’t reuse the “building block” nouns and verbs,
then new_foo can have a totally independent value that doesn’t use the
substitution.
I am not sure that a professional or semiprofessional translator would
find this feature of any use whatsoever. If I’m reading over my
translation for a sanity check before sending it off to the client, I’d
rather read
base:
foo: фу
bar: бар
new: новый
new_foo: новый фу
which is repetitive but fluently readable, than
new_foo: “{{t.base.new}} {{t.base.foo}}”
which is DRY but incomprehensible.
It’s a bit of convention over configuration. It can be overridden
when necessary, but for those where it “just works” then they get the
benefit of it.In other words, we don’t assume it will be right for all locales, but
we do provide it for those that can take advantage of it.
I think this is trying to DRY up your translatable text too much. I
have generally seen this practice advised against. You’re making too
many linguistic assumptions about the way the text breaks down, for one
thing.
If you don’t expect to do this sort of sophisticated reuse of
translations, then Marmen may be right.
I am not convinced that this reuse is as sophisticated as it looks.
(Please note correct spelling of my name.)
Sorry about that.
That’s OK.
Cheers,
Walter
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
I take your points and I have certainly considered many of them. Like
many things, there are design tradeoffs and you have to weigh them in
your particular situation. I’m quite aware that linguistically these
patterns aren’t always useful and that is why they can be opted out of
easily. They have sped up the process of translation for us, though
(Chinese, Arabic, and Te Reo MÄori so far). The professional
translators for Chinese worked with Excel…
It should be noted that the “base” translations that act as building
blocks are in supplement to standard named translation keys that
correspond to the controller/action pattern of naming that you talk
about with PO. I.e. if I’m translating “accounts.new.welcome”, it
will be in app/views/accounts/new template. It just may be that the
value in the locale’s .yml file is derived from base.welcome.
Anyway, I imagine I’m providing more detail than is needed.
Cheers,
Walter
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs