Am Son, 2001-10-07 um 15.32 schrieb 1002461554:

> Dia uses intltool/xml-i18n-tools for sheet files.

That's new then. They didn't when I was translating the sheets.

> Because one of the fundamentals of easy translation is simply to have
> the original text handy. This is so you can easily compare the original
> and the translation, and ensure that the translation is entirely
> correct. I have to visually compare the strings many times during the
> translation of a single message, and at least twice: first to interpret
> the message I'm about to translate, and finally to compare what I wrote
> with the original so nothing got lost or added or any meaning changed in
> the translation.

That's the same with the proposed XML format, just that all translations
are within one file and thus the unnecessary redundancy is gone.

> If you add a large number of translations to a single file and expect me
> to edit it, I have to skip a large number of unrelevant "garbage" (since
> I'm usually not at all interested in the other translations) just to
> compare the original and my translation. This makes the process of
> visually verifying translations harder.

Okay, but then again it's just a matter of tools. I believe EMACS can
fold the unwanted ones away as can do VIM 6.0 and if necessary you
can use any XML editor of choice.
> Another more dangerous thing is encodings. Multiple encodings in a
> single file don't mix well.

UTF-8 rules.

> I've got bitten too many times by other
> translators accidentally saving the whole file with their encoding and
> thus ruining my and many other's translations. Actually this was one of
> the most important reasons why we went away from editing .desktop files
> directly in GNOME: With hundreds of translators, the danger of someone
> accidentally doing this became very imminent (happened quite frequently)
> and it became a pain to ensure that translations weren't broken because
> of simple "accidents" like this. Also, it became a mess to "clean up"
> since effectively all translators had to be contacted to verify that
> their translations were still correct after such an accident.

We live in a global world and we should act like that. The different
8bit encodings are from a time where people cared very much about space
and not so much about internationalisation but this is not longer the
case; I believe that anything but UTF-8, Unicode and ASCII is futile and
will even be more in the future.

> While enforcing the use of UTF-8 solves the encodings problem, it is not
> feasible for many other reasons. One is simply the lack of support in
> many editors and many other text processing tools (and terminals and so
> on).

That's true. But what you're suggesting will only work for 8bit charsets
anyway; this broken software will most likely also fail for 2byte
charsets. Or do you want to exclude them?

> Effectively enforcing a particular editor hasn't worked yet, and
> probably never will, and it will probably take more time until all
> editors natively support UTF-8.

The good ones already do and the bad ones never will; there's still the
possibility to escape those characters and then you'll have pure ASCII.
You can even let them convert automatically if you really want.

> encodings problem again: If you force me to use UTF-8, I have to
> maintain several translation memories instead of a single one, one for
> each encoding.

Huh? You're trying to tell me that UTF-8 will mess this up? How are you
handling this right now then with different encodings?

> So while the storage of all translations in UTF-8 solves its shares of
> problems, it creates new ones for translators. This is why intltool lets
> translators use their encoding when translating, and converts it to
> UTF-8 when needed.

Okay, that's fine with me.

> And that is still a problem, as explained above. 15 lines of irrelevant
> text inbetween every single message and its translation into my language
> makes verifying translations an unnecessary difficult burden.

See above. Try the folding feature of vim 6.0, it's really cool.

> Dia uses intltool now, so it seems they have recognized the problems the
> translators had.

I haven't noticed that "problems", maybe it's only my imagination that
XML is easy to handle.

> It is necessary. po format and gettext have many important features that
> translators depend upon, something I have previously experienced that
> almost every translator knew.

important features in gettext?

> gettext has evolved. It has much of the features that translators need.
> And, as you admit, it's industry standard. If you want to replace it,
> you'd better write a better and fully compatible alternative (since a
> lot of tools across many platforms are designed to work with this
> industry standard), while keeping all existing features. I beleive this
> is where people use the phrase "show me the code".

Okay, I can hack up an application using XML for that purpose in almost
no time. While XML won't solve all problems here (I've not suggested to
replace gettext completely if you remember) it comes in quite handy 

I believe it's the righttime to say it again: I don't have anything
against the xml-i18n-tools; if people think it's much easier to use
them an .po files feel free to go ahead, however most of the brought
arguments are pretty bogus. I think it's more the fear of a change then
any technical reason not to go for the whole thing. Using .po files
being translated into XML files has one big disadvantage: You can't
use different translations for the same phrase that have a different
meaning in a different context.


Gimp-developer mailing list

Reply via email to