[haiku] Re: Haiku's localization vocabulary guidelines

PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> 2009/7/23 Jonas Sundström <jonas@xxxxxxxxxxx>:
 ...
> The idea is to actually have two level of 
> translation, one for the common "guidelined"
> strings using for example this kind of constants,
> and the other one for regular strings. I think the
> "revert" button you find in all of haiku's preflet
> will always use the same translation in any language,
> so it makes sense to have it at this global level.
> If someone ever make an app using the word "Revert"
> with another semantic, he can switch to the regular
> system, using something like TR_CMT("Revert","Beware!
> in EXOTIC_LANG this one does not translate the same
> way as LOCALIZED_REVERT_BUTTON"), maybe using a more
> precise comment saying why it is different.

I don't see how these two levels of translation is a
good thing. The shared level is only helpful in the
most simple of ways: being able to translate 5 occurances
of "OK" in an application with a single "Okej" instead
of with 5 "Okej". It doesn't actually help the translation.
There's no quality improvment, it merely reduces typing
and saves a few bytes, but it -can- potentially hurt a
translation and block it until some future release of 
the software. (Say if "OK" could not be translated as
"Okej" in all of the 5 contexts and there was no good
common term to replace it.)

Any common simple phrase could easily be looked up as a
regular string, given a unique identifier. More typing
on part of the translator (or search&replace) but no 
waiting on developer and source to replace the shared 
string lookup with a regular string lookup.

 ...
> I don't think the translation can be made right on
> the first time without any dev-translator collaboration,
> as the dev can't figure the string is used in two
> different contexts and can't mark it as such.

I see the latter as supporting my argument that using
the shared string method in localization is premature
optimization and should be avoided.

(I wouldn't want to bet my life on a guess that say 
"Revert" is easily translated to a single phrase,
regardless of context, in all languages of the world.
When it happens its probably either a very lucky guess
or smaller languages bending their backs over to invent
new phrases or force new meaning on present ones. Not
necessarily a bad thing though.)

> What should we do ? Use the sourcecode filename and
> line number to ensure each string has a unique ID ?
> Meaning the translator is left with a file holding
> dozens of lines with the same string over and over
> again, with no idea where each 'OK' will land, and
> needing to enter a different translation for each of
> them to identify where it is used ?

I don't see any way around actually checking every
string in its context, or that it would favor either
shared strings or individual strings. 

Isn't it a translator's (or translator community's) job
to ensure that the translation is correct for its 
context(s)?

If there is a unique identifier it's not hard to search
the source for it.

A website could be invented to automate screenshots of 
applications and allow a developer to tag screenshots
(sort of like Facebook photos) with string occurences
and thus pave the way for translation.

> I think communicating with the developper will help
> everyone.

If translators can get work done without waiting on
a developer to coordinate things, that's a good thing.
Think multithreading.

I'm not disputing the benefits of coherent terminology
and well chosen common phrases. I just don't see any 
great need to firmcode them by way of shared lookup.
Translators would of course benefit from knowing and 
using these common phrases. I'm thinking a guideline
and preferred-phrase-aware community translation 
solution would suffice (software or website).

/Jonas.

Other related posts: