Re: [bug-gettext] Generalized Gettext, take two

[Chusslove Illich]

> [: Vladimir 'φ-coder/phcoder' Serbinenko :]
> Having algorithmic language in translatations is an overkill in most
> cases. You can't expect translators to be skilled coders or to work deep
> through the intricacies of program they translate. In particular you can't
> expect them to produce good code. Having bugs coming from a translation to
> the language maintainer doesn't understand isn't manageable. Also
> maintaining the parser is no easy task and would use up too much time
> compared to very small benefit.

On what do you base these estimates? I mentioned in the section 7.4 that the
translation scripting system of the proposed kind is already in use, for
about five years now. That is the translation system of KDE 4. Translators
did not have to be experienced coders to use it, because they could ask
someone to help them out. For translators who did not want to use the
system, the system in no way got in their way. There was no maintenance
burden. There were approximatelly zero bugs so far in the scripting system
itself (incl. the parser), because it is very simple.

> If you have something needing complicated language-depending processing
> you should ask yourself whether you're doing something wrong in the first
> place and if you could simplify the output, in the same time making it
> more comprehensible.

The scripting system was useful in quite comprehensible situations, as shown
by examples in chapter 6. It is useful whenever a flowing sentence has to be
pieced up from parts in some sense, because it cannot be practically put as
a single message.

It is true, of course, that the translator can always make do with what is
available. In that line of thinking, plurals are not necessary either (and
no translation system but Gettext and Qt Linguist has them). However, my
proposal is not about making do. It is about not being stopped by technical
limitations to do that which is clearly possible, when translators are
willing to invest time. When translators are not willing to invest time, the
system is invisible to them.

> I've read quickly through it and while I recognize some legitimate
> drawbacks of current system, I don't see anything justifying such deep
> changes.

There are no changes, only additions.

> I don't expect any significant number of projects to migrate and so we'll
> end up with having to handle both old and new bugs.

The proposed design is such that there is no need for all-out migration.
Firstly, the complete system can be ignored, and then nothing changes.
Secondly, ordinary and new generalized calls can be used in the same code,
which makes it possible to gradually migrate, or to only use the generalized
call where judged advantageous. Finally, the design is such that all-out
migration is not that hard either, given that I did this once for three
million lines of KDE code in about a week span (section 7.1).

As for bugs, as mentioned above, for the past five years I don't recall
there being a bug reported on the translation system itself, or any
particular increase in bugs in translation caused by the system.

The only piece of grief was that there were only XML-like calls (xgettext in
the proposal) and no plain-text calls (tgettext in the proposal), while many
programmers continued assuming it is plain text and were puzzled by the
effects. Therefore in the proposal the two call types are strictly separated
(as they will be in the upcoming revision of the KDE translation system in
KDE Frameworks 5).

-- 
Chusslove Illich (Часлав Илић)

signature.asc
Description: This is a digitally signed message part.