On Tuesday 22 February 2005 00:10, Hrvoje Niksic wrote: > If wide chars were in that message, you could no longer print it with > printf, which means that a majority of gettext-using programs would be > utterly broken, Wget included. I imagine I would have gotten a bunch > of bug reports for that kind of thing in the 7 or so years that Wget > has been using gettext.
I have an interesting tale to tell. Approx one year ago I switched locale from it_IT.ISO-8859-1 to it_IT.UTF-8. Since then, almost everything has been fine, except a few application having some visualization or interaction problem. I never reported them cause I was conviced it was my problem, some misconfiguration of something. This week I had enough time to tinker, so I've tried to figure out why I get this answer when asking for a non-existent man page: [EMAIL PROTECTED] ~ $ man doesntexist Non c'ïuna voce per doesntexist You see? There's a square symbol between "Non c'" and "una voce". It's an encoding failure. If it worked, it would read: [EMAIL PROTECTED] ~ $ man doesntexist Non c'Ã una voce per doesntexist Looking at man code I've found it still uses catget, a translation tool older than gettext. The italian translation file is written in iso-8859-1 and catget doesn't convert it to my locale on the fly (as gettext would), so here is the bug. Everybody using a locale with a charset encoding different than the only one supported would hit the problem, not just italian/utf-8. After reporting to the man maintainer I've discovered: 1. he never got complaints in the many years after translation 2. he wasn't aware of the problem 3. he would be happy to switch to gettext to fix it So what I wanted to say is that your point of view is OK, cause as long as nobody complains you can *pretend* the problem is not there, but this doesn't make the problem vanish automatically ;) Sooner or later, someone will hit it, or maybe some people already hit it all the time but they don't realize it's a bug. -- Adde parvum parvo magnus acervus erit -- Ovidio
