Re: Details
Sorry, your message to [EMAIL PROTECTED] was rejected by MailScreen. MailScreen will only deliver messages to current e-mail addresses. Your message was not delivered because [EMAIL PROTECTED] is an obsolete or invalid address. Please get the current address for the recipient and send your message again. See http://www.MailScreen.com/ for more information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Always use UTF-8 when running base-config?
I've been thinking how we should handle languages not using the default charset in the linux console, when base-config is executed as the second stage installer. The current approach is to add support for new charset in /usr/sbin/termwrap, and try to make sure this work for all the different charset in use. This might work, but is quite a bit work, and the testing each charset recieves is very limited. Instead, I suggest we always use UTF-8 while running base-config, this way making sure base-config work for all the languages we need to display, instead of only the ones that recieved most of the testing. If we keep the requested locale in LANG, but uses an UTF-8 locale in LC_CTYPE, I believe the correct locale variables will be used (for sorting, translations and such), while the charset printed will be UTF-8. I'm not sure if this is how it is supposed to work, but I believe so. Testing with date indicate that I might be mistaken, but testing with the locale program indicate that I am not. se_NO uses UTF-8 charset, while fr_FR uses ISO-8859-1. First I check the charset that should be printed: % LANG=se_NO locale charmap UTF-8 % LC_CTYPE=fr_FR LANG=se_NO locale charmap ISO-8859-1 % Then I test with date, comparing the output using UTF-8 and (should be) ISO-8859-1: % LANG=se_NO date sotnabeaivi, ÄakÄamánu 07. b. 2003 16:32:46 CEST % LC_CTYPE=fr_FR LANG=se_NO date sotnabeaivi, ÄakÄamánu 07. b. 2003 16:32:33 CEST % As you can see, the charset of the printed string is not adjusted to match the current charset. Is this a bug in date/glibc, or is this expected behaviour? Anyway, if we can use UTF-8 as output charset while keeping the other locale values from the locale we want to use, we can install bogl-bterm and use this for all translations, instead of trying to adjust the console charset or start the appropriate terminal wrapper based on the charset used by a given locale. This would make it a lot easier to make sure base-config always display the translations. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Resultats de vos commandes
> Please see the attached file for details. Commande non comprise : la fin du message est ignorée. Aucune commande n'a été reconnue dans votre message -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
V I R U S A L E R T !
V I R U SA L E R T ! Virus found in message from you !!! Message was deleted. Ve vami zaslane zprave byl nalezen virus !!! Zprava byla smazana. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mklibs and brltty
[Mario Lang] > Now, the question is what would be the proper fix for this problem. Could weak symbols solve the problem? I'm not very familiar with shared library internals, but I believe a weak symbol will be selected from the library if no other matching symbol is available. If the library provides such symbol, it would make mklibs happy, while the shared library linker would still select the symbol from the executable. Is this correct? I am mostly guessing based on the rumors I've heard about weak symbols. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: patch
[Tomohiro KUBOTA] > Such a normalization is not needed if the platform is limited to > GNU/Linux. However, I tested FreeBSD and it had different naming > way for locales (for example, ISO8859-1 in FreeBSD vs ISO-8859-1 > in GNU libc). Moreover, there are many proprietary UNIX systems. Sure. If you are sure it will never mistake one charset for another, it is OK with me. There is a IETF registration for charset names. I suspect it would be better to accept the names registered there, and report errors on the others, to make it possible to detect when an incorrect charset is used. Or perhaps ask the C library if the charset is known before trying to guess which charset it is. Anyway, as long as it is hidden in some library, I do not have to worry about it. :) > I cvs-committed it. I enabled --with-textwrap of ./configure in > debian/rules because it is not used unless libtextwrap-dev is > installed (and I expect rare people have installed it now). For > people who want to test my patch, just install libtextwrap-dev (and > libtextwrap1 which is depended) and rebuild cdebconf. And I uploaded the new version, with this support enabled. The Japanese d-i install looked quite good. :) But I need to know which charset should be selected by default among the two japanese entries in /usr/share/i18n/SUPPORTED. UTF-8 or EUC-JP? This is the locale that will be included in /etc/locale.gen, and possibly in /etc/enviroment. Would you like to add Japanese support to Skolelinux too? Check http://i18n.skolelinux.no/new-language.html> for instructions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mklibs and brltty
On Sun, Sep 07, 2003 at 09:04:39PM +0200, Petter Reinholdtsen wrote: > Could weak symbols solve the problem? I'm not very familiar with > shared library internals, but I believe a weak symbol will be selected > from the library if no other matching symbol is available. If the > library provides such symbol, it would make mklibs happy, while the > shared library linker would still select the symbol from the > executable. Is this correct? I am mostly guessing based on the > rumors I've heard about weak symbols. dropping subdirs which aren't referenced via rpath from the resolver in mklibs. none of that libs will be reduced. bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: patch
Hi, From: Petter Reinholdtsen <[EMAIL PROTECTED]> Subject: Re: patch Date: 07 Sep 2003 21:12:09 +0200 > And I uploaded the new version, with this support enabled. The > Japanese d-i install looked quite good. :) Thank you very much! > But I need to know which charset should be selected by default among > the two japanese entries in /usr/share/i18n/SUPPORTED. UTF-8 or > EUC-JP? This is the locale that will be included in /etc/locale.gen, > and possibly in /etc/enviroment. For users' environment, EUC-JP is preferred. UTF-8 is not very mature, unless it is used only for limited range of softwares which we can test and modify, such as the installer. > Would you like to add Japanese support to Skolelinux too? Check > http://i18n.skolelinux.no/new-language.html> for instructions. Sorry I am not very interested in translation. I think it is one of labors which should be done for languages which OSes support very well. However, I am now working not only for Debian but also various upstream softwares, because it is needed for these softwares' i18n. When I say about i18n, it usually means about ability to display, input, print, basic process (counting number of characters, extracting a character, and so on) non-Latin/multibyte/doublewidth/combining characters. These upstream-level effort will help i18n of any distributions. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
