Created attachment 63167 [details] [review]
Use po/LINGUAS file

This is not the proper solution for adding support for po/LINGUAS. Proper support needs to be added to intltool, rather than faking support for it, by merging the LINGUAS back in to configure later.

If I may give my comments on this issue as mostly doing translations, I would like to give emphasis to the point that from the translators perspective this is really progress forward, because we do not anymore need to modify files in root directory. Also from the point of view in configure.(in|ac), it is just some M4 macros and so on, therefore I do not understand the point of "faked support".

This method is really "future compatible". I mean that when "proper" support for po/LINGUAS is added to intltool or other autoconf things, the po/LINGUAS file will remain same, it will not need any changes when the method in configure.ac is changed.

I don't disagree that using po/LINGUAS is the right thing to do. However, the method of doing it as advised in the goal linked above, and in the subsequent patches as a result of that goal, is not the correct way to accomplish this. It is a hack to make it work with the current set of tools.

We need to add proper support to intltool and do it the correct way, removing all relation between the configure script and LINGUAS. The intent is that it keeps translations from messing with configure. But if we have to regenerate the configure script every time po/LINGUAS changes, then nothing is really different.

But you do _not_ need to regenerate configure script if po/LINGUAS changes. Each time configure script is _evaluated_ it reads  the file po/LINGUAS.

The line
ALL_LINGUAS="`grep -v '^#' "$srcdir/po/LINGUAS"`"
will be untouched in configure (remember that autoconf is actually M4 macro processor , not an shell script evaluator). Thus when proper support to intltool is added, it actually contains just a bunch of M4 macros which are expanded to similar line in generated configure script.

I think what Rodney means (but I may be wrong - sorry if so) is that this way we need to execute the configure script each time po/LINGUAS is modified. I don't know how it works, but I suppose intltool has not this inconvenient. However, at the moment, this is already the case, so it's not worse than before... Moreover, we lose no functionnality, and add the po/LINGUAS file that will be needed also for the intltool migration. So even if it's a little dirty step, I think it's still a step forward.
My 2 cents...

What I mean is that configure has to get re-created and re-run if po/LINGUAS changes, and the ALL_LINGUAS variable is still used. So it's not really using po/LINGUAS, it's just faking the use of it, by using it through the old cruft.

And I've already added support to intltool for po/LINGUAS in CVS.

Created attachment 63463 [details] [review]
New proposed patch

This patch is based on GnomeGoal wiki guidelines

I've committed the necessary changes based on what was currently in ALL_LINGUAS at the time. Thanks!