This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Running in other locale with localized msgs/jars, create feedreader sample or regular nb module project, and then run; some messages in output window don't display multibyte correctly, many others do. This happens at least on solaris euc locales and ja sjis. Masaki has seen this situation also, and attached gifs are from both his environment and mine. And for those msgs in attached gif wrt could not find certain modules, where the mbyte does not display ok, in a separate popup window that shows these same errors, the mbyte does display ok, so this is probably some encoding handling detail. BTW, not related to this issue, but noticed from the errors that when profiler and/or mobility installed, that these errors referred to some of those modules, and also that new nb appeared as feedreader app, but didnt have the functionality of it. See attached gifs for output window lines that had incorrect mbyte. Also, some show the project name as having mbyte in it, which is legal for nb, but in this case, its just showing the incorrect display of the mbyte.
Created attachment 28095 [details] image
Created attachment 28096 [details] image
Created attachment 28097 [details] image
Created attachment 28098 [details] image
Created attachment 28099 [details] image
Most likely unfixable. Probably a result of the operating system and/or Java not cooperating in how they handle non-ASCII characters in IO streams, file names, etc. FWIW - running on Fedora Core 4 Linux, with UTF-8 locale (which has been the default for FC for a while now), I can create a FeedReader suite example in a directory using Czech characters in its name; create Java classes named with Czech characters; create window system components using Czech characters in the component definition; create bundle entries using Czech characters in the key (as well as the value). Everything works perfectly. (It is true that these characters are qualitatively different in some respects from Asian characters, but they do fall outside the ISO-8859-1 range, and thus correct display implies that some kind of UTF-8 translation is happening at the right times.) Did not try localizing bundles in NB to Czech characters (as for "Turning on modules") but I think I have successfully done so in the past. This observation, as well as past experience with many similar problems on Solaris and/or Windows, leads me to believe that the bug is "below the line": i.e. not the fault of any code in Ant or NetBeans; and that full non-English support for apps involving text streams is only possible if the operating system and/or the JRE is fixed. IMHO the proper fix for Solaris would be to follow the path that Linux took and make UTF-8 the standard encoding for all installations, even for Asian markets; only support legacy encodings via conversion tools (or transparent filesystem-level translations); and do a thorough end-to-end audit of all system tools, libraries, terminal emulators, etc. to make sure they behave sanely with this encoding. I have no idea what would be required for Windows to behave as nicely. I know modern versions of Windows already use UTF-8 routinely for text files (at least if the marker U+FFFE is present). Yet it seems that this consistency does not extend to text consoles (NT shell). At least, I have spent hours fooling with an XP installation to try to get it to do proper UTF-8 I/O on a text console with a Java app, without any success. Someone expert in Windows internals may be able to say more about it. Sorry I can't be of more help. You may want to contact Solaris engineers (localization team? or core?) and ask them for background on usage of non-ASCII text in console streams from Java.
Verified.