On Mon, Jun 19, 2006 at 08:57:02PM +0200, Steinar H. Gunderson wrote: > On Mon, Jun 19, 2006 at 01:42:53PM -0400, Joey Hess wrote: > > The easiest way would probably be to not track the information and store > > (and output) the field as utf-8 without doing any transcoding. This is > > not exactly what debconf does, but fields that do not define an encoding > > are basically using an undefined encoding and it's ok if cdebconf > > assumes it's really utf-8. If this causes a mojibake then the right way > > to fix it is to make the package define an encoding. > > After some discussion on IRC, here's the updated patch. > > --- cdebconf-0.102.orig/src/template.c 2005-09-21 19:07:46.000000000 > +0200 > +++ cdebconf-0.102/src/template.c 2006-06-19 20:54:35.000000000 +0200 > @@ -354,7 +354,7 @@ > free(orig_field); > return NULL; > } > - cp = strstr(altlang, ".UTF-8"); > + cp = strcasestr(altlang, ".UTF-8");
I am not sure that this is desirable, next time you will encounter "utf8" instances, and maybe other names too (except that I cannot find another one ;)) > + /* Plain debconf supports undefined character sets, on the > + form "Description-nb_NO: ", which is valid if the text is > + ASCII (but debconf still uses that syntax regardless of > + validity if the application does not specify a character > + set). To avoid losing these fields, we simply read them > + in as if they were UTF-8 fields, as valid ASCII is always > + valid UTF-8 as well. Ditto, this is supported by debconf for compatibility reasons, but we should try hard to get rid of undefined encodings wherever possible. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]