You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Eugen Kuleshov <an...@hco.kollegienet.dk> on 2000/02/16 23:37:56 UTC
request for comments about Multilinguage JSP
Hello!
I would like to see any comments about implementing support for
Multilanguage Java Server Pages in JSP engine.
Apache have module named mod_negotiation. This module use
accept-language heager http variable and negotiate request to
corresponding file. ie index.html.en, index.html.de, etc...
It will be great to add same functionality to JSP engine. For example
we have these pages:
index.en.jsp
index.de.jsp
index.it.jsp
One of them marked in config as default page (if no accepted
languages).
For every request JSP must check accept-language in http headers and
call corresponding jsp file. I think it's not so hard to add this
functionality to jsp class loader.
Any comments.
Thank you.
Eugen Kuleshov.
PS: maybe someone can forward it to jsp-interests list?
Re: request for comments about Multilinguage JSP
Posted by Jose Alberto Fernandez <jo...@us.oracle.com>.
Ups, please replase "locale" for "local" everywhere in my respose.
Jose Alberto Fernandez wrote:
> Anna Stepanova wrote:
>
> > Jose Alberto Fernandez wrote:
> >
> > > I would suggest using the same mechanism as resource bundles.
> > > That is:
> > >
> > > index_en.jsp
> > > index_en_US.jsp
> > >
> > > and so on and so forth. This allows a lot of flexibility and the only
> > > thing required is for a way for the webserver to decide the locale to
> > > us.
> >
> > What the difference bewtween index_en.jsp and index.en.jsp ?
> > You can use system resource loader or class loader here. I think
> > better if it will be look like web server files for negotiation.
> >
>
> In principle there is no difference, except that the resource bundle
> notation has provisions not only for language but for regional differences
> and more. It also defines a specific algorithm for finding the right version
> to use. So is a firm clear and Java known framework for dealing with
> language differences.
>
> I am open to discussions on the merits of that framework, if it is not
> suitable then it should not be used, but I think is a reasonable starting
> point.
>
> >
> > > By the way, the need is not only for JSPs but I can see the same need
> > > for
> > > Servlets in general. Of course it is upto users to decide what to use.
> >
> > I have implemented this feature for GNUJSP (but not released it yet).
> > I don't think that this feature needs for servlets. There are better
> > way to use resources. Like this:
> >
>
> [snipped very nice code]
>
> Here we go again, trying to tell people how to write their programs instead
> of giving options and let people decide what is best for them. I understand
> how to manage resource bundles, but what I am reffering to is the ability to
> call completely different Servlets (not just different strings on the same
> servlet) given the language local of the client. So the code may be
> completely different, the look and feel may be different, etc.
>
> One could envision something like that in the servlet container. You would
> need a way to plug-in locale mapping code from request, for a given
> application. And then the container just need to be able to select the
> correct servlet given the local.
>
> One way to do this is by using the ServletNames name space. In Servlet 2.2
> you associate virtual paths with a particular Servlet name, MyServlet, ( a
> symbolic name for your servlet com.me.MyServlet). In the local mapped case
> the association is with a family of names: MyServlet_en_US, MyServlet_en,
> MyServlet, etc.. Notice this does not envolve ClassLoaders at all. Is just
> the name resolution mechanism of the Servlet container and it can be as
> efficient as what we have today.
>
> We should also need a way to determine the local used to select a particular
> Servlet so that you may do things programatically. JSPs then can do their
> Multilingual processing based on this ground work.
> I am sure it will make things easier and more consistent.
>
> Jose Alberto
> --
> ------------------------------------------------------------------------
> Jose Alberto Fernandez 500 Oracle Parkway, M/S 9op4
> Development Manager Redwood Shores, CA 94065
> ORACLE Corp. Phone: (650) 506-8830
> Java Products Group Fax: (650) 506-7303
> Languages & Obj-Relational Tech Email: jofernan@us.oracle.com
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
------------------------------------------------------------------------
Jose Alberto Fernandez 500 Oracle Parkway, M/S 9op4
Development Manager Redwood Shores, CA 94065
ORACLE Corp. Phone: (650) 506-8830
Java Products Group Fax: (650) 506-7303
Languages & Obj-Relational Tech Email: jofernan@us.oracle.com
Re: request for comments about Multilinguage JSP
Posted by Eugen Kuleshov <an...@hco.kollegienet.dk>.
Jose Alberto Fernandez wrote:
> > > I would suggest using the same mechanism as resource bundles.
> > > That is:
> > >
> > > index_en.jsp
> > > index_en_US.jsp
> > >
> > > and so on and so forth. This allows a lot of flexibility and the only
> > > thing required is for a way for the webserver to decide the locale to
> > > us.
> >
> > What the difference bewtween index_en.jsp and index.en.jsp ?
> > You can use system resource loader or class loader here. I think
> > better if it will be look like web server files for negotiation.
> >
>
> In principle there is no difference, except that the resource bundle
> notation has provisions not only for language but for regional differences
> and more. It also defines a specific algorithm for finding the right version
> to use. So is a firm clear and Java known framework for dealing with
> language differences.
Of course you can use regional differences too. Just look at your
netscape or MSIE language properties. You can find: en-US, etc strings.
I just use it for find index.en-US.jsp files (or if web server have
en-US then user will get index.en.jsp...)
> Here we go again, trying to tell people how to write their programs instead
> of giving options and let people decide what is best for them. I understand
> how to manage resource bundles, but what I am reffering to is the ability to
> call completely different Servlets (not just different strings on the same
> servlet) given the language local of the client. So the code may be
> completely different, the look and feel may be different, etc.
right.
> One could envision something like that in the servlet container. You would
> need a way to plug-in locale mapping code from request, for a given
> application. And then the container just need to be able to select the
> correct servlet given the local.
>
> One way to do this is by using the ServletNames name space. In Servlet 2.2
> you associate virtual paths with a particular Servlet name, MyServlet, ( a
> symbolic name for your servlet com.me.MyServlet). In the local mapped case
> the association is with a family of names: MyServlet_en_US, MyServlet_en,
> MyServlet, etc.. Notice this does not envolve ClassLoaders at all. Is just
> the name resolution mechanism of the Servlet container and it can be as
> efficient as what we have today.
>
> We should also need a way to determine the local used to select a particular
> Servlet so that you may do things programatically. JSPs then can do their
> Multilingual processing based on this ground work.
> I am sure it will make things easier and more consistent.
I completely share your opinion.
Eugen Kuleshov.
Re: request for comments about Multilinguage JSP
Posted by Jose Alberto Fernandez <jo...@us.oracle.com>.
Anna Stepanova wrote:
> Jose Alberto Fernandez wrote:
>
> > I would suggest using the same mechanism as resource bundles.
> > That is:
> >
> > index_en.jsp
> > index_en_US.jsp
> >
> > and so on and so forth. This allows a lot of flexibility and the only
> > thing required is for a way for the webserver to decide the locale to
> > us.
>
> What the difference bewtween index_en.jsp and index.en.jsp ?
> You can use system resource loader or class loader here. I think
> better if it will be look like web server files for negotiation.
>
In principle there is no difference, except that the resource bundle
notation has provisions not only for language but for regional differences
and more. It also defines a specific algorithm for finding the right version
to use. So is a firm clear and Java known framework for dealing with
language differences.
I am open to discussions on the merits of that framework, if it is not
suitable then it should not be used, but I think is a reasonable starting
point.
>
> > By the way, the need is not only for JSPs but I can see the same need
> > for
> > Servlets in general. Of course it is upto users to decide what to use.
>
> I have implemented this feature for GNUJSP (but not released it yet).
> I don't think that this feature needs for servlets. There are better
> way to use resources. Like this:
>
[snipped very nice code]
Here we go again, trying to tell people how to write their programs instead
of giving options and let people decide what is best for them. I understand
how to manage resource bundles, but what I am reffering to is the ability to
call completely different Servlets (not just different strings on the same
servlet) given the language local of the client. So the code may be
completely different, the look and feel may be different, etc.
One could envision something like that in the servlet container. You would
need a way to plug-in locale mapping code from request, for a given
application. And then the container just need to be able to select the
correct servlet given the local.
One way to do this is by using the ServletNames name space. In Servlet 2.2
you associate virtual paths with a particular Servlet name, MyServlet, ( a
symbolic name for your servlet com.me.MyServlet). In the local mapped case
the association is with a family of names: MyServlet_en_US, MyServlet_en,
MyServlet, etc.. Notice this does not envolve ClassLoaders at all. Is just
the name resolution mechanism of the Servlet container and it can be as
efficient as what we have today.
We should also need a way to determine the local used to select a particular
Servlet so that you may do things programatically. JSPs then can do their
Multilingual processing based on this ground work.
I am sure it will make things easier and more consistent.
Jose Alberto
--
------------------------------------------------------------------------
Jose Alberto Fernandez 500 Oracle Parkway, M/S 9op4
Development Manager Redwood Shores, CA 94065
ORACLE Corp. Phone: (650) 506-8830
Java Products Group Fax: (650) 506-7303
Languages & Obj-Relational Tech Email: jofernan@us.oracle.com
Re: request for comments about Multilinguage JSP
Posted by Anna Stepanova <an...@hco.kollegienet.dk>.
Jose Alberto Fernandez wrote:
> I would suggest using the same mechanism as resource bundles.
> That is:
>
> index_en.jsp
> index_en_US.jsp
>
> and so on and so forth. This allows a lot of flexibility and the only
> thing required is for a way for the webserver to decide the locale to
> us.
What the difference bewtween index_en.jsp and index.en.jsp ?
You can use system resource loader or class loader here. I think
better if it will be look like web server files for negotiation.
> By the way, the need is not only for JSPs but I can see the same need
> for
> Servlets in general. Of course it is upto users to decide what to use.
I have implemented this feature for GNUJSP (but not released it yet).
I don't think that this feature needs for servlets. There are better
way to use resources. Like this:
public void doGet( HttpServletRequest req, HttpServletResponse res) {
ResourceBundle resources = getResourceForLocaleFromHeaders( req,
"yourResources");
...
out.print( resources.getString(
yourResources.SOME_STRING_RESOURCE));
}
For better performance you must have resources pool for different
locales.
Resources must look like this:
--------------------
import java.util.ListResourceBundle;
public class yourResources extends ListResourceBundle {
public Object[][] getContents() {
return contents;
}
static final String SOME_STRING_RESOURCE = "someString";
static final String ANOTHER_STRING_RESOURCE = "someString";
static final Object contents[][] = {{ SOME_STRING_RESOURCE, "This is
some string from resources"},
{ ANOTHER_STRING_RESOURCE, "This is another string from
resources"}};
}
etc.
Eugen Kuleshov.
Re: request for comments about Multilinguage JSP
Posted by Anna Stepanova <an...@hco.kollegienet.dk>.
Jose Alberto Fernandez wrote:
> I would suggest using the same mechanism as resource bundles.
> That is:
>
> index_en.jsp
> index_en_US.jsp
>
> and so on and so forth. This allows a lot of flexibility and the only
> thing required is for a way for the webserver to decide the locale to
> us.
What the difference bewtween index_en.jsp and index.en.jsp ?
You can use system resource loader or class loader here. I think
better if it will be look like web server files for negotiation.
> By the way, the need is not only for JSPs but I can see the same need
> for
> Servlets in general. Of course it is upto users to decide what to use.
I have implemented this feature for GNUJSP (but not released it yet).
I don't think that this feature needs for servlets. There are better
way to use resources. Like this:
public void doGet( HttpServletRequest req, HttpServletResponse res) {
ResourceBundle resources = getResourceForLocaleFromHeaders( req,
"yourResources");
...
out.print( resources.getString(
yourResources.SOME_STRING_RESOURCE));
}
For better performance you must have resources pool for different
locales.
Resources must look like this:
--------------------
import java.util.ListResourceBundle;
public class yourResources extends ListResourceBundle {
public Object[][] getContents() {
return contents;
}
static final String SOME_STRING_RESOURCE = "someString";
static final String ANOTHER_STRING_RESOURCE = "someString";
static final Object contents[][] = {{ SOME_STRING_RESOURCE, "This is
some string from resources"},
{ ANOTHER_STRING_RESOURCE, "This is another string from
resources"}};
}
etc.
Eugen Kuleshov.
Re: request for comments about Multilinguage JSP
Posted by Jose Alberto Fernandez <jo...@us.oracle.com>.
I would suggest using the same mechanism as resource bundles.
That is:
index_en.jsp
index_en_US.jsp
and so on and so forth. This allows a lot of flexibility and the only
thing required is for a way for the webserver to decide the locale to
us.
By the way, the need is not only for JSPs but I can see the same need
for
Servlets in general. Of course it is upto users to decide what to use.
Eugen Kuleshov wrote:
>
> Hello!
>
> I would like to see any comments about implementing support for
> Multilanguage Java Server Pages in JSP engine.
>
> Apache have module named mod_negotiation. This module use
> accept-language heager http variable and negotiate request to
> corresponding file. ie index.html.en, index.html.de, etc...
>
> It will be great to add same functionality to JSP engine. For example
> we have these pages:
>
> index.en.jsp
> index.de.jsp
> index.it.jsp
>
> One of them marked in config as default page (if no accepted
> languages).
> For every request JSP must check accept-language in http headers and
> call corresponding jsp file. I think it's not so hard to add this
> functionality to jsp class loader.
>
> Any comments.
>
> Thank you.
>
> Eugen Kuleshov.
>
> PS: maybe someone can forward it to jsp-interests list?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
Re: request for comments about Multilinguage JSP
Posted by Assaf Arkin <ar...@exoffice.com>.
Eugen Kuleshov wrote:
>
> Assaf Arkin wrote:
>
> > My test case is actually a Servlet which contains only the logic and
> > does not generate a single line of HTML. Everything is done in XSLT, and
> > it rocks.
> >
> > Of course that raises the question, why would one use JSP for?
> >
> > Certainly not for presentation. But when JSP gains XML capabilities, you
> > might find it easier to use existing XML beans from inside an XML page.
> > Your JSP page will in effect invoke beans, glue them together, maybe do
> > some code, maybe not.
> >
> > You will also need to produce some XML for the portion of the
> > information that is static.
>
> Thats right. But it is not the answer on my question and not solve
> problem of multilanguage JSP.
> Other reason for don't use XML/XSLP egine is a speed of request
> processing. "Classical" JSP produced HTML is faster and eat less
> resources. JSP complied in first request and then run like other
> servlets.
Depends on how much you do.
Pier has been working on compiling XML, so you get a Java class, not an
parsed files. Approximately 3x faster.
Internally everything happens through SAX, which are reasonably fast,
even compared to streams.
Simple XSLT transformations are also very fast, and so is the
serialization.
It will never be as fast as present day JSPs, but neither will JSP be as
fast as an Apache module written in C++. But if it's not that much
slower (and people are working hard to make that happen), and it is that
much better, I bet you'll end up using it :-)
arkin
>
> Eugen Kuleshov.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: request for comments about Multilinguage JSP
Posted by Assaf Arkin <ar...@exoffice.com>.
Eugen Kuleshov wrote:
>
> Assaf Arkin wrote:
>
> > My test case is actually a Servlet which contains only the logic and
> > does not generate a single line of HTML. Everything is done in XSLT, and
> > it rocks.
> >
> > Of course that raises the question, why would one use JSP for?
> >
> > Certainly not for presentation. But when JSP gains XML capabilities, you
> > might find it easier to use existing XML beans from inside an XML page.
> > Your JSP page will in effect invoke beans, glue them together, maybe do
> > some code, maybe not.
> >
> > You will also need to produce some XML for the portion of the
> > information that is static.
>
> Thats right. But it is not the answer on my question and not solve
> problem of multilanguage JSP.
> Other reason for don't use XML/XSLP egine is a speed of request
> processing. "Classical" JSP produced HTML is faster and eat less
> resources. JSP complied in first request and then run like other
> servlets.
Depends on how much you do.
Pier has been working on compiling XML, so you get a Java class, not an
parsed files. Approximately 3x faster.
Internally everything happens through SAX, which are reasonably fast,
even compared to streams.
Simple XSLT transformations are also very fast, and so is the
serialization.
It will never be as fast as present day JSPs, but neither will JSP be as
fast as an Apache module written in C++. But if it's not that much
slower (and people are working hard to make that happen), and it is that
much better, I bet you'll end up using it :-)
arkin
>
> Eugen Kuleshov.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: request for comments about Multilinguage JSP
Posted by Eugen Kuleshov <an...@hco.kollegienet.dk>.
Assaf Arkin wrote:
> My test case is actually a Servlet which contains only the logic and
> does not generate a single line of HTML. Everything is done in XSLT, and
> it rocks.
>
> Of course that raises the question, why would one use JSP for?
>
> Certainly not for presentation. But when JSP gains XML capabilities, you
> might find it easier to use existing XML beans from inside an XML page.
> Your JSP page will in effect invoke beans, glue them together, maybe do
> some code, maybe not.
>
> You will also need to produce some XML for the portion of the
> information that is static.
Thats right. But it is not the answer on my question and not solve
problem of multilanguage JSP.
Other reason for don't use XML/XSLP egine is a speed of request
processing. "Classical" JSP produced HTML is faster and eat less
resources. JSP complied in first request and then run like other
servlets.
Eugen Kuleshov.
Re: request for comments about Multilinguage JSP
Posted by Eugen Kuleshov <an...@hco.kollegienet.dk>.
Assaf Arkin wrote:
> My test case is actually a Servlet which contains only the logic and
> does not generate a single line of HTML. Everything is done in XSLT, and
> it rocks.
>
> Of course that raises the question, why would one use JSP for?
>
> Certainly not for presentation. But when JSP gains XML capabilities, you
> might find it easier to use existing XML beans from inside an XML page.
> Your JSP page will in effect invoke beans, glue them together, maybe do
> some code, maybe not.
>
> You will also need to produce some XML for the portion of the
> information that is static.
Thats right. But it is not the answer on my question and not solve
problem of multilanguage JSP.
Other reason for don't use XML/XSLP egine is a speed of request
processing. "Classical" JSP produced HTML is faster and eat less
resources. JSP complied in first request and then run like other
servlets.
Eugen Kuleshov.
Re: request for comments about Multilinguage JSP
Posted by Assaf Arkin <ar...@exoffice.com>.
My test case is actually a Servlet which contains only the logic and
does not generate a single line of HTML. Everything is done in XSLT, and
it rocks.
Of course that raises the question, why would one use JSP for?
Certainly not for presentation. But when JSP gains XML capabilities, you
might find it easier to use existing XML beans from inside an XML page.
Your JSP page will in effect invoke beans, glue them together, maybe do
some code, maybe not.
You will also need to produce some XML for the portion of the
information that is static.
arkin
> Of course this is another way. There I have more control and can
> choice .xsl stylesheet.
> But I'm don't sure about JSP for generating XML content. Where is
> profit there? I think using servlets is better for generating XML
> content. Because XML must contain only data and not contain any visual
> issues.
> Most profit of JSP is a separation of data generation (beans or
> controller servlets) and presentation design issues (html and so on).
>
> Eugen Kuleshov.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: request for comments about Multilinguage JSP
Posted by Assaf Arkin <ar...@exoffice.com>.
My test case is actually a Servlet which contains only the logic and
does not generate a single line of HTML. Everything is done in XSLT, and
it rocks.
Of course that raises the question, why would one use JSP for?
Certainly not for presentation. But when JSP gains XML capabilities, you
might find it easier to use existing XML beans from inside an XML page.
Your JSP page will in effect invoke beans, glue them together, maybe do
some code, maybe not.
You will also need to produce some XML for the portion of the
information that is static.
arkin
> Of course this is another way. There I have more control and can
> choice .xsl stylesheet.
> But I'm don't sure about JSP for generating XML content. Where is
> profit there? I think using servlets is better for generating XML
> content. Because XML must contain only data and not contain any visual
> issues.
> Most profit of JSP is a separation of data generation (beans or
> controller servlets) and presentation design issues (html and so on).
>
> Eugen Kuleshov.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: request for comments about Multilinguage JSP
Posted by Eugen Kuleshov <an...@hco.kollegienet.dk>.
Assaf Arkin wrote:
> My personal opinion is that this practice will erode over time as we
> tend to rely more and more on XML.
>
> Your XML JSP page will produce the information for the page, but not the
> actual text content (or presentation). The text content will come from
> an XSLT stylesheet.
>
> So you'll reuse the same JSP, but apply different stylesheets or
> otherwise embed the language-specific information into the stylesheet.
>
> The XSLT engine hidden behind the JSP page will need to support the
> language (and media type) negotiation, of course.
>
> I do think that having a design patten like:
>
> style.en.xsl
> style.fr.xsl
> style.de.xsl
Of course this is another way. There I have more control and can
choice .xsl stylesheet.
But I'm don't sure about JSP for generating XML content. Where is
profit there? I think using servlets is better for generating XML
content. Because XML must contain only data and not contain any visual
issues.
Most profit of JSP is a separation of data generation (beans or
controller servlets) and presentation design issues (html and so on).
Eugen Kuleshov.
Re: request for comments about Multilinguage JSP
Posted by Eugen Kuleshov <an...@hco.kollegienet.dk>.
Assaf Arkin wrote:
> My personal opinion is that this practice will erode over time as we
> tend to rely more and more on XML.
>
> Your XML JSP page will produce the information for the page, but not the
> actual text content (or presentation). The text content will come from
> an XSLT stylesheet.
>
> So you'll reuse the same JSP, but apply different stylesheets or
> otherwise embed the language-specific information into the stylesheet.
>
> The XSLT engine hidden behind the JSP page will need to support the
> language (and media type) negotiation, of course.
>
> I do think that having a design patten like:
>
> style.en.xsl
> style.fr.xsl
> style.de.xsl
Of course this is another way. There I have more control and can
choice .xsl stylesheet.
But I'm don't sure about JSP for generating XML content. Where is
profit there? I think using servlets is better for generating XML
content. Because XML must contain only data and not contain any visual
issues.
Most profit of JSP is a separation of data generation (beans or
controller servlets) and presentation design issues (html and so on).
Eugen Kuleshov.
Re: request for comments about Multilinguage JSP
Posted by Assaf Arkin <ar...@exoffice.com>.
My personal opinion is that this practice will erode over time as we
tend to rely more and more on XML.
Your XML JSP page will produce the information for the page, but not the
actual text content (or presentation). The text content will come from
an XSLT stylesheet.
So you'll reuse the same JSP, but apply different stylesheets or
otherwise embed the language-specific information into the stylesheet.
The XSLT engine hidden behind the JSP page will need to support the
language (and media type) negotiation, of course.
I do think that having a design patten like:
style.en.xsl
style.fr.xsl
style.de.xsl
would make it easy to support different languages.
arkin
Eugen Kuleshov wrote:
>
> Hello!
>
> I would like to see any comments about implementing support for
> Multilanguage Java Server Pages in JSP engine.
>
> Apache have module named mod_negotiation. This module use
> accept-language heager http variable and negotiate request to
> corresponding file. ie index.html.en, index.html.de, etc...
>
> It will be great to add same functionality to JSP engine. For example
> we have these pages:
>
> index.en.jsp
> index.de.jsp
> index.it.jsp
>
> One of them marked in config as default page (if no accepted
> languages).
> For every request JSP must check accept-language in http headers and
> call corresponding jsp file. I think it's not so hard to add this
> functionality to jsp class loader.
>
> Any comments.
>
> Thank you.
>
> Eugen Kuleshov.
>
> PS: maybe someone can forward it to jsp-interests list?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: request for comments about Multilinguage JSP
Posted by Assaf Arkin <ar...@exoffice.com>.
My personal opinion is that this practice will erode over time as we
tend to rely more and more on XML.
Your XML JSP page will produce the information for the page, but not the
actual text content (or presentation). The text content will come from
an XSLT stylesheet.
So you'll reuse the same JSP, but apply different stylesheets or
otherwise embed the language-specific information into the stylesheet.
The XSLT engine hidden behind the JSP page will need to support the
language (and media type) negotiation, of course.
I do think that having a design patten like:
style.en.xsl
style.fr.xsl
style.de.xsl
would make it easy to support different languages.
arkin
Eugen Kuleshov wrote:
>
> Hello!
>
> I would like to see any comments about implementing support for
> Multilanguage Java Server Pages in JSP engine.
>
> Apache have module named mod_negotiation. This module use
> accept-language heager http variable and negotiate request to
> corresponding file. ie index.html.en, index.html.de, etc...
>
> It will be great to add same functionality to JSP engine. For example
> we have these pages:
>
> index.en.jsp
> index.de.jsp
> index.it.jsp
>
> One of them marked in config as default page (if no accepted
> languages).
> For every request JSP must check accept-language in http headers and
> call corresponding jsp file. I think it's not so hard to add this
> functionality to jsp class loader.
>
> Any comments.
>
> Thank you.
>
> Eugen Kuleshov.
>
> PS: maybe someone can forward it to jsp-interests list?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: request for comments about Multilinguage JSP
Posted by Jose Alberto Fernandez <jo...@us.oracle.com>.
I would suggest using the same mechanism as resource bundles.
That is:
index_en.jsp
index_en_US.jsp
and so on and so forth. This allows a lot of flexibility and the only
thing required is for a way for the webserver to decide the locale to
us.
By the way, the need is not only for JSPs but I can see the same need
for
Servlets in general. Of course it is upto users to decide what to use.
Eugen Kuleshov wrote:
>
> Hello!
>
> I would like to see any comments about implementing support for
> Multilanguage Java Server Pages in JSP engine.
>
> Apache have module named mod_negotiation. This module use
> accept-language heager http variable and negotiate request to
> corresponding file. ie index.html.en, index.html.de, etc...
>
> It will be great to add same functionality to JSP engine. For example
> we have these pages:
>
> index.en.jsp
> index.de.jsp
> index.it.jsp
>
> One of them marked in config as default page (if no accepted
> languages).
> For every request JSP must check accept-language in http headers and
> call corresponding jsp file. I think it's not so hard to add this
> functionality to jsp class loader.
>
> Any comments.
>
> Thank you.
>
> Eugen Kuleshov.
>
> PS: maybe someone can forward it to jsp-interests list?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org