Issue: When should numbers and dates be formatted for internationalization (I18N)? When displayed on the screen is an obvious answer, but what about storing/retrieving them in a text file?

Discussion: I set up my Enum objects to return their I18N name when the toString() function is called.  This is useful when displaying the values in a GUI listbox for example.  The user sees the values in their own language, and the correct Enum object is selected.  I also figured that the I18N name would be the storage text, since it would also be easier for the user to interpret that file, if it became necessary.

But the Boolean object, for example, doesn’t allow for any I18N.  The class is final and the values returned by toString() are “true” or “false”.  Of course I could create my own Enum version, which I’ve done for YesNoEnum, and others, but that is not the point.  Another example is numbers and dates.  These are especially sensitive to I18N.  For instance, most Europeans use a comma rather than a period in floating point numbers.  The value 1,000.25 in English is 1.000,25 in German.  This number is stored internally by Java as 1000.25 and a NumberFormat object would be used to format the number to appear correctly for the desired (or default) locale.  An example is: 

   NumberFormat nf = NumberFormat.getInstance(Locale.GERMAN);
   String s = nf.format(1000.25); // s will be “1.000,25”

When displaying the number it only makes sense to show it in the user’s format, so a German would see 1.000,25 and an American would see 1,000.25.  So the conversion, or formatting, would occur when a number is displayed.  The same would be true when reading a value entered by the user.  A German would enter 1.000,25 while an American would enter 1,000.25.  The parse method of a NumberFormat object handles that as well. 

   Float f = nf.parse(“1.000,25”).floatValue(); // nf is for locale.GERMAN

This will parse correctly in the German locale (as nf was set up), but fail in the American (US) locale.  So naturally, the values must be parsed using a NumberFormat object when a String is input from the user.  The internal (Java) representation is irrelevant.

But, should these values, when stored as text in a file, be in their locale format, or in the internal (US) format used by the toString() methods on numbers and dates?  While storing them in their locale format would be preferable, it will add complexity to the storage and retrieval process.  It is no problem to have a I18N toString() method for my classes, like enums and BowlingDates, but I can’t override the toString() method for numbers (Integer and Float) or Boolean.  I can’t extend these classes, either, to add some other I18N method, like asString(), to accomplish the formatting.  So I’m stuck using the US format for storage, and thus, retrieval.

So that begs the question, why bother to do the I18N saves for enums or dates?  It doesn’t really matter for the text file as much as it does for being able to display enums as lists in the GUI.  In that case there is some benefit to having the toString() method return the I18N name, so that is my choice.

Conclusion: