I can not see any difference in translation between RC4 and RC5 version (spanish).
The options and campaign preferences remain fully in English.
Yep. That's why I said:
The localization work will continue -- albeit a little slower -- even once 1.3 goes Final.
The implication being that we're not done yet.
Only one dialog has been localized. They're a pain in the butt to do currently.
Every string that appears in the dialog has to be looked up in the translation file and then replaced with whatever is found. There is only one dialog that does this currently and the code is pretty ugly, so my plan is to create a separate function that knows how to do this work in some kind of automated way (I have some ideas for that) and then add a call to that function in every piece of code that opens a dialog.
Needless to say, this is slow going. And I've been working on bug in the actual operation of the program and leaving the cosmetic stuff for later.
If anyone with some Java experience wants to take a shot at it, I can outline my plan in more detail. Otherwise, I'll get to it eventually...
Actually I posted the log in the previous b81 thread:
Ah, okay. That's not a NullPointerException (NPE), that's an IllegalStateException (ISE?). I commented
a few posts down that this is a Java/OS bug, not a MapTool bug.
You hypothesized that it could be memory related, and I agree. It could be application memory, but more likely it's low GDI memory in Windows. This article
is from a developer who hit this limit and how he diagnosed it. He refers to a free diagnostic tool, GDIUsage, and says that even Task Manager can provide some of the information needed to determine if this is a problem.
His application was .Net-based but it could happen to any application that talks to the OS using the Win32 APIs... which includes the Java runtime.
So if you run those tools and find that you're having the GDI problem, let me know which resource it is and we can report the bug more specifically to Oracle and perhaps find a way to work around it in MapTool...
The obvious solution is to use an OS that doesn't statically allocate memory or array sizes. Linux is probably the best choice as just about everything is done dynamically. OSX might be a good second choice, but I'm not familiar enough with Aqua/Carbon to know how they manage memory internally.