Bug 509902

Thank you for the bug report!

However Plasma 6.3.4 no longer receives updates or maintenance from KDE; active versions are 6.4 or newer. Please upgrade to an active version as soon as your distribution makes it available to you. Plasma is a fast-moving project, and bugs in one version are often fixed in the next one.

If you need help with Plasma 6.3.4, please contact your distribution, who bears the responsibility of providing help for older releases that are no longer receiving updates from KDE.

If you can reproduce the issue after upgrading to an active version, feel free to re-open this bug report.

This problem still persist for kde 6.4.5

I confirmed the same bug on KDE Plasma (6.4.90) (KDE neon Testing Edition)

I ran some more tests today, and the issue seems to only occur with pt_BR. I specifically tested languages ​​with code longer than two characters (en_GB and ca@valencia, for example), and it seems that the bug only occurs when I set pt_BR as default language.

The workaround I've been using (individually changing the language settings for each app) isn't 100% effective, as libraries and some apps  continue to respect the system's default setting (which in this case is the one mentioned above - primary: pt, fallback: pt_BR; fallback 2: pt, fallback 3: pt). A more complete workaround was to manually delete (or rename) the entire 'pt' translation from my system (/usr/share/locale/pt) to force the system to use the fallback (pt_BR). By doing this, I fixed several translation issues I had already noticed.

By searching the KDE code, I saw that the regional settings module is in the plasma-workspace package. I noticed that there are some specific lines of code that manipulate pt_BR in the languagelistmodel.cpp file (plasma-workspace/kcms/region_language/). Could this have anything to do with the bug?

The "correct" language setting is in the "Region & Language" section of **System Settings** Application. The attachment shows the language setting for Kate. Can you check if the result is correct after setting the language to "Portuguese (Brazil)" in System Settings and reboot the system?

