You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 000030320180) "~A, ~B ~e, ~Y"))
"Friday, March 30, 2018";; should be Spanish
> (current-locale "es")
> (require srfi/19 srfi/29)
> (date->string (make-date 000030320180) "~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 000030320180) "~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 text was updated successfully, but these errors were encountered:
euhmeuh
changed the title
srfi/19 reads the locale once then never check the current language
srfi/19 reads the locale once then never checks the current language
Apr 9, 2018
The srfi/19 module uses locale bundles defined in srfi/29.
But it reads
(current-locale)
only once atrequire
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:
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-template
is called.What do you think about that new behavior?
The text was updated successfully, but these errors were encountered: