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.
Summary: | i18n - Multi-byte strings set in Component Inspector are displayed in Unicode Escapes in Source Editor | ||
---|---|---|---|
Product: | platform | Reporter: | akiko.mochizuki <akikomochizuki> |
Component: | -- Other -- | Assignee: | David Strupl <dstrupl> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | issues |
Priority: | P2 | Keywords: | I18N |
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Component Inspector replaced in Japanese text
Form Editor displayed Japanese "New Time" label. Source Editor displayed Japanese "New Time" label in Unicode Escapes. Japanese jlblNewTime variable on Source Editor. Japanese timeFormat input on Source Editor. Result of Japanese timeFormat. See the lien 80 in Source Editor. |
Description
akiko.mochizuki
2001-05-01 13:09:51 UTC
Created attachment 1283 [details]
Component Inspector replaced in Japanese text
Created attachment 1284 [details]
Form Editor displayed Japanese "New Time" label.
Created attachment 1285 [details]
Source Editor displayed Japanese "New Time" label in Unicode Escapes.
I think that it is the intended behavior in order to get rid of the case when the source would be saved using chartobyte converter not supporting the original charset. I'm reassigning to core because the StringEditor that does the translation to escape sequences is maintained by core team. The initComponents() body is un-editable intentionally. It's called a guarded section and it's designated by the blue background. Personally I consider this a feature, not a bug. Storing anything non-ASCII in the source file is potentially unsafe. Keeping it as Unicode escapes in the .java is the best way to go, I think. Ideally I guess the editor's kit would automatically translate the escapes to Unicode when reading and vice-versa so that you could work comfortably in your native language in the source window, but still safely store the result on disk. Wasn't this the idea behind non-lexical \uXXXX escapes in the first place? If you wish to work on the source outside NetBeans in an editor supporting your character set but not Unicode escapes, use ascii2native and then native2ascii again. Similarly for escapes in .properties files. Target milestone -> 3.3 I think this is a bug because a multi-byte string can be displayed correctly in other portion. 1. A variable name can be display in multi-byte characters correctly. Please see the attached jlblNewTime.gif. Check Japanese jlblNewTime variables on the line 73 - 75. 2. The user can input some multi-byte characters in non-guarded section correctly and the program can be worked well. Please see the attached timeFormat.gif. Check timeFormat variable on the line 164. And see the attached timer.gif, which is the execution of the code. If this is a feature and not a bug, this should be improved to be able to display multi-byte characters on Source Editor. Many Japanese developer have to use Japanese strings in their source code due to the specification of the solution they depelop. That they can't confirm their code visually is not a user friendly and not convenient. Of course other Japanese edition of the IDE solution like MS Visual Basic can be realized this feature. So, please fix as soon as possible. Created attachment 1320 [details]
Japanese jlblNewTime variable on Source Editor.
Created attachment 1321 [details]
Japanese timeFormat input on Source Editor.
Created attachment 1322 [details]
Result of Japanese timeFormat.
Fixed in [dev]. StringEditor 1.12. Please verify. Target Milestone is NB3.3. Akiko, can you please verify this fix, thanks? Not fixed yet on Build 010619. Please see the line 80. Japanese string can't be displayed correctly. Created attachment 1709 [details]
See the lien 80 in Source Editor.
For the fix to take effect you have to run the IDE with -Dnetbeans.stringEditor.useRawCharacters=true command line switch. The switch can be specified also in the launcher script or in configuration file (ide.cfg). I hope that this is ok. Verified in build 010714EE_JA on Japanese locale. The correct command line parameter is: runide.sh -J-Dnetbeans.stringEditor.useRawCharacters=true Adjusting target milestone. Consistent use of the I18N keyword. Resolved for 3.4.x or earlier, no new info since then -> closing. |