GNOME Bugzilla – Bug 119613
Should support Sun gettext
Last modified: 2009-08-15 18:40:50 UTC
According to #85718, intltool currently does not support Sun's implementation of gettext at all. intltool uses GNU gettext options, and many of them are not available in Sun gettext.
Damien, please, could you tell us what are you doing with intltool and gettext with your GNOME release? Could we just requiere GNU gettext >= 0.12? Please, we need this issue fixed before the GNOME 2.4 release. Cheers
Hi Tim, Damien. I don't know if you are the people who can answer our questions about gettext && GNOME && Solaris, but I think that you are working on l10/i18n at SUN so I hope you can answer us or redirect to someone else that can give us an answer. Cheers.
The incompatability arises during intltool-update --pot or intltool-update [lang].po using Solaris xgettext. They produce the not so useful output : elcray% intltool-update --pot xgettext: illegal option -- - xgettext: illegal option -- - xgettext: illegal option -- - xgettext: illegal option -- - xgettext: illegal option -- k xgettext: illegal option -- e xgettext: illegal option -- y xgettext: illegal option -- w xgettext: illegal option -- o xgettext: illegal option -- r xgettext: illegal option -- - xgettext: illegal option -- k xgettext: illegal option -- e xgettext: illegal option -- y xgettext: illegal option -- w xgettext: illegal option -- o xgettext: illegal option -- r xgettext: illegal option -- - xgettext: illegal option -- k xgettext: illegal option -- e xgettext: illegal option -- y xgettext: illegal option -- w xgettext: illegal option -- o xgettext: illegal option -- r xgettext: illegal option -- - xgettext: illegal option -- f xgettext: illegal option -- i xgettext: illegal option -- l xgettext: illegal option -- e xgettext: illegal option -- - xgettext: illegal option -- f xgettext: illegal option -- r xgettext: illegal option -- o Usage: xgettext [-a [-x exclude-file]] [-jns][-c comment-tag] [-d default-domain] [-m prefix] [-M suffix] [-p pathname] files ... xgettext -h WARNING: It seems that none of the files in POTFILES.in contain marked strings We use Solaris gettext & msgfmt at build time and intltool-merge appears to work fine here. Let me know if you want the Solaris 10 manpages.
Hmmm And how do you update the .pot file?, the msgmerge needs an updated .pot file. If you could attach the manual pages here it will be really good. I saw them at your website but seems to be old.
Yes, Solaris xgettext manpage would be helpful here. The failure you're seeing comes from the long options of GNU gettext: xgettext --keyword=... --file-from=... Besides, can Sun gettext extract non-ASCII strings from C code? Newer intltool will be more dependent on that capability, though it's not a strict requirement.
If you cannot handle UTF-8 strings inside source code, those strings will not be inside the .pot file generated so the application will not be full translated. I think that it's only an issue if you use Sun gettext to release/develop programs.
Created attachment 19113 [details] manpage for S9u5 xgettext
Please, could you give us a text or PDF version? I think that I don't have the needed files to build this sgml file into somethig more readable. Or <!DOCTYPE REFENTRY PUBLIC "-//Sun Microsystems//DTD DocBook V3.0-Based SolBook Subset V2.0//EN" [ is the same that the "normal" DocBook? Thanks
Created attachment 19115 [details] text version of s9u5 manpage for xgettext
This is the same page I found at sun.com website. :-( Will you add any other file format to your gettext version? For example, GNU gettext can handle directly: C, C++, ObjectiveC, PO, Python, Lisp, EmacsLisp, librep, Smalltalk, Java, JavaProperties, awk, YCP, Tcl, PHP, RST and Glade 1.x The idea behind intltool is that we add support for files that xgettext does not support directly, but as soon as it gets native support we don't need the code duplication. The problem is that GNU gettext is adding more and more file formats but SUN gettext can only support .c files (that's what the manpage say). Could we know what are your future plans with SUN gettext?, If you cannot improve your xgettext, perhaps you could just add the GNU xgettext command... any other ideas? P.S.: Perhaps we should move this discussion to the gnome-i18n mailing list?
The xml-i18n-tools list is probably a better choice, as 1) this is hihly relevant to intltool 2) we then don't need to bother several hundreds of translators that don't know anything about Solaris or intltool/gettext internals, or want to know for that matter, with a potentially long thread ;) Just my opinion.
Let me find out some of what the plans are overnight and get back to you on it tomorrow. Frankly, if all that is affected is extraction of content using intltools then I'm ok with using GNU gettext for this but others might have other ideas. I agree that xml-i18n-tools is a more suitable discussion alias.
Some questions I can think of: 1. Can SUN gettext extract strings from other languages? (most notably C++, others are of lower importance) 2. Since intltool-update failed on SUN platforms, how can it generate correct .pot files? (One solution I can think of is intltool-extract + xgettext) 3. If intltool is dropping glade 1 support in favor of GNU gettext implementation, would that be a problem for SUN gettext? (intltool has glade 1 support builtin currently) 4. Can SUN gettext extract non-ASCII (most notably UTF-8) strings? If not, will SUN plan on supporting it soon? 5. Some more info on SUN's xgettext is needed, such as: a) how to decide a certain xgettext binary is SUN's xgettext and not GNU xgettext? b) any clearer info on xgettext "-a" option"? c) can it write output to stdout?
Damien, What's up with this bug report?
Due the lack of interest from Sun about this bug, I think we should move intltool to take care only of GNU Gettext. Latest gettext has support for .glade (version 1.x and 2.x) so we should use it instead of our own functions if we detect gettext >= 0.13 Our objective should be move all file formats from intltool to GNU Gettext. Cheers. P.S.: Please, could we close this bug report?
If I don't get comments from Sun before January (I will be going on vacation shortly) I will close this bug as WONTFIX. Carlos, if you want please send me a patch that will use gettext's functions for glade etc. when users have a recent gettext. It should be pretty easy - just leave 'glade' out of the $xml_support string - OR even better, set the gettext type to "gettext/buildin" and make sure that all functions use this and NOT the $xml_support string. Cheers, Kenneth
Feel free to re-open if you are serious about fixing this bug - or have a patch.
Nah, I was just thinking if sun people needs such support badly, but it turns out not the case, as Carlos said.