Issue: Resources are composed of two types of items. One is the internationalized Strings and the other is data, not just strings, used by the program. The internationalized (I18N) Strings are read only. That is, they are read in, used, but not changed by the program. They can be stored in a Properties object, or by a ResourceBundle object. The program data must be stored in a class which allows saving the changed data for use when the program is re-opened. The issue is how to store and use these resources. You can see the other issues with non-String internationalized values here.
Discussion: First I'll discuss the internationalized resources. These are read only Strings. While the Java tutorials seem to recommend that a ResourceBundle be used to hold these Strings, I find it less useful since they must be included in the Jar file, and therefore cannot be changed or altered by the user for their own purposes. I prefer to have the data stored outside the Jar file and available to the user. Since they would be straight text, it would be easy for a competent user to modify them. So, for example, a German user could modify these files into German, and the program would not have to be recompiled to update the Jar. The Properties class would work for this purpose, because it uses external text files. While the Properties class allows for the source information to be stored as text it also allows for it to be stored in XML format. I've decided not to use the XML format as the text format is easier to read and modify. The Properties class seems appropriate for this purpose, but I don't want to rule out the possibility of using a ResourceBundle in the future.
As for the data that the program will be using, that is a different problem. The Properties classes does not allow storing data as anything except a String. Of cource the ResourceBundle class allows storing objects, but does not allow for saving any changed data, so it is not useful for this purpose. The Properties class, while it allows saving data, all of the data must be a String. Since I need data other than Strings, I created my own class, which uses the Stringer class to convert routine objects to and from a String. So, while the source file for a Keys object appears identical to a Properties file, the data does not need to be only Strings, once it is read in, to be used by the program.
The final problem is whether these resources should be stored as one large file, or in many smaller files. Initially I thought to use one large file for each type, I18N, and data, but because the I18N file became very large, it became unwieldly. Finding a particular String to edit became time consuming. I also concluded that there should be a separate directory/folder to store these resource files in.
Conclusion: For I18N, the solution I will use is a Properties class external file, however I will create a special class to handle the loading of these Strings so that it could easily be changed to use a ResourceBundle in the future, with liitle work. The data will also be stored as an external file, but my own Keys class will be used since much of the data is not Strings when used by the program. I also decided to use multiple files to store the I18N Strings, to make finding a particular String and editing it easier.