Anne Wilson wrote:
My i18n file contains
I presume the font line stays unchanged, and the top line seems
straightforward, but what does your SUPPORTED: line look like?
Odd. I don't have one on this system, and I haven't noticed any
A backup from an FC3 machine listed
although I doubt both en references are strictly necessary.
I can't find any references as to where it is used...
I asked (about files that were apparently incorrectly named)
So from where did you get those files? Were they generated on
Some on this computer, some on what is now the server box. The email
mentioned arrived in kmail, showing the same symptoms, a couple of days ago.
Here's a sample -
The title should read
That's actually a different symptom of the same problem. UTF8 takes two
bytes to store most common non-ASCII characters, whereas the ISO-8859
family always uses one byte.
What you first described was seeing the two UTF8 bytes in an ISO-8859
program, so each accented character shows as two ISO-8859 characters
(some of which will probably be "illegal", so you'll see spaces or
something similar there).
What you've just illustrated is an ISO-8859 name viewed in an UTF-8
environment, where two ISO-8859 characters are interpreted as one
illegal UTF-8 character.
My first reaction is to blame the generating program (what was it?) In
my experience, many MP3 programs, following Winamp's example, have gone
flat-out for skins and custome text-handling. Too many of them don't
support UTF8 in $LANG properly.
Alternatively, what did the server box use to run? How did you transfer
the files? Red Hat went to UTF-8 early, and many other distros took a
lot longer to upgrade. And transferring files might not get the
(You used to use Mandriva, didn't you? I'm not sure when they adopted
As for the single e-mail -- I'd blame the other end, personally.
Maybe. Maybe he has the same problem as I do.
Um. Mail clients have no business not knowing which encoding they're
using. And if they know that, they've no business not putting it into
the headers of outgoing e-mail properly.
We've proved that your e-mail client can receive UTF-8. I suppose
there's still the chance that your correspondent used a weird encoding
that your client didn't understand. But you're not going to get the
"right" message anyway in those situations, except by blind luck.
E-mail address: james | In the Royal Air Force a landing's OK,
@westexe.demon.co.uk | If the pilot gets out and can still walk away.
| But in the Fleet Air Arm the outlook is grim,
| If your landings are duff and you've not learnt to