This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | I18N - multibyte in uml reports not display correctly in some ja or zh asian locales | ||
---|---|---|---|
Product: | uml | Reporter: | Ken Frank <kfrank> |
Component: | Reporting | Assignee: | Yang Su <sherylsu> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | sunlit |
Priority: | P2 | Keywords: | I18N |
Version: | 5.x | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Ken Frank
2006-10-14 03:01:58 UTC
happens as well in solaris ja_JP.PCK locale (sjis encoding) think it will happen in the other unix zh_CN locales as well. On windows, even without localized files, on the lower left section All Elements, of the report window, if a classname of a class diagram has multibyte, then this name shows as garbage ascii, even though shows correctly in the main part of the windows. So this is not related to the localized html files, and perhaps needs a separate issue ? But clicking all packages, then in lower left, these class names show mbyte ok. To clarify, user who does not run localized release can still use mbyte in java class,method and other names, as well as in other places in uml diagrams. ken.frank@sun.com The root cause is that we read template in client default encoding, ignoring the fact that there are often multiple encodings associated with one locale which is supplied with one localized jar resource. So the encoding used in html templates must be well defined at implementation time, in our case, it's UTF-8. Report module will read static content in UTF-8 and add generated data, then write out to html files in the same encoding, which is UTF-8. I have implemented logic to take care encoding for reading and writing, tested on Solaris 10 under zh_CN with various encoding. I noticed that in 061113_2 build, a few localized html templates (e.g. overview-summary.html) were done in non-utf8 encoding, that must be corrected by localization team. may be issue 78633 has the same root as this one (was closed as not reproducible) I can't verify this one with ja locale this can be verified now due to changes and fixes from other issues related to uml reports if anything related to uml reports still does not seem correct, please open a new issue on it. ken.frank@sun.com |