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 Spanish
While 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 time localized-template is called.
What do you think about that new behavior?
The srfi/19 module uses locale bundles defined in srfi/29.
But it reads
(current-locale)only once atrequiretime, 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:
While SRFI/19 specifies that locales should be handled:
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.
(current-locale)only once to set the default values.(current-language)and(current-country)every timelocalized-templateis called.What do you think about that new behavior?