1. Add a string to the properties file of choice (if multiple exist) or a new one. Even if 1 or more exist, there should be an option to specify a new one.
2. The names of the new entries can be automatically driven from the hard coded values according to a "code style" (delimiter, small/capital letters, etc.).
3. When a new property is introduced, a search for the hard coded string should be done so that it will be tied to the same property.
I would also love to see some clean-up features such as - transform 1 / all property files to a specific code style.
Regards, Amnon
Dmitry Kashin wrote:
Hi I'm very interested in ideas of action expected by different programmers when plugin detects not externalized string.
Now I am even more productive moving to ThunderBird :)
1,3. Great :) 2. You can start with forming the code style configuration and highlight the entries not conforming to it. When the options for the code style are established, then we'll know more precisely what the automatic formatting options can be.
It would be cool to see support of //$NON-NLS1$ //$NON-NLS5$ comments, as eclipse does (I was thinking about implementing this myself).
The number in comment corresponds to index of string literal in line where comment is, and corresponding string literal is ignored from externalization.
Something like that:
And we should see only 1st string highlighted.
But we should consider minor drawback here: refactoring (and other tools) will break this commenting scheme. For example when I extract expression with string literal into variable, I will loose corresponding comment.
Currently our team uses these comments and ignores these drawbacks.
Thanks to all who answered. For Irida planned i18n support which will duplicate this feature and cause core features usually more usable then plugin ones I won't continue to develop this branch of PE.
1. Add a string to the properties file of choice (if multiple exist) or
a new one. Even if 1 or more exist, there should be an option to specify
a new one.
2. The names of the new entries can be automatically driven from the
hard coded values according to a "code style" (delimiter, small/capital
letters, etc.).
3. When a new property is introduced, a search for the hard coded string
should be done so that it will be tied to the same property.
I would also love to see some clean-up features such as - transform 1 /
all property files to a specific code style.
Regards,
Amnon
Dmitry Kashin wrote:
Hi,
How always you the first, thanks!
1. Planned
2. There are many strange srings where it won't working if anyone write such routine I'll add it PE.
3. Planned
It would be good but tight coupled with 2.
TIA,
Dmitry
Now I am even more productive moving to ThunderBird :)
1,3. Great :)
2. You can start with forming the code style configuration and highlight
the entries not conforming to it. When the options for the code style
are established, then we'll know more precisely what the automatic
formatting options can be.
Amnon
Hi
It would be cool to see support of //$NON-NLS1$ //$NON-NLS5$ comments, as eclipse does (I was thinking about implementing this myself).
The number in comment corresponds to index of string literal in line where comment is, and corresponding string literal is ignored from externalization.
Something like that:
And we should see only 1st string highlighted.
But we should consider minor drawback here:
refactoring (and other tools) will break this commenting scheme. For example when I extract expression with string literal into variable, I will loose corresponding comment.
Currently our team uses these comments and ignores these drawbacks.
Thanks to all who answered. For Irida planned i18n support which will duplicate this feature and cause core features usually more usable then plugin ones I won't continue to develop this branch of PE.
TIA,
Dmitry