Opened 15 years ago

Closed 14 years ago

#49 closed defect (fixed)

Detect locale properly

Reported by: Dmitry A. Kuminov Owned by: Dmitry A. Kuminov
Priority: blocker Milestone: Qt Beta 5
Component: QtCore Version: 4.5.1 Beta 1
Severity: Keywords:
Cc:

Description

String conversion functions depend on the locale. Currently, the locale is derived (as on Linux) from the LC_* and LANG environment variables. However, LANG may absent from the environment on OS/2 systems in which case we should derive the locale from the current code page of the process.

The second problem to solve is the ru_RU locale. According to the standard, if the code page number is missing from the locale definition, it's 8859-5 for ru_RU but it's obviously makes no sense on OS/2 where it should be cp866 if not specified explicitly.

Change History (8)

comment:1 Changed 15 years ago by Dmitry A. Kuminov

I committed the temporary hack for ru_RU in r135 since it's annoying to specify ru_RU.cp866 all the time.

In any case, the full LANG specification (language_COUNTRY.codepage) will override everything and Qt will operate in the specified codepage.

comment:2 Changed 15 years ago by Dmitry A. Kuminov

Priority: majorblocker

A must for the GA.

comment:3 Changed 15 years ago by Dmitry A. Kuminov

My previous plan was to map the system code page (IBMnnn) to a standard encoding used by QTextCodec (such as "iso-8859-1", "cp866", "koi8-r" and so on). However, there is no guarantee that all IBM code page numbers (as returned by DosQueryCp?) have an equivalent standard encoding understood by QTextCodec.

For this reason, if no LANG is set or if the encoding part is missing in LANG, we will use the so-called system encoding (named "System") which will use system routines (the ULS (Uni*) API provided by <unidef.h>) to convert between Unicode and whatever the system code page is. The similar approach is used on Windows and even on Linux actually.

For this, I will have to implement a special QTextCodec bound to the "System" name.

comment:4 Changed 14 years ago by Silvan Scherrer

Milestone: Qt GAQt Beta5

comment:5 Changed 14 years ago by Dmitry A. Kuminov

Owner: set to Dmitry A. Kuminov
Status: newaccepted

comment:6 Changed 14 years ago by Dmitry A. Kuminov

The special "System" codec is implemented in r349. It is always the default codec for any locale which is based on the current system code page. This completely obsoletes the old Linux-like approach (where the <encoding> part of the LANG specification in the environment is used to define a codec for the locale) so the latter is no longer supported. The LANG environment variable now only defines the country and the language for Qt to pick up regional settings and to use in UI translations.

Dropping of the explicit encoding specification should not make any harm because OS/2 is a single 8-bit code page system and specifying an encoding that OS/2 isn't prepared for is quite useless (there may be no necessary fonts and the file system will still be limited to the original system encoding anyway).

The only way to influence the 8-bit (or DBCS) code page Qt works in is to use the 'chcp' command to change the code page of the current process. Note that this command will only allow to set a codepage that OS/2 supports (some OS/2 locales have simultaneous support two code pages).

comment:7 Changed 14 years ago by Dmitry A. Kuminov

Silvan, please check if the encoding (title bars, window text, file names) works for you w/o setting the LANG variable. I will also ask komh to test in #102.

comment:8 Changed 14 years ago by Dmitry A. Kuminov

Resolution: fixed
Status: acceptedclosed

As komh reports that it works for Korean, and it also works for Russian, I suppose it will work for all other languages too.

Note: See TracTickets for help on using tickets.