[Top][All Lists]

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

Re: [bug-gettext] Further about --kde mode for xgettext

From: Daiki Ueno
Subject: Re: [bug-gettext] Further about --kde mode for xgettext
Date: Fri, 13 Feb 2015 13:16:57 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Chusslove Illich <address@hidden> writes:

> Any decision about this?

I haven't decided anything about it yet.

> To recap, the minimal needed support would be to add the kde-xml-format flag
> (or whatever is a better name), such that xgettext would never put it on
> extracted messages, and msgfmt -c would treat it same as kde-format.

By the way, thanks for the suggestion[1].  That makes sense.
Are you fine with xml-format which only checks XML well-formedness?

> Additional support would be to make xgettext aware of default Ki18n's
> keywords when --kde option is issued, and to put one of the two flags to
> every extracted message, regardless of whether it has a placeholder or not.

> In the meantime I did see in x-c.c that environment-specific keywords are
> avoided in principle (e.g. commented out GCC internal keywords). But,
> relying solely on --flag options to set formats, we would get into strange
> situation that --kde option serves no purpose any more.

Yes, but I'm not too sure that reusing the existing --kde option is a
good idea.  The option is designed to be similar to --qt and --boost,
and if we changed the meaning, it would become inconsistent and backward
incompatible (even though it is currently not in use).  At least, we
would need to announce the change and reorganize the documentation.

So, I'd rather add a new option if the shorthand form is really desired,
and that's my question.  Isn't it feasible to maintain the custom --flag
list within the KDE's build infrastructure?  Then users don't need to
wait for a new release of gettext being deployed when a new keyword is
added to ki18n.

[1]  https://lists.gnu.org/archive/html/bug-gettext/2015-01/msg00023.html

Daiki Ueno

reply via email to

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