https://qa.mandrakesoft.com/show_bug.cgi?id=1723
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From [EMAIL PROTECTED] 2003-02-18 00:11 -------
One needs to understand how Perl works to fix this problem.
Perl code source is parsed a first time, at which time the code in modules
designated by "use <module>" is executed (the code in BEGIN {} is also executed
at that time).
Then it's parsed a second time, at that time it executes the normal code,
definitions of global variables, function calls, and the code in modules
designated by "require <module>".
So when one puts global datastructures containing N() in packages, these N() are
called when the "use" is executed.. that will actually be before the
prepare_gtk2 call, hence the translations will be broken.
One cheap fix could be to replace the "use" by "require" but it has several
drawbacks (prototype checking better, functions prototypes available) and also
it's not possible for "interactive" tools because we don't know if we're running
in console or gtk2 before the interactive->vnew has been actually called.
Thus, the solution is to never use N() in global variables. Two solutions to fix
current code containing N() in globals:
- use N_() [this function asks gettext to extract strings, but doesn't actually
call the "translate" function -> functionally, N_() is the identity function];
this requires the programmer to call translate() when extracting information
from the global variable, before displaying in the UI
- replace globals by function calls; these functions may contain lexical
variables ("my" variables) containing N()
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
------- Reminder: -------
assigned_to: [EMAIL PROTECTED]
status: RESOLVED
creation_date:
description:
Similar problem as in bug #1175
By adding ugtk2::prepare_gtk2(); the interface displays correctly, but the
dropsown list of security levels ("Standard", etc) is still incorrect (it
displays the utf-8 strings as if they were latin1).
Even putting ugtk2::prepare_gtk2(); after the "use lib" line doesn't solve it.
Maybe the problem is in security/level.pm
To test it, launch draksec with translations of a non latin locale (to be sure
that the level names are not in ascii), for example in Russian.
LC_ALL=ru LANGUAGE=ru draksec
LC_ALL=ru_RU.UTF-8 LANGUAGE=ru draksec
the result isn't the same, which means that the translated string is converted
to locale charset encoding, while it shouldn't.
