[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: making changes to Makefile.in.in to allow multiple domains
From: |
Yann Dirson |
Subject: |
Re: making changes to Makefile.in.in to allow multiple domains |
Date: |
Tue, 14 Sep 2004 23:25:52 +0200 |
User-agent: |
Mutt/1.5.6+20040523i |
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/>