Original Target Release: coco_dev; Suggested Target Milestone : 5.5

Original submitter: kfrank

Description:
This is seen in current uml griffin but coco will be getting griffin
code later this month so filing in BT also besides filing in bugtraq.

If this is not correct, please let me know how it should be referenced
for coco.

background - uml reports use html files in uml report jar as basis for
some information/labels, but running in solaris ja utf-8 locale, vs ja euc
locale, the localized words do not show correctly in uml web report pages.

from mail exchange with Sheryl:

 Sheryl,

am doing some additonal testing of report, and how mbyte looks in web pages.

And realized, as to needing to change meta charset tag - the problem is that
for unix, there are 3 ja sub locales, and 3 zh sub locales, each with a different
default encoding.

What I do:

1. in ja locale, add mbyte to some lines of web report html template files.
2. add meta charset tag of euc-jp
3. run in ja_JP.UTF-8 locale  (things are mostly ok if run in ja locale, will
discuss
that another time)

For other product html files, like javahelp and new wizard description areas
html files, it was found that if the meta charset was euc-jp or euc-cn,
characters would still display ok or all of those sub locales, plus windows.

I am not sure if this is because javahelp viewer and template description
area in nb allows for it or something else.

But in report viewer, using meta charset, euc-jp, and/or combined with that the
actual characters were created in ja locale (euc-jp  is default encoding
for regular ja solaris locale,) then characters dont display ok in report pages
when running in ja utf-8 locale - the
characters all either incorrect or have random ascii.
(and changing in browser the encoding value from euc-jp to utf8 does not help - then
the characters are not shown ok also with different symptoms.

PROBLEM - there can be only one meta charset value used per localized jar
and files in it, since there is just one localized jar per ja and one for zh,
so that the product code needs to take care of case when user is in
another sub locale of ja or zh or whatever other locale user is in that might have
this situation of sublocales with different encodings (users in any locale can
have diagrams with non ascii, even if they not run in localized locale)

---> I can file something but want to make sure my steps are ok as to your
assumptions first.

Thanks - Ken

Sheryl reply:
hat's indeed the problem, we are using a combination of static templates and
generated runtime contents, any suggestions to address it? Should we use utf-8
instead?