Export env language var matching document state #2064
Conversation
Useful for setting variables before running external processes via os.execute() or similar.
|
This will need some re-arranging to confirm to whatever layout #2072 settles on for Rust based Lua module stuff. |
| @@ -28,6 +28,7 @@ function settings:_init () | |||
| ]]):format(language, language, language, language)) | |||
| end | |||
| fluent:set_locale(language) | |||
| SU.setenv("LANG", language) | |||
There was a problem hiding this comment.
While this could work for some language, the correct approach might be trickier:
LANGexpect a Unix locale (eg.de_DE)- Our current
document.languageis only a two letter code (eg.de), which may be under-resolved - If we move our
document.languageat some point to possibly fit either BCP47 or ICU locales, it still likely wouldn't be a valid Unix locale (e.g. consider e.g. BCP47 codesr-Latn-RS, ICU localesr_Latn_RS, Unix localesr_RS@latin)
So we might have to consider conversion utilities (BCP47 -> ICU locale -> Unix locale)
There was a problem hiding this comment.
While there are one-to-one canonicalization rules between BCP47 languages and ICU locales (which our justenoughicu wrapper even implements), I can't find any clear source for mapping to Unix/Posix locales (setlocale) as expected by LANG. So it might be a a hornest's nest.
(BTW, Why would we want it? For Lua os.date etc. to be localized? I'm not sure there's a good use case for it)
There was a problem hiding this comment.
Yes, this whole maneuver is dependent on us starting to use proper locales (BCP47 or whatever) internally and on adding a mapping to the setenv() function that converts whatever than scheme is to a Unix locale.
I'm already using this is production with a small hack to map the languages I use. I have documents where one class is used to render inputs in multiple languages, and for example the inprint page has date information. This is rendered with the system date command, but in only outputs the correct localized string if the locale is set. This already works if I supply the right mapping. I also have other tools besides date that output content that gets ingested during the SILE render process (for figures, music, etc.) and is sensitive to the locale.
The real question is whether there is ever a case that setting the LANG will produce undesired results. For it to work the system tools need to have support for the expected locales compiled using locale-gen or similar, but would the user ever not expect it to work this way? I couldn't think of any time this would be objectively wrong.
There was a problem hiding this comment.
Aside note: for rendering a properly localized date (say, today as "10 Eylül 2024 Salı" / "вторник, 10 сентября 2024 г." / "mardi 10 septembre 2024"), rather than using Lua's os.date and expect the host has some appropriate Unix locale.... we might wrap the ICU methods in our "justenoughicu" library: https://unicode-org.github.io/icu/userguide/format_parse/datetime/examples.html#c-1 --- so one can feed an epoch time, however obtained, to ICU for proper rendering according to the locale, and the expected format (full, long, medium, etc.)
There was a problem hiding this comment.
Yes, except that instead of having our own custom "just enough" wrapper for ICU we're going to have access to the full ICU API surface via Rust crates (and of course can expose whatever bits of it we want on the Lua side, which is basically what we have now in justenough... except we won't need the C wrapper.
…document language
|
This approach used here is going to de ditched when #2072 comes to fruition, but at that point there is stuff here that can either be refactored or cherry picked. |
Closes #2038. Needs to be merged after #2062 and #1641.