From owner-freebsd-i18n@FreeBSD.ORG Mon May 28 18:39:36 2007 Return-Path: X-Original-To: freebsd-i18n@freebsd.org Delivered-To: freebsd-i18n@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A460D16A4D1; Mon, 28 May 2007 18:39:36 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) by mx1.freebsd.org (Postfix) with ESMTP id 0B89C13C44B; Mon, 28 May 2007 18:39:35 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (juno.lyxys.ka.sub.org [IPv6:2001:5c0:8521:0:20f:feff:fe0e:7312]) by saturn.lyxys.ka.sub.org (8.14.1/8.14.1) with ESMTP id l4SIdY0A011201; Mon, 28 May 2007 20:39:34 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.1/8.14.1) with ESMTP id l4SIeT37019265; Mon, 28 May 2007 20:40:29 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.1/8.14.1/Submit) id l4SIeSn4019264; Mon, 28 May 2007 20:40:28 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyxys.ka.sub.org: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Mon, 28 May 2007 20:40:28 +0200 From: Wolfgang Zenker To: Andrey Chernov Message-ID: <20070528184028.GA19098@lyxys.ka.sub.org> References: <200705272241.l4RMfg07051300@juno.lyxys.ka.sub.org> <20070528072847.GA18850@nagual.pp.ru> <20070528084659.GA77240@lyxys.ka.sub.org> <20070528115250.GA24812@nagual.pp.ru> <20070528123456.GA12679@lyxys.ka.sub.org> <20070528124944.GA26009@nagual.pp.ru> <20070528181829.GA18332@lyxys.ka.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070528181829.GA18332@lyxys.ka.sub.org> User-Agent: Mutt/1.4.2.2i Organization: private site X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (saturn.lyxys.ka.sub.org [IPv6:2001:5c0:8521:1:240:63ff:fed8:ce97]); Mon, 28 May 2007 20:39:34 +0200 (CEST) Cc: freebsd-i18n@freebsd.org Subject: Re: Why no non-latin TODIGIT mappings in UTF-8.src ? X-BeenThere: freebsd-i18n@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD Internationalization Effort List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2007 18:39:36 -0000 * Wolfgang Zenker [070528 20:18]: > * Andrey Chernov [070528 14:49]: >> On Mon, May 28, 2007 at 02:34:56PM +0200, Wolfgang Zenker wrote: >>> What would be a good place to read >>> up about how much can be localised with locales and how much of it we >>> currently (and maybe in the near future) support? >> The Open Group Base Specs Issue 6 >> http://www.opengroup.org/onlinepubs/009695399/toc.htm > So, as 7.3.1 says, in the "POSIX locale", which appears to be otherwise > known as the "C" locale, only '0' to '9' can be defined as being in class > digit. Because we use UTF-8.src as source for the "C" locale, we can not > add definitions for digits in other scripts, right? > In "a locale", which appears to be the generic case now, we are only > allowed to define the digits to in the digit class. The > digits '0' to '9' from the "portable character set" (= ASCII?) would be > automatically included in the class. > So if we have a locale using a non-latin script that happens to have its > own "digit" characters, we can not use the UTF-8.src for the LC_CTYPE > definitions but would best work with a copy and add DIGIT mappings for > the digit characters in the script used? Or are to > again fixed to be the ASCII codes '0' to '9'? Found the answer in chapter 6. So, to are defined as the respective digits in the portable character set. This leaves no possibility to define digits for other scripts, AFAICS. So, can anyone clue me in why this has been handled this way? It appears to me that the possibilities of localization are quite limited as soon as languages in non-latin scripts come into play. Are these problems usually handled in individual applications then? Wolfgang