GNOME Bugzilla – Bug 303453
A way to set a default character encoding
Last modified: 2005-05-08 11:16:24 UTC
Gnome-terminal isn't unable to set a default character encoding. On my system locale is ok: [zefram@nx01 ~]$ locale LANG=it_IT.iso885915@euro LC_CTYPE=it_IT.iso885915@euro LC_NUMERIC="it_IT.iso885915@euro" LC_TIME="it_IT.iso885915@euro" LC_COLLATE="it_IT.iso885915@euro" LC_MONETARY="it_IT.iso885915@euro" LC_MESSAGES=en_US LC_PAPER="it_IT.iso885915@euro" LC_NAME="it_IT.iso885915@euro" LC_ADDRESS="it_IT.iso885915@euro" LC_TELEPHONE="it_IT.iso885915@euro" LC_MEASUREMENT="it_IT.iso885915@euro" LC_IDENTIFICATION="it_IT.iso885915@euro" LC_ALL= and [zefram@nx01 ~]$ locale -a | grep ^it_IT it_IT it_IT@euro it_IT.iso88591 it_IT.iso885915@euro it_IT.utf8 so the chosen locale is supported. Nevertheless, gnome-terminal always start with a character encoding "Current Locale (UTF-8). It's impossible to remove UTF-8 as default encoding (I've tried this as adding ISO-8859-15 as character encoding, and then removing UTF-8 to have ISO-8859-15 as default), there is not a "choose default character encoding" options anywhere, and there is not a command line options to choose the character encoding. It took me hours trying to find why, as an example, less was unable to display properly some files, and so cat, while vi was ok. And this problem, worste, appears with slrn. This problem could be related to the behaviour of the file command, because if the intented-to-view file is categorized as UTF-8 Unicode text gnome-terminal is capable of displaying it properly, while when it's a "ISO-8859-text" I lost the èàò etc characters. Anymway, the suggested feature would resolve the problem, and could also be helpfule in other scenarios like the definition of different gnome-terminal icons, to see different types of document. Really, I do not understand why this feature is missing. Other information: The problem appears with Fedora Core 3.0 and Scientific Linux 64bit 4.0 (a rebuild of RedHat Enterprise Linux).
Probably the locale from gdm/X is different than when started from bash. Anyway feature request has been requested before. *** This bug has been marked as a duplicate of 108711 ***