bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] .twjr=awk support


From: Daiki Ueno
Subject: Re: [bug-gettext] .twjr=awk support
Date: Thu, 04 Jun 2015 14:59:17 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Karl Berry <address@hidden> writes:

>     where glob patterns are allowed to avoid repetition.
>
> Allowed but required?  Not sure if this would come for free.  E.g., a
> particular foo.cpp file might have a special keyword that bar.cpp (or
> *.cpp in general) does not.  This actually happens in Texinfo, although
> thankfully in our cases it does not hurt to define our special keyword
> for all files.

In such cases, I guess we could let people write other file names
explicitly without using glob, or adopt the !-patterns from git.

>     *.cpp --keyword ...
>
> I wonder about adding a keyword to the beginning of the line, like
> file *.cpp --keyword ...
>
> That way, if later on it turns out to be useful to define other aspects
> of gettext configuration in the same file, another keyword could be used
> and it would all be nicely parallel.

I am not sure if there will be any configuration aspects other than
files.  Do you have anything particular in mind?

If only per-file options are sufficient, I would propose to name the
file as POTFILES.opts, so it looks clear that the file complements
POTFILES.in.

> Which makes me think of another possibility, though I'm not sure if it
> makes sense: maybe such additional config could be optionally added to
> Makevars, which users are already (supposed to) edit.  Instead of
> creating a separate/second file.

That might make sense; I suppose you mean to pass the per-file options
through XGETTEXT_OPTIONS?

>     and a user needs to check if the option is available.
>
> Maybe the user could declare at some level (AM_GNU_GETTEXT, Makevars, ?)
> that such an options file is used and then the pot-update code can check
> that (a) the file exists, and (b) the version of xgettext is sufficient.

Yes, we could do that exactly, in a similar way that the pot-update code
checks xgettext/msgmerge versions.

I tend to think if we could generalize the version checks and move them
to m4/po.m4 so all the version checks can be done at configure time,
though I am not sure if it is feasible.

Regards,
-- 
Daiki Ueno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]