> [: 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.
