* Bas Zoetekouw wrote:
> Would you rather consider adding a patch as I suggested above, that
> adds a new config option "default_header_charset" or so, which
> controls the charset to fall back to for non-encoded headers? I can
> see if I can hack on that later today...
Any news here already?
* Bas Zoetekouw wrote:
> The patch is attached.
Great, thanks!
> It adds an option "fallback_charset" for slrnrc, which selects the
> default charset that is to be used if the header or the article
> doesn't speficy anything.
Tested, and works nice... upload within the next minutes.
Hi Norbert!
You wrote:
> * Bas Zoetekouw wrote:
> > Would you rather consider adding a patch as I suggested above, that
> > adds a new config option "default_header_charset" or so, which
> > controls the charset to fall back to for non-encoded headers? I can
> > see if I can hack on that later to
Package: slrn
Version: 0.9.8.1pl1-24
Severity: important
Tags: l10n
Hello,
As in the bug title; after eliminating the mime_charset variable now
there's no way to specify the default charset for the newsgroup or the
whole running instance of slrn; this causes displaying '?' in place of
diacritical
severity 406210 wishlist
tags 406210 wontfix
thanks
* Miros/law L. Baran wrote:
> As in the bug title; after eliminating the mime_charset variable now
> there's no way to specify the default charset for the newsgroup or
> the whole running instance of slrn; this causes displaying '?' in
> place of
9.01.2007 pisze Norbert Tretkowski ([EMAIL PROTECTED]):
> > As in the bug title; after eliminating the mime_charset variable now
> > there's no way to specify the default charset for the newsgroup or
> > the whole running instance of slrn; this causes displaying '?' in
> > place of diacritical cha
* Miros/law Baran wrote:
> If introduction of a change that will decrease your user base and
> cause deterioration of user experience was something you desired
> (the whole pl.* hierarchy is now hard to read using your patched
> version of slrn), fine by me.
The reason why I reactivated the charse
9.01.2007 pisze Norbert Tretkowski ([EMAIL PROTECTED]):
> * Miros/law Baran wrote:
> > If introduction of a change that will decrease your user base and
> > cause deterioration of user experience was something you desired
> > (the whole pl.* hierarchy is now hard to read using your patched
> > ver
tags 406210 -wontfix
thanks
* Miros/law Baran wrote:
[...]
> The patch in slrn at this moment does not allow for setting your
> preferred output encoding and does not allow for setting the default
> encoding that should be applied to 8-bit headers wthout charset
> declaration.
>
> In terms of use
Hi!
Miros/law wrote:
> OK, but this patch does not enable full utf-8 support (it merely causes
> slrn not to be broken in most popular configurations). Full utf-8
> support (and MIME support) is something that mutt has. From the
> newsreaders, both tin and slrn to this moment do not have really d
* Bas Zoetekouw wrote:
> Norbert wrote:
> > There's one thing I can do to make everyone happy... provide two
> > binary packages, one called slrn which does not contain the charset
> > patch, and the other one called slrn-utf8 which does contain charset
> > patch.
>
> That's a rather ugly solution
[Norbert Tretkowski pisze na temat "Re: Bug#406210: slrn: there's no way to
specify default charset"]:
> * Bas Zoetekouw wrote:
[snip]
> > That's a rather ugly solution, if you ask me.
> Agreed.
, having slrn understanding Unicode encodings without
12 matches
Mail list logo
