Skip to main content

make java compiler multi language

4 replies [Last post]
Joined: 2003-06-21

Hello, java , and other major programming languages are all designed for english language. it is not possible to change it. However, for people who do not know english much, at least making compiler error and warnings in their language would be nice. i do not think it is a big deal to add a compiler parameter and allow comunity access to that areas of the compiler..
JavaDocs also should be available in different languages. Comunity support will be handy in this case, but i guess there are validation problems. and maybe this should be unoffical.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-12-02


Not only would it be a MASSIVE effort (and impossible for the Javadoc, which you quite obviously have no clue as to how it's generated, you seem to think someone sits down and writes it all) but it would make support impossible.

We'd get a million Indian (and others) programmers come to the forums posting their localised compiler errors and asking for help in pidgin "help me now!!!!! prob comp this" followed by a spade of compiler output in a language noone understands.

Since all keywords are in English, I'd guess you want those localised as well? And what about the standard library classes and methods?

There's no word "List", "Array", "Thread", etc. etc. in my language.
Those would need to be localised as well.

At last count there were several thousand recognised languages worldwide.
If you add local variations spoken by major subgroups you probably end up at over 10.000 languages that would need to be supported.

That will mean 10.000 codebases and 10.000 documentation sets that need to be maintained (can't skip any to prevent possibly discriminating against someone).

Liste MeineListe = neue ReiheListe();
would of course have to yield the same bytecode as
List myList = new ArrayList();
mind that the compiler would have to translate your own variable names as well...

Joined: 2003-12-08

I think you have missed the point. From what I can tell the op is asking for (correct me if I'm wrong), it seems that this is quite possible based on successes with the wiki world.

If I know broken English and another language fluently, it would not be a far reach for me to find what I need from the syntax and standard libraries in Java in English. Figuring out the details, however, would be much harder. Having Javadocs and standard output messages (compiler/exceptions) have translated versions would be of great benefit to these people.

Lets focus on Javadocs, as those would be the easiest to localize. After the Javadocs for a major release are compiled in English and posted on, Sun could set up a wiki-like space for the community to contribute translated versions of the Javadoc web pages. Even better would be a web form where someone could just input the translated version of a specific method, class, package, etc. The form would then update a dummy Java file, which would be used by the Javadoc tool to create the translated version of the docs. However it is implemented, it is certainly possible.

You may be concerned about security. If anyone can edit the docs, couldn't someone malliciously change a detail in them? Sure, but why would they? If you're really concerned about it, there are some measures that you can use to ensure all content is reviewed.

So, this would be a massive effort, but shared among thousands of programmers.

By the way, I have written code like this in the past, and it can work very well (you may not be able to see the Hebrew characters in the forum posting):
[code]public תפוח getתפוח() {
if (תפוחי != null) return תפוחי;
else return new תפוח();
Not only did it work, but it was extremely helpful to be able to use Hebrew characters instead of broken transliterations that are hard to read. Hebrew and Arabic are particularly difficult due to the characters being read from right to left, but a good IDE can handle it.

Note that I agree that translating the standard libraries would be a bad move. If someone wants to write translated wrappers, that's ok, but there has to be a standard somewhere. Trying to agree on translations for all of the libraries would be insane. Good documentation should eliminate the need for translated libraries.

Joined: 2003-12-02

My main problem is where to stop localising?
Maybe it will start with just documentation, but it won't end there.
And even that's a major problem, the documentation is a formal definition, translation errors could lead to floods of spurious bug reports and/or buggy software that would have been avoided had the programmer but read and understood the official documentation.
I've had to deal with translated documentation in the past. English isn't my first language and most of the study material we got to use was translated.
On many occasions the only reason we were not lead down to wrong avenues due to errors in translation only because someone (often me or the teacher ;) ) had gone further than the official curriculum and purchased extra (original language) books or other documentation.

But as I said it won't stop there.
Sooner rather than later demands will start for fully localised language versions, leading to all the problems I described.
While I agree this isn't what the OP intended, my fear is that if we do as he wishes then that will be the (almost) inevitable eventual outcome.
Where that leads can be seen in MS Office 97 which had a fully localised scripting language.
Documents created in one localised version could not be used in any other localised version if they contained macros (the one exception being that all localised versions could interpret English language macros).

If a company has offices in multiple countries, all working together but using localised versions of their software, this becomes an insurmountable problem.

Joined: 2003-06-10

Isn't the JDK already available in Japanese?

Edit: Just the installation instructions.