Do you think it makes sense to translate English text embedded in template code? eg in the examples/ module, or in a class like /org.jboss.tools.ws.creation.core/src/org/jboss/tools/ws/creation/core/commands/ClientSampleCreationCommand.java It's not difficult to externalize the English text, but I suppose there could be a problem if a translator used a non-ASCII character and the compiler uses the wrong character set. Or if the translator chooses a variable name which isn't a legal identifier in Java. Is it worth the trouble (and extra testing)?

Well, I haven't externalized that text yet. (I'm not a translator, so I don't actually translate anything myself.) If someone chooses to use JBoss Tools in (say) Japanese, he/she might expect code generators to use Japanese where possible, so that the generated code will be more readable. (I'm not talking about translating the Java keywords in the generated code, but the embedded strings, comments and maybe variable names.) However, the Japanese version of the Hibernate reference guide seems to use all-English examples: http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/ja_JP/html/Hiberna... What's good for the goose is good for the gander. I'll mark them as non-translatable. Sean. On 01/07/09 14:31, feng.qian wrote: > In the ClientSampleCreationCommand.java ,the english text should not be > translated to other language. > Why do you translate them? > >> Do you think it makes sense to translate English text embedded in >> template code? >> >> eg in the examples/ module, >> or in a class like >> /org.jboss.tools.ws.creation.core/src/org/jboss/tools/ws/creation/core/commands/ClientSampleCreationCommand.java >> >> >> >> It's not difficult to externalize the English text, but I suppose >> there could be a problem if a translator used a non-ASCII character >> and the compiler uses the wrong character set. Or if the translator >> chooses a variable name which isn't a legal identifier in Java. >> >> Is it worth the trouble (and extra testing)? >> >

> My good friend dart once demonstrated for me that now in java you can > actually use chinese / japanese characters in class and method names > also. Yes, Java support UTF-8 in their Java lang spec - one of their selling points when it came out, which luckily did not catch on too much. I did have to do a consultancy gig once where they used Portuguese words and accents in the code....veery hard to debug :)

On the subject of translating code generated comments then I would say we shouldn't, it is simply too much work and we risk the examples to go out of sync. It is more important that the code example runs/works than its comments are in a localized language.

Sean Flanigan wrote: > On 01/07/09 17:41, Max Rydahl Andersen wrote: >>> My good friend dart once demonstrated for me that now in java you >>> can >>> actually use chinese / japanese characters in class and method >>> names >>> also. >> Yes, Java support UTF-8 in their Java lang spec - one of their >> selling >> points when it came out, which luckily did not catch on too much. >> I did have to do a consultancy gig once where they used Portuguese >> words >> and accents in the code....veery hard to debug :) > > Yeah, I think you can start a Java identifier with almost any > character on the planet... except ASCII punctuation and the > "arabic" digits 0-9. I think all the other Unicode digits are fine: http://www2.hawaii.edu/~hlibcat/documents/246.html Even more, following code will work fine: public class Test { public static void main(String[] args) { int \u006d\u0079\u0056\u0061\u0072 = 1; /*int myVar = 1; \u002a \u002f System.out.println(myVar); } } You should take this into account when you parse code. User could close comment by unicode representation. Eclipse colouring doesn't take it into account. > >> On the subject of translating code generated comments then I would >> say >> we shouldn't, it is simply too much work and we risk the examples >> to go out of sync. It is more important that the code example runs/ >> works >> than its comments are in a localized language. > > Yeah, that's my feeling too. I just wanted to make sure to have > the discussion, since there are pro's and con's. > -- Best regards, Dmitry Geraskov dgeraskov(a)exadel.com Senior Developer Exadel Inc

>> You should take this into account when you parse code. User could >> close comment by unicode representation. >> Eclipse colouring doesn't take it into account. "Should" and "could" are two very different things. lol