Le 28/09/2017 à 16:25, Brad Jorsch (Anomie) a écrit :
On Thu, Sep 28, 2017 at 5:19 AM, mathieu stumpf guntz < psychoslave@culture-libre.org> wrote:
According to lua wiki http://lua-users.org/wiki/Lua Locales%20In%20Lua%205.1, in Lua 5.1 "identifiers [are] locale dependent, and from the reference manual which states that "[the documentation] derived from the Lua 5.1 reference manual < http://www.lua.org/manual/5.1/index.html%3E", I guess tha Scribunto is still derived form Lua 5.1.
That's correct.
Ok, thank you, I think that's a very important point. It appears to me that Lua developers have a rather "we don't care about backward compatibility" approach, so later version can have significant incompatibilities.
By the way is there an official policy or whatever document regarding Scribunto evolutions?
So, what I would like is being able to set the locale for a module and use identifiers with locale characters. But `os.setlocale` isn't accessible in scribunto modules.
Allowing os.setlocale would very likely cause problems on threaded webservers where one thread's locale change stomps on another's. It might even cause trouble for subsequent requests on non-threaded servers if the locale doesn't get reset, or for other code running during the same request (e.g. see T107128 https://phabricator.wikimedia.org/T107128).
Ok, thank you. I guessed that each Scribunto process was hugely sandboxed, especially as everything seems to be done to prevent passing information between successive invocations of the same module. I hadn't thought of possible side effect on PHP execution as explained in the ticket. Do we have some nice (or even ugly) schema of PHP/Scribunto execution process so I could have a clearer representation of what's happening when I grab a webpage of a mediawiki article with some Scribunto invocation?
For sanity's sake, on Wikimedia wikis we use C.UTF-8 as the OS-level locale. This doesn't affect much since MediaWiki usually uses its own i18n mechanisms instead of using the locale.
Well, ok. I mean that doesn't seems a problem for string, all the more when the mw library provide specific helper around the topic.
But that's not the concern I was writing for. That is, I can't use unicode identifiers as in `locale plâtrière = préamorçage()`. When I see UTF-8 somewhere, I would expect no problem to use any glyph. So are my expectations misguided, or is there something wrong with the way C.UTF-8 is handled somewhere in the software stack?