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.

Bug 42919 - Poor UI of *.properties used for non-I18N purposes
Summary: Poor UI of *.properties used for non-I18N purposes
Alias: None
Product: utilities
Classification: Unclassified
Component: Properties (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker with 2 votes (vote)
Assignee: issues@utilities
Keywords: I18N, UI, USABILITY
: 42795 94993 (view as bug list)
Depends on: 48263
Blocks: 41448
  Show dependency tree
Reported: 2004-05-06 20:31 UTC by Jesse Glick
Modified: 2008-08-15 13:59 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-05-06 20:31:49 UTC
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 I am using to
load Ant properties for a project, it appears in
the Explorer as "". Fine. But if I
have some, it does not
appear as a separate node! It shows up under as some kind of unrecognized
locale variant. Bizarre.

2. The editor tab for shows
"build(default language)" which is absurd. Should
show "" - 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.
Comment 1 Tomas Pavek 2004-05-14 14:12:39 UTC
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.
Comment 2 Jesse Glick 2004-05-14 20:58:42 UTC
I don't think it's that serious - P3 seems about appropriate. Jano?
Comment 3 jrojcek 2004-05-17 08:38:30 UTC
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.
Comment 4 Jesse Glick 2004-05-17 17:07:01 UTC
Good point, this would be a nice place to use multiview.
Comment 5 Jan Stola 2004-06-02 10:30:20 UTC
*** Issue 42795 has been marked as a duplicate of this issue. ***
Comment 6 giorgio42 2006-08-28 16:01:55 UTC
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...
Comment 7 Marian Petras 2007-02-12 15:33:56 UTC
*** Issue 94993 has been marked as a duplicate of this issue. ***
Comment 8 Petr Jiricka 2007-07-16 14:40:34 UTC
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?
Comment 9 Marian Petras 2007-07-16 17:34:16 UTC
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).
Comment 10 Petr Jiricka 2007-10-05 09:38:21 UTC
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 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.
Comment 11 Petr Jiricka 2007-10-05 09:40:00 UTC
Changing target milestone to TBD, let's reevaluate please.
Comment 12 Marian Petras 2007-10-16 16:01:49 UTC
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.
Comment 13 Tomas Pavek 2008-07-23 09:52:07 UTC
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.

Comment 14 Jesse Glick 2008-07-23 15:52:34 UTC
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.
Comment 15 Tomas Pavek 2008-07-23 19:00:02 UTC
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.
Comment 16 giorgio42 2008-07-23 20:24:04 UTC
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...

Comment 17 giorgio42 2008-08-11 14:45:29 UTC
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:

displayed as
  + default language
  + bar - (bar - unknown language)

in both cases.

If I expand both nodes and select the versions and then try Tools -> Diff, the files
are compared, instead of the variants.

As already suggested below, this issue should be made a P2. It is more than 4 years old.

Comment 18 Tomas Pavek 2008-08-15 13:59:48 UTC
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 and 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: