Re: Internationalization of Lua

[mathieu stumpf guntz <psychoslave@...>]

Le 21/11/2016 à 16:41, Soni L. a écrit :

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.

I am happy to learn in your interest of coding in your native language, that make Lua-i18n all the more relevant, and concerns you are feedbacking are exactly the reason Lua-i18n is a separate project from Lupa and Mallupa, on which it have no dependency. On the contrary, in later development Lupa and Mallupa may rely on Lua-i18n, but you don't have to care about that if you are not interesting in Esperanto.

Regarding what you are talking about, I agree that make having the ability to make something like `_ENV = require("my_dialect")` would be an interesting idea.

You don't necessarily need to change tokens used internally for that though: they can be decorrelated from the token exposed in the interpreter. Like it's done with the solution proposed by Luiz. This solution however, unlike what you are suggesting, is a static compile time process. But maybe it might be used as a point of start for implementing something like you are suggesting.

"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).

Sure this would be a good point to also provide translated libraries. This doesn't really require any change to the interpreter, does it? Aliasing function is straight forward in plain Lua, as far as I can tell, so this might be done with the current language facility. Or is there a problem I miss here?

Actually, the goal here is somewhat providing the same flexibility given for function identifiers to reserved keywords.

If you wanna bastardize something, at least do it in a way that everyone wins.

Yes, that's what Lua-i18n is all about. However I would rather name it allow dialectal extensions than bastardize, because "mal nommer les choses c'est ajouter au malheur du monde", and that I prefer to add misery in the world in a far more subtle devilish fashion. :)

Translating a programming language isn't the way to go, but removing any and all references to a specific language and/or culture is.

You can abstract things, but you can't remove any and all references to a specific language and/or culture. Abstracting things is obviously a cultural practice. Now if you want to speak ethnology or even ethology with me, please make that in a private answer.

Even Perl has yet to manage this. Actually the only programming language I know that has managed this is plain old brainfuck.

Actually, Perligata let you code in a Latin dialect. Your welcome. ;)