Re: Internationalization of Lua

["Soni L." <fakedme@...>]

On 21/11/16 01:19 PM, mathieu stumpf guntz wrote:
> Le 21/11/2016 à 15:03, Soni L. a écrit :
> > Yes, but language-agnostic rather than language-specific.
>
> Again, I don't see the difference with internationalization, which 
> aims to make software as as independant as possible from any cultural 
> specificity. Do you mean that the interpreter should be change in a 
> way that get rid of all English token in it's internal (at least the 
> one exposed by default externally) and substitute them with some 
> relevant Unicode mathematical characters 
> <http://unicode.org/reports/tr25/tr25-6.html#_Toc24>? If yes, to my 
> mind it would be a funny idea, but doesn't match the "change as little 
> as possible in the current code base as possible". Also be aware that 
> whatever character set you may elect, it will never be a culturally 
> agnostic practice, even relying on mere integer you won't go out of a 
> cultural practice.
>
> > It requires no change to the VM in order to add new languages - just 
> > create a module for the new language. It also supports multiple 
> > languages at the same time (in the same VM).
> If you mean a solution that might work out of the box with the current 
> Lua interpreter, I can't figure how it would be possible.
>
> If you mean a solution that would require "no further" change in the 
> Lua VM for each specific language, then that fall in the definition of 
> internationalization. So if you have more detailed feedback, 
> suggestions, questions or code to provide on this, please go on. :)

I don't wanna learn Esperanto to write code. I'd be happy to write code 
on my own language, however, and have it interoperate with code written 
in other languages. The easiest way to do that is to define symbols for 
keywords - for best cultural compatibility these symbols would either a) 
be specific to the bastardized Lua you'd make, and would use the private 
use areas of unicode, or b) be emoji - and then use "environment wrapper 
libraries" to define the globals.

"Wrapper libraries" would be used to adapt libraries across languages, 
too - the "soquete" library would simply translate the names for the 
"socket" library, rather than reimplementing sockets in an incompatible 
way (however, sharing objects returned by such library would require 
some sort of "wrap" and "unwrap" functionality, also exposed by the 
wrapper library. It'd be common practice to wrap function parameters and 
unwrap function arguments).

If you wanna bastardize something, at least do it in a way that everyone 
wins. Translating a programming language isn't the way to go, but 
removing any and all references to a specific language and/or culture 
is. Even Perl has yet to manage this. Actually the only programming 
language I know that has managed this is plain old brainfuck.

So yeah.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.