Hi, Patrick, >I only regret that using this new getResourceBundle, it looks like the standard getBundle search algorithm is not implemented. I personnaly believe it is usually bad >design to hardcode a default language, One should rather use a Locale for setting the language (picked from the argv for instance) or getting the platform's default >one and rely on the getBundle algorithm. The default resource language could then become the platform's language (locale) unless no resource exist for it, in which >case the resources found in the base resource bundle could be used (this could be a different file for each system according to installation option).
I agree. This is better than my proposals. Ive found the old message from Satoshi Ishigami, Jan 28, 2002 (see below) and he says the same. Satoshi wrote: > The language to use on AWTViewer is decided by getting the > system default or specifying -l option. The decided language > is used for the suffix of resource files. However Java has > a feature that access to a resource file for every language > by default (i.e. java.util.ResourceBundle class and > for examples rsources_ja.properties). Also I've understood why the resources.ru file was in that strange encoding. Satoshi wrote: > I also convert all existed resource file for AWTViewer from > iso-8859-1 to UTF-8 automatically. resources.ru was in the iso-8859-5 (as you says), not in the iso-8859-1. And it was converted to UTF-8, supposed what the primary encoding is 8859-1. Because of this I saw the european additional letters (from 8859-1) instead of cyrillic. It could happened with every 8859-x (not -1) encoded resource, if it was presents there. The full text of Satoshi Ishigami message: ----- Original Message ----- From: "Satoshi Ishigami" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 28, 2002 4:32 AM Subject: i18n in awt viewer [PATCH] > > Hi all ! > > For AWTViewer i18n, I hacked the AWTViewer for FOP-0.23.0rc > maintenance release and I had some questions. > > I tried to show the menu as Japanese text for i18n for trial. > I wrote the resource files by UTF-8 encoding because it is not > possible to map multi-bytes characters by iso-8859-1 encoding. > I also convert all existed resource file for AWTViewer from > iso-8859-1 to UTF-8 automatically. > > I modified some source files associated with AWTViewer, too. > This modification is for the message i18n and for additional > fonts support on AWTViewer. > > The additional fonts are specified in a userconfig.xml file. > And you may start FOP with -c and -awt options. NOTE:Now the > additional fonts that you can specified is only TrueType font > (.ttf and .ttc). This restriction comes from the feature of > SUN's JDK (see java.awt.Font javadoc). > > 1) If you specify the embed-file attribute in userconfig.xml > and use JDK1.3 or higher, the specified TrueType font is loaded > and used in AWTViewer. > > 2) Otherwise, if you don't specify the embed-file attribute or > use JDK1.2, the additional font is regarded as Java's "Dialog" > logical font name for each Locale. > > I attempt to show Japanese fo file. My test environment is: > SUN's JDK1.2.2 and JDK1.3. LANG=EN and JA environment variable. > > When use LANG=JA, 1) and 2) are works fine (menu is Japanese > text and the represented document is readable). > > LANG=EN and 1) also works fine (menu is English text and > document readable). But the convination of LANG=EN and 2) does > not works fine (menu looks English text well but document is > unreadble). However I think that this behavior is right. > > > Below is my questions. > > Currently the text of menu for the AWTViewer is loaded from > org.apache.fop.viewer.resources package. The AWTViewer needs > two kinds of resource file (messages.lang and resources.lang). > > I can not found messages.lang file for some languages (fi,fr, > it,pl.ru). Therefore the following command can not start the > AWTViewer (thrown NPE). > > fop -awt -l fi foo.fo > > Q1.Is not messages.lang file necessary with resources.lang file? > > > The language to use on AWTViewer is decided by getting the > system default or specifying -l option. The decided language > is used for the suffix of resource files. However Java has > a feature that access to a resource file for every language > by default (i.e. java.util.ResourceBundle class and > for examples rsources_ja.properties). > > Currently AWTViewer regards resource files as written by > iso-8859-1 encoding. This is not good for i18n. I converted > them to UTF-8 encoding, but I think that the ResourceBundle > framework is better than now because AWTViewer can start > even if there are not resource files for any languages. > > Q2.Why AWTViewer does not use ResourceBundle? > > Best Regards. > > --- > 石神 覚司(Satoshi Ishigami) VIC TOKAI CORPORATION > ----- Original Message ----- From: Patrick Andries To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 6:09 PM Subject: Re: AWTRenderer L10N issues Alex V. Alishevskikh wrote: Hi, Patrick,You wrote: No, it was coded in 8859-5 (Cyrillic) or Windows 1251, AFAIK, ISO8859-5 is not the same that Windows 1251. Well, Microsoft adds to 8859-5 a few Cyrillic characters in the 80-9F range (euro sign for one, and diacritic forms such as k apostrophe on top). My point was rather that it was not 8859-1 as mentioned but 8859-5 or CP 1251 which are hard to distinguish. I see the extended latinletters (with umlauts etc) instead of cyrillic characters.I've compiled FOP on machine (WinXP, Sun JDK 1.3) with russian locale. ? The only encoding that Properties and PropertyResourceBundleunderstand is ISO 8859-1 with Unicode escapes. This is not UTF-8. But why my Properties encoded as UTF-8 works and I see the readable russiantext? As pointed out in a different message by Satoshi, and I missed this, AWTStarter uses a getResourceBundle which in turns uses a SecourceResourceBundle that reads UTF-8 (I still see 8859-1 in my source). I suppose I should update my tree. I only regret that using this new getResourceBundle, it looks like the standard getBundle search algorithm is not implemented. I personnaly believe it is usually bad design to hardcode a default language, One should rather use a Locale for setting the language (picked from the argv for instance) or getting the platform's default one and rely on the getBundle algorithm. The default resource language could then become the platform's language (locale) unless no resource exist for it, in which case the resources found in the base resource bundle could be used (this could be a different file for each system according to installation option). P. Andries --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
