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 words CSS, DTD, XML Objects 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. 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.
I checked it and all seems OK in original Forte's module. What module did you used? Object types string = displayName of loader from bundle Module description = manifest entry from bundle (fixed now)
I saw this using FFJ Pilsen FCS. The words appeared to be in the bundle files, but just not shown as coming from pseudo localzied bundle files. This situation happened with some other FFJ modules and bugs were filed in those also. ken.frank 2001-09-07
Need to reassign.
Hello Ken, could you please update bug status. As it is not caused by bug in XML module code, I would appreciate if you can resolve it as all other bugs of this flavour you have entered.
Petr mentioned that this issue was not from xml module and suggested openide, so am changing it to that - the issue is seen in localized release also, and there have been other similar bugs filed on other modules. Email between Petr and myself below: ENNETH FRANK wrote: > > Petr, > > You had asked me to update bug's status. > Can you tell me what needs updating, > or what other module this might be from ? > As I mentioned, I saw the words like > CSS Objects in bundle files but on using pilsen, > it did not come from the localized bundle file. > > And looking at localized FFJ, also see this > situation. I've filed bugs in other areas > on this same issue, so if you can let me > know which module area this bug needs to be > in, I'll transfer it there. > > Thanks - Ken As far as I know you have probably mixed settings of English and a other locate. Non I18N texts you have reported are in code properly I18N-ed but calls to this core is cached (and serialized as a setting) by OpenIDE. If it is the case you should report an error agains OpenIDE that is serializes/persistently stores display names. ken.frank@sun.com 2001-10-09
Ales, please investigate.
After a brief look, it looks that DataLoader has the defaultDisplayName() method back from March 2001. Loaders are recommended to provide this method instead of invoking setDisplayName(). So either this bug is fixed in post Pilsen releases or the XML module should should provide its display name by the default method.
So - DTDDataloader and XMLDataLoader contain in their initialize methods setDisplayName(...). Can you just provide defaultDisplayName()? Also, throw away whole initialize method if possible, i.e. use createDefaultActions() instead, see java module for instance. We are pushing to do it for performance reasons.
Strange API but what can we do. Will fix it to experimental XML module alpha.
Ales's suggestion applied.
Just updating the subcomponent.
Comment: Verified on Release 3.3 Beta 6 (Build 2001112701845)
Consistent use of the I18N keyword.
Resolved for 3.4.x or earlier, no new info since then -> closing.