*.desktop files: Enconding=... may disallow the "shortcut" from being editable - right-click + edit-launcher does nothing; item-Properties allow some changes, but not the name of the thing (disabled).
As I asked on the mailing list, is there any output to console when you select that menu item? If necessary, kill xfdesktop and run it manually from a terminal.
ok, here the thing: exo-desktop-item-edit: /home/az/Desktop/kmail.desktop: Key file contains unsupported encoding 'cp1251' Take one normal .desktop UTF8-icon, having Name[LANG]=..., where LANG is your non-C locale, and change the content of that Name[LANG] to some other encoding. The icon is immediately auto-moved to next empty place. Edit launcher here still works - but the name shown is the file name. (this is the other similar bug) if u also change the Enconding= to anything else, Edit Launcher causes the above message to appear on console - which is nowhere on a normal system - and nothing else. here, i have utf-8 and cp1251 as valid cyillic encodings, and bg_BG bg_BG.UTF-8 bg_BG.cp1251 are all valid locales (default one is bg_BG cp1251). Still, it complains. i don't mind that it complains, actualy, every time i see a working cp1251 locale + font + settings, i still put a mark on the wall of joy (not even 5 there), but this way to the normal user this Edit Launcher becomes useless. maybe add the encoding as option in the editor and let the user screw himself up.
Ok, this is Benny's then...
Encodings other than UTF-8 are deprecated for .desktop since a very long time, and are not supported by Xfce (nor by GLib), and will probably be never supported.
The error message you see is actually from GKeyFile, so if you want this fixed, file a bug report to GLib. But don't count on this being fixed ever, the Encoding field was one of the worst mistakes in the initial KDE .desktop design, and was deprecated for good reasons. Just use UTF-8, which is the only encoding supported by all implementations; there's no reason to use another encoding anyway. The "normal user" should not use anything but UTF-8, and no sane desktop file editor should generate files with non UTF-8 encoding, so unless you mess it up manually, it'll just work.