Daniel Egger wrote:
> IF we need to add another dependency it has to be worth it. Solving
> problems by using XML for everything seems only clever to me. It does
> not make sense to use XML for tip files while plug-ins still keep
> in beeing broken (in the localisation context).
> > Someone mentioned how well Dia seemed to be doing in that respect.
> > Well, Dia puts the text strings for a sheet in a different file per
> > sheet. Even with only 8 supported languages, this already looks
> > totally cluttered to me.
> Really? Everything is were it belongs to and nothing is used within
> wrong context and, last but not least, its extensible and that even
> easily.

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

> > The tips file is 9 kB now. With 15 supported languages (how many on
> > the way?), that would become 135 kB.
> In contrary to po files untranslated messages are simply nonexistant.
> And you forget one thing: All .po files together are by definition
> bigger since the original text is repeated within every single file.

And that is for a good reason (see below)...

> > You cannot expect translators to wade through 30 lines of other
> > languages to be able to add his/her own translation (30 lines per
> > string to be translated, that is), so that translators do need to work
> > on separate files.
> Why not?

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.
This means that the original string and the translation should be as
close as possible to each other, and this is why po format has the
messages this way: First the original, and immediately below the space
for the translation.
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.

Another more dangerous thing is encodings. Multiple encodings in a
single file don't mix well. 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.

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). 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. Also, many translators use "translation
memories", that is large po format databases with existing translations,
created and managed by special translation memory. I use such a memory
with all my existing translations (it's 6.4 MB of text) to automatically
generate a skeleton for all new po format translations, with messages
similar to existing translations already translated. Aside from the fact
that this won't work if you don't use po format, this points out the
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.
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.

> And where do you get the 30 from? If you have 15 languages then
> you'll have at maximum 15 times the original text to skip.

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.

> Beeing a translator myself (and in fact also one of the one of the DIA sheets)
> I can tell that this is not as evil as it might look.

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

> > so I expect you have got a tool for the translators in mind?
> If necessary I can hack something up but it should not be necessary.
> I really don't see the big difference to hacking a .po file.

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.

If you do an alternative "hack", it better support most of the features
that gettext has and translators need. More of this in another letter.

> > gettext is also a standard.
> Great. Show me the specs... I'm not talking about de-facto or so
> called "industry-standards". gettext is such a crap that I really
> doubt there was a standarisation process which led to a proper
> specification.

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".

Gimp-developer mailing list

Reply via email to