Hi Marnen,
On Thu, Sep 9, 2010 at 12:44 AM, Marnen Laibow-Koser <[email protected]> wrote: > 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... 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
