Great, I see what you mean. I'll try to look for this as soon as possible :)
Loic -----Message d'origine----- De : Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Envoy� : samedi 16 mars 2002 00:48 � : Poi Dev Objet : Re: [L10N/I18N] formats I like it except I don't see why we need multiple editions of FormatRecord (a low level binary structure mapping to an Excel BIFF record). I think I prefer the following signature: int HSSFDataFormat.getFormat(String format, String locale); Within that we could have a hashmap of locales that held maps of format strings to ints. Orrrr..... int HSSFDataFormat.getFormat(String format, HSSFLocale locale); HSSFLocale could hold the actual functionality. Anything else that got localized could take an instance (subclass) of HSSFLocale. The locale would conform to the following interface for the moment: ... getFormat(String format); ... As we localize more things the methods would be added as abstract functions to the parent HSSFLocale. This way they'd have to be implemented for every locale as needed. Thoughts? Localization/Globalization is really important to our userbase. Everyone should get interested in this. BTW it looks great on the resume too :-) -Andy On Fri, 2002-03-15 at 11:22, Lo�c Lef�vre wrote: > How about centralize the different formats used in Excel. > > I explain: > As I've seen, there are two places where we can find the > data (date, number...) formats: HSSFDataFormat and Workbook. > > The ones in the class Workbook are the new ones (personal formats) > added to the general ones which stand in HSSFDataFormat. > > As I understood, when one want to specify a format to a cell, let's > say a date format, one has to specify the code of this format or > the pattern (for example: mmmm-yy ). If the pattern mode is used, > then the format has to be declared in the HSSFDataFormat. If the > specified pattern is not present, then a -1 code format is returned. > > Well how about localize all these formats (default ones) thus, one can > do this: > > HSSFCellStyle cs = wb.createCellStyle(); > cs.setDataFormat( HSSFDataFormat.getFormat("(# ##0 F_);[Rouge](# ##0 > F)") ); > > which is the french equivalent for the english/us pattern: > ($#,##0_);[Red]($#,##0) > > And they it seems, they have the same code! > > So according to the Locale.getDefault() locale object, > the HSSFDataFormat.getFormat( /* localized pattern */ ) would return the > good code. > Thus, an other idea comes: how about to declare constants for the different > patterns? > eg: > public static short GENERAL = 0; // 0, "General" > public static short NUMBER_DEFAULT = 1; // 1, "0" > ... > public static short DATE_DEFAULT = 0xe; // 0xe, US => "m/d/yy", FR => > "d/m/yy" > ... > > Seems, the constant names will be somewhat hard to find ;) > > After that, in the class Workbook, the method: > > protected Record createFormat(int id) > { // we'll need multiple editions for > FormatRecord retval = new FormatRecord(); // the differnt formats > > switch (id) > { > > case 0 : > retval.setIndexCode(( short ) 5); > retval.setFormatStringLength(( byte ) 0x17); > retval.setFormatString("\"$\"#,##0_);\\(\"$\"#,##0\\)"); > break; > > ... > > case 7 : > retval.setIndexCode(( short ) 0x2b); > retval.setFormatStringLength(( byte ) 0x31); > retval.setFormatString( > "_(* #,##0.00_);_(* \\(#,##0.00\\);_(* \"-\"??_);_(@_)"); > break; > } > return retval; > } > > will look like: > > protected Record createFormat(int id) > { > return FormatRecordFactory.getInstance(( short ) id); > } > > See FormatRecordFactory (attachment) > > Waiting for your answer(s) :) > > Lo�c -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh
