http://bugzilla.opensuse.org/show_bug.cgi?id=1202037 http://bugzilla.opensuse.org/show_bug.cgi?id=1202037#c2 --- Comment #2 from Gordon Leung --- For one example of a correct handling of locales, there is the fonts config for Fedora's Noto CJK fonts which removes the zh-MO lang from every font except for Noto CJK HK. https://src.fedoraproject.org/rpms/google-noto-cjk-fonts/blob/rawhide/f/65-g... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1202037 http://bugzilla.opensuse.org/show_bug.cgi?id=1202037#c4 --- Comment #4 from Gordon Leung --- (In reply to Cliff Zhao from comment #3)

We don't support zh-MO, Could your problem reproduce between zh-HK and zh-TW? Where can I get a list of supported locales? it is a bit confusing as the Macau locale (zh_MO.UTF-8) is selectable from KDE's region section. I have tested it on zh-HK and zh-TW locale and it was not a problem there. So as far as I know it is only a problem for zh-MO. Another question: The attachment is the correct result or the incorrect result? Thank you for the feedback. The attachment labeled "with Noto TC and Noto HK installed" is incorrect, the other attachment is correct.

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1202037 http://bugzilla.opensuse.org/show_bug.cgi?id=1202037#c6 --- Comment #6 from Gordon Leung --- (In reply to Cliff Zhao from comment #5)

...

(In reply to Cliff Zhao from comment #3)

...

We don't support zh-MO, Could your problem reproduce between zh-HK and zh-TW? Where can I get a list of supported locales? it is a bit confusing as the Macau locale (zh_MO.UTF-8) is selectable from KDE's region section. I have tested it on zh-HK and zh-TW locale and it was not a problem there. So as far as I know it is only a problem for zh-MO. We only support GNOME; KDE desktop is supported by the community if there has someone willing to contribute. So you can check: GNOME desktop-> gnome-control-center -> Region & Language -> Language There are only have: "������ ������"��������� ������" ������ ������"��� There's no guarantee all languages in the list will be supported but the language not in this list is absolutely no support. If you want the detailed list, please open an L3 bug,

(In reply to Gordon Leung from comment #4) the product manager should have one, and he will consider whether to make it public. Generally, we deal with Chinese Hongkong and Chinese Macau problems inside Chinese Taiwan. means if the same bug CAN reproduce in the Chinese Taiwan locale, we will fix it; otherwise, we don't fix it. Then I will open up an L3 bug I guess because I don't want to be surprised again and learn that another locale I thought was supported was in fact not supported.

Another point is: You said that the character "���" is incorrect in the bug description, could you please show some Macau government formal character standards which define the correct "���" font type? I search for the Macau font standards for several days but get nothing. If you have, maybe we could discuss it further. To be honest, I am mainly going off of my gut intuition so fair enough... I guess this won't be fixed then since I also have problems trying to find such standards.

I will be transparent and admit that this bugzilla was mostly raised because someone from openSUSE/fonts-config https://github.com/openSUSE/fonts-config/pull/23 wanted me to open a bugzilla report about the zh-MO locale. I guess this bug can be closed as zh-MO is not supported anyways. -- You are receiving this mail because: You are on the CC list for the bug.

(In reply to Cliff Zhao from comment #5)

...

(In reply to Gordon Leung from comment #4)

...

(In reply to Cliff Zhao from comment #3) ...

I will be transparent and admit that this bugzilla was mostly raised because someone from openSUSE/fonts-config https://github.com/openSUSE/fonts-config/pull/23 wanted me to open a bugzilla report about the zh-MO locale. I guess this bug can be closed as zh-MO is not supported anyways. Sorry for the requirement caused your ineffective labor work. Because generally traditional Chinese problems report in one certain area, but

http://bugzilla.opensuse.org/show_bug.cgi?id=1202037 http://bugzilla.opensuse.org/show_bug.cgi?id=1202037#c8 --- Comment #8 from Cliff Zhao --- Created attachment 860682 --> http://bugzilla.opensuse.org/attachment.cgi?id=860682&action=edit Variant character example of traditional Chinese (collect from internet). (In reply to Gordon Leung from comment #6) they always can be reproduced in all areas including Taiwan, Hongkong, Macau, and Singapore. But I learned later that your problem was unique to only affected Macau. Second, after several days of search, I found the Macau government seems didn't have a formal set of font type standards under maintenance. that also blocks the fix work. At the same time, China's mainland and Taiwan have their own standard. I suppose that should be a reason both these two areas are in support. The last is that Chinese has a lot of variant characters, which means these words that sound the same and mean the same but are written differently. How to know the character type "���" in Macau is not a variant character but is a wrongly written character without the standard document? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1202037 http://bugzilla.opensuse.org/show_bug.cgi?id=1202037#c10 --- Comment #10 from Gordon Leung --- (In reply to Cliff Zhao from comment #9)

I think maybe I didn't express myself clearly, I mean you could request to get the language supporting list through an L3 bug or something like that, I think. I don't mean we will support Macau if you could open the L3 bug.

I meant what "Product" and "Component" the L3 bug should be filed under to get a list. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1202037 http://bugzilla.opensuse.org/show_bug.cgi?id=1202037#c12 Marguerite Su changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |i@marguerite.su --- Comment #12 from Marguerite Su --- Hi, all, A. the misleading state of "we don't support zh-MO": zh-MO is an official locale defined by ISO organization. https://salsa.debian.org/iso-codes-team/iso-codes/-/blob/main/data/iso_3166-... the GNU C Library doesn't support zh-MO locale. https://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales;h=cdd948... gnome follows glibc so it doesn't support zh-MO. kde uses ki18n which refers to iso-codes and timezone data so it supports zh-MO. for openSUSE, the situation is complicated: our filesystem package doesn't even have zh_SG: https://build.opensuse.org/package/view_file/Base:System/filesystem/language... fcitx/fcitx5 package introduced zh_SG to /usr/etc/X11/xim.d for SUSE, SLED uses gnome desktop but it also has fcitx (I think because I don't have a registration code) :-D for fonts-config part, I prefer to fix zh-MO instead of removing it. because that handler was introduced back in 2018, many users may have adapted to it already. Zhao said we need government official documents to support font type variants, I doubt because Singapore government may not have such documents too, no need to mention Malaysia or South Thailand. Google/Adobe develop Noto font glyphs based on such standard, but they never prevent usage in other cases. B. I agree that Macau should bind to Hongkong. Because the Traditional Chinese standard in Taiwan region is not so traditional. Other Chinese areas uses Kang Xi glyph variants(. that is, the HK variant is more traditional than Tiwan's, and more like what people in Macau see daily. The physically and culturally saying on github is not wrong actually. I myself didn't do such tweaks before because back to 2018 there's no Noto CJK HK variant at all I think. So, please go ahead if you have better solutions, we can continue the talk on github. C. the Fedora fontconfig configuration should not be applied to openSUSE. they use "Noto Sans CJK SC" but we should use language specific variants instead of CJK variants whose name is "Noto Sans SC" (that's a bug since revision 2, I need to fix it later), so they can remove the redundant language matches. the CJK variants will always display Japanese variant. -- You are receiving this mail because: You are on the CC list for the bug.