Date: Mon, 8 Apr 2002 09:53:58 +0200 From: Cejka Rudolf <cejkar@fit.vutbr.cz> To: "Andrey A. Chernov" <ache@nagual.pp.ru> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/share/colldef cs_CZ.ISO8859-2.src Message-ID: <20020408095357.A4194@fit.vutbr.cz> In-Reply-To: <20020407204132.GA69778@nagual.pp.ru>; from ache@nagual.pp.ru on Mon, Apr 08, 2002 at 12:41:34AM %2B0400 References: <20020407170804.A79700@fit.vutbr.cz> <20020407181849.GA68881@nagual.pp.ru> <20020407205501.A84706@fit.vutbr.cz> <20020407204132.GA69778@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrey A. Chernov wrote (2002/04/08): > Because programs gets broken in other case. If they gets broken, we have to fix them or leave them as they are and wait for fixing them, but it is not possible to "solve" localization problems by breaking localization itself. If you think in this way, when we can expect that you break localization for numbers and for dates? These both are much bigger problem than collation: * When you call setlocale(LC_ALL, ...), floating numbers are automatically printed with comma instead of dot in printf() in some localizations. It is very common and really painful problem, for example when some programs generate broken PostScript files. * When you call setlocale(LC_ALL, ...), strftime() automatically produces localized strings and not all applications take it into account, even if it is everywhere specified. * On the other hand, with collation you have to use setlocale(LC_ALL, ...) and specialized strcoll()/strxfrm(), so applications have to know that this collation is different from standard collation, so applications have to expect problems. > Almost any current system > strcoll usage suppose ASCII-compatible charset and produce unpredictable > bugs otherwise. We are not ready to free-form collates yet. As for example Acrobat Reader, which does not work with our localization. However it is not the case when we can break localization - we have to force to fix broken applications. We use it and we live with it and we know about it. On the other hand - you do not use it and you do not live with it, so why you still want to break our localization? We have to fix "current system strcoll usages" and please do not break localization itself. > Because it is not in the form suitable for FreeBSD. It worked fine before, so why it could not work anymore? > Do you check other collates before making your variant? Yes. And you? I'm afraid that you did not and even you did not check our norm and you did not contact anybody about this. Check all other systems for example, please: Linux: C = A B a b cs_CZ.ISO-8859-2 = A a B b Solaris: C = A B a b cz = A a B b Irix: C = A B a b cs = a A b B Unixware: C = A B a b cs_CZ.ISO8859-2 = a A b B FreeBSD (old): C = A B a b cs_CZ.ISO8859-2 = A a B b AcheBSD (new): C = A B a b cs_CZ.ISO8859-2 = A B a b AcheBSD is currently the only system I know, which wants to have ASCII compatibility upon national standards. > Do you notice their similarity in some aspects? Yes, but our collation is different from them so we have to have different collation. Is it so hard to understand it? > I preserve as much of your variant as I can, making it ASCII > backward-compatible. I can't see how it can be very broken. No, our collation is not ASCII backward compatible, so for us it is very broken. > There are certain rules. I.e when you sort ASCII file, it must > remains the same as with LANG=C for compatibility reasons. And it is said in which norm? It still looks just as your personal opinion. Why people implementing and using other systems such as Solaris, Irix, Unixware and Linux think different? -- Rudolf Cejka <cejkar at fit.vutbr.cz> http://www.fit.vutbr.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020408095357.A4194>