I believe this is very much needed, as I think it cannot be assumed
that every package that needs intltool uses autoconf (see bug 129482). 

Yes, this is a good addition, but I we add this feature, we should do
it correctly.

Use the gettext way to define it:

http://www.gnu.org/software/gettext/manual/html_chapter/gettext_12.html#SEC179

Created attachment 23213 [details]
Sample Makevars

I forgot to say that I think we should move to the new gettext layout
for GNOME 2.8, so we need intltool support for it.

That will be the end of GLIB_GETTEXT_PACKAGE glib-gettextize and other
ugly hacks needed int the past.

Are you up to making such a patch Carlos? It should be quite easy when you've
figured out how you want it to work. I will review it ofcourse.

I cannot do it now, but I will try to prepare a migration plan for GNOME 2.8
that could include this patch, but I don't think it will come from me, as you
know, my perl knowledge is null

I've made a patch to do this: use "Makevars" file to read DOMAIN name and
top_builddir (Makevars has priority over everything else).

Autoconf-style files are not needed anymore, and if there's not even Makevars,
it will assume domain name of "untitled".  So, you can simply put POTFILES.in in
"po/" and have intltool-update work.

I've kept the old Makefile.in.in (XGETTEXT_KEYWORDS) option for sake of
compatibility, though it'd be wiser if everybody started using Makevars instead
(which currently means gtk+/po-properties only).

Please comment on the patch.

Created attachment 28686 [details] [review]
Read parameters from Makevars; don't require autoconf files

2004-06-14  Danilo Šegan  <dsegan@gmx.net>

	* intltool-update.in.in (FindMakevarsDomain): Read $DOMAIN from 
	po/Makevars.
	(FindPOTKeywords): Try Makevars/XGETTEXT_OPTIONS first, then
	Makefile.in.in/XGETTEXT_KEYWORDS.
	(FindPackageName): Try FindMakevarsDomain first.
	Don't bork out if there's no configure.in or configure.ac.
	(CONF_Handle_Open): Try Makevars first, don't bork out if
	there're no autoconf-style files.

Why do you say "(which currently means gtk+/po-properties only)."?

The new gettext layout supports without problems multiple po directories easily.

Also, I had in my mind a migration plan from the old layout to the new one, but
I will not be able to redact and execute it before GNOME 2.8 freeze, take care
we should add also libintl inside tarballs and use it when GNU Gettext is not
available so the plural forms will work always. And we must depend on GNU
Gettext to generate/merge the .po/.pot file If someone has the time to do it, I
will try to help, but I cannot do anything more.

I don't see anything wrong with the patch

Regarding:

+		if (/^top_builddir[ \t]*=/) 
+		{
+		    $src_dir = $_;
+		    $src_dir =~ s/^top_builddir[ \t]*=[ \t]*([^ \t\n\r]*)/$1/;
+

Any reason why you don't do something like this:

if (/^top_builddir[ \t]*=[ \t]*([^ \t\n\r]*)/)
{
   $src_dir = $1;

Just wondering...since it doesn't really matter :)

Feel free to commit

Kenneth

Carlos: I only meant to say that gtk+/po-properties is currently the only known
user of XGETTEXT_KEYWORDS variable in Makefile.in.in.  There's nothing stopping
others from using this, and new functionality is even much better.

Kenneth, I copied that logic verbatim from finding top_srcdir in Makefile --
it's a bit below the added code in the same function :)  It looked funny to me
as well, but I didn't bother cleaning it up right away.

I'll commit it as-is now (since I'm leaving the house in 15 minutes), and
perhaps clean both of these later on (I hope it's ok to clean that up without
approval?). I'll mark this as RESOLVED/FIXED as soon as I commit.