GNOME Bugzilla – Bug 168168
Running intltool-update delivers wrong message catalog in po-functions
Last modified: 2005-03-23 06:46:20 UTC
As discussed on gnome-i18n list the line XGETTEXT_KEYWORDS = --keyword --keyword=F_ needs to be added to Makefile.in.in inside po-functions to get all function descriptions.
Created attachment 37789 [details] [review] Proposed patch
/me scratches head. That line was there. I wonder where it went.
There is a line with --keyword --keyword=F_ in there, but it isn't the one defining XGETTEXT_KEYWORDS. Why does po-functions/ have a Makefile.in.in when po/ does not? (Well, po/ does, but it is generated somehow.)
intltool generates the po we have no need of intltool for po-functions and nothing actually uses XGETTEXT_KEYWORDS as far as I can tell
Well, translators have a need of intltool and intltool-update uses XGETTEXT_KEYWORDS. We just work with fresh CVS checkouts without building anything. Have a look at http://l10n-status.gnome.org/HEAD/de/office/index.html to see whats going wrong if XGETTEXT_KEYWORDS is missing.
Ok. Jody, any objections to doing this? (With a comments as to why, I'd suggest.)
I've add the dependency to bug#134089, because the aim is to split the function data.
That's not a dependency. It's true that the bugs are related, but we can fix either without fixing the other one first.
I fixed the po-functions/ handling in the CVS. The files Makefile.in.in, POTFILES.in and POTFILES.skip in that directory are created dynamically, by autogen.sh. So you cannot work with literally "the fresh checkout". But if you run TRANSL_ONLY=1 ./autogen.sh everything should be set up, without any requirements for your development environment. (If we tried to check in the po-fuctions/POTFILES.* files, we'd surely make mistakes, so I believe this setup is much more reliable.)
I created files po/README_TRANSLATORS and po-functions/REDAME_TRANSLATORS which mention the need to run TRANSL_ONLY=1 ./autogen.sh
That's very bad, and you won't be making most of the GTP resources this way. Many translators only grab updated PO files from status pages, and then check-out just gnumeric/po/ and gnumeric/po-functions/ directories (or even only ChangeLog's and their relevant .po files), and do a commit. Now, you're requiring everyone to do a complete check-out, and statistics won't work (so, translators won't know when there is a new/changed string to translate). If you don't want to cooperate with GTP, that's your call, though (as I said, this will probably result in sub-par translations in po-functions, not because translators don't care, but because you're making it harder for them).
As for checking in POTFILES.*, I don't see what errors would you make there: intltool would catch only appropriate F_ keywords, and you can use "intltool-update -m" to check if any of the files are missing (and you'd get help from several translators who regularly run "intltool-update -m").
Danilo : Could you walk me through what is very bad here ? People are free to do what they've always done, but if they need to use intl-tool something needs to tell intl-tool about the new directory. Do we have other options ?
What is bad: http://l10n-status.gnome.org/HEAD/PO/gnumeric-functions.HEAD.sr.po Look at POT-Creation-Date: it should be today or at worst, yesterday (they are updated about once every 8 hours). This means that intltool-update isn't able to correctly update any of the PO files, so our statistics will lie to us, and we won't know when translation needs to be updated. For a domain to appear correctly in translation status pages (which are basically our most important tool, since they're accessible to non-hacker types, and because they can show you state of your translations without having to manually check each of them [and with ~200 Gnome CVS modules with support for translation, you can guess why this is so useful]), it must support intltool-update (not intltool Makefile-magic, just intltool-update). So, until we improve our status pages, it's best if you add this single line to your Makefile.in.in and commit POTFILES.in (and perhaps POTFILES.skip, though that will only bother translators who tend to check status with "intltool-update -m"), which will make it show up correctly. Gtk+ and Gnome-Applets are already using intltool for two separate domains each. XGETTEXT_KEYWORDS was specifically added to intltool-update so Gtk+ could separate out another domain, and while it is a hack, it's best we've got (now, I'm lying here: if you use GNU gettext po-functions/Makevars file, it's much cleaner, and supported by intltool as well). Basically, you don't have to have intltool do the building and installation steps, you only need to have "intltool-update -p", "intltool-update <lang>" work inside po-functions/.
OK, this explanation really looks like we need to check po-functions/Makefile.in.in and po-functions/POTFILES.in to the CVS. And as soon as we do that, there is a danger that some developer will run intltool-update -m there, so we should add POTFILES.skip as well. All these files are still generated by autogen.sh, so the developers will update them "automatically". ;-) I removed the TRANSL_ONLY hack and README_TRANSLATORS files, as I see no need for them now. Danilo, could you please tell us whether all works as expected?
I looked at the URL mentioned in Comment #14, and the POT-Creation-Date: is today. So I think the issue is resolved.