GNOME Bugzilla – Bug 66155
intltool-update hack to figure out package name fails for gconf, other packages
Last modified: 2004-12-22 21:47:04 UTC
If you use intltool-update -P at gconf/po directory (branch gconf-1-0) It creates the gconf$MAJOR_VERSION.pot file because this (from configure.in): <configure.in> dnl used to rename everything and support simultaneous installs. dnl not incremented for bugfix or unstable releases. MAJOR_VERSION=1 AC_SUBST(MAJOR_VERSION) GETTEXT_PACKAGE=gconf$MAJOR_VERSION AC_SUBST(GETTEXT_PACKAGE) AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE,"$GETTEXT_PACKAGE") </configure.in> I don't know if this could be fixed.
Pan has a similar problem. you get AC_PACKAGE_NAME.pot instead of pan.pot. It uses: <configure.in> dnl init autoconf AC_INIT([pan],[0.11.0.93],[http://bugzilla.gnome.org/enter_bug.cgi?product=Pan])AC_PREREQ(2.50) AC_CONFIG_SRCDIR(pan/pan.c) dnl init automake AM_INIT_AUTOMAKE(AC_PACKAGE_NAME,AC_PACKAGE_VERSION) </configure.in>
*** Bug 65988 has been marked as a duplicate of this bug. ***
gaby module has a similar problem like previous ones, but also it use only a configure.ac file instead of configure.in then intltool does not know how use this package (It looks only for configure.in or Makefile but it does not look for configure.ac). Should I add a new bug report?
I think the fix here is going to be to add a package name parameter to intltool-update, for use in cases where it doesn't correctly guess the package name by parsing the configure.in file.
What happened with this? What did we agree on with havoc?
*** Bug 70371 has been marked as a duplicate of this bug. ***
Created attachment 6944 [details] [review] Fix the ggv's .pot name
Here you have a patch to get the name from packages that use AC_INIT to give the package name. I have only use cut && paste and it have a problem ;-( It works for ggv that use: AC_INIT(ggv, 1.99.0, http://bugzilla.gnome.org/enter_bug.cgi?product=ggv) but with Pan: AC_INIT([pan],[0.11.90],[http://bugzilla.gnome.org/enter_bug.cgi?product=Pan]) I don't know how should I remove the [] chars and I get a [pan].pot file :-(
I will find you on irc and help out
Fixed with kenneth's help ;-) Here is the correct line: $name = $1 if $conf_source =~ /^AC_INIT\(\[?(\w+)/m; Could I commit this change? With this change, I think that we only have the gconf problem.
Yes, please commit and then close this bug report afterwards Thanks!
Sorry don't close, this bug report is also about gconf :(
Hopefully the patch below can be the ultimate patch that covered all of the possible problems discussed in this thread. It incorporates Carlos' unapplied patch too.
Created attachment 8090 [details] [review] Patch I just described
#78926 is very similar to this report.
Created attachment 8093 [details] [review] Enhanced patch that fixes both #66155 and #78926
I'll look at the patch tomorrow and most possibly apply it
Just discovered some last-minute bug I introduced after intltool bumped version, too bad. The regular expression to extract variable is too strict, it doesn't allow any non-'\w' and non-'$' character to go through. That means "GETTEXT_PACKAGE=gimp-plugin-template" will be extract as "GETTEXT_PACKAGE=gimp". Perhaps need to replace [\$\w] into [^,\)\s\]] in a few places. Patch following. Kenneth, can you please reopen this bug for now?
Created attachment 8109 [details] [review] Patch fixing bad regex I introduced
Does this also fix the problems with sawfish? Or does that have nothing to do with this problem?
I'm not quite sure what you mean about sawfish. But if you mean that sawfish pot file can't be generated by intltool, then this has nothing to do with intltool. Sawfish has it's own method to generate pot, similar to what gimp-perl does.
Ok. But intltool could be extended with some weird hackery to support that format, no? But I guess that request should go into a bug report of its own, and I'm not sure it's even worth it since it's a minor inconvenience and since we might go with Metacity as official GNOME wm in the future.