If gnome-terminal client is started with a locale whose encoding doesn't match the profile's encoding, bad things are bound to happen (applications running inside the terminal are likely to misbehave).  Maybe we could do something here.


0. Do nothing, let users figure out what's the problem and how to fix it, and sometimes file invalid (pebkac) bugreports.


1. Modify the terminal's encoding to match the locale.

This goes against our current approach of the encoding being part of the profile, and it'd probably cause a big confusion as to when is the one from profile used and when is it overridden.

We could totally remove the encoding from the profile and just rely on the locale.  This would cause problems with those who modify the locale (the profile) run-time to match with whatever they're doing inside (running a legacy crap app, ssh'ing to a host of a different encoding etc.).  Probably this solution wouldn't be any better than the current and some users would begin to hate us.


2. Modify the locale to match the terminal's (profile) encoding.

Technically problematic.  There's no way to find an LC_CTYPE (language_COUNTRY.charset) for a charset.  We probably don't want to override LC_ALL (it's way too intrusive), and setting LC_CTYPE doesn't have an effect if LC_ALL is set, so it wouldn't work for those users.

I personally would expect the terminal not to fiddle with my environment to this extent.


3. Warn the user

When the two encodings don't match, g-t could feed a warning message to the terminal, before starting the shell.  (It'd appear as the top line, followed by the shell prompt in the 2nd line.)


/me votes for 0 or 3.  Maybe 1 if we can figure out how to make it not confusing.