Opened 15 years ago
Closed 15 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 by , 15 years ago
comment:3 by , 15 years ago
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 by , 15 years ago
| Milestone: | Qt GA → Qt Beta5 |
|---|
comment:5 by , 15 years ago
| Owner: | set to |
|---|---|
| Status: | new → accepted |
comment:6 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | accepted → 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.
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.