Standard gettext PO format

[Chusslove Illich]

While giving one more round of thinking to redefine i18n interface, I got a 
bit confused with some implementation matters: it depends on how the 
underlying mechanisms are going to change because of switch to standard 
gettext format.

I don't know whether the preferred option would be to completely switch 
implementation to gettext default (ie. using internally gettext's basic, 
context and plural calls), or just extending the current code based on 
some prehistoric Gettext version (the stuff in kdecore/libintl.cpp). I've 
been fiddling a bit with both approaches.

I couldn't really implement gettext defaults; it uses those setlocale() and 
binddomain() calls, providing its own resolution of paths to catalogs, 
which I don't know how to interleave with KDE's resources resolution. And 
just ripping the important parts out of the current Gettext code (as it 
was done eight years ago) is beyond my abilities at this moment. Not that 
I haven't looked around it, but it got awfully entangled...

Extending the current code wasn't much of a problem (but it's all hack), 
*providing* that one would be satisfied with retaining KDE's plural form 
choosing scheme. To be clear, PO file would contain standard plural 
translations (msgstr[xx] stuff), but KDE would take the proper form as it 
does now (specified via that message in kdelibs.po). The Plural-Forms 
header field would be there only as a dummy, say for msgfmt to do its 
checks. If this approach is feasible (as transitional perhaps, no BC 
breaks would be needed to replace it), I can present a patch.

A perl script to convert PO files to standard gettext also seems to be 
working at this point.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051228/b30cfe9f/attachment.sig>