Re: lenny release-notes built and available, questions
Hi webmaster,
please delete generated .txt files in the working copy of lenny release notes
on www-master. They are currently wrongly encoded and the problem got fixed
which requires a rebuild.
On Wed, Jan 14, 2009 at 06:24:47PM +0100, Simon Paillard wrote:
> On Wed, Jan 14, 2009 at 05:08:58PM +0100, Jens Seidel wrote:
> > On Wed, Jan 14, 2009 at 03:53:07PM +0100, Jens Seidel wrote:
> > > On Wed, Jan 14, 2009 at 02:19:49PM +0100, Simon Paillard wrote:
> > > > On Wed, Jan 14, 2009 at 01:25:31PM +0100, Jens Seidel wrote:
> > > > > On Wed, Jan 14, 2009 at 10:48:18AM +0100, W. Martin Borgert wrote:
> > > > > > locales-all is *not* installed, neither in etch nor lenny, but I
> > > > > > have en_GB.UTF-8 as LANG. Without an UTF-8 locale txt output
> > > > > > will be broken!
> > > > >
> > > > > It *is* broken on the build host! See for example
> > > > > http://www.debian.org/releases/lenny/i386/release-notes.de.txt
> > > > > which contains "?" instead of 8bit umlauts.
> > > > >
> > > > > How to fix this, using LANG=en_GB.UTF-8 in Makefile (is this a supported)
> > > > > locale on the build host)? Maybe it is better to change the system locale on
> > > > > www-master?
> > > >
> > > > It's less intrusive (and with no possible side effect on other
> > > > applications on www-master) to specify the locale in the makefile.
> > >
> > > What locale should we use? Even if en_GB.UTF-8 is supported on the build
> > > host is it supported on your/my box?
> > >
> > > Maybe it's better to locally adapt the single affected txt rule (xsltproc or w3m?)
> > > instead of all rules. Maybe there is a specific option to enable UTF-8 output
> > > (or will something as LC_CTYPE=UTF-8 work?).
> >
> > Ah, it seems specifying the option "-o display_charset=UTF-8" to w3m is the
> > trick which works independent of the locale. Simon, it would be nice if you
> > could test this.
>
> Tested ok and commited to SVN trunk.
> (actually not commited since you've just commited before :-)
Right, I do not consider my change to be wrong. Nevertheless I remember a similar
problem with the text based browser lynx (many possible configuration
variables, no proper support of UTF-8). The solution was to upgrade to lynx-cur
and this was really not obvious for me.
Jens
Reply to: