RFE: PropertiesEditor plugin: handle character conversion
The thing that bothers me most about property files (and the reason that
I can't use IDEA to edit them) is that for some reason property files
should be encoded in ISO-8859-1 and no other encoding.
Since I'm usually writing international applications (and happens to write
in at least one double byte language myself), I'm using UTF-8 for my
source code and everything else for quite sometime. However, I can't do
this for property files. It would be nice if the PropertiesEditor plugin
could automagically show the property files as UTF-8 on screen (so I can
see the actual characteres instead \u1234\u4321 gibberish), but keep the
file in disk as ISO-8859-1, doing all the necessary conversions for me.
By the way, I think this feature is actually a core thing that should be
handled by IDEA itself, but it seems that PropertiesEditor is my best
chance to get this implemented. Maybe I'll take a shot at it myself when I
get some free time.
--
Marcus Brito <pazu@animegaiden.com.br>
Please sign in to leave a comment.
Hi,
It was planned from the beginning of plugin development but for technical reasons not implemented yet :( I'll try to do it one more time in near future. But anyway textual search in escaped files doesn't work and how to do this feature better not decided.
TIA,
Dmitry
Or even hook to Compiler API and keep source properties files in UTF-8 and convert to canonical view after compilation?
TIA,
Dmitry
Em Tue, 25 May 2004 23:11:48 +0400, Dmitry Kashin escreveu:
The canonical form for property files is iso-8859-1 encoding. This is how
they should always be encoded and stored. Tool like IDEA (or your plugin)
may provide a way to view it differently (that's what I'm asking about,
anyway), but it should always be left as iso-8859-1 on disk.
I just wonder what the guy/gal who designed the property files was
thinking when s/he jush slapped "property files must be iso-8859-1!"
on the specification...
--
Marcus Brito <pazu@animegaiden.com.br>
I mean that files can be stored in any encoding and may be edited by any editor but after project building with ant task it may transformed using task, and inside IDEA by usual compilation.
TIA,
Dmitry
Absolutely a core thing. Btw. , the plugin becomes more and more usable and the only big problem for now is the one U mentionned. Anyway , the editor imlpementation in SunONE seems more handy.
Some kind of compatibility , may be. No other reason.
Which of SunONE plugin features missed? Personally I'm don't use it for a long time and most missed feature is extraction from exisiting code bundles, most probably it will available after Pallada release. Which else?
Last time plugin targets changed and planned core features still not implemented for variuos reasons.
TIA,
Dmitry
Mostly the very advanced new bundle creation. Also the way the whole thing is presented is hard to read - SunOne uses tabular view to present the keys which is far more readable. Also U're right about the extraction.
Not agree that tabular view more convenient. If you want to see one property more detailed in all bundles you can use Shift+F4 on it.
New bundle creation is not easy to implement for all cases that's why it delayed. I'll add kind of inspections to extract properties from existing code after Pallada release and this may partially substitute it.
TIA,
Dmitry
Well, if it was just me, I would agree that we simply have different feeling about this point, but just check out the professional software internationalization packages like Multilizer - they also use tabular view. Supposingly they know how this should be done :-). Don't get me wrong - I just want to help to make it better.