21–29 of 29 posts
This gives me nightmares of the time I was hired on contract to update a bunch of Word95 macros to manage the ISO9001 quality handbook for an international company. Thing is, Word95 could (or always did?) localize the BASIC keywords at least for some countries (no idea when/if that stopped - I have thankfully not needed that particular skill again..) and stored the scripts tokenized. Which was usually not a big probl…
Earlier quoted context omitted.
Yep. And programming languages, while they use English keywords, are not English. They are languages in their own right, and "translating" words is not a good idea, because that's creating a new language.
I agree this is probably a bad idea, but I still think the basic problem it's trying to solve is a real one. A less hack-y solution might be for new languages to start incorporating more languages in their choices of keywords and class names. Suppose someone were designing a new language (let's call it Foolang), and these were some of the keywords: * publico, privado, protegido (access specifiers in Spanish) * eetha/…
Doesn't this just mean that when you need to look up something by searching your localized terms, you won't get any hits?
JavaScript? Are you sure? "extends": "erweitert", "abstract": "abstrakt", "volatile": "volatil", "interface": "schnittstelle", "protected": "geschützt", "transient": "transient", "implements": "implementiert", "synchronized": "synchronisiert",
You can see them here: http://viewvc.svn.mozilla.org/vc/projects/mozilla.org/trunk/...
Search for "Future Reserved Words"
Earlier quoted context omitted.
I agree this is probably a bad idea, but I still think the basic problem it's trying to solve is a real one. A less hack-y solution might be for new languages to start incorporating more languages in their choices of keywords and class names. Suppose someone were designing a new language (let's call it Foolang), and these were some of the keywords: * publico, privado, protegido (access specifiers in Spanish) * eetha/…
I think the language constructs/keywords are the "easy" part. But how do you translate identifiers, comments and other "textual" content automatically?
This should really be an editor feature, something that can automatically replace localized words with english words and later show the localized version when the english version is moused over (or something like that). Writing the entire codebase with localized words hinders collaboration, and code portability. But having an editor feature that assists with the (human) language would keep all the localization with j…
Agreed. This would be fabulous as a vim plugin.
What is this projects relation to the referenced BabylScript project? They seem similar enough.
The main difference between the approaches is that BabylScript does things in a more Right Way (they do punctuation, number parsing, localised object property names) whereas js-i18n only maps translated tokens to JavaScript tokens. Token mapping is easy to implement and has no effect on the generated code (though you need to watch out for namespace collisions, as different words in language X may map into one word in language Y). From reading the paper, the BabylScript project needs to do some runtime dispatching to handle translated property names.
How does this handle reserved keywords? An acceptable variable name in English might be a reserved word in Finnish.
I'll need to extend the compiler to escape reserved words in the target language.