Opened 10 years ago

Closed 9 years ago

#49 closed defect (fixed)

Detect locale properly

Reported by: dmik Owned by: dmik
Priority: blocker Milestone: Qt Beta 5
Component: QtCore Version: 4.5.1 Beta 1
Severity: Keywords:


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 10 years ago by dmik

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 10 years ago by dmik

  • Priority changed from major to blocker

A must for the GA.

comment:3 Changed 10 years ago by dmik

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 9 years ago by diver

  • Milestone changed from Qt GA to Qt Beta5

comment:5 Changed 9 years ago by dmik

  • Owner set to dmik
  • Status changed from new to accepted

comment:6 Changed 9 years ago by dmik

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 9 years ago by dmik

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 9 years ago by dmik

  • Resolution set to fixed
  • Status changed from accepted to closed

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.