From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: More i18n Date: Tue, 12 Dec 2006 10:36:31 +0100 Organization: LAAS-CNRS Message-ID: <87bqm9tq00.fsf@laas.fr> References: <877iwzokpz.fsf@chbouib.org> <87ac1uhv52.fsf@zip.com.au> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1165916299 18605 80.91.229.10 (12 Dec 2006 09:38:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 12 Dec 2006 09:38:19 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Dec 12 10:38:19 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1Gu45a-0003Ya-T9 for guile-devel@m.gmane.org; Tue, 12 Dec 2006 10:38:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gu45a-0007BE-7A for guile-devel@m.gmane.org; Tue, 12 Dec 2006 04:38:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gu45B-0006zV-5c for guile-devel@gnu.org; Tue, 12 Dec 2006 04:37:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gu459-0006xy-U4 for guile-devel@gnu.org; Tue, 12 Dec 2006 04:37:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gu457-0006wo-GX for guile-devel@gnu.org; Tue, 12 Dec 2006 04:37:49 -0500 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1Gu457-0007jx-1l for guile-devel@gnu.org; Tue, 12 Dec 2006 04:37:49 -0500 Original-Received: from messiaen.laas.fr (messiaen [IPv6:2001:660:6602:0:230:65ff:fed4:9d20]) by laas.laas.fr (8.13.8/8.13.8) with SMTP id kBC9bkAB026110 for ; Tue, 12 Dec 2006 10:37:46 +0100 (MET) Original-Received: by messiaen.laas.fr (sSMTP sendmail emulation); Tue, 12 Dec 2006 10:36:31 +0100 Original-To: guile-devel@gnu.org X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 22 Frimaire an 215 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: guile-devel@gnu.org In-Reply-To: <87ac1uhv52.fsf@zip.com.au> (Kevin Ryde's message of "Tue, 12 Dec 2006 10:26:17 +1100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Spam-Score: 0.306 () MAILTO_TO_SPAM_ADDR,NO_RELAYS X-Scanned-By: MIMEDefang at CNRS-LAAS on IPv6:2001:660:6602::2 X-MIME-Autoconverted: from 8bit to quoted-printable by laas.laas.fr id kBC9bkAB026110 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6316 Archived-At: Hi, Kevin Ryde writes: > ludo@chbouib.org (Ludovic Court=E8s) writes: >> >> In order to be consistent with the rest of `(ice-9 i18n)', >> `language-information' accepts an optional argument which should be a >> locale object. Consequently, `language-information' has to perform >> appropriate charset conversion. > > If you ask for something from a particular locale object, shouldn't > you get the charset of that object? That'd be what I'd expect. My understanding is that, implicitly, Guile currently uses the current locale's encoding as its "internal representation". For instance, `scm_from_locale_string ()' stores the input string "as is", i.e., in the current locale's encoding. Thus, I think it makes sense to remain consistent with this view. When we have a non-8-bit internal representation, conversion will probably be needed in any case. > AM_ICONV (from gettext, see its manual) is good for that detection, it > can cope with various oddities. Ok. > DAY_1 smells a lot like C, surely something more schemely is possible? > After all, guile isn't a C interpreter with parenthesized syntax! :-) Agreed, but changing the name makes it harder to automate the definition with macros... > You should setup to use localeconv and strftime too, if nl_langinfo > isn't available, that'd cope with DOS systems. Or if you want to tie > only to nl_langinfo then calling the function nl-langinfo will make it > clearest what's being had. Are there many systems that provide `localeconv' but not `nl_langinfo'? I guess Windows has the former but not the latter, in which case it might make sense to support it. That would require a bit of work, though. > Though I suspect there's quite a few places in existing code that may > leak resources of one type or another under out of memory errors. And > I doubt out of memory is even recoverable at all if genuinely almost > full. Yes, out-of-memory is currently mostly handled by `abort ()' (e.g., `scm_memory_error ()'). > Incidentally, if you're thinking about iconv (which I suspect is not > needed yet), then I've found it useful to also have conversions that > put in dummies for untranslatable chars. With glibc the charset names > "foo//TRANSLIT" etc give that effect, but elsewhere you have to watch > for EILSEQ and skip that char. Good for output to at least display > something. The issue is that (i) it is glibc-specific and (ii) it is not a desired behavior in many cases. >> (define priv:locale-abbr-weekday-vector >> - (vector "Sun" "Mon" "Tue" "Wed" "Thu" "Fri" "Sat")) >> + (cond-feature (language-information >> + (vector ABDAY_1 ABDAY_2 ABDAY_3 >> + ABDAY_4 ABDAY_5 ABDAY_6 ABDAY_7)) > > This raises a point about the interface. It should be possible to ask > for "day number N". If ABDAY and friends aren't consecutive then they > should be. Right. I guess we could provide a higher-level API, along the lines of: (language-information AB_DAY 1) ... that would use the same kind of vector internally to map day numbers to `nl_langinfo' constants. This could be implemented in Scheme. So, maybe we should rename `language-information' to `nl-langinfo' and keep the C code as simple as possible, while leaving room for a higher-level implementation that would possibly deserve the name of `language-information'? Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel