On Sun, 13 May 2001, Alec Yu wrote:
>
> The servlet/JSP specifications made me feel that:
> they only aimed at L10N problems, not I18N problems.
>
I can understand your concerns. However, the correct forum for addressing
them is the spec feedback addresses, rather than here:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Tomcat implements the specifications -- it does not define them. Both
specs are in "Proposed Final Draft 2" state right now, so it is getting
close to being too late to make any changes for the 2.3/1.2 versions, but
you would still want to make your concerns known.
As a member of the expert group that defined these specs (in the Java
Community Process, this is being managed by Java Specification Request
#53), I can tell you that internationalization concerns *were* addressed,
and several adjustments were made to servlet 2.3 and JSP 1.2 in order to
improve I18N support. Given the way that HTTP is defined, and the
lackluster support for correct implementations of HTTP in many browsers,
there are no perfect answers.
> [snip] I just feel curious, why the standard specifications cost
> people here so much maintainance time, just because they don't allow
> us to specify default encodings for compilation time, input time and
> runtime once only in some few configuration files, but force us to
> specify them in every pages & every servlet code. Meanwhile, in this
> manner, as our products co-operate with those code/pages come from
> other people, we have to ask their developers: May you send us a copy
> of source code/pages? May you take concern on some character encodings
> other than your own using one? May you ......
>
Sounds like great comments for the spec feedback addresses.
> What an I18 solution looks like this. Sure, UTF-8 greatly eased the
> problems on input & output, but it does not solve the maintainance
> problem on other people's code/pages. And, not everybody willing to
> take UTF-8 as their default encoding, because only few tools are being
> able to edit UTF-8 documents (Let's forget M$ FrontPage, it surely
> with poor support to JSPs; Dreamweaver is great, but lack of UTF-8
> support; Amaya has poor DBCS support, not mentioning JSP; even among
> plain text editors, there are few suppoting UTF-8).
>
Yep ... there is no perfect solution :-).
> You know, lots of, if not most, JSP pages around the world come with
> no page contentType directives, many servlets do not even specify
> their own character encoding, or do not provide an option in some
> configuration files to do so. The real nightmare is not in our own
> servlets/pages, but in other people's.
>
IMHO that is because most page and servlet authors haven't given
sufficient consideration to I18N. The ability to set character encoding,
for example, has been there since the very early days of servlets.
> ps. I am a newbie, not knowing how to make code submission to Apache
> projects. I installed JAMES 1.2.1 on my personal web site, and found
> it garbaged 8-bit MIME mail headers. I fixed it, and put SMTP AUTH
> LOGIN function into its SMTP handler. (such that, you may put a
> matcher to allow mail relay by checking accounts, not by IP). I'd like
> to contribute such a feature to JAMES. What should I do without join
> Apache's membership?
>
>
The guidelines for code contributions to all Jakarta projects can be found
on the Jakarta web site, starting at this page:
http://jakarta.apache.org/site/getinvolved.html
I would imagine that they will welcome your contributions.
Craig
