Re: making changes to Makefile.in.in to allow multiple domains

[Yann Dirson]

On Fri, Sep 10, 2004 at 01:31:34PM +0200, Bruno Haible wrote:
> Yann Dirson wrote:
> > For "Battle for Wesnoth" I did some work to have po/Makefile.in.in
> > handle arbitrary multiple textdomains.  I'd think it would be useful
> > to have such a support in standard gettext distribution.
> >
> > Basically, what I implemented had to get in the way of the usual po/
> > handling.  The basic ideas are as follows - what do you think of the
> > general idea ?
> >
> > - new po/DOMAINS file to list the domains
> > - still use po/$domain.pot for potfiles
> > - use po/$domain.POTFILES.in instead of po/POTFILES.in
> > - translated pofiles in po/$lang/$domain.po
> 
> Thanks for the suggestion.
> 
> The ability to handle multiple text domains is already supported since
> gettext 0.11.5. The way it is done is through multiple po/ directories,
> one for each textdomain. You can name them the way you like, po1/ or
> wesnoth-po/ or whatever, and they don't need to be directly under the
> package root directory. But you need to be careful about the
> 'DOMAIN', 'subdir' and 'top_builddir' variable in each directory's
> Makevars file.

Hm, that certainly simplifies the implementation.  However, if a
project needs to modify Makefile.in.in, it has to be quite careful in
keeping all those copies in sync.  Or can we arrange to use just one
copy of it ?  Given the way po/Makefile is generate, I'd think it
would be possible...

While I'm at talking about Makefile.in.in changes, here are the
changes I had to make for Wesnoth:

- support for a format-specific xgettext-like tool for the wesnoth
datafiles

 => surely it would be better if there were hooks to allow plugging
 such alternatives without having to modify the Makefile by hand.

- support for specifying a command to find the files to be scanned by
xgettext instead of hardcoding into POFILES.in.  Such files are
currently a simple list of shell commands such as find and echo.  But
I understand it may not be easy to make this fully portable to
non-unix archs.


If we ignore the portability issue for now, my idea for a
generalization would look like defining parsers in a file like:

====
xgettext        cat ${DOMAIN}.POTFILES.in
wmlxgettext     sh ${DOMAIN}.FINDCFG
====

What do you think ?

-- 
Yann Dirson    <address@hidden> |
Debian-related: <address@hidden> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>