Re: I18N (Multibyte Enablation) of debconf
From: firstname.lastname@example.org (Denis Barbier)
Subject: Re: I18N (Multibyte Enablation) of debconf
Date: Mon, 4 Aug 2003 21:52:45 +0200
> IMHO you should first focus on providing working solutions for each
> individual program, and see later how to provide reusable code.
Ok. Line-folding is small but complex (i.e., easily containing bugs)
processing, so I would like to write one code and reuse it for both.
I will also start a general project to develop a library for multilingual
line-folding at the same time:
> The main reason is that this would allow Japanese translators to
> work on these programs, maybe they are not willing to do so now.
> There are surely other problems which are hidden now, and the sooner
> these programs are known to work with your locales, the better.
If possible, I would like to translate task names and descriptions
into Japanese. Since tasksel is one of basic packages, I imagine
someone will want to translate even if I won't.
BTW, I have noticed that tasksel has to use slang1-utf8 instead of
slang1 to support Japanese in EUC-JP encoding (I have not tested
UTF-8). (Changing Build-Depends: line in debian/control file seems
to be enough on this point.)
(Offtopic) Is slang1a-utf8 an extension of slang1 not only for UTF-8
but also for other multibyte encodings? If it were true, the name
and Description: of the package would not be appropriate.
> About cdebconf, a fake C.UTF-8 locale is used, so all strings are UTF-8
> encoded. Language selection is done via the LANGUAGE environment
> With tasksel, LC_CTYPE encoding is used.
I see. In cdebconf case, usage of C.UTF-8 locale will mean that
LC_CTYPE encoding is UTF-8. Thus, adoption of LC_CTYPE for my
line-folder can support both cases.
Tomohiro KUBOTA <email@example.com>