"pcg"@goof.com ( Marc) (A.) (Lehmann ) wrote: > > Native support for UTF-8 is uncommon and of course that is bad and > > Sorry? my mailer supports it (mutt) my editor supports it (vim), my terminal > supports it (xterm), my irc-client supports it (epic), my browser(s) suipport > it (lynx, netscape, mozilla), my os supports it on the console (linux)... My mailer doesn't (pine), my editor doesn't (Emacs), my terminal doesn't (gnome-terminal), my irc client doesn't (xchat), and lots of ordinary console text tools don't. > utf-8 support is more common than supprot for most other charsets, > actually. Hardly compared to iso-8859-1, which I was referring to. > > Editors aside, simply looking at and otherwise using console text tools > > on UTF-8 files with non-ASCII content, usually has little if any > > support. > > The same is true for anythign except ascii. No it's not. Tell me any console text tool that *doesn't* handle iso-8859-1 correctly by default nowadays. > Hint: you cannot represrnt the majority of languages with ascii. I'm very well aware of that fact, thank you. > (and I was told emacs can do utf-8. at least people found a way to decode > my mails properly in emacs). Maybe it's just that emacs can't natively > edit utf-8 text No, it cannot do it natively > but it should be possible to just convert it to some > native charset. every unix comes with iconv I know that, but if I'm understanding it correctly, you are suggesting that iconv be used manually before and after every translation update as extra steps? Manual steps that are completely unnecessary since intltool does this automatically. > > I'm sure you'll find out many other surprises when you check what text > > tools in any major GNU/Linux distribution actually fully supports UTF-8, > > I'd say the majority does. In my experience, that's far from true. > > Sure the tools need to get updated in the end, but it's a very slow > > process that has already taken years with little happening and surely > > many years remain to come > > I realyl think you need a reality check. Thank you, I have checked reality regarding UTF-8 support every time this has been brought up (and as a translator, I've experienced this debate a lot of times), and every time the disappointing results have been that progress is slow and that many of even the most common applications don't have support, or in some cases where UTF-8 support is claimed it is incomplete or broken. Nevertheless, insulting me doesn't make your opinion more valid. > > have to use UTF-8 is a big practical problem for translators. Note that > > s/big/little/ every editor should eb able to pipe through some > external program (iconv -f utf-8 -t koi8-r for russian for example) on > loading/saving. Why would this manually piping be favorable over using intltool that already does this automatically, requires no additional manual steps in the process of translation, and lets translators work with their preferred encoding? > And I am quite sure translators for non-ascii languages > already know how to cope with charset problems - they needed to. I'm a translator for a non-ascii language, but I never have to cope with charset problems (aside from the thankfully very rare occasions when people demand things to be in UTF-8). So I guess this effectively makes this theory moot. > > That still won't solve the problems: > > (agreed to all of them - i wa spurely concerned about utf-8 ;) > > > > While I do agree with Marc that XML is not the all-purpose solution I > > > really think it's going to help in the case of localisation by the > > > consistent use of UTF-8 and other concepts like includeable files and > > > overrideable tags. > > XML and UTF-8 are two completely orthogonal concepts - xml is represented > in unicode and can be written in almost any encoding (ascii, viscii, > whatever). > > I don't see any problem having multiple different(!) files with different > encodings, pleasing whatever a local translator likes. And so we do in fact agree... Christian
