"Sergei Butakov" butsergej@yandex.ru wrote:
This patch fix for me two bugs:
- I'm using locale
# export LANG="POSIX" # export LC_CTYPE="ru_RU.CP1251" # export LC_COLLATE="ru_RU.CP1251" with which in many programs some Russian glyphs look wrong or as square. 2. in many programs English/Russian glyphs are ugly.
There are workaround by # export LANG="ru_RU.CP1251" but it not suit for me.
Probably you just need to set LC_MESSAGES to en_US.
On Sunday 16 April 2006 19:04, Dmitry Timoshkov wrote:
Probably you just need to set LC_MESSAGES to en_US.
Do you mean # export LANG="POSIX" # export LC_CTYPE="ru_RU.CP1251" # export LC_COLLATE="ru_RU.CP1251" # export LC_MESSAGES="en_US" ? That's don't work.
Because: There are two wine's variables which define default locale (dlls/ntdll/resource.c): user_lcid and system_lcid. system_lcid defined by first not NULL environment variable LC_ALL, LC_CTYPE, LANG (in that order). If that L* is "POSIX"/"C" or all are not defined then system_lcid set up as en_US. user_lcid defined by LC_ALL, LANG. If that L* ...<same as above>.
Is there reason don't check LC_CTYPE for defining user_lcid? IMHO no. Wine is the only program which don't work properly with my locale (and with other locale which isn't en_US or don't use LC_ALL/LANG variable for that).
--------------------------------- LANG - default value for all LC_* variables. LC_CTYPE - define using character types and encoding. LC_ALL - override all other LC_* variables. --------------------------------- The same trouble with other wine's locale variables: user_ui_language and system_ui_language.
"Sergei Butakov" butsergej@yandex.ru wrote:
Probably you just need to set LC_MESSAGES to en_US.
Do you mean # export LANG="POSIX" # export LC_CTYPE="ru_RU.CP1251" # export LC_COLLATE="ru_RU.CP1251" # export LC_MESSAGES="en_US" ? That's don't work.
I mean LANG="ru_RU.CP1251", LC_MESSAGES="en_US". Your intent is to avoid russian menus and messages, right?
Is there reason don't check LC_CTYPE for defining user_lcid? IMHO no.
There is already a test for LC_CTYPE a couple of lines below your changes.
On Monday 17 April 2006 10:04, Dmitry Timoshkov wrote:
I mean LANG="ru_RU.CP1251", LC_MESSAGES="en_US". Your intent is to avoid russian menus and messages, right?
Not fully. The equivalent of # export LANG="POSIX" # export LC_CTYPE="ru_RU.CP1251" # export LC_COLLATE="ru_RU.CP1251" is # export LANG="ru_RU.CP1251" # export LC_CTYPE="ru_RU.CP1251" # export LC_COLLATE="ru_RU.CP1251" # export LC_NUMERIC="POSIX" # export LC_TIME="POSIX" # export LC_MONETARY="POSIX" # export LC_MESSAGES="POSIX" # export LC_PAPER="POSIX" # export LC_NAME="POSIX" # export LC_ADDRESS="POSIX" # export LC_TELEPHONE="POSIX" # export LC_MEASUREMENT="POSIX" # export LC_IDENTIFICATION="POSIX" - i.e. LANG and all LC_* must be defined (except LC_ALL).
Both variants are right. All *NIX's programs MUST work equally with both variants. And they do it except Wine. Wine works with the second variant. Wine doesn't works as expected with the first variant but it MUST! For *NIX's programs the value of LANG doesn't matter in the second variant. But for Wine is important. For Wine the meaning of LANG is same LC_CTYPE (see below).
One must correct bug in Wine but not use workaround (the second variant of locale) for bypass this bug! Programs must obey to system configs but not vice-versa.
Is there reason don't check LC_CTYPE for defining user_lcid? IMHO no.
There is already a test for LC_CTYPE a couple of lines below your changes.
From dlls/kernel/locale.c: void LOCALE_Init(void) { ---skip---- 1. lcid = get_env_lcid( NULL, NULL ); 2. NtSetDefaultLocale( TRUE, lcid ); ---skip---- 3. lcid = get_env_lcid( &unix_cp, "LC_CTYPE" ); 4. NtSetDefaultLocale( FALSE, lcid ); ---skip---- }
Here 2. - this set value of user_lcid 4. - this set value of system_lcid system_lcid affect on some part of Wine, user_lcid affect on other one. Thereby only some part of Wine is defined by LC_CTYPE:
If set # export LANG="POSIX" # export LC_CTYPE="ru_RU.CP1251" system_lcid (defined by LC_CTYPE) will be "ru_RU.CP1251"; user_lcid (defined by LANG) will be "en_US" - It's bug and it's visible in programs for Windows.
If set # export LANG="ru_RU.CP1251" # export LC_CTYPE="ru_RU.CP1251" system_lcid (defined by LC_CTYPE) will be "ru_RU.CP1251"; user_lcid (defined by LANG) will be "ru_RU.CP1251" - bug still here but it isn't visible in programs for Windows.
With my patch "user_lcid" is defined by LC_CTYPE as is done for "system_lcid".
"Sergei Butakov" butsergej@yandex.ru wrote:
If set # export LANG="POSIX" # export LC_CTYPE="ru_RU.CP1251" system_lcid (defined by LC_CTYPE) will be "ru_RU.CP1251"; user_lcid (defined by LANG) will be "en_US" - It's bug and it's visible in programs for Windows.
That's correct IMO, LANG takes the precedence over LC_TYPE. If you specify LANG="POSIX" you get what you asked for. AFAIK glibc does the same thing.
On Tuesday 18 April 2006 09:39, Dmitry Timoshkov wrote:
"Sergei Butakov" butsergej@yandex.ru wrote:
If set # export LANG="POSIX" # export LC_CTYPE="ru_RU.CP1251" system_lcid (defined by LC_CTYPE) will be "ru_RU.CP1251"; user_lcid (defined by LANG) will be "en_US" - It's bug and it's visible in programs for Windows.
That's correct IMO, LANG takes the precedence over LC_TYPE. If you specify LANG="POSIX" you get what you asked for. AFAIK glibc does the same thing.
No.
From `man locale` (glibc-2.3.4):
LANG - Provide a DEFAULT value for the internationalization variables that are UNSET or NULL. LC_ALL - IF SET to a non-empty string value, OVERRIDE the values of all the OTHER internationalization variables. LC_CTYPE - Determine the locale for the interpretation of sequences of bytes of text data as characters.
So any program must check variables in that order: LC_ALL, LC_CTYPE, LANG. (First check LC_ALL. If LC_ALL defined then stop, if not defined then check LC_CTYPE. If LC_CTYPE defined then stop, if not defined then check LANG)
In Wine system_lcid defined by LC_ALL, LC_CTYPE, LANG. It's right. user_lcid defined by LC_ALL, LANG only. It's wrong. LC_CTYPE must be checked too!
"Sergei Butakov" butsergej@yandex.ru wrote:
So any program must check variables in that order: LC_ALL, LC_CTYPE, LANG. (First check LC_ALL. If LC_ALL defined then stop, if not defined then check LC_CTYPE. If LC_CTYPE defined then stop, if not defined then check LANG)
In Wine system_lcid defined by LC_ALL, LC_CTYPE, LANG. It's right. user_lcid defined by LC_ALL, LANG only. It's wrong. LC_CTYPE must be checked too!
You are right, thanks for taking time explaining everything in details.
Sergei Butakov butsergej@yandex.ru writes:
Here 2. - this set value of user_lcid 4. - this set value of system_lcid system_lcid affect on some part of Wine, user_lcid affect on other one. Thereby only some part of Wine is defined by LC_CTYPE:
Well, yes, the point is that you can have user and system locales use different values. If you use the same check for both then they will always be identical, which isn't really what we want. You could maybe find a better heuristic for the user locale, but I don't think LC_CTYPE is appropriate.
On Tuesday 18 April 2006 16:11, Alexandre Julliard wrote:
Sergei Butakov butsergej@yandex.ru writes:
Here 2. - this set value of user_lcid 4. - this set value of system_lcid system_lcid affect on some part of Wine, user_lcid affect on other one. Thereby only some part of Wine is defined by LC_CTYPE:
Well, yes, the point is that you can have user and system locales use different values. If you use the same check for both then they will always be identical, which isn't really what we want. You could maybe find a better heuristic for the user locale, but I don't think LC_CTYPE is appropriate.
If somebody want to use different values of user and system locales in Wine he must set LC_CTYPE for system_lcid, LANG for user_lcid and unset LC_ALL. (Is it really anybody use different values?) Most users don't know about it, don't want and don't use different values but they must set LANG equal LC_CTYPE or use LANG/LC_ALL environment variable only. Otherwise Wine will not work correctly with locale. So, Wine use variable LANG for own purpose. And this purpose isn't concurrence with *NIX's one (in *NIX LANG provide a DEFAULT value for LC_* variables that are UNSET or NULL).
I propose a solution wich can satisfy everyone: define user_lcid by WINEUSERLC, system_lcid (where WINEUSERLC is one more environment variable). I.e. if WINEUSERLC is setted then Wine use it for defining of user_lcid. Else Wine use user_lcid equal to system_lcid.
Thus Wine will work on any *NIX's locale without any effort from users. (With my locale and current Wine-0.9.12 I must run: $ LANG=ru_RU.CP1251 wine some_program ). If somebody want to use user_lcid differ from system_lcid he start Wine like: $ WINEUSERLC="some_differ_locale" wine some_program (or insert in starting script of system # export WINEUSERLC="some_differ_locale" and then run $ wine some_program ).
How about it?
P. S. IMHO some problems of fonts reported by users can be related that bug about I talk. It's simple to test. Just run like: $ LC_ALL="your_locale" wine your_ugly_program.
From my experience: Wine-0.9.7/fontforge-20050502/empty ~/.wine/drive_c/windows/fonts/ Windows programs work OK. Wine-0.9.9/fontforge-20050502/empty ~/.wine/drive_c/windows/fonts/ English/Russian glyphs are ugly, it can be corrected by copying Corefont (Windows fonts) to ~/.wine/drive_c/windows/fonts/ set LC_ALL=ru don't help Wine-0.9.11/fontforge-20060125/empty ~/.wine/drive_c/windows/fonts/ some English glyphs are OK, other ugly some Russian glyphs are ugly, other square If I copy Corefont to ~/.wine/drive_c/windows/fonts/ then almost OK, but many Russian glyphs are square still. All can be corrected by LC_ALL=ru wine ..., and fonts in ~/.wine/drive_c/windows/fonts/ is not needed anymore. Wine-0.9.12/fontforge-20060408/empty ~/.wine/drive_c/windows/fonts/ Same as Wine-0.9.11 above
Sergei Butakov butsergej@yandex.ru writes:
If somebody want to use different values of user and system locales in Wine he must set LC_CTYPE for system_lcid, LANG for user_lcid and unset LC_ALL. (Is it really anybody use different values?) Most users don't know about it, don't want and don't use different values but they must set LANG equal LC_CTYPE or use LANG/LC_ALL environment variable only. Otherwise Wine will not work correctly with locale.
I'm not sure why you expect LC_CTYPE to set the user locale. LC_CTYPE defines the locale used for character conversions, and that's what Wine does by setting the system locale. The user locale affects things like resource loading and date formats, but these have nothing to do with LC_CTYPE.
From my experience: Wine-0.9.7/fontforge-20050502/empty ~/.wine/drive_c/windows/fonts/ Windows programs work OK. Wine-0.9.9/fontforge-20050502/empty ~/.wine/drive_c/windows/fonts/ English/Russian glyphs are ugly, it can be corrected by copying Corefont (Windows fonts) to ~/.wine/drive_c/windows/fonts/ set LC_ALL=ru don't help Wine-0.9.11/fontforge-20060125/empty ~/.wine/drive_c/windows/fonts/ some English glyphs are OK, other ugly some Russian glyphs are ugly, other square If I copy Corefont to ~/.wine/drive_c/windows/fonts/ then almost OK, but many Russian glyphs are square still. All can be corrected by LC_ALL=ru wine ..., and fonts in ~/.wine/drive_c/windows/fonts/ is not needed anymore. Wine-0.9.12/fontforge-20060408/empty ~/.wine/drive_c/windows/fonts/ Same as Wine-0.9.11 above
If the system locale is set to Russian, then I'd expect Russian characters to display properly no matter what the user locale is set to. It sounds like there's a real bug here, and playing with the locale setting is only hiding it.
1)On Wednesday 19 April 2006 15:00, Alexandre Julliard wrote:
I'm not sure why you expect LC_CTYPE to set the user locale. LC_CTYPE defines the locale used for character conversions, and that's what Wine does by setting the system locale. The user locale affects things like resource loading and date formats, but these have nothing to do with LC_CTYPE.
I did not find any information about purpose of system_lcid/user_lcid. So I wrongly thinked variables with similar names have similar purpose: system_lcid affect _ALL_ Windows locale variables of _SOME_ part (system) of Wine, user_lcid affect _ALL_ Windows locale variables of _OTHER_ part of Wine. And it was "confirmed" by my practice :). But reality system_lcid affect on _SOME_ part of Windows locale variables, user_lcid affect on _OTHER_ one.
... It sounds like there's a real bug here, and playing with the locale setting is only hiding it.
Is it means that something in Wine is defined by user_lcid but must by system_lcid?
So, is it right for Wine: LANG - define default values of all Windows locale variables; LC_CTYPE - is equivalent of LC_CTYPE and LC_COLLATE of *NIX locale; LC_MESSAGES - see below; LC_ALL - override all above; ?
3) There are system_ui_language and user_ui_language variables in Wine: system_ui_language set same system_lcid, user_ui_language can be setted by LC_MESSAGES. Changing LC_MESSAGES (LC_ALL is unsetted) I don't see any visible changes of Wine's or Windows'es programs. The result is same if I set system_ui_language equal user_ui_language. What is purpose of system_ui_language/user_ui_language?
4)
... like resource loading ...
Is it De.rc, En.rc, ... files?
-
Alexandre Julliard -
Dmitry Timoshkov -
Sergei Butakov