This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9536 - i18n: Prepare UI for localization
Summary: i18n: Prepare UI for localization
Status: NEW
Alias: None
Product: mobileOK Basic checker
Classification: Unclassified
Component: Web interface (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 enhancement
Target Milestone: ---
Assignee: fd
QA Contact: fd
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-16 08:28 UTC by fd
Modified: 2010-04-16 08:28 UTC (History)
0 users

See Also:


Attachments

Description fd 2010-04-16 08:28:15 UTC
The mobileOK Checker library is almost ready for internationalization (see Bug 5764), but the UI is not exactly internationalization-friendly.

A short and possibly non exhaustive list of changes that need to be made on the UI:

- Error messages hardcoded in TesterHttpServlet.java should be defined in a localized resource file.

- Messages in the XSL stylesheets use to create the final report UI (common.xsl, functions.xsl, processByCategory.xsl, mobileokresults2html.xsl, ...) contain strings that need to be localized as well, e.g. following info in:
 http://docstore.mik.ua/orelly/xml/jxslt/ch08_06.htm
 http://www.stylusstudio.com/xsllist/200008/post81310.html

- Same thing with template.xsl

- Same thing with parameters.xsl. One way to do it could be to create one parameters.xsl per language in that case, since most of the file is about providing descriptions. That said, it may be wiser to use the same i18n for everything so that translations only need to provide one and only one localized XSL file.

- The locale template should be defined.

- The mobileOK Checker library unfortunately hides precious information in the messages it returns (marked with PLACEHOLDER_1 and PLACEHOLDER_2 in the definition of the messages). For the UI to extract the messages, it needs to know the regular expression to use. It may be better to: translate all the messages returned by the library right at the UI level, and stick to English when communicating with the mobileOK Checker library... but validation errors returned by the underlying HTML parser would then be in English. A better solution would be to put that precious information in separate tags in the report returned by the library and use the appropriate locale to communicate with the library.