Hebrew Translation not recognized?

[udif]

I've tried translating ArduBlock to Hebrew. After translating a small portion (14%) of the files, I've tried to test my translations as explained in the block entry: http://blog.ardublock.com/2013/08/16/how-to-test-translations-locally/ Unfortunately, following the instructions didn't show any sign that the translation files were picked up. I created the required com/ardublock/block/ardublock_he.properties file, ran it using: java -Duser.language=he -cp .:ardublock-all.jar com.ardublock.Main but it there were no apparent changes in the ardublock run.

I also tried:

1. Adding the file directly to the JAR file - didn't matter
2. renaming it ardublock_he_IL.properties, runnign it using: java -Duser.language=he -Duser.country=IL -cp .:ardublock-all.jar com.ardublock.Main - also didn't change anything.
3. renaming the file into ardublock-de.properties, letting it override the original german translation - the result was that no ardublock windows got opened at all.
4. renaming ardublock_de.properties into ardublock_he.properties (the opposite of 3 above) - the file was ignored, and ardublock opened in English.

I got my translation file directly from crowdin, as explained in the blog.

[taweili]

Where do you put the ardublock_he_IL.properties related to the ardublock-all.jar? It should be at com/ardublock/block/ardublock_he_IL.properties

[udif]

I was very specific in my bug report. I placed the file under com/ardublock/block/ardublock_he.properties. What I also didn't mention was that I had a soft link in the same directory from ardublock_he_IL.properties pointing to ardublock_he.properties, so I have both covered. The instructions on the blog, BTW, suggest to use ardublock_he.properties, without the IL country code. You can pull off my partial translation from crowdin.

[taweili]

We have done the investigation into this.

1. Java has a issue with Hebrew's ISO designation. When you specify user.language=he, the internal locale shows "iw."
2. Once the ardublock_he.properties is changed to ardublock_iw.properties, it gets loaded.

However, it won't launched all the way. We have to look into if the underlying library can handle right to left language correctly.

Thanks a lot for the bug report and bring this to our attention! We are working on this!

David

On Oct 22, 2013, at 5:43 AM, udif notifications@github.com wrote:

I was very specific in my bug report. I placed the file under com/ardublock/block/ardublock_he.properties. What I also didn't mention was that I had a soft link in the same directory from ardublock_he_IL.properties pointing to ardublock_he.properties, so I have both covered. The instructions on the blog, BTW, suggest to use ardublock_he.properties, without the IL country code. You can pull off my partial translation from crowdin.

— Reply to this email directly or view it on GitHub.

[udif]

I made some progress on this bug.

First, I bypassed the he/iw encoding issue by linking ardublocks_iw.properties and ardublocks_iw_IL.properties to ardublocks_he.properties . I found a stackoverflow.com discussion that explained that the JDK simply renamed the 'he' code to 'iw'.

The problem is that even after this, the program simply hangs. I debugged this further, but still don't have a bug fix (I've never worked on Java before). From what I found out, all the translations related to the buttons on the top of the Window (New/Open, etc.) are OK. Messages are OK as well. However, the first Hebrew entry for a component name causes the program to lock up. Using the current translation, we lock up due to the line: bc.repeat_times=פעמים (line 82)

From what I can tell it fails within openblocks, not ardublocks itself. on the 2nd time that line #271 in the updateLabelText() method (LabelWidget.java): textField.setText(text); is called with text equals to פעמים , it never returns. Drilling deeper, it locks within the replace() call (JTextComponent.java from the JDK) in the setText() method from above. On the first call, it called as : ((AbstractDocument)doc).replace(0, doc.getLength(), t,null); where doc.getLength() returns 0, and t equals to פעמים in which case it doesn;t lock up. In the 2nd time it is called, doc.getLength() returns 5 (other arguments identical), which causes it to stay in an infinite loop. Since the actual loop is within some JDK methods, and my JDK is not compiled with debug info, I haven't progresses further yet, as I can see the JDK code lines, but not thr variable values within the netbeans debugger.

Trying a different approach, I simply ran the program with no breakpoints, and paued it with the netbeans debugger after I was sure it locked up. It seems that the infinite loop is in FlowView.java, in the layout() method, around line 469, where the loop controlled by while(p0 < P1) { ...} never terminates.

I hope this helps. I may try to advance further by recompiling the JDK with debug info.

[udif]

Another quick update: By following this explanation: http://stackoverflow.com/questions/18255474/debug-jdk-source-cant-watch-variable-what-it-is I managed to compile a debug version of the JDK and can now watch variables within the JDK.

[taweili]

This is likely to be a bug with openblocks, underlying graphics framework we hare using for graphics having some problem with left to right languages.

[udif]

Yes, I guessed that. I just checked github to see if your upstream repository has any relevant updates, but unfortunately not :-( Any chance you might be looking at this?