(In reply to hanyoung from comment #5)
> The "correct" language setting is in the "Region & Language" section of
> **System Settings** Application. The attachment shows the language setting
> for Kate. Can you check if the result is correct after setting the language
> to "Portuguese (Brazil)" in System Settings and reboot the system?

Yes. As mentioned above, the language is configured correctly in the system settings, on the "Region & Language" page. However, when configured, it applies the aforementioned default (pt as the primary language and pt_BR as the fallback) to all KDE/Plasma applications. The screenshot I showed was just an example of a KDE app, in this case Kate, that prioritizes pt over pt_BR after systemsettings setup. I've attached two more screenshots with the system settings. I ran the same test with the aforementioned list of distributions, with the same result. If you setup your system for pt_BR, you will get the same result for KDE apps. For other languages, this bug does not happen.

Created attachment 185259 [details]
System Settings setup - Region and Language page

Created attachment 185260 [details]
System Settings setup - Region and Language page (another screenshot)

If the $LANGUAGE and $LC_* env is correct, then it's applications' problem. Or simply just a lack of translation for Brazilian Portuguese.

(In reply to hanyoung from comment #9)
> If the $LANGUAGE and $LC_* env is correct, then it's applications' problem.
> Or simply just a lack of translation for Brazilian Portuguese.

I think you misunderstood. After configuring it in the system settings, KDE changes the default application language for all KDE apps, which we see in the "Settings -> Configure Language" app menu. It does this for any changes made to the system settings. However, when I set, for example, 'pt 'as the default language or 'en_GB' as the default language, KDE sets 'pt' or 'en_GB' as the primary language for its apps (correctly). However, when I set 'pt_BR' as the language, KDE mistakenly sets 'pt' as the primary language. That's where I'm pointing out the error.

> After configuring it in the system settings, KDE changes the default application language for all KDE apps

This is incorrect. System setting are only responsible for setting the ~/.config/plasma-localerc file. Plasma will set the $LANG and LC_* vars according to the contents of that file.

(In reply to hanyoung from comment #11)
> > After configuring it in the system settings, KDE changes the default application language for all KDE apps
> 
> This is incorrect. System setting are only responsible for setting the
> ~/.config/plasma-localerc file. Plasma will set the $LANG and LC_* vars
> according to the contents of that file.

Who controls the order of entries in the "Settings -> Configure Language" menu of all KDE applications? These entries aren't respecting the settings in systemsettings and plasma-localerc. They're not respecting system variables either. Is this done by Qt or KDE? The fact is, the behavior of these entries isn't consistent. And the fact is, the 'pt' translation, which is outdated compared to the 'pt_BR' translation, is being used by default.

I can reproduce your problem, and I confirm this is indeed not a system settings problem. The related code is at https://invent.kde.org/frameworks/kxmlgui/-/blob/master/src/kswitchlanguagedialog_p.cpp?ref_type=heads

(In reply to hanyoung from comment #13)
> I can reproduce your problem, and I confirm this is indeed not a system
> settings problem. The related code is at
> https://invent.kde.org/frameworks/kxmlgui/-/blob/master/src/
> kswitchlanguagedialog_p.cpp?ref_type=heads

Good to know. Thank you very much. Now, it's important to note that the issue impacts apps that don't have access to this menu. For example, systemsettings itself doesn't use 'pt_BR' by default when this language is selected. It uses 'pt' like other apps. I know this because I've noticed strings translated to 'pt' instead of 'pt_BR' in my interface. And in this case, I can't even manually change this setting. In Dolphin, which has access to the menu, it fixes some things, but I've noticed that others don't, probably due to libraries that have the same issue. I don't know exactly why. What's the next step for this bug? Do I need to change the package it refers to?

I think I have figured out what happened in kxmlgui. Specifically, this block of code:
```
for (int i = 0; i < languagesList.count();) {
        QString languageCode = languagesList[i];
        if (!KLocalizedString::isApplicationTranslatedInto(languageCode)) {
            if (stripCountryCode(&languageCode)) {
                if (KLocalizedString::isApplicationTranslatedInto(languageCode)) {
                    languagesList[i] = languageCode;
                    ++i;
                    continue;
                }
            }
            languagesList.removeAt(i);
        } else {
            ++i;
        }
    }
```
The languagesList is QList("pt_Latn_BR", "pt_BR", "pt_Latn", "pt"), we check if the application has the translation for each language.

I'm pretty sure we only have translations for "pt_BR" and "pt_PT".
Now, for the first language we check -- "pt_Latn_BR", we don't have translation for that, so the function "stripCountryCode" is executed.
After stripping country code, the language becomes "pt", and we have translation for "pt", so the first language in the list is "pt", the first item in the list is used as primary language.

The fault is in "stripCountryCode", this essentially turns "pt_Latn_BR" into "pt".

I'll come up with a fix tomorrow after work, since it's midnight here.

(In reply to hanyoung from comment #15)
> I think I have figured out what happened in kxmlgui. Specifically, this
> block of code:
> ```
> for (int i = 0; i < languagesList.count();) {
>         QString languageCode = languagesList[i];
>         if (!KLocalizedString::isApplicationTranslatedInto(languageCode)) {
>             if (stripCountryCode(&languageCode)) {
>                 if
> (KLocalizedString::isApplicationTranslatedInto(languageCode)) {
>                     languagesList[i] = languageCode;
>                     ++i;
>                     continue;
>                 }
>             }
>             languagesList.removeAt(i);
>         } else {
>             ++i;
>         }
>     }
> ```
> The languagesList is QList("pt_Latn_BR", "pt_BR", "pt_Latn", "pt"), we check
> if the application has the translation for each language.
> 
> I'm pretty sure we only have translations for "pt_BR" and "pt_PT".
> Now, for the first language we check -- "pt_Latn_BR", we don't have
> translation for that, so the function "stripCountryCode" is executed.
> After stripping country code, the language becomes "pt", and we have
> translation for "pt", so the first language in the list is "pt", the first
> item in the list is used as primary language.
> 
> The fault is in "stripCountryCode", this essentially turns "pt_Latn_BR" into
> "pt".
> 
> I'll come up with a fix tomorrow after work, since it's midnight here.

Once again, thank you very much!

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/297

Git commit 15f457f5a4d83614d49e7a01ec4092f0f8d07c84 by Han Young.
Committed on 26/09/2025 at 13:57.
Pushed by hanyoung into branch 'master'.

switchlanguage: push country stripped language code to the back of the list

If the $LANGUAGE is pt_BR.UTF-8, the QLocale().uiLanguages() returns
QList("pt_Latn_BR", "pt_BR", "pt_Latn", "pt").
We check the translation support of each language code one by one.
If the language is unsupported, we strip the country from the code,
then check the new language code again.

In the pt_BR.UTF-8 case, the first language code "pt_Latn_BR" is
unsupported, after stripping, the code became "pt", which is supported.

This behavior is incorrect, because the result language list is
[pt, pt_BR] instead of [pt_BR, pt].

Push the country stripped language code to the back of the list ensure
the proper precedence.

M  +1    -5    src/kswitchlanguagedialog_p.cpp

https://invent.kde.org/frameworks/kxmlgui/-/commit/15f457f5a4d83614d49e7a01ec4092f0f8d07c84

SUMMARY
- I tested this patch on KDE Neon unstable (with the last compilation that included this patch), and the bug has been partially resolved. 
- Applications that have the "Settings -> Configure Language" menu now correctly select pt_BR as the primary language. 
- However, applications that don't have this menu option, such as KDE's own systemsettings, and likely KDE libraries that don't have an interface, continue to select 'pt' instead of 'pt_BR'.

STEPS TO REPRODUCE
- Select Brazilian Portuguese (pt_BR) as the KDE language (System Settings -> Region and Language).
- Go to the System Settings -> Spell Checking page.

OBSERVED RESULT
- The translation used on this page is not 'pt_BR', but 'pt'.

EXPECTED RESULT
- The 'pt_BR' translation should be used.

SOFTWARE/OS VERSION
- KDE-Neon unstable version, with patch applied.

Additional Information
- As I said, the patch fixed the issue for most applications, but it didn't fix it for system libraries or applications that don't have a "Settings -> Configure Language" menu.
- Note that this difference isn't immediately apparent because there are many common translations. But there are also differences.
- I was able to verify this by performing the following workaround:
    - In KDE Neon, I renamed the system folder containing the European Portuguese (pt) translations (/usr/share/locale/pt) to other name (/usr/share/locale/pt_off).    
    - By doing this, I remove all European Portuguese (pt) translations from my system. (forcing the use of pt_BR translation).

- I've attached two screenshots that prove this (one with the 'pt' translation displayed before the workaround, and another with the 'pt_BR' translation displayed after workaround).
- When I re-enable the 'pt' translation, the bug comes back.

Created attachment 185489 [details]
Screenshot with 'pt' translation active

In this image, I've highlighted the translation of string 1, which is in European Portuguese.
Strings 2 and 3 are not translated because these strings have not been translated into European Portuguese.

Created attachment 185490 [details]
Screenshot with 'pt_BR' translation active

In this image, strings 1, 2, and 3 are all translated into Brazilian Portuguese.

In the attached images, I've only highlighted a few differences. If you look closely, you'll see that several texts are different. The fact is that in applications like systemsettings, pt_BR is sometimes used, sometimes not. It depends on the translation into European Portuguese, which shouldn't be the expected behavior.

(In reply to Marcus Gama from comment #20)
> Created attachment 185489 [details]
> Screenshot with 'pt' translation active
> 
> In this image, I've highlighted the translation of string 1, which is in
> European Portuguese.
> Strings 2 and 3 are not translated because these strings have not been
> translated into European Portuguese.

Isn't the "default language" shows Brazilian Portuguese?

(In reply to hanyoung from comment #23)
> (In reply to Marcus Gama from comment #20)
> > Created attachment 185489 [details]
> > Screenshot with 'pt' translation active
> > 
> > In this image, I've highlighted the translation of string 1, which is in
> > European Portuguese.
> > Strings 2 and 3 are not translated because these strings have not been
> > translated into European Portuguese.
> 
> Isn't the "default language" shows Brazilian Portuguese?

Yes. The 'default language' is Brazilian Portuguese. 

I've already detected some libraries that present this issue, even with the default language set to pt_BR. 

In addition to 'sonnet,' which is responsible for the spellchecking configuration module, I've also observed this behavior in kcoreaddons or plasma-workspace. These are libraries that, from what I've observed, provide MIME type information to Dolphin. The string 'Just now' (used in the modification date when a file is recently changed) in the pt_PT translation is translated as 'Mesmo agora,' which in Brazil is an incorrect expression. In pt_BR, the translation is correct for 'Agora mesmo.' If I don't use the workaround, the text pt_PT appears. When I use the workaround, the correct text, pt_BR, appears. There are other apps  and libs  that still have this problem.

Note that in the workaround, I don't change the 'default language.' I just remove the pt_PT translations folder from the system, which indicates that these applications are giving priority to pt_PT even when the default language is pt_BR. Why? I don't know.

I'm not a programmer, but I've been trying to explore the C++ code to figure out which code tells the application which translation to use. I've already explored the KLocalizedString class, but my knowledge isn't sufficient to understand it yet. I suspect that the routine being used to tell the program to use translation A or B may be experiencing the same issue detected in the KXMLGUI routine. 

I initially thought the issue would be fixed with the KXMLGUI patch, but the symptoms in apps and libs that don't have the 'configure language' menu suggest that it might be elsewhere. The fact is that some libbs and apps continue to use pt_PT instead of pt_BR, even with the default language configured correctly. And the only solution I've found so far was to manually remove all pt_PT translations from the system so that pt_BR would be used as a fallback.

Turns out there is another unrelated but essentially same bug in extra-cmake-modules. Because the sonnet settings module is part of sonnet, a KDE tier one framework, thus cannot use KDE i18n framework, there is a QTranslator loader to convert Gettext .po files into Qt Translation .pm files. The said loader also determine the language precedence.

The bug is in https://api.kde.org/ecm/module/ECMPoQmTools.html, the generated loader produces language list like below. 

QList("pt_Latn_BR", "pt", "pt_BR", "pt_Latn")

That's why you will see European translations despite having Brazilian locale.

(In reply to hanyoung from comment #25)
> Turns out there is another unrelated but essentially same bug in
> extra-cmake-modules. Because the sonnet settings module is part of sonnet, a
> KDE tier one framework, thus cannot use KDE i18n framework, there is a
> QTranslator loader to convert Gettext .po files into Qt Translation .pm
> files. The said loader also determine the language precedence.
> 
> The bug is in https://api.kde.org/ecm/module/ECMPoQmTools.html, the
> generated loader produces language list like below. 
> 
> QList("pt_Latn_BR", "pt", "pt_BR", "pt_Latn")
> 
> That's why you will see European translations despite having Brazilian
> locale.

Good to know that at least the cause has been identified. It makes sense. kcoreaddons would fall into the same category.

As I said, I'm not a programmer, but I contribute to the translation, and it was frustrating to see the translation not being used due to some issue I couldn't identify. In the last few months, we managed to get the pt_BR translation of the interface to 100%, so there shouldn't be any untranslated strings.

Is there already a bug report open for this issue? Do I need to do anything?

And Thank you for your support.

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/559

>  In the last few months, we managed to get the pt_BR translation of the interface to 100%, so there shouldn't be any untranslated strings.

Thanks for your effort on translations! I've long gave up on the Chinese localizations :P

Git commit 1bc794fcd741f64c1caac2d130c6f9a921422854 by Han Young.
Committed on 22/10/2025 at 01:38.
Pushed by hanyoung into branch 'master'.

ECMQmlLoader: generic languages should have lower precedence

In ECMQmlLoader, we convert uiLanguages into locale list. If the
language has country code, we also add the country stripped generic
language **JUST AFTER** the origin language. This behavior is incorrect.

If the $LANGUAGE is pt_BR.UTF-8, the QLocale().uiLanguages() returns
QList("pt_Latn_BR", "pt_BR", "pt_Latn", "pt").

After stripping, the first language "pt_Latn_BR" became "pt",
and "pt" is added immediately behind. The resulting language list then
became [pt, pt_BR] instead of [pt_BR, pt]. **This means users with
language set as Brazilian Portuguese will see the European Portuguese
translations.**

Push the country stripped language code after the same language dialect
to ensure the proper precedence.

M  +25   -5    modules/ECMQmLoader.cpp.in
M  +4    -0    tests/ECMPoQmToolsTest/check.cmake.in
A  +22   -0    tests/ECMPoQmToolsTest/tr_test-po/pt/catalog.po
A  +22   -0    tests/ECMPoQmToolsTest/tr_test-po/pt_BR/catalog.po

https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/1bc794fcd741f64c1caac2d130c6f9a921422854