There is also Internationalization of domain names, and ultimately URL's
http://www.faqs.org/rfcs/rfc3492.html
-Rob
yasuhiko yoshikawa wrote:
I do not think always passing UTF-8 as character encoding type is rightI am glad you spoke up,
behavior. As far as I can tell, there is no such requirement to mandate(or
even recommend) UTF-8 as character encoding type in the HTML4
specification (and relevant RFCs).
A while ago, I submitted a patch that enables the encoder to take
character encoding name as second parameter. I see no reason why the
character encoding is done with UTF-8.
We need (1 or more) an Japanese/Asian/Russian/Arabic Struts Committers, because they will have supporting the i18
in their best interest.
If an Asian/Russian/Arabic developer(s) started making regular contributions,
then after a while(3 - 9 months) we would know that that person would be a valuable committers,
and they might be nominated.
The qualities that would increase the likely hood that I would nominate
them as a Committer are:
through : (attach diff patches against Nightly builds) (Test patches throughly)
persistent (make noise) so as to make sure patches are applied.
semi-fluent: in written english (able to clearly describe a problem, and solution in written english)
skelling (Spelling ;-) ) is not important !
flexible : willing to discuss different approaches with other developers/committers,
and arrive at a good solutions regardless of whose Ideas they are.
centered :They know that its ok to make mistakes, and learn from them.
We normally like to gradually add new committers.
Do you know of anyone that might want to step up ?
What is the Bug report number ? Have been tested by Japanese users ?
These could be rolled into the 1.2.1 release, which could cut be made to address this problem.
Using UTF-8 as character encoding type works only if the html documents sent from the application are encoded in UTF-8, but many i18n applications use 'native' character encodings (like Shift_JIS, Big5, EUC-KR etc) instead, for variety of reasons.
The issue was recently discussed on the mailing list of Japanese struts user's. And we found that, for example, html:link tag's parameter populating functionality has been unusable for many of us because it ignores the response's character encoding and uses UTF-8 to get the bytes for url encoding.
--- Robert Leland <[EMAIL PROTECTED]> wrote:
Pierre Maury wrote:
The patch would need to be usable with different encoding types.
Why? The Java 1.3 version doesn't accept an encoding type and we always pass UTF-8 to the 1.4 version.
This memory storage seems like a small price to pay for the improvement,
but I would like to hear from other commiters.
I'm not a big fan of this because there are much bigger performance optimizations to be had in other layers of a Struts app but I won't stop anyone from applying a clear and *tested* optimization.
David
-Rob
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
