You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <Cr...@eng.sun.com> on 2000/12/08 18:41:56 UTC
Proposed Solution to Non-Serializable MessageResources Class
As Struts get used in more and more environments, we run into the bleeding edges
once in a while. One place that was recently discovered is that some
application servers insist on application scope beans (i.e. servlet context
resources) being Serializable under certain circumstances. (Note -- this is not
a spec requirement issue; it is a container-specific restriction).
The Struts example application is not going to work in such an environment,
because of the way that the pseudo-database is architected and used. However, a
more serious issue is that the MessageResources class (used to store the
application resources for your internationalized message strings) is not
Serializable, and it cannt be made so -- because the underlying
java.util.ResourceBundle family of classes are not Serializable.
There is an additional headache that is caused by the current implementation --
it relies on loading properties files to initialize the message strings. For
languages that use ISO-8859-1 character sets, that is pretty easy -- just edit
the files with a text editor and you are done. For other character sets,
however, you have to remember to run "native2ascii" on the properties files
after editing.
To deal with both of these problems, I propose to create a new MessageBundle
class, which will be Serializable. The external API will be very much like
MessageResources, so minimal code changes will be required. The key difference
will be in how it is initialized. I propose to load the messages from an XML
file (so that you can declare the character set, and use an XML-based editor).
For the Struts example app, the file would look like this:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-messages PUBLIC
"-//Apache Software Foundation//DTD Struts Messages 1.0//EN"
"http://jakarta.apache.org/struts/dtds/struts-messages_1_0.dtd">
<struts-messages default="en_US">
<!-- Messages for US English -->
<locale locale="en_US" xml:lang="en-US">
<message name="button.cancel" value="Cancel"/>
<message name="button.confirm" value="Confirm"/>
...
</locale>
<!-- Messages for Spanish -->
<message name="button.cancel" value="..."/>
<message name="button.confirm" value="..."/>
...
<locale locale="es" xml:lang="es">
...
</locale>
</struts-messages>
The existing mechanism (MessageResources) would remain available in 1.0 for
backwards compatibility, but would be deprecated in favor of MessageBundle in
future versions.
What do you think?
Craig McClanahan
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Louis Tribble <lo...@metamata.com>.
"Craig R. McClanahan" wrote:
>
> As Struts get used in more and more environments, we run into the bleeding edges
> once in a while. One place that was recently discovered is that some
> application servers insist on application scope beans (i.e. servlet context
> resources) being Serializable under certain circumstances. (Note -- this is not
> a spec requirement issue; it is a container-specific restriction).
>
> The Struts example application is not going to work in such an environment,
> because of the way that the pseudo-database is architected and used. However, a
> more serious issue is that the MessageResources class (used to store the
> application resources for your internationalized message strings) is not
> Serializable, and it cannt be made so -- because the underlying
> java.util.ResourceBundle family of classes are not Serializable.
>
> There is an additional headache that is caused by the current implementation --
> it relies on loading properties files to initialize the message strings. For
> languages that use ISO-8859-1 character sets, that is pretty easy -- just edit
> the files with a text editor and you are done. For other character sets,
> however, you have to remember to run "native2ascii" on the properties files
> after editing.
>
> To deal with both of these problems, I propose to create a new MessageBundle
> class, which will be Serializable. The external API will be very much like
> MessageResources, so minimal code changes will be required. The key difference
> will be in how it is initialized. I propose to load the messages from an XML
> file (so that you can declare the character set, and use an XML-based editor).
> For the Struts example app, the file would look like this:
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
>
> <!DOCTYPE struts-messages PUBLIC
> "-//Apache Software Foundation//DTD Struts Messages 1.0//EN"
> "http://jakarta.apache.org/struts/dtds/struts-messages_1_0.dtd">
>
> <struts-messages default="en_US">
>
> <!-- Messages for US English -->
> <locale locale="en_US" xml:lang="en-US">
> <message name="button.cancel" value="Cancel"/>
> <message name="button.confirm" value="Confirm"/>
> ...
> </locale>
>
> <!-- Messages for Spanish -->
> <message name="button.cancel" value="..."/>
> <message name="button.confirm" value="..."/>
> ...
> <locale locale="es" xml:lang="es">
> ...
> </locale>
>
> </struts-messages>
>
> The existing mechanism (MessageResources) would remain available in 1.0 for
> backwards compatibility, but would be deprecated in favor of MessageBundle in
> future versions.
>
> What do you think?
TMX looks like it might make sense for the XML format:
http://www.lisa.org/tmx/
There is a DTD and a link to an article describing its use from
Java, including code for a TMXResourceBundle class.
Regards,
Louis Tribble
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Louis Tribble louis@metamata.com
Metamata, Inc. http://www.metamata.com
Tools for serious Java developers. +1 510 796 0915
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Laird Nelson <lj...@unix.amherst.edu>.
----- Original Message -----
From: "Pierre Métras" <ge...@sympatico.ca>
> - Message bundles files are already used for localization of other
> softwares. So translators know how to handle them. I don't want the
> translators to use an XML editor to do the work they used to do with
their
> prefered world processor or editor.
[snip]
> - And last, XML syntax is too much verbose and had no advantage here
> (translators are frequently paid for the word!).
[snip]
> The real i18n problems with the message files (apart from their
format) is
> how to track changes between revision, how to check for completeness
between
> different locale files and how to break them into smaller files
(inclusion).
FWIW, I second Pierre's concerns.
Cheers,
Laird
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Pierre Métras <ge...@sympatico.ca>.
Hi Craig,
I really don't think the XMLization of the message files is a good idea.
- Putting all the messages in only one file is not judicious as the various
sections are treated by different translators. It's far more easy to give
each of them a different file.
- Also, some languages can use different local character sets. The croatean
message file will use a local character set that will be incompatible with
the japanese one. Putting all them in a single file will not make the task
easier.
- Message bundles files are already used for localization of other
softwares. So translators know how to handle them. I don't want the
translators to use an XML editor to do the work they used to do with their
prefered world processor or editor.
- Property files have a syntax adapted for large blocks of text. You can use
the escape character \ at the end of a line to break a sentence into
multiple lines. I don't think that such a facility is offered under XML
syntax.
- And last, XML syntax is too much verbose and had no advantage here
(translators are frequently paid for the word!).
The real i18n problems with the message files (apart from their format) is
how to track changes between revision, how to check for completeness between
different locale files and how to break them into smaller files (inclusion).
If you really want to include extra information, for instance the default
locale or the xml:lang, just put them in the struts-config.xml file, where
they are used to describe the configuration of the Struts application. But
please, don't try to mix application configuration with application data...
Pierre Métras
> I propose to load the messages from an XML
> file (so that you can declare the character set, and use an XML-based
editor).
> For the Struts example app, the file would look like this:
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
>
> <!DOCTYPE struts-messages PUBLIC
> "-//Apache Software Foundation//DTD Struts Messages 1.0//EN"
> "http://jakarta.apache.org/struts/dtds/struts-messages_1_0.dtd">
>
> <struts-messages default="en_US">
>
> ...
>
> </struts-messages>
>
> The existing mechanism (MessageResources) would remain available in 1.0
for
> backwards compatibility, but would be deprecated in favor of MessageBundle
in
> future versions.
>
> What do you think?
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by "Rousseau, John" <JR...@silverstream.com>.
On Friday Dec 8, 2000, Craig R. McClanahan wrote:
> As Struts get used in more and more environments, we run into the bleeding edges
> once in a while. One place that was recently discovered is that some
> application servers insist on application scope beans (i.e. servlet context
> resources) being Serializable under certain circumstances. (Note -- this is not
> a spec requirement issue; it is a container-specific restriction).
>
> The Struts example application is not going to work in such an environment,
> because of the way that the pseudo-database is architected and used. However, a
> more serious issue is that the MessageResources class (used to store the
> application resources for your internationalized message strings) is not
> Serializable, and it cannt be made so -- because the underlying
> java.util.ResourceBundle family of classes are not Serializable.
>
> There is an additional headache that is caused by the current implementation --
> it relies on loading properties files to initialize the message strings. For
> languages that use ISO-8859-1 character sets, that is pretty easy -- just edit
> the files with a text editor and you are done. For other character sets,
> however, you have to remember to run "native2ascii" on the properties files
> after editing.
>
> To deal with both of these problems, I propose to create a new MessageBundle
> class, which will be Serializable. The external API will be very much like
> MessageResources, so minimal code changes will be required. The key difference
> will be in how it is initialized. I propose to load the messages from an XML
> file (so that you can declare the character set, and use an XML-based editor).
> For the Struts example app, the file would look like this:
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
>
> <!DOCTYPE struts-messages PUBLIC
> "-//Apache Software Foundation//DTD Struts Messages 1.0//EN"
> "http://jakarta.apache.org/struts/dtds/struts-messages_1_0.dtd">
>
> <struts-messages default="en_US">
>
> <!-- Messages for US English -->
> <locale locale="en_US" xml:lang="en-US">
> <message name="button.cancel" value="Cancel"/>
> <message name="button.confirm" value="Confirm"/>
> ...
> </locale>
>
> <!-- Messages for Spanish -->
> <message name="button.cancel" value="..."/>
> <message name="button.confirm" value="..."/>
> ...
> <locale locale="es" xml:lang="es">
> ...
> </locale>
>
> </struts-messages>
>
> The existing mechanism (MessageResources) would remain available in 1.0 for
> backwards compatibility, but would be deprecated in favor of MessageBundle in
> future versions.
>
> What do you think?
Yes please! Allowing the serialization of message data would make
things here _much_ better!
-John
----------------------------------------------------------------
John Rousseau jrr@silverstream.com
SilverStream Software Phone: +1 978 262 3564
2 Federal Street Fax: +1 978 262 3499
Billerica, MA 01821 http://www.silverstream.com
----------------------------------------------------------------
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Louis Tribble <lo...@metamata.com>.
"Craig R. McClanahan" wrote:
>
> As Struts get used in more and more environments, we run into the bleeding edges
> once in a while. One place that was recently discovered is that some
> application servers insist on application scope beans (i.e. servlet context
> resources) being Serializable under certain circumstances. (Note -- this is not
> a spec requirement issue; it is a container-specific restriction).
>
> The Struts example application is not going to work in such an environment,
> because of the way that the pseudo-database is architected and used. However, a
> more serious issue is that the MessageResources class (used to store the
> application resources for your internationalized message strings) is not
> Serializable, and it cannt be made so -- because the underlying
> java.util.ResourceBundle family of classes are not Serializable.
>
> There is an additional headache that is caused by the current implementation --
> it relies on loading properties files to initialize the message strings. For
> languages that use ISO-8859-1 character sets, that is pretty easy -- just edit
> the files with a text editor and you are done. For other character sets,
> however, you have to remember to run "native2ascii" on the properties files
> after editing.
>
> To deal with both of these problems, I propose to create a new MessageBundle
> class, which will be Serializable. The external API will be very much like
> MessageResources, so minimal code changes will be required. The key difference
> will be in how it is initialized. I propose to load the messages from an XML
> file (so that you can declare the character set, and use an XML-based editor).
> For the Struts example app, the file would look like this:
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
>
> <!DOCTYPE struts-messages PUBLIC
> "-//Apache Software Foundation//DTD Struts Messages 1.0//EN"
> "http://jakarta.apache.org/struts/dtds/struts-messages_1_0.dtd">
>
> <struts-messages default="en_US">
>
> <!-- Messages for US English -->
> <locale locale="en_US" xml:lang="en-US">
> <message name="button.cancel" value="Cancel"/>
> <message name="button.confirm" value="Confirm"/>
> ...
> </locale>
>
> <!-- Messages for Spanish -->
> <message name="button.cancel" value="..."/>
> <message name="button.confirm" value="..."/>
> ...
> <locale locale="es" xml:lang="es">
> ...
> </locale>
>
> </struts-messages>
>
> The existing mechanism (MessageResources) would remain available in 1.0 for
> backwards compatibility, but would be deprecated in favor of MessageBundle in
> future versions.
>
> What do you think?
TMX looks like it might make sense for the XML format:
http://www.lisa.org/tmx/
There is a DTD and a link to an article describing its use from
Java, including code for a TMXResourceBundle class.
Regards,
Louis Tribble
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Louis Tribble louis@metamata.com
Metamata, Inc. http://www.metamata.com
Tools for serious Java developers. +1 510 796 0915
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by "Rousseau, John" <JR...@silverstream.com>.
On Friday Dec 8, 2000, Craig R. McClanahan wrote:
> As Struts get used in more and more environments, we run into the bleeding edges
> once in a while. One place that was recently discovered is that some
> application servers insist on application scope beans (i.e. servlet context
> resources) being Serializable under certain circumstances. (Note -- this is not
> a spec requirement issue; it is a container-specific restriction).
>
> The Struts example application is not going to work in such an environment,
> because of the way that the pseudo-database is architected and used. However, a
> more serious issue is that the MessageResources class (used to store the
> application resources for your internationalized message strings) is not
> Serializable, and it cannt be made so -- because the underlying
> java.util.ResourceBundle family of classes are not Serializable.
>
> There is an additional headache that is caused by the current implementation --
> it relies on loading properties files to initialize the message strings. For
> languages that use ISO-8859-1 character sets, that is pretty easy -- just edit
> the files with a text editor and you are done. For other character sets,
> however, you have to remember to run "native2ascii" on the properties files
> after editing.
>
> To deal with both of these problems, I propose to create a new MessageBundle
> class, which will be Serializable. The external API will be very much like
> MessageResources, so minimal code changes will be required. The key difference
> will be in how it is initialized. I propose to load the messages from an XML
> file (so that you can declare the character set, and use an XML-based editor).
> For the Struts example app, the file would look like this:
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
>
> <!DOCTYPE struts-messages PUBLIC
> "-//Apache Software Foundation//DTD Struts Messages 1.0//EN"
> "http://jakarta.apache.org/struts/dtds/struts-messages_1_0.dtd">
>
> <struts-messages default="en_US">
>
> <!-- Messages for US English -->
> <locale locale="en_US" xml:lang="en-US">
> <message name="button.cancel" value="Cancel"/>
> <message name="button.confirm" value="Confirm"/>
> ...
> </locale>
>
> <!-- Messages for Spanish -->
> <message name="button.cancel" value="..."/>
> <message name="button.confirm" value="..."/>
> ...
> <locale locale="es" xml:lang="es">
> ...
> </locale>
>
> </struts-messages>
>
> The existing mechanism (MessageResources) would remain available in 1.0 for
> backwards compatibility, but would be deprecated in favor of MessageBundle in
> future versions.
>
> What do you think?
Yes please! Allowing the serialization of message data would make
things here _much_ better!
-John
----------------------------------------------------------------
John Rousseau jrr@silverstream.com
SilverStream Software Phone: +1 978 262 3564
2 Federal Street Fax: +1 978 262 3499
Billerica, MA 01821 http://www.silverstream.com
----------------------------------------------------------------
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Greg Murray <gm...@eng.sun.com>.
Hi,
In the past I have worked heavily with properties files and resource bundles. I
spent
over a year on tools to load and configure these files. In the web world I do not
like
either option for content that may change. As has been mentioned in this thread
Resource
bundles require compiling and properties files require navitve2ascii as mentioned.
This
requires that those doing localization have and use tools that may be complicated.
Both
of these formats (in there end prodcut) are not human readable assuming that the
language
is not a latin based language.
I would have to concure with Craig that XML is the best format. I do like the
idea. I
believe it would be good to keep the language based information in serparate files
which
all for different encodings. Multi-lingual pages can use UTF-8 or Unicode.
As far as translation history or notes from translators this information can be
kept
in XML comments.
IMHO Resource Bundles and properties files seem more sutible for system messages
that
are related to an application. XML seems more sutible for content that can be
changed
and configured.
Let me know what you all think,
greg
"Craig R. McClanahan" wrote:
> Pierre Métras wrote:
>
> > Hi again,
> >
> > To temper my previous post.
> > Yes, you can define org.apache.struts.MessageBundle to correct the
> > serialization problem under some servlet containers.
> > No, don't change the syntax of the message files.
> >
>
> How about, as a compromise, we emulate the java.util.ResourceBundle family and
> have it accept input information either way (properties files or XML files)?
> This would be pretty simple to implement.
>
> The reason for this is that I've heard just as many complaints about the
> property file format, especially in having to remember to run native2ascii on
> them -- to say nothing of some translators that screw up the format with their
> text editors.
>
> >
> > Pierre Métras
>
> Craig McClanahan
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Michael Westbay wrote:
> Vaala-san wrote:
>
> > I would like to further propose on this idea - create a
> > MessageResourcesInterface that various implementations can be created for. Four
> > standard implementations could ship with struts: XML, Properties, and database.
> > I could see that some people may find it easier, or more practical to store
> > their messages in a database.
>
> This is the best idea I've heard so far. And I believe I read that the
> factory pattern was one of McClanahan-san's favorites?
>
Yep :-). Its a good idea.
Craig
>
> --
> Michael Westbay
> Work: Beacon-IT http://www.beacon-it.co.jp/
> Home: http://www.seaple.icc.ne.jp/~westbay
> Commentary: http://www.japanesebaseball.com/
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Michael Westbay <we...@seaple.icc.ne.jp>.
Vaala-san wrote:
> I would like to further propose on this idea - create a
> MessageResourcesInterface that various implementations can be created for. Four
> standard implementations could ship with struts: XML, Properties, and database.
> I could see that some people may find it easier, or more practical to store
> their messages in a database.
This is the best idea I've heard so far. And I believe I read that the
factory pattern was one of McClanahan-san's favorites?
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/
Re[2]: Proposed Solution to Non-Serializable MessageResources Class
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Evan,
Saturday, December 09, 2000, 12:24:30 AM, you wrote:
EV> I would like to further propose on this idea - create a
EV> MessageResourcesInterface that various implementations can be created for. Four
EV> standard implementations could ship with struts: XML, Properties, and database.
EV> I could see that some people may find it easier, or more practical to store
EV> their messages in a database.
Great idea!
One addition can be very useful for "exotic" languages (corean,
russian, etc. ) - specify codepage for message source. Only for
russian, five codepages can be used - dos866, win1251, iso-8859-5,
koi-8r, codepage for Mac...
--
Best regards,
Oleg mailto:gonza@penza.net
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Evan Vaala <ev...@csi.com>.
"Craig R. McClanahan" wrote:
> How about, as a compromise, we emulate the java.util.ResourceBundle family and
> have it accept input information either way (properties files or XML files)?
> This would be pretty simple to implement.
>
> The reason for this is that I've heard just as many complaints about the
> property file format, especially in having to remember to run native2ascii on
> them -- to say nothing of some translators that screw up the format with their
> text editors.
Craig,
I would like to further propose on this idea - create a
MessageResourcesInterface that various implementations can be created for. Four
standard implementations could ship with struts: XML, Properties, and database.
I could see that some people may find it easier, or more practical to store
their messages in a database.
There would need to be a mapping in a struts configuration file. Something
like:
<messageresource name="en_us" source="messages.xml"
class="org.apache.struts.XMLMessageResource" />
or
<messageresource name="en_us" source="messages.properties"
class="org.apache.struts.PropertiesMessageResource" />
or
<messageresource name="en_us" source="jdbcpool_connection_name"
table="MessageTable"
class="org.apache.struts.DatabaseMessageResource" />
This would also give the developer an option to create their own if if they
implemented the MessageResourcesInterface.
Just my 0.02 worth.
Evan Vaala
P.S. I would also like to see similiar interfaces and implementations for
templates and actions. However a properties resource may be too simplistic for
templates and actions. I do like the Pet Store "screendefinitions.xml" for
templates and "requestmappings.xml". From what I can tell,
"requestmappings.xml" is similiar to struts action-mappings found in
struts-config.xml samples.
One thing that I like in JPS's requestmappings.xml is that you can direct the
url directly to a screen definition, or the url can be directed to a request
handler first, which I believe to be synonymous with structs action mapping.
Can struts also map a url directly to a screendefinition/template, or does it
only map actions?
Thanks!
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Michael Westbay <we...@seaple.icc.ne.jp>.
M騁ras-san wrote:
> - Add localization information in the struts-config.xml file. If one wants
> to overide ResourceBundle file search, we could have your proposed syntax
> with adapted rules.
> <struts-messages default="en_US">
> <locale locale="en_US"
> xml:lang="en-US"
> file="MyApp.en" />
> <locale locale="es"
> xml:lang="es"
> file="MyApp.es" />
> </struts-messages>
To this idea, I would add encoding="euc-jp" to the locale tag. Then write a
LocalizedResourceBundle which will take the file encoding and automatically
convert from it to Unicode on getString().
I've written such a LocalizedResourceBundle before which, when initialized,
looks for the BundleEncoded key within itself to decide which, if any,
encoding to use. That way I can manage my properties files in a text editor
friendly format.
> - That way, an application can ask the configuration which languages are
> supported. You can write a <selectLanguage /> tag that lists the languages
> and change the default locale for the user.
I really like that idea. But what language will the SELECT text be in? I've
generally found that one should have a language selector in 7-bit ASCII or
as an image so that people who don't have support for the character set of
the page can at least display the language selector.
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Pierre Métras <ge...@sympatico.ca>.
Hi Craig,
> How about, as a compromise, we emulate the java.util.ResourceBundle family
and
> have it accept input information either way (properties files or XML
files)?
> This would be pretty simple to implement.
>
> The reason for this is that I've heard just as many complaints about the
> property file format, especially in having to remember to run native2ascii
on
> them -- to say nothing of some translators that screw up the format with
their
> text editors.
The proposed solution seems to me that you want to replace "native2ascii" by
a "property2xml" processor (and don't forget to write the "xml2property"
corresponding to the already existing "ascii2native").
I don't know which platform the translators you work with are using, but
finding a text editor using a local character set is still easier than a
Unicode, or an XML one... And remember that the majority of translators
don't use high-end workstations.
Do you think translators will use XML editors? They will just continue using
their word processor and screw up your XML file. And finding a forgotten /
character to close a tag can have much more impact and be time losing that
forgetting to run native2ascii.
You suggested in another post to run a script to "concatenate" (or include)
different translated xml files. Don't you think that this solution is better
applied to the native2ascii problem? And I can tell you that concatenating
property files is a lot easier than concatenating XML fragment files ;-)
What are the present benefits of Message Bundles (that's not Struts
specific)?
- They use a simple syntax, and you can explain it in 2 minutes to a new
translator.
- This file format/syntax is used by many other softwares, even tomcat!;-)
(they are in the place from many years...). So generally the 2 minutes
briefing of the translator is not necessary...
- Information is not context sensitive. You can decide how to order the
elements in the file, either lexicographically by key (like a dictionnary),
or by module/class access, or first-in-first-out to track changes.
- They must contain ISO-8859-1 text, so you can manage them with the
majority of tools presently available, even in old databases with ASCII-7
support.
- The "native2ascii" and "ascii2native" tools allows loss-less convertion
form native format to ISO-8859-1.
- They can handle *big* block of text, and you don't have to manage special
characters (like ", <, > or />). Due to their simple syntax, breaking a line
rarely introduce non wanted blank space.
- They are small (ie they don't introduce redundant non usefull
information).
Apart from the serialization problem on *certain* servlet containers, I can
add:
- They support a well defined naming, so you don't need to open the file to
know the language used.
- Based on that file naming, there's a well defined path to propose to the
user a language corresponding to his request
(http://java.sun.com/j2se/1.3/docs/api/java/util/ResourceBundle.html).
At the present time, localization data for applications don't need to
associate other information attached to each message data. At the speed
application and pages are changing on the Web, translators don't need to
keep comments or references attached with each message translation (and in
the case they would, they can add #comments).
A problem with property files in "exotic" languages is that you can't
distinguish content between russian and corean, if you look either at the
local characters file encoding or the "native2ascii" processed file. But
your proposal doesn't give a solution for that problem either. And with the
property file naming, you can have some hints on the language used...
That's the reason I think your proposal of XML for Struts localized string
is useless. I would have a different opinion if we need to exchange
translated document (not data!) between translators research centers or
offices, and manage bibliographical references and annotations, where XML
(and of course SGML) would have a role to play. But not here...
What are the benefits of your suggested syntax?
Wait a few hours that people in non-US time zone, in countries where locale
management is a real need, have a look at it, and I think my vehement
reaction will not be alone.
Now, to be constructive on the subject.
I don't think Struts has a need for 2 message bundles file formats. But what
Struts needs is
(1) to solve the problem with serialization (and I don't think it's
ResourceBundle specific, so it can appear with other classes, in other
applications, on other servers...)
(2) offer a better support for internationalization.
Ways to solve (1):
- (General) How BEA suggests to solve it when you need to share an object,
on the source of which you don't have control?
- (Future general) Amend the servlet specification document to completely
specify the accepted behavior. And what about Java2 1.4 for ResourceBundle?
- (Local to Struts) Write a MessageBundle class that supports the
Serializable interface, or less clean (but that's a problem where not
everybody is concerned) don't cache messages, so you don't need to have an
application scope object. We can add an option attribute to activate this
behavior for the BEA users meanwhile ;-)
Ways to solve (2)
- Add localization information in the struts-config.xml file. If one wants
to overide ResourceBundle file search, we could have your proposed syntax
with adapted rules.
<struts-messages default="en_US">
<locale locale="en_US"
xml:lang="en-US"
file="MyApp.en" />
<locale locale="es"
xml:lang="es"
file="MyApp.es" />
</struts-messages>
- That way, an application can ask the configuration which languages are
supported. You can write a <selectLanguage /> tag that lists the languages
and change the default locale for the user.
I'm in a hurry. More comments tonight.
Pierre Métras
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Pierre Métras wrote:
> Hi again,
>
> To temper my previous post.
> Yes, you can define org.apache.struts.MessageBundle to correct the
> serialization problem under some servlet containers.
> No, don't change the syntax of the message files.
>
How about, as a compromise, we emulate the java.util.ResourceBundle family and
have it accept input information either way (properties files or XML files)?
This would be pretty simple to implement.
The reason for this is that I've heard just as many complaints about the
property file format, especially in having to remember to run native2ascii on
them -- to say nothing of some translators that screw up the format with their
text editors.
>
> Pierre Métras
Craig McClanahan
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Pierre Métras <ge...@sympatico.ca>.
Hi again,
To temper my previous post.
Yes, you can define org.apache.struts.MessageBundle to correct the
serialization problem under some servlet containers.
No, don't change the syntax of the message files.
Pierre Métras
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Michael Westbay <we...@seaple.icc.ne.jp>.
McClanahan-san wrote:
> For editing convenience, it would be easy to maintain a separate file for each
> language, and then concatenate them together in your build script.
I have a feeling that that won't work when the files are written in different
character encodings. This generally isn't a problem with European languages,
but CJK (Chinese, Japanese, Korean) all have character encodings that
overlap. Even with Chinese and Japanese, there are multiple ways of encoding
character set within the same langauge - all mutually incompatible. Such a
file would be impossible to edit. Multiple
<?xml version="1.0" encoding="ISO-2022-JP" ?>
lines would be required, or a mechanism whereby the character encoding could
be changed on the fly for each
<locale locale="en_US" xml:lang="ja-JP" xml:encoding="ISO-2022-JP">
Hey, that's an interesting idea. But should the resulting file with several
encodings ever be opened by a text editor, one can expect a great deal of
corrupt data.
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Frank Starsinic wrote:
> This is a good idea. I'm wondering. Is there a performance hit having all
> the resource strings in one XML file or
> would it be better to have a seperate file for each locale?
>
There is a hit to parse the messages when you first create the new object --
this corresponds to the current hit to load in the various properties files.
After that, everything is cached in memory and accessed via HashMaps so that it
is pretty fast. This is true for the current implementation as well -- the only
difference is that it loads the resources for a particular Locale only when you
ask for it.
As a side benefit, we can avoid the class loader bug that currently plagues
Orion 1.4 (workaround: extract the properties files out of struts.jar and put
them under WEB-INF/classes).
For editing convenience, it would be easy to maintain a separate file for each
language, and then concatenate them together in your build script.
>
> thanks,
> frank
>
Craig McClanahan
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Laird Nelson <lj...@unix.amherst.edu>.
----- Original Message -----
From: "Frank Starsinic" <fr...@projectarena.com>
> This is a good idea. I'm wondering. Is there a performance hit having
all
> the resource strings in one XML file or
> would it be better to have a seperate file for each locale?
I echo this; it would be nice to be able to farm out resource files to,
say, separate translation teams in different locations.
Can you (Craig) emulate or at least work off the (IMHO rather nice) way
that PropertyResourceBundle looks up resources automatically? It's nice
being able to just bash out resources as they're needed.
Cheers,
Laird
--
W: laird.nelson@time0.com / P: ljnelson@unix.amherst.edu
http://www.amherst.edu/~ljnelson/
Good, cheap, fast: pick two.
Re: Proposed Solution to Non-Serializable MessageResources Class
Posted by Frank Starsinic <fr...@projectarena.com>.
This is a good idea. I'm wondering. Is there a performance hit having all
the resource strings in one XML file or
would it be better to have a seperate file for each locale?
thanks,
frank
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Cc: <st...@jakarta.apache.org>
Sent: Friday, December 08, 2000 9:41 AM
Subject: Proposed Solution to Non-Serializable MessageResources Class
> As Struts get used in more and more environments, we run into the bleeding
edges
> once in a while. One place that was recently discovered is that some
> application servers insist on application scope beans (i.e. servlet
context
> resources) being Serializable under certain circumstances. (Note -- this
is not
> a spec requirement issue; it is a container-specific restriction).
>
> The Struts example application is not going to work in such an
environment,
> because of the way that the pseudo-database is architected and used.
However, a
> more serious issue is that the MessageResources class (used to store the
> application resources for your internationalized message strings) is not
> Serializable, and it cannt be made so -- because the underlying
> java.util.ResourceBundle family of classes are not Serializable.
>
> There is an additional headache that is caused by the current
implementation --
> it relies on loading properties files to initialize the message strings.
For
> languages that use ISO-8859-1 character sets, that is pretty easy -- just
edit
> the files with a text editor and you are done. For other character sets,
> however, you have to remember to run "native2ascii" on the properties
files
> after editing.
>
> To deal with both of these problems, I propose to create a new
MessageBundle
> class, which will be Serializable. The external API will be very much
like
> MessageResources, so minimal code changes will be required. The key
difference
> will be in how it is initialized. I propose to load the messages from an
XML
> file (so that you can declare the character set, and use an XML-based
editor).
> For the Struts example app, the file would look like this:
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
>
> <!DOCTYPE struts-messages PUBLIC
> "-//Apache Software Foundation//DTD Struts Messages 1.0//EN"
> "http://jakarta.apache.org/struts/dtds/struts-messages_1_0.dtd">
>
> <struts-messages default="en_US">
>
> <!-- Messages for US English -->
> <locale locale="en_US" xml:lang="en-US">
> <message name="button.cancel" value="Cancel"/>
> <message name="button.confirm" value="Confirm"/>
> ...
> </locale>
>
> <!-- Messages for Spanish -->
> <message name="button.cancel" value="..."/>
> <message name="button.confirm" value="..."/>
> ...
> <locale locale="es" xml:lang="es">
> ...
> </locale>
>
> </struts-messages>
>
> The existing mechanism (MessageResources) would remain available in 1.0
for
> backwards compatibility, but would be deprecated in favor of MessageBundle
in
> future versions.
>
> What do you think?
>
> Craig McClanahan
>
>