Ticket #129 (new enhancement)
Solar_Locale->getCode() generates non RFC1766 compliant output.
| Reported by: | umka.dk@… | Owned by: | pmjones |
|---|---|---|---|
| Priority: | minor | Component: | code |
| Keywords: | Solar_Locale, ISO 3166, ISO 639, RFC1766 | Cc: |
Description
Just spent a day trying to integrate Solar_Locale functionality into a multi-lingual app and noticed that Solar_Locale->getCode() returns a language locale string a bit different to that defined by RFC1766. This makes it a bit awkward to use with XHTML's lang and xml:lang attributes as W3C expect a RFC1766 compliant value.
From what I could workout, Solar_Locale->getCode() returns a locale of the following format:
[language code as defined by ISO 639 alpha-2]_[country code as defined by ISO 3166 alpha-2]
while RFC1766 and thus XHTML expects:
[language code as defined by ISO 639 alpha-2]-[country code as defined by ISO 3166 alpha-2]
The only difference between the two string is the separator, one uses an "_" [underscore] while the other one uses a "-" [dash].
I realise that Solar_Locale->getCode() is probably used to determine the name of the file that contains all current locale strings so it is unlikely that the output of the function and thus the filenames will be changed to use a "-" [dash] instead of an "_" [underscore]. However it would be very handy if an assistive function getLanguageCode() which returns language code as defined by ISO 639 alpha-2 was added to Solar_Locale! This way getLanguageCode() combined with getCountryCode() could be used to build language locale string in the desired/any format.
Thanks,
Dmytro
PS: Also, as pointed out by PACE on IRC, as a result of the above behaviour Solar locale files are the only files in the entire framework where "_" [underscore] is used as part of the filename and not as a directory separator.
