Version 5 (modified by 17 years ago) ( diff ) | ,
---|
MapGuide RFC 45 - Enhanced Locale Support
This page contains an change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.
Status
RFC Template Version | 1.0 |
Submission Date | Jan 23, 2008 |
Last Modified | Walt Welton-Lair Timestamp |
Author | Walt Welton-Lair, Trevor Wekel |
RFC Status | draft |
Implementation Status | pending |
Proposed Milestone | 2.0 |
Assigned PSC guide(s) | Tom Fukushima |
Voting History | (vote date) |
+1 | |
+0 | |
-0 | |
-1 |
Overview
MapGuide currently supports specifying locales using two-letter language codes from the ISO 639-1 standard, e.g. LOCALE=en. We need to extend this to support locales encoded as [language]-[country], as allowed by the HTTP Accept-Language header (e.g. en-us or en-gb).
Motivation
A two-letter language code is sometimes insufficient to distinguish between the different variations of a language. Chinese is a good example. Using just a two-letter language code ("zh" for Chinese) does not allow a localization distinction between the two languages "Simplified Chinese" and "Traditional Chinese". However using the proposed extended format these would be uniquely encoded as zh-CN and zh-TW.
Proposed Solution
For MapGuide, the HTTP Accept-Language header is a reasonable way to determine the language:
http://www.w3.org/International/questions/qa-accept-lang-locales.
The value of the header is generally encoded as [language]-[country], such as en-us, en-gb, zh-cn, or zh-tw. The country can be upper or lower case. HTTP also accepts just "en" or "zh".
MapGuide platform code (MgUserInformation::SetLocale) will be extended to accept both formats. To simplify the permutations we will convert to a (lower)-(upper) convention, i.e. zh-cn would become zh-CN. Resource filenames would also follow this convention (e.g. "mapguide_zh-CN.res", or just "mapguide_zh.res"). A browser can make a request using either the extended format or the basic format. If the extended format is requested and those resources are not found, then we default to the basic format. In other words, "zh-CN" should default to using "zh" resources if "zh-CN" resources are not present.
Implications
When providing resource files that use the extended format, a default file that uses the basic format must also be provided. This can simply be a copy of one of the extended versions.
Extended format resource files need to use the (lower)-(upper) convention (matters in Linux where filenames are case-sensitive).
Test Plan
Funding/Resources
Supplied by Autodesk.