M. Scott Gartner
The program is cool, but when I edit our files, which have lots of existing comments, have the strings in sections within the file, have a copyright header at the top, etc. all of this important information is lost. Frankly, I think this loss of important information makes this program unusable for us. The program should not destroy the existing formatting of the files and it is very important (I would say vital) in a large project to have strings organized within the file into groups. It would be fine if the UI of the program doesn't show this (though it would be a nice feature to optionally show the strings in file order with grouping by comment and optionally show them alphabetically), but when changing a string it should replace the string in the existing location and not lose any non-string information.
I see the problem, but this behaviour is inherent to the inner system how the program works. It reads all property files for one specific base file name, constructs an internal data structure out of these, works on this data structure, and finally writes the files out again (using the standard property file writing classes). So, files are actually newly written each times somethings changes within them.
I see hardly any possibility to change this behaviour. Perhaps a very smart writing algorithm which rereads the existing file, changes everything which is needed and keeps the file structure intact this way. But I do not see the "real" advantage. In fact, the .properties files should be as short as possible as they are written verbatim to the JAR containing the application.
I18NEdit implements its own comment mechanism using the .metaprops files. The comments are shown in the GUI. This could be a replacement for the in-file comments. For a copyright header in the .properties files, an extension could be added, however.