[Bug 53770] New: [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )
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: wine-bugs(a)winehq.org Reporter: 399989567(a)qq.com 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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 399989567(a)qq.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 399989567(a)qq.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|7.18 |7.12 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #1 from 399989567(a)qq.com --- I found this commit 7ab46c4f21d18c355cffd94df1f67602abb47e0d change the local.nls Can anyone tell me how to Generate a .nls file for wine ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 399989567(a)qq.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |blocker Version|7.12 |7.18 Priority|P2 |P1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 Sagawa <sagawa.aki+winebugs(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sagawa.aki+winebugs(a)gmail.c | |om --- Comment #2 from Sagawa <sagawa.aki+winebugs(a)gmail.com> --- 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... ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #3 from 399989567(a)qq.com --- (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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #4 from 399989567(a)qq.com --- (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
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #5 from 399989567(a)qq.com --- (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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #6 from 399989567(a)qq.com --- (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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #7 from Nikolay Sivov <bunglehead(a)gmail.com> --- 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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #8 from 399989567(a)qq.com --- (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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 399989567(a)qq.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |399989567(a)qq.com --- Comment #9 from 399989567(a)qq.com --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #10 from Nikolay Sivov <bunglehead(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 399989567(a)qq.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #73303|0 |1 is obsolete| | --- Comment #11 from 399989567(a)qq.com --- 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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #12 from Nikolay Sivov <bunglehead(a)gmail.com> --- (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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #13 from 399989567(a)qq.com --- (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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #14 from 399989567(a)qq.com --- Created attachment 73305 --> https://bugs.winehq.org/attachment.cgi?id=73305 WINEDEBUG=+nls,+locale WINEDEBUG=+nls,+locale -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #73305|text/plain |application/zip mime type| | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #15 from Sagawa <sagawa.aki+winebugs(a)gmail.com> --- 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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #16 from 399989567(a)qq.com --- Created attachment 73315 --> https://bugs.winehq.org/attachment.cgi?id=73315 PIC1 problem pic1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #17 from Nikolay Sivov <bunglehead(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 Nikolay Sivov <bunglehead(a)gmail.com> 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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #18 from 399989567(a)qq.com --- (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
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #19 from 399989567(a)qq.com --- (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 ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #20 from Nikolay Sivov <bunglehead(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #21 from Nikolay Sivov <bunglehead(a)gmail.com> --- I'll look into it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #22 from 399989567(a)qq.com --- (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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #23 from Nikolay Sivov <bunglehead(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |4172c0482626b56c76fd1e5e362 | |a3711594a25e6 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from Nikolay Sivov <bunglehead(a)gmail.com> --- Marking fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #25 from 399989567(a)qq.com --- (In reply to Nikolay Sivov from comment #24)
Marking fixed.
What function does wine use to determine the system locale? Like Chinese or English? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #26 from 399989567(a)qq.com --- (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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #27 from Nikolay Sivov <bunglehead(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #28 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 7.20. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #29 from 399989567(a)qq.com --- (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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #30 from 399989567(a)qq.com --- (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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53770 --- Comment #31 from 399989567(a)qq.com --- (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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla