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.
The UI of the properties module is poorly suited to uses other than creating localized text resources (and arguably not ideal for that either). 1. If I have some build.properties I am using to load Ant properties for a project, it appears in the Explorer as "build.properties". Fine. But if I have some build_debug.properties, it does not appear as a separate node! It shows up under build.properties as some kind of unrecognized locale variant. Bizarre. 2. The editor tab for build.properties shows "build(default language)" which is absurd. Should show "build.properties" - the name of the file I am editing. 3. The editor tab also does not apparently show VCS status badges. (The Explorer node does.) It also shows a different icon than is used for the file in the Explorer - shows the icon used *beneath* the file node. Recommendation - delete all the weird hacks that make a group of *.properties appear as one DataObject. It is obsolete and probably quite buggy. Make PropertiesDataObject a simple DataObject using UniFileLoader and checking by extension, nothing special. It should have the current syntax coloring of course, and could keep the structure view in the Explorer (in case anyone really uses this). For those users who actually are using the localization features, this only matters w.r.t. the table view over a suite of files - if they are editing the properties as text, they won't be affected by the change. So keep "Open" in the context menu of the *.properties files; when that is selected (and only then) look for other *.properties files which appear to be part of a localization suite, and open the table view as now. You could actually make it *more* useful than it is now because you could be more flexible in finding locale variants - e.g. check for a ClassPath.EXECUTE and if you find one, search for all *.properties in the same "package" as the current one with locale-variant names, and assume they are part of the suite. Also would need to do some minor patch in the internationalization wizards and I18N string editor for form, to only offer the base-locale *.properties file as the "localizing bundle" the user selects.
Nice analysis, I agree with it (almost) completely. But this probably won't be done for NB 4.0 - it's a feature change and I'm afraid it's too late now - unless it is a serious problem.
I don't think it's that serious - P3 seems about appropriate. Jano?
I agree that it isn't serious and should be well thought out before making the change (I tend to agree with Jesse, though). The nested editors feature behavior (multi-view in editor) might also be considered when making this change.
Good point, this would be a nice place to use multiview.
*** Issue 42795 has been marked as a duplicate of this issue. ***
Most of the issues with the current way of handling property files have been summarized really well below. I keep running into each of them every other week (or so). But today I ran into yet another "bizarre" problem: It is not possible to copy/paste the properties files individually, only the group as a whole. If I expand the group's node and select an individual member of the group, the "Copy" menu entry is enabled. However, when I try to paste it back, "Paste" is still greyed out. I actually have to use the OS to copy the file to one of the folders in my Favourites window. In the NB world the ring to rule them all is simply the part before the first underscore in the name of a Java properties file...
*** Issue 94993 has been marked as a duplicate of this issue. ***
I see the target milestone of this bug was changed to 'future' in January. Does it mean this issue is not considered for 6.0? Can you please fix this for NB 6?
No, it is not planned for NB 6.0. It is tentatively planned for the release after 6.0 (as the first and only planned feature/change at the moment).
Another manifestation of this issue: 1. Open the NetBeans source tree in the Favorites tab, select the 'db' node. 2. Open the Find... dialog and search for file Bundle_noi18n* (leave the "Containing Text") field empty. => No results are found, although file Bundle_noi18n.properties exists in the source tree. So the UI is not only bad for non-I18N purposes as the subject of this bug suggest, but also for things related to I18N. Looking at all the aspects of this issue, I tend to think this is a P2 rather than a P3.
Changing target milestone to TBD, let's reevaluate please.
Changing target milestone back to 'future'. Please do not change it to 'TBD' until a target milestone value larger than '6.0' is available. Bugs with target milestone set to 'TBD' are considered unevaluated, which is not this case.
The full fix of this issue requires changes in the dataloader and internal representation of multiple locales which is needed in the table view and also used heavily by form editor. That's quite some changes and dependencies to be handled. What about a quick fix that would: 1. Only group properties files containing a known locale sufix in their name (leave everything else separate). 2. Don't show the 'default language' subnode if there is only one "locale" present. This would make most users happy (all problems reported here) and keep the internationalization functionality working the same way in relevant cases. And would be quite easy and safe to implement. Opinions?
The proposed fix is OK as a short-term workaround for some problems. It does not solve other problems, such as the poor handling of VCS operations, and the internal complexity of the loader is likely to continue to cause various issues.
Some issues will remain (will update), but only for the case with multiple real locales. For the other properties files ("non-I18N purposes" as this issue was reported) it will behave like a simple dataobject with no issues.
A quick fix is ok at this point in time (NB6.5 approaching M2), but only if you promise a real fix after 6.5 is out... Cheers.
I just spent 30 minutes searching for a .properties file until I remembered this issue and expanded the node... One additional issue caused by the current implementation (NB200807300201) impacts diffing: Picture this: /dir1/foo.properties /dir1/foo_bar.properties /dir2/foo.properties /dir2/foo_bar.properties displayed as - foo.properties + default language + bar - (bar - unknown language) in both cases. If I expand both nodes and select the foo_bar.properties versions and then try Tools -> Diff, the foo.properties files are compared, instead of the foo_bar.properties variants. As already suggested below, this issue should be made a P2. It is more than 4 years old.
I've integrated the fix described above and some minor additional fixes: * More properties files are grouped under one node/data object only if they represent a real locales (known language/country suffix). Files like build.properties and build_debug.properties are left as separate data objects. * For a single properties file its node has no "default language" subnode (the subnodes for properties are displayed directly), neither "default language" is shown in its name in the editor (file name and icon displayed correctly). Nothing resembles it has something to do with i18n - unless there are more real locales present. I think this makes the UI for non-i18n purposes fixed (for great majority of cases). Problems that remain appear only in case you really use multiple locale variants (properties files) for internationalization. For more locale variants, the UI is kept as so far (files grouped under one node), with some more fixes: * Versioning status is correctly shown both in editor and explorer for individual locale files. * The locale files can now be compared using Tools | Diff. The VCS operations work with individual files, the status/changes view also shows files (no data objects) - so I don't see any problem with versioning right now. I'm now aware of two remaining problems of grouping more locales under one data object: 1) The individual locale files can't be copied separately into a folder - only into another properties data object, or the entire data object must be copied. I'm not sure if copying a separate locale file is useful in practice, anyway - there is an easy workaround. 2) The find in files feature does not search in additional locale files, only in the default one. There's issue 26705 about this (only primary files of data objects are searched). So I think the multi data object should be eliminated - even for the i18n case, as was originally suggested. Just the table view of multiple locales should be kept, as well as the GUI builder ability to switch between locales of one resource bundle. That requires more work than the simple fix I've made. Issue 48263 is exactly about this remaining work. Integrated changeset: http://hg.netbeans.org/main/rev/bd233cf0044e