Hi Philippe,

> On 13 Feb 2024, at 23:54, Philippe Michel <philippe.mich...@free.fr> wrote:
> 
> The NC_() documentation you quote adds that "To get the translated 
> string, you should call g_dpgettext2() at runtime" but GTK (GTK2 at 
> least) doesn't do this in gtk_action_group_add_actions(), it uses 
> g_dgettext(), so there is not support for a message context.

Yes, it doesn’t even compile if you use `NC_()`.

> It looks like the alternatives would be to have the actionEntries table 
> non static, which may be somewhat complicated, or to use "Move" for move 
> as a noun and "verb|Move" for move as a verb. The latter seems the more 
> practical choice.

There are also dirty tricks for introducing message contexts like just adding 
some whitespace, for example using ”Move ” instead of ”Move” if it is a 
noun/verb.

But we could also leverage the kind of hacky implementation of message contexts 
in GNU gettext. Message contexts were introduced in a manner that did not 
require a modification of the format of .mo resp. .gmo files. It was simply 
assumed/stipulated that message ids must not contain the control character 
end-of-transmission (ASCII 004), and that was then solemnly declared the 
separator between a message id and a message context. Therefore, these two 
calls should be equivalent (not 100 % sure though):

    C_(”noun”, ”Move)
    _(”noun\004Move”)

The second line should not really appear as such in the sources because we 
don’t want that convoluted message id to be extracted by xgettext. But there 
are ways to prevent that.

Yes, it’s a hack but not too bad, imho. And it would be a little bit more 
straightforward than just randomly adding some whitespace to message ids.

I think I still have push permissions. Should I try that out and push it to 
main/~~master~~ or whatever that was in CVS?

By the way, it should not go unmentioned that this problem is caused by the 
gnubg feature ”switch language at runtime” which has never been a feature 
supported by GNU gettext. If we would just require a restart of the application 
after a language switch, we could avoid these kinds of problems.

Cheers,
Guido



Reply via email to