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.
Start multilingle build (en-ja-zh) under C locale; Select Tool->Options to invoke the option dialog; Some options are displaying as white squares.
Please attach screenshots. Also try to guess modules that the options belongs to. Use I18N keyword instead of assigning to the code internationalization project.
Created attachment 10970 [details] Screenshot for NetBeans option window (multilingal build) running under C locale
The error messages are from different modules: autoload/debuggerCore.jar form.jar i18n.jar db.jar core.jar autoupdate.jar
What error messages? Please, attach them too.
I cannot reproduce launching IDE using: runide -locale C
I didn't use -locale option, but run "runide.sh" command under C locale. You can reproduce it by the steps: 1, % setenv LANG C or login with C locale 2, cd <NB351 root>/bin 3, ./runide.sh 4, Open the option dialog, some messages are unreadable. I don't know any difference between -locale option and setting LANG to C. When I running with "-locale C" option, the error messages are displayed as Chinese characters. I think they should be English. And the error messages are from the following files: nb_all/debuggercore/src/org/netbeans/modules/debugger/support/Bundle.properties key is CTL_Debugger_option nb_all/form/src/org/netbeans/modules/form/Bundle.properties key is CTL_FormSettings nb_all/i18n/src/org/netbeans/modules/i18n/Bundle.properties key is LBL_Internationalization nb_all/db/src/org/netbeans/modules/db/resources/Bundle.properties key is Kervices/org-netbeans-modules-db-explorer-DatabaseOption.settings nb_all/core/src/org/netbeans/core/Bundle.properties key is Services/org-netbeans-core-IDESettings.settings src/org/netbeans/modules/autoupdate/resources/Bundle.properties key is Services/org-netbeans-modules-autoupdate-Settings.settings
Jack, Would you try to switch your user directory? Some messages in option dialog is loaded from existing user directory. If IDE launched in Chinese locale, some Chinese information is stored in user directory, and information is displayed in Chinese. Please try: % ./runide.sh -userdir <new dir> or, delete your existing user directory: ~/.netbeans/3.5 ~/studio5se_user
The problem occurs only after I start netbeans on zh locale and restart it on C locale without deleting ~/.netbeans directory. I think netbeans caches something in the user directory.
Keiichi thank you for the suggestion! I think that this scenarion must be marked as unsupported or caches must be invalidated on locale change. I guess the first option will prevail because user is expected to use constant locale. However locale change should be detected during startup, terminating IDE on inconsitency presenting an explanation text. Passing to core module owners.
Yes, I agree that its more general issue and we need guidance from developers if - it should just be forbidden that user uses same userdir if running in different locale (or that ide caches locale name the first time and not allow subsequent use of this userdir if in other locale) or - that it is permitted and that cached items/values that are locale specific are reread to get correct values. ken.frank@sun.com
Jesse please do you know what could be cached? (Does it mean that some instances are cached and their display names are NOT loaded from bundle?) Is there any info what was locale of last run? If not where should this be stored?
"we need guidance from developers if it should just be forbidden that user uses same userdir if running in different locale" - no. This *is* supported. It is a bug in any module if it caches to disk any localized string that it had loaded from a bundle (unless it is careful to simultaneously mark that cache with the locale and branding in effect when it was created, so it can be quietly invalidated). The user should be able to freely change locale at every startup while using the same userdir. Of course if the *user* enters a new international string explicitly when prompted (e.g. file name, service name) then it is the user's responsibility to run in a locale in which those characters can be displayed. I don't happen to know what is wrong here; would have to see the user directory. If the bug is reproducible, it may be straightforward to fix it too. Probably some bug in settings; I suspect core/settings does something evil but who knows.
Jesse, We can start keeping track of where issues like this are seen in product and file appropriate issues. Would any of the details seen as filed in this issue be applicable to this iz category or should separate bugs be filed on those also, using the comments in this bug to refer to ? Based on Jesse's comments, I'm making this a p2 as it seems that it could be common that user of localized release might run in other locales while using same userdir while developing apps that will themselves be localized; please change this back if it needs to be p3. ken.frank@sun.com 12/04/2003
Taking over this issue for Marek.
Seems to be a simple problem: All of the problem nodes use SystemOption, which is a pseudo bean, and has a method "displayName()" which intentionally avoids the bean pattern so the value won't be serialized. However, SerialDataNode looks first for a getter for getName(), then getDisplayName(). SystemOption *does* have a getName() method, which will is serialized. And SystemOption.getName() just calls SystemOption.displayName(). So a simple fix is to have it look first for "displayName", then for "getDisplayName", then for "getName" (which is probably the order it should have been in the first place). I'll attach a patch for this. The bad news is that the fix probably has performance implications, and I can't think of a way to do it that doesn't. For every SerialDataNode that is *not* a SystemOption, one NoSuchMethodException will be thrown and caught when the Options window is opened.
Created attachment 13224 [details] patch for both copies of SerialDataNode in core
Created attachment 13225 [details] Binary patch
Please try the attached binary patch and let me know if it cures the problem. Just put it into $NB_HOME/lib/patches and start the IDE normally; the problem should disappear.
Correction, it should be doable without the performance hit - core can reference SystemOption without a problem, so it shouldn't be a problem to test if SystemObject.class.isAssignableFrom(clazz), and go straight to the displayName() method if so.
Created attachment 13273 [details] New diff - includes locale check for cached name in InstanceDataObject
Created attachment 13274 [details] New binary patch
Having tested the attached patch as best I can (not having run NetBeans in a non-english locale before - I'm having some trouble telling what things are missing from the localization vs. what things are affected by the bug), I'm sorry to say the last patch still doesn't completely solve the problem - there is still some lurking caching happening somewhere, presumably to avoid classloading. It *does* work for changed settings, but the locale test is causing some problems with good names getting dumped - it's too aggressive. Given that this issue does not come up unless a user runs in one locale and later in another (not a terribly common situation), I am dropping the priority of this issue to P2. To fix it will involve changes in InstanceDataObject (a very central piece of NetBeans architecture) and other places - changes I am not comfortable making this late in the release cycle. So I'm also moving the target milestone to promotion D. My apologies, but the problem goes deeper that one would expect.
Re-assigning Tim's issues to Dafe.
Passing to Martin to distribute bugs evenly. Thanks Martine :-)
Reporters and others, is this problem still reproductible? It's very old and SystemOptions were changed and deprecated AFAIK. Thanks.
No info from reporters for very long time, so I suppose that the bug is gone, closing. Please reopen with detail info if the bug is still valid, thanks.