http://qa.mandrakesoft.com/show_bug.cgi?id=2270
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
------- Additional Comments From [EMAIL PROTECTED] 2003-04-01 16:50 -------
On Tue, Apr 01, 2003 at 08:58:12AM -0500, fcrozat wrote:
mendurake must write .menu files in UTF-8, it is simply easier like that;
so the source encoding is known, and you can convert to other encodings if
needed (for WM using locale encodign instead of UTF-8).
I didn't knew .menu files told their charset; in that case, there is
yet another bug: that info is not used! if the cahrset is told in .menu
files, then whe ncreating the *.desktop files (that must be in utf-8)
the strigns ahve to be translated from that encoding to utf-8.
But there seems that the encoding of .menu files is never requested nor
used.
In the menu methods source strings are supposed to be in UTF-8 (that is
because translations are retrieved in UTF-8).
So the easiest would be to mandate UTF-8 as the only charset encoding
valid for .menu files; have menudrake use UTF-8 when writting them,
and have all .menu files in the rpm packages be in UTF-8 too (that should
already be the case, well, they don't have any 8bit char at all it seems)
And no, it won't be a problem for non-Gnome/KDE environments, as the
menu files from rpm packages are already supposed to be in UTF-8 only
(the menu methods creating the menu structures used by the WM already
expect to work with UTF-8 as the source text).
The only difference in menu methods is the charset encoding of the target
(the menu structure to be created), if it is to be in the locale charset,
then translate(lang,string) is used; if it is to be in utf-8, then
encode_translate(lang,string,"utf-8") is used.
As you can see, the source encoding is never specified, so it can only
be UTF-8.
At the current state of UTF-8 deployment it is much better to use UTF-8
the most possible, and only switch to another encoding at the final stage,
and only if there is no other solution.
That is, only when creating menu structures for WM that don't use UTF-8
but the locale charset.
Remember also that UTF-8 will be more and more used (all functions allowing
to draw strings antialised require strings to be in UTF-8), and also that
UTF-8 will be more and more used as the default encoding.
Non-UTF-8 should be handled as special exception cases, and not the opposite
way.
------- 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.
