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.
In tools-options->object types, the listings of items in attached gif do not come from Bundle files even though Bundle files may have those words. Thus users of localized release will not see these in their language. The bug had been in bugtraq before but could not be verified as fixed; it was closed so this could be entered. If these come from manifest files, which are not now localized, can they (and any other items that can be localized) be put into bundle files. There is a mechanism now in place to do this; see 12549.
Created attachment 1963 [details] options.objecttypes window
Can not reproduce in build FFJ-20011031. What I did was: 1) manually changed the display names of the loader names in bundle files. 2) rebuilt module jar files with the updated properties and copied the jars to IDE installation 3) deleted the user settings directory 4) started the IDE The changed names correctly showed up under the Object Types node.
I still see these issues, perhaps not as many - in 11/28 orion build see these not from locale specific message file: Taglib Descriptor Objects JSP Objects War LoaderDreamweaver Templates Objects Servlet Objects advanced (if <displayname of data loader> is in this area, then that one too.
Ok, sometimes it is necessary to disable and enable the module containing the object type in Tools -> Options -> IDE Configuration - > System -> Modules (as step 5). After doing this, the display name reappears correctly. I tried this for Tag Library descriptor objects and it worked. Please verify this for the other object types too and close the bug if it works.
The <displayname of data loader> does not come from Open source code - it comes from the J2EE Application Assembler.
Tried it on tag lib descriptor and it worked, also on a corba one like this. I think it still a bug since user should not need to do this, and it only happens on a few of these labels in options->object types. k. frank 12.03.01
I think the problem is more in the way we do i18n testing and not in the code. It is true that the user will not want to disable and enable module, but on the other hand s/he will also not manually hack the Bundle.properties files in module jar files. So the steps to reproduce should be steps which the user will normally do, not an artificial sequence which involves code modification. Here is a new sequence which I believe verifies that this is NOT a bug: 1. Install a fresh FFJ CE build, do not run it. 2. In modules/taglibed.jar, extract file org/netbeans/modules/web/taglibed/resources/Bundle.properties 3. Modify the value of key TLD_TLDLoader.tld_file in the extracted file 4. Put the changed Bundle.properties back into taglibed.jar 5. Start the IDE 6. Go to Tools -> Options -> IDE onfiguration -> System -> Object Types Now the tld loader shows the modified value. Note that no disabling/enabling of modules is necessary. If you feel this is still a bug, please include steps to reproduce that would normally be performed by the user.
Marking as worksforme per previous comment.
verified - ken.frank@sun.com 01-02-2002
Consistent use of the I18N keyword.
Resolved for 3.4.x or earlier, no new info since then -> closing.