[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2005-08-03 17:17:09
Message-ID: 200508031917.12627.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: Clytie Siddall :]
> This is much like the plurals issue: gettext handles plurals very
> well now, with a setting for each language. There may well be a way
> for translators of different languages to indicate their gender use,
> to include variations, and eventually, to have a way for gettext to
> pick up on this automatically.

You are having a little too much expectation of the Gettext :) Consider 
that even the plural handling is not without dispute, as the KDE still 
doesn't use the default Gettext's way of handling plurals. Also, current 
plural handling (Gettext's or KDE's, whichever) will not allow you to have 
more than one plural argument per message.

This, however, is not the fault or lack of agility on the side of Gettext 
developers, but rather a consequence of huge differences between 
languages. One can simply not hope that specific needs of many languages 
can be covered in a monolithic way (single library), in such a way that 
solution for one language doesn't get in the way of the other.

Just look at the topic at hand, KGeography. First of all, instead of the 
problem being solved on the level of specific language, we need all this 
concensus talk (one solution fits all), which wouldn't be too bad if it 
weren't that all proposed solutions are:

1) Introducing a lot of work even for the languages that don't need it 
(David's proposal for context info "flag of...", or Matthieu's for "of..." 
messages). This is actually what Albert wanted advice against in the first 
place.

2) Complicating the code, asking developer to implement what he cannot 
really get the feel of (Albert's observation on the languages he speaks).

3) Reducing to lowest common denominator solution (as Federico proposed 
"Contry: %1, Capital: ?"), which is going to reduce the legibility in any 
language. Worse, it will do so even for languages which were well off in 
the first place.

4) After all, still very probably not working for this or that language 
(Marek and Federico demonstrate well the possible diversity). And don't 
forget that upon implementing current "least worse" solution, any further 
tweaks would be much harder.

In the current i18n framework, I would do pretty much nothing. I would 
leave the messages as they were originally ("%1 is the capital of...", 
"The flag of %1 is...", "The capital of %1 is..."), and forget about the 
names in different contexts. And let the translator wrestle with it, 
perhaps giving some info. For example, in my language I could use "%1 is 
the capital of which country?", "Which flag does %1 have?" and "%1, the 
capital is:", it wouldn't be too ugly (well, except for the last one :) In 
inescapable situation in some language, translator could still go for 
"Country: %1, Capital: ?" and the like.
Odds are, I guess, that less people are going to be annoyed this way, than 
seeing one huge PO file.

More general solution to this problem, and many more of its kind, would be 
to introduce some sort of scripting system for translators, such as the 
one that I have been proposing: 
http://caslav.gmxhome.de/writings/ktranscript.html

Concerns have been raised about its ease of use, performance and security, 
and I would be happy to discuss them further (as I have before), but there 
are two important points that I think I might have not made obvious.

First, the only change from the programmer's point of view would be that 
i18n functions are ditched in favor of i18n functional classes (thus 
almost retaining source compatibility). Now that KDE4 is approaching, it 
would be the perfect moment to make this switch. It would allow us to 
afterwards experiment heavily without breaking binary or source 
compatibility. We could talk about the choice of scripting language (or 
even have more of them!), implement natively specific i18n handlings that 
are found to be very widespread in application, and who knows what else. 
Or, if the worst happens, just ditch the scripting approach alltogether, 
with almost no leftover overhead.

Second, from the point of view of translator who does not need to use such 
scripting system, nothing changes at all. And for those who do need to use 
it but are unsure exactly how, there is this list to talk it over :)

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]