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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Tue, Sep 7, 2010 at 6:54 AM, Peter De Berdt <peter.de.berdt-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org> 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 (http://github.com/kete/kete/ and our version of the plugin at http://github.com/kete/translate). It''s good for a whole site''s UI translation. We have some guides that we point our translators at here: http://kete.net.nz/documentation/topics/show/289-using-translate-plugin-to-translate-your-kete-installation http://kete.net.nz/documentation/topics/show/276-general-strategies-for-creating-a-localization-of-the-kete-ui-for-13 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: http://github.com/kete/kete/tree/enhancement_285_add_non_left_to_right_layout_support 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 (http://github.com/kete/mongo_translatable) 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: http://github.com/ahe/mongo_translation Cheers, Walter -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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: * 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. 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, > AndrasBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Wed, Sep 8, 2010 at 2:43 AM, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Walter McGinnis wrote:> On Wed, Sep 8, 2010 at 2:43 AM, Marnen Laibow-Koser > <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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, > WalterBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org Sent from my iPhone -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hi Marnen, On Thu, Sep 9, 2010 at 12:44 AM, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Walter McGinnis wrote: >> On Wed, Sep 8, 2010 at 2:43 AM, Marnen Laibow-Koser >> <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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...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.> >> 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.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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Marnen Laibow-Koser
2010-Sep-09 04:38 UTC
Re: Re: Re: i18n assets management / translation UI
Walter McGinnis wrote:> Hi Marnen, > > > On Thu, Sep 9, 2010 at 12:44 AM, Marnen Laibow-Koser > <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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, > WalterBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Walter McGinnis
2010-Sep-09 22:13 UTC
Re: Re: Re: Re: i18n assets management / translation UI
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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.