-
-
Notifications
You must be signed in to change notification settings - Fork 10
Description
The srfi/19 module uses locale bundles defined in srfi/29.
But it reads (current-locale) only once at require time, which sets the values of (current-language) and (current-country), then never bothers to read the parameters again.
This means that if you want to display a date in different languages, you're stuck with the language that was set when running the program.
Example of what's wrong:
> (require srfi/19 srfi/29)
> (parameterize ([current-locale "es"]
[current-language 'es])
(date->string (make-date 0 0 0 0 30 3 2018 0) "~A, ~B ~e, ~Y"))
"Friday, March 30, 2018" ;; should be Spanish> (current-locale "es")
> (require srfi/19 srfi/29)
> (date->string (make-date 0 0 0 0 30 3 2018 0) "~A, ~B ~e, ~Y")
"viernes, Marzo 30, 2018" ;; is Spanish because the locale was set before loading the module
> (parameterize ([current-locale "en"]
[current-language 'en])
(date->string (make-date 0 0 0 0 30 3 2018 0) "~A, ~B ~e, ~Y"))
"viernes, Marzo 30, 2018" ;; should be English but is still SpanishWhile SRFI/19 specifies that locales should be handled:
These procedures provide conversion to and from strings. They are required. The specification below describes a 'locale;' the specification of locales is beyond this SRFI.
~A | locale's full weekday name
~B | locale's full month day
...
Expected behavior:
(current-locale) should set the values of (current-language) and (current-country) once.
The locale is not supposed to change during runtime, so reading it once is fine. This is already the case so it's already good.
BUT changing the (current-language) or (current-country) should have an impact on the date formats! Those values are expected to change.
I'm planning to make a pull request with those changes.
- Reading
(current-locale)only once to set the default values. - Reading
(current-language)and(current-country)every timelocalized-templateis called.
What do you think about that new behavior?