From kde-i18n-doc Thu Aug 18 16:53:26 2005 From: Chusslove Illich Date: Thu, 18 Aug 2005 16:53:26 +0000 To: kde-i18n-doc Subject: Re: KGeography needs your help Message-Id: <200508181853.29428.caslav.ilic () gmx ! net> X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=112438411308731 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart2091533.k3RQoT7lKj" --nextPart2091533.k3RQoT7lKj Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > [: Nicolas Goutte :] > Gettext remains the reference implementation, which continues to be > developed, while KDE's support remains at an old level. > [...] > Personally I do not find this situation satisfactory. I agree. > I do not tell that everything has to be done now. Even it cannot be > done now, especially as there would be a need of the Gettext plural > support in KBabel. Err, doesn't KBabel support Gettext plurals already? At least when I open a= =20 PO file with Gettext plurals, it shows plural forms using tabs. Or perhaps= =20 this feature is still not working well throughout? > However, even if it cannot be so right now, I feel that the way should > be prepared and especially avoid to artificially block the path. Scripting is decoupled from underlying format, and thus doesn't represent a= =20 stopage of any kind. It is same as context infos currently are in standard= =20 Gettext: special embedding, using delimiter.=C2=A0As for this new take on=20 plural handling, technically it is again same as contexts and scripting,=20 however... > I do not think that completely freeing programmers from thinking about > plurals is such a good idea. Less work for the developer could well > mean more work for the translators. A balance would be better I think. Here I also see a possible trouble. Currently, if programmer forgets to use= =20 a plural handling variant of i18n, some of the translation teams is bound=20 to make him aware of that. Then, *all* other teams will be forced to=20 acknowledge this, for automatic tools will complain if some translator=20 just neglects plurals. In this other approach, there would be no such=20 forcing measure, now allowing *translators* to forget about plurals :) Krzysztof did talk about interface spewing warnings to log file when=20 translators don't use plurals, but using this as correction tool seems a=20 lot more harder than having automatic tools, like check_po_files and such. There is another point too. It would be nice to settle on Gettext plurals,= =20 so that translators and translation tools don't have to think about=20 particular "dialects" of PO files. (On a side note, why wasn't Gettext's=20 plural handling used in the first place, it seems to me there are no=20 technical reasons?) The lack of functionality could be supplemented with=20 scripting (or, with future extensions to Gettext, hmm...) Having said that, using Gettext plurals doesn't prevent us from *scripting*= =20 additional plural forms (or whatever else within plural message). With=20 Gettext plurals, the script would simply be attached to the msgstr that=20 one gets when number is 99 :) (checking the conditions in KDE's plural=20 implementation, that would be the last msgstr for any language.) > On the other side, I still think that a scripting extension would be > more useful if it was not something pure KDE-home-brew but something > that other projects, for example GNOME, could use too. (Think about > being it a freedesktop.org specification one day.) So this would mean > supporting Gettext plurals too. I'd just like to point out again that scripting stuff we've been talking=20 about has nothing to do with the plural stuff that we've been talking=20 about :) (except for the fact that both require exact same modification to= =20 programmer's i18n interface). And scripting stuff has nothing to do with=20 whether standard Gettext is used or not. I do agree that a broader support for scripting would be nice, but there=20 has to be someone to pave the way (or not pave, likewise :) In KDE we've=20 been lucky that existing code and programmers' habits don't have to be=20 changed to introduce scripting (or changed very little, depending on what=20 form of that KI18n we would settle for). Last time I looked, that wouldn't= =20 be the case in Gnome. So KDE seems a good start. =2D-=20 Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8= =D1=9B) Serbian KDE translation team --nextPart2091533.k3RQoT7lKj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDBL0JMSGXgigGr3ERAnBQAJ9xiR7kbioBsOi8IDFOY0NCuqe61wCeNioN NMXiquo0FlshFTUKl5k7VFQ= =jk9B -----END PGP SIGNATURE----- --nextPart2091533.k3RQoT7lKj--