[ANN] PropertiesEditor Plugin 1.0.2 关注
Change notes
Foreground coloring of text supported
Speed search to keys tree attached
Reworked error stripe renderer(I'm hope now OSX supported)
Small improvements and minor bugs fixes
Special thanks to Alexey Efimov for text coloring and to Hani Suleiman for help in OSX support.
TIA,
Dmitry
请先登录再写评论。
Nice work!
I have a (probably small) bug to report, and an RFE:
First, the bug: some of the property-files I have, use single-digit
keys, in other words:
1=First Value
2=Second Value
3=Third Value
These keys show up in the tree as
com.resedit.propedit.structure.PropertyItem@]]> (the default
toString(), I suppose)
As soon as I change (for example) the '1' to a 01 (or any non-single
character key), it shows up correctly.
As for the RFE: it would be really cool if you could get it to work on
multiple i18n-property files in one go - i.e. combine
resources_nl.properties, resources_de.properties and
resources.properties into one tree. It's one of the (few) NetBeans
features I miss in IDEA: it makes it really easy to keep the resources
in sync across different locales.
CU,
Edwin
Hi,
Bug will be fixed ASAP.
As for RFE:
I didn't see NetBeans last 2 years and forget this feature looks like.
Can you propose how better combine files with different languages? Something like tree on the left panel and on right 3 splitted vertically files with content and synchronized navigation? May be you see it other way?
I'm interested in typical configuration of projects with i18n support description. For example where resources stored with java code or separated from it in another folder? And others like this. Can you share info like this?
TIA,
Dmitry
Dmitry Kashin wrote:
No, I think that would be perfect - and better than NetBeans currently
does it: I really like the way you map 'hierarchical properties' to the
tree panel. NetBeans uses a table with one column per file
I've got a screenshot of the current NetBeans propertyfile editor here:
http://www.cadwal.org/nb-props.png
Probably yet another RFE: The context menu for the tree allows you to
bring up the 'new locale' dialog you see superimposed on the table. It
creates a new propertyfile correctly named for the selected
locale/country/variant. Maybe some inspiration ;)
Personally, I keep resources like resourcebundles & propertyfiles with
in the same tree & same package as the .java sources (and package/deploy
them with the classes). That way, I can simply use
Class.getResourceAsStream() (with a relative path) to load them - saves
a whole lot of filepath/classloader/classpath/version nightmares.
Non-propertyfile resources are in a separate folder off the root of the
project (usually /res)
I know a lot of my colleagues do the same, but I'm sure there are other
strategies.
CU,
Edwin
Hi,
This plugin not only for i18n but for editing and navigation of other properties files and how to separate this 2 processes? Any idea?
TIA,
Dmitry
Dmitry Kashin wrote:
That's true, but it's not that different - the basic key-value mapping &
navigation stuff is the same. Editing a 'normal' propertyfile is
basically the same as editing a 'resourcebundle' for only 1 locale.
How about switching to I18N mode (basically the table/column view) when
two or more property-files conforming to the resource-bundle convention
are found?
CU,
Edwin
Hi,
Thanks for suggestion, I'll try it, but anyway manual mode switching required cause when application developed usually it single languaged. I'll also plan to provide tool for finding not externalized resources in code and building this properties files.
What you can say about automatical replacement of such strings by call to some externalization routine?
TIA,
Dmitry
Dmitry Kashin wrote:
Well, a manual switch would definitely be useful - but I think it's not
really needed: like you said, when you develop an application initially,
it usually is single-language, i.e. one resource-bundle (e.g.
"messages.properties"). In that case, editing would be exactly like it
is now - like any 'normal' property file.
Now as soon as you add a second one (e.g. messages_de.properties), your
plugin could switch to 'column'-(i18n) mode.
Either way, you might add a popup-menu for creating a new property-file
using the resourcebundle naming conventions.
What do you think?
That would be really useful, but the 'externalize strings' feature I've
seen in other IDE's is far from perfect. Perhaps the far mor advanced
refactoring-support available in IDEA could help.
Probably you should add something like filtering - i.e., don't replace
in these classes/packages/types. Often parts of an app. are never i18n-d
even though they contain static text (utility-packages, etc.)
CU,
Edwin
Hi,
Detection with filtering is not main problem(it's partially done), main problem is what to do with detected strings? Your suggestions?
TIA,
Dmitry
Dmitry Kashin wrote:
Euhm, maybe you could show a list of the detected strings, with a
suggested key (similar to what the "Introduce Constant" refactoring
does). From that list the user would select/deselect strings to be
externalized, pick a property file to store them, and blammo! ;)
Does that sound like a reasonable workflow?
CU,
Edwin