From: ludo@gnu.org (Ludovic Courtès)
To: Zefram <zefram@fysh.org>
Cc: 24186@debbugs.gnu.org
Subject: bug#24186: setlocale can't be localised
Date: Tue, 11 Oct 2016 10:06:15 +0200 [thread overview]
Message-ID: <87h98j1f9k.fsf@gnu.org> (raw)
In-Reply-To: <20160808223037.GI24721@fysh.org> (zefram@fysh.org's message of "Mon, 8 Aug 2016 23:30:37 +0100")
Hi,
Zefram <zefram@fysh.org> skribis:
> (define (call-with-locale cat val body)
> (let ((oldval #f))
> (dynamic-wind
> (lambda () (set! oldval (setlocale cat)) (setlocale cat val))
> body (lambda () (setlocale cat oldval)))))
>
> (define (day-of-week-string)
> (strftime "%A" (localtime (current-time))))
>
> (define (day-of-week-string-for-locale loc)
> (call-with-locale LC_TIME loc day-of-week-string))
>
> ;; user-locale is application-specific code defined elsewhere
> (define (day-of-week-string-for-user user)
> (day-of-week-string-for-locale (user-locale user)))
This does not really answer your question, but (ice-9 i18n) provides
first-class locale objects, which avoid the whole global locale issue
(info "(guile) Internationalization").
Currently important procedures such as ‘strftime’ or SRFI-19’s
‘date->string’ cannot use such locale objects, though. I think it would
make sense to add an optional locale object argument to ‘srftime’ and
‘date->string’ (though we should create a (srfi srfi-19 gnu) module for
that to make it clear that this is a GNU extension.)
That wouldn’t help with the ‘setlocale’ issue you describe per se, but
this would address such use cases in a different way.
WDYT?
Ludo’.
next prev parent reply other threads:[~2016-10-11 8:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-08 16:32 bug#24186: setlocale can't be localised Zefram
2016-08-08 20:33 ` Andy Wingo
2016-08-08 22:30 ` Zefram
2016-08-09 12:15 ` Zefram
2016-08-09 17:43 ` Andy Wingo
2016-10-11 8:06 ` Ludovic Courtès [this message]
2016-10-11 12:49 ` Zefram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h98j1f9k.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=24186@debbugs.gnu.org \
--cc=zefram@fysh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).