Bug 437994

I'm not sure we can do anything about this. This is the string QLocale::ativeLanguageName() returns us, so it's a bug in Qt.

Created attachment 138952 [details]
subtitle composer

Hi,

Maybe we look how other apps construct this dialog. For example, Subtitle Composer has this "português" listed twice but adds pt and pt_BR to diferenciate.

Created attachment 138953 [details]
konsole

Hi,

Konsole in the other hand shows "português" and "português do Brasil"

In a sense, yes, but there is more going on... I only have one portuges in my konsole. I checked what we get and I'm not sure what's going on. This is a debug dump of all the pt_ locales that get considered in this list:

QLocale(Portuguese, Latin, Brazil)
1 >>>>>>>>>>>> nativeName "pt_BR" "português" : "português" in insertedLangages false is translated true
QLocale(Portuguese, Latin, Angola)
2 >>>>>>>>>>>> nativeName "pt" "português" : "português" in insertedLangages false is translated true
QLocale(Portuguese, Latin, Cape Verde)
QLocale(Portuguese, Latin, East Timor)
QLocale(Portuguese, Latin, Equatorial Guinea)
QLocale(Portuguese, Latin, Guinea Bissau)
QLocale(Portuguese, Latin, Luxembourg)
QLocale(Portuguese, Latin, Macau)
QLocale(Portuguese, Latin, Mozambique)
QLocale(Portuguese, Latin, Portugal)
QLocale(Portuguese, Latin, Sao Tome And Principe)
QLocale(Portuguese, Latin, Switzerland)

