kernel: fix determination of using locale

Sergei Butakov butsergej at yandex.ru
Wed Apr 19 03:19:09 CDT 2006


On Tuesday 18 April 2006 16:11, Alexandre Julliard wrote:
> Sergei Butakov <butsergej at 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



More information about the wine-devel mailing list