https://qa.mandrakesoft.com/show_bug.cgi?id=1723
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
------- Additional Comments From [EMAIL PROTECTED] 2003-02-17 18:37 -------
more info:
- not all programs are affected (some are just ok with "use interactive")
- those affected need, in that order, "use ugtk2", "use interactive",
"ugtk2::prepare_gtk2();"
- and when some translations come from a file referenced by "use foo::bar;" it
doesn't work, but if that is changed to "require foo::bar;" it does... of course
that line must come after the prepare_gtk2.
So far I've found the following tools to have this problems:
- harddrake2: needs prepare_gtk2, and reaordering of a "require hardware::data;"
line. I commited it to cvs as without it the program crashes (bloquing bug)
- draksec: needs use ugtk2, prepare_gtk2, and changing "use security::level"
into "require security::level"
- drakfirewall: needs prepare_gtk2, and changing "use network::firewall" into
"require network::firewall"
- drakgw and drakpxe: need use ugtk2 and prepare_gtk2 (the encoding problem only
shows on the title in big letters on, blue backgroung; which is defined simply
as $::Wizard_title = N("title"); )
should I commit those changes to cvs ? they will fix the encodings problems on
display; unless a better fix is found we should at least do the above so that we
ship 9.1 with working tools.
------- 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: NEW
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.