(In reply to Halla Rempt from comment #4)
> In a sense, yes, but there is more going on... I only have one portuges in
> my konsole. I checked what we get and I'm not sure what's going on.

Hello, yes, I can confirm this: some applications only show the current locale (Konsole, Kate, Kdenlive), however KDevelop and Subtitle Composer show the correct full list.

> This is a debug dump of all the pt_ locales that get considered in this list:
> 
> QLocale(Portuguese, Latin, Brazil)
> 1 >>>>>>>>>>>> nativeName "pt_BR" "português" : "português" in
> insertedLangages false is translated true
> QLocale(Portuguese, Latin, Angola)
> 2 >>>>>>>>>>>> nativeName "pt" "português" : "português" in insertedLangages
> false is translated true
> QLocale(Portuguese, Latin, Cape Verde)
> QLocale(Portuguese, Latin, East Timor)
> QLocale(Portuguese, Latin, Equatorial Guinea)
> QLocale(Portuguese, Latin, Guinea Bissau)
> QLocale(Portuguese, Latin, Luxembourg)
> QLocale(Portuguese, Latin, Macau)
> QLocale(Portuguese, Latin, Mozambique)
> QLocale(Portuguese, Latin, Portugal)
> QLocale(Portuguese, Latin, Sao Tome And Principe)
> QLocale(Portuguese, Latin, Switzerland)

This is correct, typically only Brazil includes the pt_BR variant, whereas all other places use pt. Calamares for instance only distinguishes between "Português" and "Português europeu" (expectedly), however System Settings displays many region formats, like pt_MZ for Moçambique.

I can only assume each application is using a different implementation to show locales as Luiz mentioned, but that's another issue to be filed I suppose. Krita expectedly shows many locales, but isn't distinguishing between Portuguese and European Portuguese. KDevelop and Subtitle Composer are probably doing something to fix this.

(In reply to Halla Rempt from comment #1)
> I'm not sure we can do anything about this. This is the string
> QLocale::ativeLanguageName() returns us, so it's a bug in Qt.

I agree, this does seem like some issue in Qt if different implementations with QLocale can lead to not display the full/correct list.

So, the reason I assigned myself so quickly is that, some time ago I was already working on some changes in my stash that would fix this exact issue. But when I looked carefully again, it turns out there are actually more issues with the language list than I originally thought, which means my changes are incorrect.

... But let's not talk about those here.

For our Portuguese translations, there are `pt` and `pt_BR`. `pt_BR` is obviously for Brazillian Portuguese, so I'm assuming `pt` is "Portugal" Portuguese. The lazy way is to just show the language code in parentheses, and this would work simply for disambiguating all languages, but it would not be very user-friendly.

Upstream KConfigWidgets actually uses more info [1] to get the language name, but this doesn't really work as we don't ship the `kf5_entry.desktop` files in our releases.

For now, we can instead do this: If the language code contains an underscore, we append the country name in parentheses. In fact I will commit this change now. This doesn't resolve the other issues that I found, but I'll just leave them for later.

[1]: https://invent.kde.org/frameworks/kconfigwidgets/-/blob/40e36e9b255de3ec621d8531ef46daa3e1e5476b/src/klanguagebutton.cpp#L133

Git commit 73be7ee9f0302069acce8fb6cc6b03a5d65d0f6d by Alvin Wong.
Committed on 03/06/2021 at 05:38.
Pushed by alvinwong into branch 'master'.

Show country in language list for disambiguation

M  +16   -1    libs/widgetutils/xmlgui/kswitchlanguagedialog_p.cpp

https://invent.kde.org/graphics/krita/commit/73be7ee9f0302069acce8fb6cc6b03a5d65d0f6d

(In reply to Alvin Wong from comment #7)
> Git commit 73be7ee9f0302069acce8fb6cc6b03a5d65d0f6d by Alvin Wong.
> Committed on 03/06/2021 at 05:38.
> Pushed by alvinwong into branch 'master'.
> 
> Show country in language list for disambiguation
> 
> M  +16   -1    libs/widgetutils/xmlgui/kswitchlanguagedialog_p.cpp
> 
> https://invent.kde.org/graphics/krita/commit/
> 73be7ee9f0302069acce8fb6cc6b03a5d65d0f6d

I would strongly disagree with the change here. A Language is a language. It has nothing to do with "country". 

Just like Simplified Chinese doesn't need a (U.S.) variant for the Chinese Asian living in the U.S. We don't need Spanish (Spain), Spanish (Mexico), Spanish (Philippine) or Spanish (Basque). Nor do we need British English (England), British English (Welsh), British English (Scotland), British English (Ireland), British English (India).

In the commit you said American English and British English do not need this, and I too believe we don't need this for Simplified Chinese and Traditional Chinese - there is zero possibility for mistaking their names.

By sneaking this highly controversial and political concept into a language list, you are bound to trigger unnecessary political drama between some regions without any actual usability gain.

Specifically it will potentially lead to a ban of Krita in China, wasting years of hard work from the local community, and put me, the main translator and the splash artwork artist, in danger of public wrath, losing my job or even facing punishment from the authority because it too will be displayed that way in the Simplified Chinese version. This is not some fairy tale because similar debacles happens almost every month here in the mainland, and it's only going to get worse.

I know you can argue with that it's not technically "wrong" from some perspectives, but for one you can't reason with politics or nationalist fever with logic. And two why change something that has been working fine for everyone for so many years? 

I believe KDE is a community that develops free software for EVERYONE to use EVERYWHERE. It is not its job to fiddle with politics that endangers its ability to distribute free software in some regions. And it should not endanger the personal safety of its volunteers who has nothing to do with the politics they are subjected to.

Nationality is the ideology created by the politicians to divide us. KDE is an international cooperative and it should never be divided by the same artificial border within itself or among its users.

Therefore I implore you to revert this change.

Also, there is no need to mention Taiwan in the language lists of the Welcome Screen News module and Krita.org. The only place that uses "正體中文" is Taiwan, elsewhere it is labeled as "繁體中文". Everyone knows this, nobody will mistake it to be anything not-Taiwan, the 繁體 (Traditional) to 正體 (Correct and Justified) change was already a political move in the first place and we have treated it as a safe middle ground for both side. Why breaking this delicate position we so desperately maintained?

Git commit e44b60165fc60c6c6ce09c3291533b51dd824d61 by Alvin Wong.
Committed on 04/06/2021 at 07:36.
Pushed by alvinwong into branch 'krita/4.3'.

Show country in language list for disambiguation


(cherry picked from commit 73be7ee9f0302069acce8fb6cc6b03a5d65d0f6d)

M  +16   -1    libs/widgetutils/xmlgui/kswitchlanguagedialog_p.cpp

https://invent.kde.org/graphics/krita/commit/e44b60165fc60c6c6ce09c3291533b51dd824d61

Git commit 79b777405b95b563248a6ef5db4289bf41051a62 by Alvin Wong.
Committed on 04/06/2021 at 09:30.
Pushed by alvinwong into branch 'master'.

Do not append country name to zh_CN and zh_TW

We don't need to do that, at least not until someone adds zh_HK
translations...

M  +4    -1    libs/widgetutils/xmlgui/kswitchlanguagedialog_p.cpp

https://invent.kde.org/graphics/krita/commit/79b777405b95b563248a6ef5db4289bf41051a62

Git commit 6495e76cc454f9d1ff98901fa06c3e017da69ebe by Alvin Wong.
Committed on 04/06/2021 at 09:34.
Pushed by alvinwong into branch 'krita/4.3'.

Do not append country name to zh_CN and zh_TW

We don't need to do that, at least not until someone adds zh_HK
translations...


(cherry picked from commit 79b777405b95b563248a6ef5db4289bf41051a62)

M  +4    -1    libs/widgetutils/xmlgui/kswitchlanguagedialog_p.cpp

https://invent.kde.org/graphics/krita/commit/6495e76cc454f9d1ff98901fa06c3e017da69ebe

Sorry for the long text, and thank you for the latest change. I really had a heart attack when I saw how it looked in the new nightly.

If you must disambiguate between HK and TW in the future, a safe and sensible middle ground is to NOT tag Simplified Chinese with any region.

Otherwise you are only going to hurt people who support Krita and possibly sympathize with your cause.

We can't always choose the circumstances we live in, especially that of the political correctness and jurisdiction we are subjected to. At the end of the day, people just want to draw with Krita peacefully. So please be more considerate.

I think Alvin's final version solved what Tyson worried. It won't show country name after the language name. For possible zh_HK language, I don't think we need worry it very soon.