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
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
--
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 [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.
