Community
Participate
Working Groups
AK (10/9/2001 4:58:42 PM) having an outline for .proprties files would be very useful NOTES: EG (10.10.2001 21:53:48) an outline with one entry per file, is this really usefull?
moved to 'active'
defer
Reopen
Won't fix for 2.x or 3.x
*** Bug 86273 has been marked as a duplicate of this bug. ***
Might be considered in the nls tooling effort
*** Bug 107996 has been marked as a duplicate of this bug. ***
Gathering requirements from the duplicates 1. The outline shows all *keys* 2. The outline should be sortable (view toolbar toggle). 3. The non-plus-ultra would be a hierarchical outline that groups common key prefixes. 4. Clicking on a (leaf) item would open the file and place the cursor at the key location. Hovering would display the value? The first 2 have to be implemented... For the hierarchical representation we could maybe have another tool bar button, to toggle between hierarchical and flat representation. Or do we want only hierarchical representation? Or only flat representation?
>Hovering would display the value? There's already the OS hover when the item doesn't fit the view. We shouldn't override that. I'm not longer convinced that his is too useful.
I agree that we shouldn't show the value in a tooltip in the Outline view. The default presentation should be flat (with a toggle to enable alphabetical sorting). I would start with that. A quick outline would also be handy. Hierarchical mode should go into a separate bug (or dropped altogether). It's not clear how the hierarchies should be built, since the keys are only defined as flat char sequences and groupings are mere ad-hoc conventions (separate at dot, underscore, slash, camelCase boundary, ...).
*** Bug 333521 has been marked as a duplicate of this bug. ***
It would be nice if one could see the property keys in the outline e.g. to sort and group them. I've just written an implementation which I published at http://tomsondev.bestsolution.at/2011/01/04/improvement-properties-editor/. If JDT is interested I could make a patch for JDT-UI which enhances the current editor.
Tom, can you read through this bug and comment on our requirements and concerns we discussed and also attach some screenshots from your solution?
(In reply to comment #13) > Tom, can you read through this bug and comment on our requirements and concerns > we discussed and also attach some screenshots from your solution? My requirements who are implemented are: * Hierarchical (currently I group by "_" but I'd also like to add ".") * Sortable * Display at least some parts of the translation (I display the first 20 chars using StyledString) On my todo list: * Flat representation
Created attachment 186071 [details] Screenshot of hiearchical implementation
(In reply to comment #10) > I agree that we shouldn't show the value in a tooltip in the Outline view. > Agreed - I've used the new StyledCellLabelProvider stuff to show this extra information > The default presentation should be flat (with a toggle to enable alphabetical > sorting). I would start with that. A quick outline would also be handy. > Agreed - it's on my todo list but very to add to my code base because I already remember those informations in a flat list. > Hierarchical mode should go into a separate bug (or dropped altogether). It's > not clear how the hierarchies should be built, since the keys are only defined > as flat char sequences and groupings are mere ad-hoc conventions (separate at > dot, underscore, slash, camelCase boundary, ...). IMHO _ (underscore) and . (point) are the most common and used because the NLS-Tooling uses those patterns.
Other interesting resources: * http://wiki.eclipse.org/Babel_/_Message_Bundle_Editor * http://mytourbook.sourceforge.net/mytourbook/index.php/development/translation/install-resource-editor but they go a lot beyond what I'd like to get as a default properties editor (maybe some formatting stuff would be nice but that's for another bug :-)
Tom, what are the scenarios/usecases where you really use that view in your daily work?
UC1: * add new key next to the same group (currently I have to hit CTRL+F and enter the first part == group) => Could be solve naturally also by an autoformat which puts groups together things according to their prefix UC2: * Find current keys a) to modify their value (e.g. you have spot a typo) b) delete the key because it is unused
Why do you perform this manually instead of using the wizard and 'Find Broken Externalized Strings' action?
>UC2: >* Find current keys > a) to modify their value (e.g. you have spot a typo) Where do you get the key from? If it's in the code then you can go directly to it via Ctrl+click.
(In reply to comment #20) > Why do you perform this manually instead of using the wizard and 'Find Broken > Externalized Strings' action? because this only works if you use the NLS-System which you won't e.g. in a Web-Environment where you simply do a ResourceBundle#getBundle() or you want to write RAP applications where the current static field approach of NLS fails completely.
(In reply to comment #21) > >UC2: > >* Find current keys > > a) to modify their value (e.g. you have spot a typo) > Where do you get the key from? If it's in the code then you can go directly to > it via Ctrl+click. See comment 22
(In reply to comment #22) (In reply to comment #23) Makes sense. Tom, would you be able to invest more time into this? As you mentioned the "flat" style is missing and I'd probably also like an option to hide the values. Furthermore I expect some polish so it fits into our existing code base. If so, the first step would be to provide an initial patch for 'org.eclipse.jdt.ui'.
Sure I'll: * first add the features to my code base at eclipse * provide a patch for JDT-UI (should it go to JDT-UI component wise then) => this was the reason I haven't found this bug report in first place :-) I'll come back with a patch hopefully soon
