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.
Closes #2038. Needs to be merged after #2062 and #1641.