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.
Swing GUI Form looses the whole i18n after a new JMenu or JMenuItem is added. A complete internationalization of a GUI Form is completely lost after a new menu item is created. All localizatione code is automatically changed as showed below: BEFORE GUI CHANGE: component.setText(bundle.getString(LOCALE_STRING)); AFTER GUI CHANGE: component.setText(null); This is a big problem because I have to restart the localization work from the beginning many times. This problem was available on previous Netbeans versions as well. Roberto
In order to simulate this bug just follows these few steps: 1) Create a JFrame GUI Form 2) Setup a new Properties Bundle file from the properties of the Form 3) Add a menubar 4) Add a JMenu to the menubar 5) set the JMenu text using the Resource Bundle (fill up the bundle name, key, value, and default format) 6) let's compile and run the frame to see the Menu working. 7) Add a new JMenu on the menubar and maybe a JMenuItem under it. 8) Close the Editor of the Form. 9) Compile an run the Form... at this point instead of the Localized Menu you'll have a "null" Roberto
Reassigned to "form".
I am sorry, I am not able to reproduce this issue. Could you, please, provide more details? What type of project do you use (ordinary J2SE project or Java Desktop Application)? > 2) Setup a new Properties Bundle file from the properties of the Form I don't understand to this step. Can you, please, elaborate it?
Response from the reporter: > What type of project do you use (ordinary J2SE project or Java Desktop Application)? ordinary J2SE >> 2) Setup a new Properties Bundle file from the properties of the Form > > I don't understand to this step. Can you, please, elaborate it? > yes, just go to the Inspection view in Netbeans and right-click on the Form root to show its properties... below the properties you'll find "Properties Bundle" menu item where you can select an existing or create a new bundle.
I am sorry, I am still not able to reproduce this issue. I tried to follow your steps and it worked correctly: 1. Create new Java Application. 2. Create new JFrame form. 3. Create new Properties Bundle in the same package. 4. Add JMenuBar into JFrame. 5. Add new top-level JMenu into JMenuBar. 6. Change text of the JMenu and make sure that the text is taken from the resource bundle. 7. Clean and Build the project. 8. Execute the JFrame 9. Add new top-level JMenu into JMenuBar. 10. Save and Close the form. 11. Clean and Build the project. 12. Execute the JFrame Could you, please, try to experiment with the steps to reproduce to find out what I may do in a different way. Thank you in advance.
The response from the reporter: > I just tried your steps, and it works fine. > However these are pratically the same steps I did, but I found the only > difference has been I created a new project. > My original project is located on another workspace and another hard disk > on the same machine. > I created the same application test on the default workspace and into my > personal workspace... the sources are exactly the same, including the > *.form GUI files. > So the only difference is the hard disk. > If I make the test on my workspace I experience the bug. > I think I could move all my Workspace on the same disk of the default one, > and I'll try again. > Thanks for the support, the bug do not seems to be so hard. > Can you try to create the same test on another Disk ? Another response: > ok I just moved my workspace on the same disk where NetBeans 6.1 is > installed and all is working fine now. > It seems the Form cannot keep all i18n settings when located on a disk > different from the Netbeans installation. > Thank you, you can now move the priority to a lower value if you prefere, > however I seen there have been many issues about similar problems that > could be connected to the same thing.
I assume that you use Windows and that you mean another drive letter (e.g. c:, d:, e:) by 'another disk'. I don't have two physical disks in my machine. So, I created a new logical disk using subst x: c:\<somePath> Then I started NetBeans installed on disk C: and used the mentioned steps on disk X: e.g. I created the project on disk X:. Unfortunately I am still not able to reproduce your problem. Could you, please, try this approach? Is there anything special/different on your problematic disk/workspace? Does your problem occur on one specific project only or you can reproduce the problem using my steps on your problematic disk?
Response from the reporter: >> I assume that you use Windows and that you mean another drive letter >> (e.g. c:, d:, e:) by 'another disk'. > > yes correct > > I will try to create a project on another workspace, > but this is what I did before. > > My OS is Windows Vista (with all SP applied). > > My project was developed on a previous version of NetBeans, but the form > GUI has been upgraded on the 1st launch of the GUI editor. > > I now suspect that my project is in some way not aligned to NetBeans 6.1 > completely. > > I'll make further tests and revert asap.
Does your problem occur in one specific project only or you can reproduce the problem using my steps on your problematic disk? Are you able to reproduce the problem on your problematic disk only or you can reproduce in on other disks as well (for example on some (logical) disk created using 'subst' command)?
Response from the reporter: > I just made a test on another disk and it works fine. > > So at this point I am confused because the only thing I made to have the > GUI localization working fine have been to move the whole workspace on the > same disk where netbeans is installed (C:) > > There is something connected to my form that could get the editor confused. > My GUI is all javabean conformant, so I am surprised. > > The problem was rised using both the automatic internationalization flag > or without. > > I think that there should not be a process able to traverse all the GUI, > and able to reset all localization work, expecially when the automatic > i18n is disabled.
If I understand correctly then this issue occurs in one specific project only and you can even workaround it by copying the project somewhere else. It seems that some metadata of the problematic project are corrupted. Are you able to reproduce this issue when you copy the project somewhere else on the problematic disk e.g. just into another directory? Are you able to reproduce this issue with the original problematic project when you start NetBeans with a different (clean) user-directory? See http://wiki.netbeans.org/FaqWhatIsUserdir to find out what user-directory is and http://wiki.netbeans.org/FaqAlternateUserdir to find out how to start NetBeans with a clean user-directory. BTW: If you are satisfied with the workaround we found already and don't want to waste your time with this issue then we can close it as non-reproducible. It is very specific and it may turn out that we would not be able to identify its root e.g. it may happen that we will find out that something got corrupted in the past, but we will not be able to determine why this corruption occured and who is responsible.
>Are you able to reproduce this issue when you copy the project somewhere else on the problematic disk e.g. just into >another directory? When I copied my whole project on the same disk (C:) of Netbeans all was fine (of course I had to reassign the locale bundle on each menu...). >Are you able to reproduce this issue with the original problematic project when you start NetBeans with a different >(clean) user-directory? From what I understand now any Netbeans workspace must be used as "--userdir" in order to work fine. I am sorry I didn't know baout this, as I always used different workspace on different hard disks, thus not only the default "userdir". As I understand the i18n feature is strictly dependent by the userdir setting, however many other Netbeans features are not dependent of such setting. If you agree with this point you can close the issue as FIXED, but it could be nice to have some improvement about i18n as it should be more independent by the workspace userdir.
> As I understand the i18n feature is strictly dependent by the userdir setting, > however many other Netbeans features are not dependent of such setting. There's no magic behind "userdir". It is simply a directory where NetBeans settings/options are stored. Almost all features directly or indirectly depend on some settings. I will close this issue as non-reproducible because it happens with one specific project with non-clean user-dir only. Feel free to reopen it if you find out that it is more general problem, but do not forget to provide exact steps to reproduce then.
Unfortunately I have to re-open this issue as it is present also in Netbeans 6.5. I loose all i18n settings for all my form (see "text" localization under "form properties"). This is using either "automatic internationalization" or the "manual internationalization". The issue happen randomly after simple changes in the code, gui, or clean & build. I have been unable to catch the exact situation for this, but I am really unable to have a stable internationalization. Thanks for any help Roberto
By developing a new Java Application with a JFrame form I am not able to reproduce the problem. My software is a big one with many libraries like projects and other jars. I think the issue appears on big projects like mine. I do not undestand for which reason the form looses the i18n configuration for each localized text. Pratically the only i18n information that is keeped is the "Key" and all other settings like the Bundle name, are lost. My code format to invoke the resoucebundle is: localeBundle.getString("{key}") Where the localeBundle is an instance variable I pre-initialize at start-up. I currently do not use the automatic internationalization as i though that this could solve my problem, but this did not solved the issue. My opinion is the i18n source code of a form should not be changed by netbeans if the automatic i18n is disabled. So it seems there are two bugs: 1) The i18n code applied from the text properties using the ResourceBundle is lost randomly 2) The i18n code applied from the text properties using the ResourceBundle should not be changed or removed if the automatic i18n is disabled. Basically the form looses the Bundle name everywhere (g.e. on a JMenuItem or a tab label).
Not sure how we can help... I can see some options: * Could you try NetBeans 6.7.1, or even current 6.8M2? We fixed a problem that looked very similar to your symptoms time ago (issue 150287), there might be other relevant fixes since 6.5 too. * Could you possibly send us (privately) the project and point us to the problematic form to try to play with? * Could you send the messages.log (e.g. go to menu View | IDE log) from a session when the i18n got lost?