http://qa.mandrakesoft.com/show_bug.cgi?id=2270
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
------- Additional Comments From [EMAIL PROTECTED] 2003-03-27 16:38 -------
It seems to be an encoding-related problem.
KDE and Gnome use utf-8 for their *.desktop files (and so should other
environments following *.desktop standard); environments not using *.desktop
however use the locale encoding.
I tried adding a menu entry, and it creates a file ~/.menu/added_by_menudrake
where the added entry is.
However, the entry is using locale encoding (iso-8859-2 for cs_CZ locale);
it should be utf-8 (and utf-8 -> iso-8859-2 performed for WindowMaker,
icewm, etc menus; but not for *.desktop that use utf-8
menudrake uses gtk2, that is, it uses utf-8 internally.
So there is an utf-8 -> locale encodign being done when writting the
~/.menu/added_by_menudrake file, and that shouldn't be done.
The reason why the non-language entryes (eg: Comment=...) are not truncated,
while those that have language info (eg: Comment[cs]=...) are, is because,
while creating the desktop files from menu definition files
the non-language entries are simply copied, without anything being done about
charset, while for the language ones there is a charset conversion being
done from utf-8 to utf-8 (*), and as the string is not in utf-8... it fails.
(*): that was because when we start with that, KDE 2.0 required utf-8, but
the return of gettext() was in locale encoding, and an iconv conversion was done.
After that, an ldgettext() function was used to force return of gettext to be in
utf-8; and the iconv conversion was left, while completly useless...
well, the finction encode_translate_func can convert to something other
than utf-8, simply it only converts to utf-8 until now.
So; the solution would be to:
- ensure menudrake write in utf-8 in the menu definition files.
- change ldgettext(), to use standard gettext and make it
always return strings in utf-8
- change translate_func() (it returns the translation of the entry, in the
locale encoding) so that it calls iconv() on the translated string,
to convert it from utf-8 to the encoding of the locale (and no need to
do lots of setenv() and setlocale() for that... just a setlocale()
in main(), either the computer uses languages of the same encoding,
either it uses utf-8; we no longer support mixed non-utf-8 encodings
in a same system)
As all strings will be in utf-8 internally, as menu won't do locale changes
anymore, and as the output encoding will be utf-8 in most cases (kde and gnome),
the time spent by update-menus should improve quite a lot.
I attach a modified (and not tested) version of the i18n patch of menu package
that does that (there is still to do the change to menudrake to ensure it writes
files in utf-8).
Could you take a look at the patch and see if everything is ok?
------- 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:
menudrake in mdk 9 with czech localization causes the following:
when you create record or folder with nonEnglish character it creates
file_xyz.desktop which is fine. the problem is that it writes something like
this in it:
Comment=the whole title in UTF-8
Comment[cs]=comment stripped after a non-english character
example:
Comment=Zábava
Comment[cs]=Z
and you can see only the letter Z in the menu :(
the only resolution is to edit the .desktop file (in ~/.kde..) manually.
