Description of Problem: Not only new gnome destroys a basic ability to have on a screen terminal windows side-by-side terminal windows using fonts with different encodings but even elementary font handling is FUBAR. Attached is an example of a small file in koi8-r encoding and two screenshots. The first shows how this file is displayed in a correct class gnome-terminal from gnome-core-1.4.0.4-54 without any changes in a general session setup. The second one shows how gnome-terminal from Limbo looks like when the same file is used and "Russian" session is picked up. The later has an effect of randomly translating various menus and message (quite undesirable in my case) but it seems to have a null effect where it really counts. Fonts used in a terminal do have a version with koi8-r encoding but this seems to be ignored. The same mess occures with iso-8859-2 fonts, at least, but effects are visually more subtle. :-)
Created attachment 65044 [details] A short text in koi8-r encoding
Created attachment 65045 [details] How this text looks on a sane display
Created attachment 65046 [details] How designers of Gnome2 seem think that you should see it
what is your locale? If your locale is koi8 then the text should have been converted, I'm not sure what's wrong. If your locale is not koi8, then the only fix is to have a manual "set encoding" menu as in Mozilla. Which is perhaps worthwhile. Nothing to do with fonts though.
I picked up "Russian" session from a login menu. You can see effects of this in a tool bar of a terminal frame as presented one of pictures. What should or should not be converted I have no idea and, unfortunately, I do not have any control over it. Actually there is nothing to "convert"; only proper fonts for a display should be used. I strongly suspect that in reality some "conversion" kicked in and pitiful results you can observe on an attached picture. Moreover if you are thinking 'iconv' then this program is truly anal-retentive and is using then slightest provocations to bail-out. In "real life" text in other encodings often contain extra characters from ASCII. Yes, I know that this is often not "correct" in some sense but I do not have the slightest degree of a control over it. For this test I picked up something which is "pure koi8-r" not to introduce extra factors. Indeed, allowing to pick up an encoding in a profile and no "conversions" seems like the only sane thing to do.
The whole point of a "choose encoding" menu is to do conversion from that encoding, so it doesn't make sense to say you want such a menu but no conversions. ;-)
I am not that interested at this moment what is going on under-the-hood. I only know from an experience that when 'iconv' is getting involved this usually spells trouble. I also know that in the currently released software things do work (maybe by an accident but so what?) and what is in beta is at this time plain broken.
Proposed UI here: http://pobox.com/~hp/terminal-encoding.png
Marking the head of the priority queue with priority high
*** Bug 75326 has been marked as a duplicate of this bug. ***
Ah, this should be done in rawhide. There's a menu Terminal->Character Coding in gnome-terminal.