Re: [Translation-i18n] Context, disambiguation, translator info

[Bruno H. <br...@cl...>]

Chusslove Illich wrote:
> xgettext should also assure that neither context nor message parts are 
> containing the context delimiter themselves. (We had nasty experience with 
> that in KDE, in particular due to dumb choice of newline as separator.)

Even better, choose a syntax which doesn't need a user-visible
"context delimiter".

> Would it be possible to partially handle overloaded calls, which we use in 
> KDE, by specifying total number of arguments? We have i18n("...", "...", 
> n) as plural call, i18n("...", "...") as context call, so keyword specs 
> could be like i18n:1,2:3 for plural i18n:1,2:2 for context. Then we can 
> get rid of old patched xgettext.

Sure. When xgettext would support interpreting one of the arguments as a
context string literal, it will also support specifying the argument position
through a command-line option.

> I think that with this, there is no reason not to introduce the default 
> cgettext("...", "...") call

Right. Assuming you only ever want to call cgettext with two string literals
as arguments, you can make it a C macro that expands into an inline C
function:

   #define cgettext(CONTEXT_LITERAL, MSGID_LITERAL) \
     _cgettext1 (CONTEXT_LITERAL "\004" MSGID_LITERAL)
   static inline const char *_cgettext1 (const char *context_msgid)
   {
     const char *translation = gettext (context_msgid);
     if (translation == context_msgid)
       return strchr (context_msgid, '\004') + 1;
     else
       return translation;
   }

This assumes that msgfmt will use the control character '\004' as
context delimiter (quite likely).

Bruno