xgettext parametrization (was: Re: xgettext deficiency?)

Christian Stimming stimming at tuhh.de
Sun Dec 30 05:40:29 EST 2007


Hello Bruno,

thanks a lot for the pointers to help. A follow-up question:

Am Samstag, 29. Dezember 2007 17:36 schrieb Bruno Haible:
> > > The string is looked up in gtk20's translation domain. If
> > > you look into the source file, you'll notice the dgettext() call around
> > > it. 
>
> 1) If this is the only call to 'dgettext' in your program, or if all the
>    'dgettext' arguments should not be added to the POT file, then you can
>    pass to xgettext a set of keywords to look for, that does not include
>    'dgettext'. Like this:
>
>       xgettext --k --keyword=gettext --keyword=gettext_noop --keyword=_ ...

Thanks for pointing this out. What I didn't know (and from the arguments isn't 
obvious) is that --keyword or -k is necessary to switch off the default 
keywords. (It might be worthwhile to consider an additional 
argument --no-default-keywords to make this much more obvious.) However, when 
using this as described and using only our aliases for gettext and 
gettext_noop, i.e.

  xgettext --k --keyword=_ --keyword=N_ ...

it turns out I forgot the ngettext() calls. Hence, I used

  xgettext --k --keyword=ngettext --keyword=_ --keyword=N_ ...

*However*, when specifying ngettext here, it turns out xgettext doesn't 
recognize the special argument semantics of ngettext anymore. Instead of 
extracting both the msgid and the msgid_plural, with the above form I only 
get the msgid and the string isn't marked as a ngettext message anymore. Any 
hints for here? (I'm using gettext 0.15, a version which is probably used by 
many of my fellow developers)

> 2) If only this particular call to 'dgettext' should be omitted from the
>    POT file, you can hide the call in a C macro or inline C function, like
>    this:
>
>       #define gtk20_gettext(string) dgettext("gtk20", string)
>       gtk20_gettext("calendar:week_start:0")

Thanks for the proposal. This one is probably the way to go.

Regards,

Christian



More information about the gnucash-devel mailing list