Re: Language `Hot Switching'

Juergen> Contrary to Tom (sorry, but you've been the only one who said
Juergen> so), I think hot switching of the language environment
Juergen> is... well, okay, not essential, but probably a Good Thing.

Actually, I think Owen agreed with me on the gtk list.  So I'm not all

I agree that it would be an interesting feature.  And I agree it would
be useful in the situations you mention.

But making the feature work is not easy.

One approach would be to have the application do all the work.  That
is, it gets a "change the language" message, and then updates all the
appropriate elements of the GUI.  The problem with this is that
applications generally are not written with this kind of bookkeeping
in mind, so making this scheme work requires big changes to every

Another approach would be to have the GUI elements themselves keep
track of the label, and do the translation internally.  This also has
problems.  For one thing, you have to add translation domain data to
every label, and you have to set this domain in some cases (the
upshot: library code must be changed).  Also, computed labels have to
be handled specially.  You could write your own printf-like routine,
so that you could pass the label the format and the data, and have the
label run the printf (and store the format and data for later use).
Then the printf could be re-run when the language changes.

But this is only part of the problem.  Some widgets will require
higher-level reinterpretation.  For instance, time and numeric formats
change when the locale changes.  Also, for r-to-l languages like
Arabic, you must reflect most GUI elements (but not all!) about the
vertical axis (some of this bookkeeping must already be done to
support Arabic in the first place; it is just the dynamic switching
that must be implemented).

It's possible there are other cases to handle which I simply haven't
thought of.

Anyway, to me it looks relatively expensive to do, and the gains don't
look that big.  But then, I'm unlikely to ever switch languages except
when debugging.

I'm certainly not deeply opposed to the feature.  If you implement it,
I'll be enthused.

Juergen> BTW, does gettext support user-specific translation data?

I thought it might, but it doesn't seem to.  It would probably be
fairly easy to change it to let the user specify a list of directories
to search for .gmo files.


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