[Bug 53770] New: [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

Bug ID: 53770
           Summary: [ nls cause BUG ] local.nls should must be update
                    (./wine/nls/local.nls )
           Product: Wine
           Version: 7.18
          Hardware: x86
                OS: other
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: kernel32
          Assignee: [e-mail]
          Reporter: [e-mail]

In China, there is a popular student software called DingTalk, in which the APP
reads the sNativeDigits value in the registry (/HKEY_USERS/S-X-XX-XX/Control
Panel International -> sNativeDigits) during getting the meeting time.

Through research, I found that This value is obtained by the function
get_locale_info, and the specific location is as follows:
> case LOCALE_SNATIVEDIGITS:   
>   if ((ret = locale_return_reg_string( &entry_scurrency, type, buffer, len )) != -1) return ret;
>   return locale_return_string( locale->scurrency, type, buffer, len );

Now, in wine7.12 to 7.18, for the Chinese environment (LOCALE_SNATIVEDIGITS),
the sNativeDigits read from local.nls is "零一二三四五六七八九", but this is
unreasonable, I checked the Windows10 registry and found that its value should
be It is "0123456789"

And if it is "零一二三四五六七八九", the program will have an error
> The timer is displayed as Chinese characters, and the actual display of "一" is not "一" but "《", it's so strange

, so I think we should update local.nls or modify the get_locale_info function.

*** update local.nls：*** 
I would like to ask how the local.nls in wine is generated, is it directly used
in windows? I once wanted to modify local.nls directly to fix this problem, but
it seems to be a binary file, and I don't know how it is generated in wine, so
I I don't know how to modify local.nls by myself.

[HELP] If you have time, I would like to ask how the nls file is generated in
wine

*** modify the get_locale_info function：*** 
I have completed the modification of the function (assignment in the Chinese
environment, other environments do not operate), if you need I can provide the
source code directly.

—————————
I hope that I can ask about the modification of the nls file, and complete the
modification through my own efforts, so that I can also join the big project of
wine, which is meaningful and interesting to me.

Thanks very much, Looking forward to your reply。

Yous: SvenL

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|7.18                        |7.12

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #1 from [e-mail] ---
I found this commit 7ab46c4f21d18c355cffd94df1f67602abb47e0d change the
local.nls

Can anyone tell me how to Generate a .nls file for wine ?

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |blocker
            Version|7.12                        |7.18
           Priority|P2                          |P1

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

Sagawa  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sagawa.aki+winebugs@gmail.c
                   |                            |om

--- Comment #2 from Sagawa  ---
Please correctly describe your situation.
The LOCALE_SNATIVEDIGITS value comes from locale.nls not local.nls.
In Chinese locale, it should be "〇一二三四五六七八九" not "零一二三四五六七八九".

Then, why don't you search the code with the above keywords using grep command?
You'll easily find the script, i.e. tools/make_unicode.

The script is written in Perl language. Can you reach to
https://github.com/unicode-org/cldr/blob/1e28c0fbb43b719b43127432f0a86323578...
?

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #3 from [e-mail] ---
(In reply to Sagawa from comment #2)
> Please correctly describe your situation.
> The LOCALE_SNATIVEDIGITS value comes from locale.nls not local.nls.
> In Chinese locale, it should be "〇一二三四五六七八九" not "零一二三四五六七八九".

Thank you very much for your help, please forgive me for not phrasing the
question correctly, sorry here.
> Then, why don't you search the code with the above keywords using grep
> command? You'll easily find the script, i.e. tools/make_unicode.

I searched 0123456789 at that time, but there was no result.
Now it looks like I should retrieve locale.nls
> The script is written in Perl language. Can you reach to
> https://github.com/unicode-org/cldr/blob/
> 1e28c0fbb43b719b43127432f0a86323578789a4/common/supplemental/
> numberingSystems.xml#L36 ?

I've found where you said, I can go to the url you sent me, and it seems I just
need to modify the script and run it.

I'm now learning about camel language and trying to generate my own, thanks a
lot

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #4 from [e-mail] ---
(In reply to 399989567 from comment #3)
> (In reply to Sagawa from comment #2)
> > Please correctly describe your situation.
> > The LOCALE_SNATIVEDIGITS value comes from locale.nls not local.nls.
> > In Chinese locale, it should be "〇一二三四五六七八九" not "零一二三四五六七八九".
>
> Thank you very much for your help, please forgive me for not phrasing the
> question correctly, sorry here.
> > Then, why don't you search the code with the above keywords using grep
> > command? You'll easily find the script, i.e. tools/make_unicode.
>
> I searched 0123456789 at that time, but there was no result.
> Now it looks like I should retrieve locale.nls

not 0123456789 is "〇一二三四五六七八九"
> > The script is written in Perl language. Can you reach to
> > https://github.com/unicode-org/cldr/blob/
> > 1e28c0fbb43b719b43127432f0a86323578789a4/common/supplemental/
> > numberingSystems.xml#L36 ?
>
> I've found where you said, I can go to the url you sent me, and it seems I
> just need to modify the script and run it.
>
> I'm now learning about camel language and trying to generate my own, thanks
> a lot

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #5 from [e-mail] ---
(In reply to 399989567 from comment #3)
> (In reply to Sagawa from comment #2)
> > Please correctly describe your situation.
> > The LOCALE_SNATIVEDIGITS value comes from locale.nls not local.nls.
> > In Chinese locale, it should be "〇一二三四五六七八九" not "零一二三四五六七八九".
>
> Thank you very much for your help, please forgive me for not phrasing the
> question correctly, sorry here.
> > Then, why don't you search the code with the above keywords using grep
> > command? You'll easily find the script, i.e. tools/make_unicode.
>
> I searched 0123456789 at that time, but there was no result.
> Now it looks like I should retrieve locale.nls
> > The script is written in Perl language. Can you reach to
> > https://github.com/unicode-org/cldr/blob/
> > 1e28c0fbb43b719b43127432f0a86323578789a4/common/supplemental/
> > numberingSystems.xml#L36 ?
>
> I've found where you said, I can go to the url you sent me, and it seems I
> just need to modify the script and run it.
>
> I'm now learning about camel language and trying to generate my own, thanks
> a lot

not camel language is "Perl language"

————————————
my goddamn brain

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #6 from [e-mail] ---
(In reply to Sagawa from comment #2)
> Please correctly describe your situation.
> The LOCALE_SNATIVEDIGITS value comes from locale.nls not local.nls.
> In Chinese locale, it should be "〇一二三四五六七八九" not "零一二三四五六七八九".
>
> Then, why don't you search the code with the above keywords using grep
> command? You'll easily find the script, i.e. tools/make_unicode.
>
> The script is written in Perl language. Can you reach to
> https://github.com/unicode-org/cldr/blob/
> 1e28c0fbb43b719b43127432f0a86323578789a4/common/supplemental/
> numberingSystems.xml#L36 ?

Thank you very much for your help, I have completely solved the problem.

By using the script written in the perl language, I successfully generated the
locale.nls I needed and solved the problem

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #7 from Nikolay Sivov  ---
What was the problem? We would want something patched in Wine if current locale
data does not match what you get on Windows. So the question is, is there
locale data mismatch for some Chinese locale, between Windows NLS data and
Unicode CLDR?

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #8 from [e-mail] ---
(In reply to Nikolay Sivov from comment #7)
> What was the problem? We would want something patched in Wine if current
> locale data does not match what you get on Windows. So the question is, is
> there locale data mismatch for some Chinese locale, between Windows NLS data
> and Unicode CLDR?

Yes，there have some problem. The current locale data not match what I get on
Windows10.

Now,when we create locale.nls,we use
"cldr/common/supplemental/numberingSystems.xml" in the code ↓
> sub build_locale_data()
> my $numbers = load_xml_data_file( "cldr", "$base/common/supplemental/numberingSystems.xml" );

However, the data of numberingSystems.xml is different from the current
window10, as shown in
https://github.com/unicode-org/cldr/blob/1e28c0fbb43b719b43127432f0a86323578...

Now:
> <numberingSystem id="hanidec" type="numeric" digits="〇一二三四五六七八九"/>

But it should be
> <numberingSystem id="hanidec" type="numeric" digits="0123456789"/>

If we don't change like this, there will be some problems on some apps，Like
Dingtalk.

I don't know if I express this problem clearly.

By the way, I have generated the correct locale.nls, you said that some patches
should be applied to wine, Can I provide this patch in my name?Contributing to
wine and being a wine developer is exciting for me.

I'll put the patch I generated in the next comment

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #9 from [e-mail] ---
Created attachment 73303
  --> https://bugs.winehq.org/attachment.cgi?id=73303
The new locale.nle by SvenL

Update the locale.nls to solve the Chinese default number problem.

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #10 from Nikolay Sivov  ---
First we'll need to validate that the change is correct. What is the exact
locale name you're using? I'm not totally sure how to check that easily, but
you could run your application like this:

WINEDEBUG=+nls,+locale wine <application.exe> &> /tmp/log.txt

and attach resulting file here. Hopefully it will show used locale name
somewhere in the log.

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #73303|0                           |1
        is obsolete|                            |

--- Comment #11 from [e-mail] ---
Created attachment 73304
  --> https://bugs.winehq.org/attachment.cgi?id=73304
The new locale.nle by SvenL

Update the locale.nls to solve the Chinese default number problem

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #12 from Nikolay Sivov  ---
(In reply to 399989567 from comment #9)
> Created attachment 73303 [details]
> The new locale.nle by SvenL
>
> Update the locale.nls to solve the Chinese default number problem.

Updated binary file is not useful. Please attach the log I just asked for
instead.

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #13 from [e-mail] ---
(In reply to Nikolay Sivov from comment #12)
> (In reply to 399989567 from comment #9)
> > Created attachment 73303 [details]
> > The new locale.nle by SvenL
> >
> > Update the locale.nls to solve the Chinese default number problem.
>
> Updated binary file is not useful. Please attach the log I just asked for
> instead.

(In reply to Nikolay Sivov from comment #10)
> First we'll need to validate that the change is correct. What is the exact
> locale name you're using? I'm not totally sure how to check that easily, but
> you could run your application like this:
>
> WINEDEBUG=+nls,+locale wine <application.exe> &> /tmp/log.txt
>
> and attach resulting file here. Hopefully it will show used locale name
> somewhere in the log.

Wait for me to open the computer to produce log files for you.

——————————————
①
Actually, I was using DingTalk when I found a bug in the program, the time was
displayed as "〇〇:〇〇:《>" during voice call, when LANG=zh_CN.UTF-8.

Problem picture: https://imgse.com/i/xDQICq

But on my English virtual machine, the time is displayed correctly here, like
"00:00:12"

——
②
I felt that this phenomenon was very strange, so I thought about this issue
from several angles.

When I investigated the registry, I exported all the registries of both Chinese
and English environments, and then used "git diff", I found that there are two
table entries in these two registries that are different, that is:
> HKEY_USERS\S-1-5-21-0-0-0-1000\Control Panel\International\sNativeDigits

English env -> sNativeDigits = 0123456789

Chinese env -> sNativeDigits = 〇一二三四五六七八九

Where "〇" is the "〇" in "〇〇:〇〇:《>" in my error picture above.

So in the Chinese environment, I'm  directly set the sNativeDigits =
0123456789,this problem disappears.

So I presume that the time display API reads the value of sNativeDigits 。

——
③
Next I opened the Chinese version of the window10 registry, I found the value
of sNativeDigits in window10(Chinese env) also is 0123456789 but not is
〇一二三四五六七八九.

Then,I took another look at wine's source code and found that the value of
sNativeDigits is passed through the function "get_locale_info" ↓
> /* get locale information from the locale.nls file */
> static int get_locale_info( const NLS_LOCALE_DATA *locale, LCID lcid, LCTYPE type,WCHAR *buffer, int len )
> {
>     .....
>     case LOCALE_SNATIVEDIGITS:
>          if ((ret = locale_return_reg_string( &entry_snativedigits, type, buffer, len )) != -1) return ret;
>     .....
> }

I'm sure this data is read from locale.nls, and I'm also sure that under
windows10（Chinese） sNativeDigits = 0123456789

————————————
On a side note, there is actually a bug here, as you can see in my error
picture, the time is displayed as "〇〇:〇〇:《>",The actual display should be
"〇〇:〇〇:一二"。

This is not correct, the "一" is displayed as "《",But I haven't found out which
API is called here, so I'm sorry I didn't find the cause of the problem. Is it
related to the byte length of Chinese characters?

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #14 from [e-mail] ---
Created attachment 73305
  --> https://bugs.winehq.org/attachment.cgi?id=73305
WINEDEBUG=+nls,+locale

WINEDEBUG=+nls,+locale

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #73305|text/plain                  |application/zip
          mime type|                            |

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #15 from Sagawa  ---
I can't see the picture[1]. Can you attach it here instead?

Reading from the log, I see the following line (line 10034):
0100:trace:nls:GetLocaleInfoW (lcid=0x804,lctype=0x13,0021DC90,11)
This shows DingTalk surely queries LOCALE_SNATIVEDIGITS.

I think DingTalk just added the digit value to the code point value of 0, i.e.
〇 (U+3007). For instance, 《 (U+300A) is used for 3 because 0x3007 plus three is
0x300A, 〉 (U+3009) is used for 2 because 0x3007 plus two is 0x3009, and so on.
See Unicode charts for these code points[2].

How about forging sNativeDigits with another character, e.g. 零一二三四五六七八九? I
guess you'll see Hanzi characters related 雨 like 雷, 雹, 電 in DingTalk.

[1] https://imgse.com/i/xDQICq -- s1.ax1x.com points to 127.0.0.1 at this
moment.
[2] https://www.unicode.org/charts/PDF/U3000.pdf

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #16 from [e-mail] ---
Created attachment 73315
  --> https://bugs.winehq.org/attachment.cgi?id=73315
PIC1

problem pic1

[Bug 53770] [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #17 from Nikolay Sivov  ---
I did try this on Windows today, but forgot to comment. On Win10 with lcid
0x804 I get 012345679 for native digits, none of CJK characters.

That means we'll need to patch the script a little.

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[ nls cause BUG ] local.nls |Wrong locale data for
                   |should must be update       |Chinese locales for
                   |(./wine/nls/local.nls )     |LOCALE_SNATIVEDIGITS class

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #18 from [e-mail] ---
(In reply to Sagawa from comment #15)
> I can't see the picture[1]. Can you attach it here instead?

Now I have successfully uploaded the picture
> Reading from the log, I see the following line (line 10034):
> 0100:trace:nls:GetLocaleInfoW (lcid=0x804,lctype=0x13,0021DC90,11)
> This shows DingTalk surely queries LOCALE_SNATIVEDIGITS.

Thanks very much, you made me sure the DingTalk used the sNativedigits
> I think DingTalk just added the digit value to the code point value of 0,

Yes !!! You inspired me, I verified it on Windows 10（ In Windows 10 , I let
sNativedigits became "〇一二三四五六七八九", the problem reproduce ）, your conclusion is
correct, you are highly skilled。
> i.e. 〇 (U+3007). For instance, 《 (U+300A) is used for 3 because 0x3007 plus
> three is 0x300A, 〉 (U+3009) is used for 2 because 0x3007 plus two is 0x3009,
> and so on. See Unicode charts for these code points[2].

I'm new to this stuff, I didn't know about this watch before you, you've given
me a lot of inspiration.
> How about forging sNativeDigits with another character, e.g. 零一二三四五六七八九?

In fact,I didn't catch what you meant.Do you mean for me to replace
"〇一二三四五六七八九" with "零一二三四五六七八九" in the registry?
> I guess you'll see Hanzi characters related 雨 like 雷, 雹, 電 in DingTalk.
>
> [1] https://imgse.com/i/xDQICq -- s1.ax1x.com points to 127.0.0.1 at this
> moment.
> [2] https://www.unicode.org/charts/PDF/U3000.pdf

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #19 from [e-mail] ---
(In reply to Nikolay Sivov from comment #17)
> I did try this on Windows today, but forgot to comment. On Win10 with lcid
> 0x804 I get 012345679 for native digits, none of CJK characters.
>
> That means we'll need to patch the script a little.

那请问是不是可以直接使用我的locale.nls文件，还是说我们需要修改./tools/make_unicode

So if that means this patch can use my locale.nls file directly ？

Or we need to modify ./tools/make_unicode ?

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #20 from Nikolay Sivov  ---
The script of course.

On Windows only two zh locales are using CJK characters for digits:

zh-Hans-HK and zh-Hans-MO

On Wine currently 18 zh-* locales are using CJK characters.

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #21 from Nikolay Sivov  ---
I'll look into it.

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #22 from [e-mail] ---
(In reply to Nikolay Sivov from comment #21)
> I'll look into it.

I would like to ask what is your revision idea? Maybe I can help.

Do you want to modify where locale.nls is generated, or where locale.nls is
read?

————————

By the way, I would like to ask if there are some quick methods or WINEDEBUG
channels to quickly check my current use environment of wine, because I found
that the realization of wine in QQ is different on the virtual machine and on
the physical machine ,where both installed on the same system image.

Since it's a closed source program, I'm guessing that the program might be
retrieving some settings. I want to list the settings in wine to find the
problem by diff.

Specifically, when a string is output, one calls ExtTextOutW and the other
calls ScriptTextOut.

Using "ScriptTextOut" will output fine, using "ExtTextOutW" will not.

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #23 from Nikolay Sivov  ---
Locale issue should be fixed now with
https://source.winehq.org/git/wine.git/commit/4172c0482626b56c76fd1e5e362a37....

Please rebuild with current wine, or wait for wine 7.20.

Arguably, it's also an application bug, if it really assumes it's safe to
increment returned digit characters.

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
      Fixed by SHA1|                            |4172c0482626b56c76fd1e5e362
                   |                            |a3711594a25e6
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #24 from Nikolay Sivov  ---
Marking fixed.

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #25 from [e-mail] ---
(In reply to Nikolay Sivov from comment #24)
> Marking fixed.

What function does wine use to determine the system locale? Like Chinese or
English?

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #26 from [e-mail] ---
(In reply to 399989567 from comment #25)
> (In reply to Nikolay Sivov from comment #24)
> > Marking fixed.
>
> What function does wine use to determine the system locale? Like Chinese or
> English?

When I " export LC_COLLATE=zh_CN.utf-8 ",my wine became Chinese,
and When I " export LC_COLLATE=es_US.utf-8 " ,my wine env became English.
I would like to ask where is this function implemented?

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #27 from Nikolay Sivov  ---
I think this happens in init_locale() function in ntdll. However, this has
nothing to do with reported issue, which was about data for particular locales.

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #28 from Alexandre Julliard  ---
Closing bugs fixed in 7.20.

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #29 from [e-mail] ---
(In reply to Nikolay Sivov from comment #27)
> I think this happens in init_locale() function in ntdll. However, this has
> nothing to do with reported issue, which was about data for particular
> locales.

I found you active in wine's website and very helpful, you helped me a lot, I
really appreciate it. Because you replied to my question on the dwrite module
before, I have a question related to font selection and want to get your help.
For your convenience, I submitted a new bug: 53857

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #30 from [e-mail] ---
(In reply to 399989567 from comment #29)
> (In reply to Nikolay Sivov from comment #27)
> > I think this happens in init_locale() function in ntdll. However, this has
> > nothing to do with reported issue, which was about data for particular
> > locales.
>
> I found you active in wine's website and very helpful, you helped me a lot,
> I really appreciate it. Because you replied to my question on the dwrite
> module before, I have a question related to font selection and want to get
> your help. For your convenience, I submitted a new bug: 53857

For your convenience -> bug 53857

[Bug 53770] Wrong locale data for Chinese locales for LOCALE_SNATIVEDIGITS class

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53770

--- Comment #31 from [e-mail] ---
(In reply to 399989567 from comment #29)
> (In reply to Nikolay Sivov from comment #27)
> > I think this happens in init_locale() function in ntdll. However, this has
> > nothing to do with reported issue, which was about data for particular
> > locales.
>
> I found you active in wine's website and very helpful, you helped me a lot,
> I really appreciate it. Because you replied to my question on the dwrite
> module before, I have a question related to font selection and want to get
> your help. For your convenience, I submitted a new bug: 53857

For your convenience -> bug 53857