Comment 55 for bug 108057

Cristi, the situation regarding UTF-8 support is quite good in Linux. Most modern graphical apps have no problems. However, there are still console apps in use which do not support UTF-8 and maybe some ancient GTK+ 1.x packages. I'm not sure about the Linux console though.

Jani, I'm not really sure what that xml file is used for. I certainly haven't added the existing "std" and "winkeys" variants in it, they were probably filled in by one of the maintainers. There also seem to be plenty of variants in the symbols/* files that are not represented in that file. Regarding apps that graphically expose existing xkb variants to users, I know at least one case in which the GUI directly picks up the variants from the symbols/* files, KDE's control center does that. I will further investigate this issue and will probably report it in xkeyboard-config bugzilla.

Mihai, I'm not sure what points you disagree on now. It may well not be your fault, as this interface is not well suited for debates. However, I cannot see the end of our contradiction regarding the "correctness" of the diacritics in the RO xkeyboard-config file.

The general discussions over diacritics, layouts, UTF-8, xkeyboard-config etc. should probably take place somewhere else, we shouldn't pollute this bug report with endless debates. I would suggest the "Diacritice" mailing list, a place for people interested in Romanian localization of free software to discuss general localization issues: http://groups.google.ro/group/diacritice . That should also ease the communication as it is throughly suited for discussions.