Apache OpenOffice (AOO) Bugzilla – Issue 8252
Using ISO 639 and ISO 3166 for language codes
Last modified: 2013-08-07 15:00:08 UTC
Now OOo uses international phone code for language codes but some countries has more than one language and some languages are used with small country specific versions in more than one country like: - Basque and Spanish in Spain - Portuguese in both Portugal and Brazil just to name a few. Other systems like Linux uses a combination of the two ISO standards: ISO 639 - "Code for the representation of names of languages": http://ftp.ics.uci.edu/pub/ietf/http/related/iso639.txt ISO 3166 - "Codes for the representation of names of countries" http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt You use the language code in lowercase and the two letter country code in uppercase and separate them with a dash. Examples with the above countries: eu-ES Basque in Spain. es-ES Spanish in Spain pt-PT Portuguese in Portugal pt-BZ Portuguese in Brazil In the beginning when a language is translated you should only use the language code. The country code can be added if the language differs. I think it should be a goal for OpenOffice.org 2.0 to use open standards and specifications within the office suite when ever it is possible.
I wholeheartedly agree. But ISO 639 shouldn't be used directly. RFC 3066[1] is a better solution, as this support ISO 639-2 (three-letter) codes when ISO 639-1 (two-letter) codes don't exist. [1] <URL: http://www.ietf.org/rfc/rfc3066.txt >
Note that the links Claus gave for ISO 639-1 and ISO 3166-1 are old and outdated. You can find the latest official versions of these standards here: ISO 639 (-1 and -2) http://www.loc.gov/standards/iso639-2/ ISO 3166-1 http://www.iso.org/iso/en/prods-services/iso3166ma/index.html
*** This issue has been confirmed by popular vote. ***
DL->NF: Would you please takeover?
In general, I agree to use 639-2. The problem is, that the OOo core libraries currently support 639. If whe change the usage of numbers, whe have to find a generic solution whith no need for code or environment changes when intorducing new language. Because of the current 639 restriction, such solution could only be based on 639 instead of 639-2. The change is already planned for a build after 1.1. NF->HJS: Please take over this task
> In general, I agree to use 639-2. As I said, I recommend using RFC 3066 instead of either ISO 639-1 or ISO 639-2. RFC 3066 uses the concept of a 'language tag', which consist of a language code, optionally followed by a country code or other subtag. (The country code only helps to specify the language, and really has nothing to do with countries in this context.) RFC 3066 basically says: 1. Use ISO 639-1 if possible 2. Use ISO 639-2 if no ISO 639-1 code exists 3. USE ISO 3166 country code if necessary, to separate to languages with the same language code, e.g. US English and British English. This means we'll have these codes: sv Swedish en-US US English en-GB UK English (note: not 'en-UK'!) zun Zuni RFC 3066 is also used in most newer standards which uses language codes, e.g. XML. (Older standards, such as HTTP uses RFC 1766, which RFC 3066 updates and obsoletes. Future versions will use RFC 3066.)
just setting the target milestone
Yes - let 2.0 be the target for this. Let OpenOffice.org 2.0 be the first office suite where open standards are used wherever possible. What are the connections to issue 11530? http://www.openoffice.org/issues/show_bug.cgi?id=11530
This task shouldn't be on priority 1, it is not a showstopper for a version. So I set it to P2.
Isn´t this the same as Issue 13735 "RFE: change language/locale identifier to standard convention"?
Yes, issue 13735 is about the same thing, probably that one should be closed as duplicate. @Ause: please set this issue here to status started, as you and Ivo are working on it in CWS mergebuild.
ok...
*** Issue 13735 has been marked as a duplicate of this issue. ***
with the "mergebuild" CWS the main issue, switch from phone code to iso code, has been addressed. although there are still some open points i would like to close this issue and handle subsequent improvements in seperate ones. still open: - support for ISO 639-2 (partially working) - support for language variants - generic language support (some preperations done) feel free to write issues on these.
.