On 2/15/06, David Stevenson <[EMAIL PROTECTED]> wrote:
On 2/15/06, David Stevenson < [EMAIL PROTECTED]> wrote:On 2/15/06, Martin Geisler < [EMAIL PROTECTED]> wrote:Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> writes:
> there's no documented call though to tell gettext to "flush your
> mush" :(
I found this in the Gettext info pages, so for GNU Gettext there is a
way to make it change language at runtime:
/* Make change known. */
{
extern int _nl_msg_cat_cntr;
++_nl_msg_cat_cntr;
}
This was one of the suggestions I'd seen, and the other was from Bruno Haible (I believe he is the current gettext maintainer). He suggests that a
textdomain (textdomain (NULL))
call is used.
[ http://lists.gnu.org/archive/html/bug-gnu-utils/2005-10/msg00092.html ]
However, I took a look at the gettext code, and basically doing what Bruno suggests is just another way of achieving the _nl_msg_cat_cntr var incrementation.
But e does in fact call textdomain when changing the language anyway (with the PACKAGE string, but the result is the same, if you read the gettext code)...
I double-checked and the _nl_msg_cat_cntr is indeed getting incremented when e changes the language...
When I switch to ja_JP.EUC-JP it gets incremented, but when I go back to POSIX it doesn't...
Whoops! But not always...
After more investigation I think this is a problem with the way the e_menus that these modules use work.
The modules create their right click menus when the module is first initialized, and the labels are retrieved from gettext at *that* point in time. The e_menu_item_label_set stores the strings for later use then, so subsequent language changes don't have effect until a restart.
But to make sure textdomain gets called when switching back to C locale perhaps the attached patch would be in order?
David
e_intl.patch
Description: Binary data
