[Bug 257905] misc/schilytools Character � displayed instead of ö

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257905

--- Comment #9 from Jörg Schilling <schily@schily.net> ---
GNU gettext definitely does not do do iconv() conversion for the from string,
it could not do that, since it cannot know the related locale for the from
string.

iconv() is only called in case there was a language translation from an .mo
file before and if that .mo file uses GNU mime enhancements to mark the
encoding of the .mo file.

See:
http://web.archive.org/web/20030608111824/http://www.li18nux.org/docs/pdf/LI18NUX-2000-amd4.pdf
for the Sun/GNU agreement from Y2000 as long as the upcomming POSIX standard
text is not yet ready for gettext().

The problem here is that we have standards that have been defined by US people
that (because they are from the US)  do not suffer from the pitfalls of the
insufficient UTF-8 standard.

Shift JIS is a really bad encoding for the command line, since it is stateful.
Stateful encodings are broken by design.

If you however are in an UTF-8 based locale, you in contrary to your claims
need to assume that the person is using UNICODE encoding and ISO8859-1 is
identical to the range 0..255 of UNICODE.

What p(1) does is just to implement a more intelligent handling for bytes that
result in an EILSEQ error. There is no "official" way for such a case and what
p(1) does just results in what people expect.

This intelligent handling could be made part of the rendering machines that are
e.g. used by xterm...

-- 
You are receiving this mail because:
You are the assignee for the bug.