Fix locale comparison when loading system translations

Environment information

• Operating System: Windows 11 25H2

• Cutter version: 2.5.0-dev-d7f11b2

• Obtained from:

  • Built from source
  • Downloaded release from Cutter website or GitHub
  • Distribution repository

• File format: N/A

Describe the bug

When building Cutter from source and copying the generated .qm translation files from:

build/src/translation

to:

%APPDATA%/cutter/translations

Cutter still fails to correctly display the system locale translation.

The translation file is present in the expected directory, but Cutter does not select the corresponding translation for the system locale.

The issue appears to be related to how Cutter compares QLocale objects when determining the appropriate translation.

Cutter appears to use QLocale::operator== to determine whether two locales represent the same language and territory. However, this is not the semantics documented by Qt for QLocale::operator==.

The official Qt documentation states:

“Returns true if the two QLocale objects, lhs and rhs, are the same; otherwise returns false.”

It also explicitly states:

“The system locale is not equal to the QLocale object constructed from its language(), script() and territory(), even if the two agree in all data fields. Nor are two locales with different number options equal.”

See the Qt documentation for [QLocale::operator==](https://doc.qt.io/qt-6/qlocale.html).

Therefore, using QLocale::operator== to determine whether two locales have the same language/territory can result in a mismatch, even when the locale information appears identical.

To Reproduce

Steps to reproduce the behavior:

1. Build Cutter from source.
2. Copy the generated .qm files from build/src/translation to %APPDATA%/cutter/translations.
3. Configure Windows 11 to use a supported non-English system language.
4. Start Cutter.
5. Observe that Cutter does not correctly select and display the corresponding system language translation.

The suspected problematic behavior is the comparison of QLocale objects using operator==.

For example, Qt documents that the following two locales are not necessarily considered equal:

QLocale systemLocale = QLocale::system();

QLocale constructedLocale(
    systemLocale.language(),
    systemLocale.script(),
    systemLocale.territory()
);

bool equal = systemLocale == constructedLocale;

Even if language(), script(), and territory() agree, operator== may still return false.

Expected behavior

If Cutter intends to determine whether two locales represent the same language, script, and territory, the comparison should explicitly compare those properties rather than relying on QLocale::operator==.

For example:

a.language() == b.language() &&
a.territory() == b.territory()

The appropriate comparison should of course depend on the intended semantics of Cutter's translation selection logic.

After placing the correct .qm file in %APPDATA%/cutter/translations, Cutter should correctly detect the system locale and load the corresponding translation.

Screenshots

before:

after:

Additional context

This appears to be a semantic misuse of QLocale::operator==.

Qt's documentation explicitly distinguishes equality of QLocale objects from equality of their language, script, and territory properties. In particular, Qt documents that the system locale and a locale reconstructed from its language(), script(), and territory() are not necessarily equal, even when those locale fields agree.

Qt documentation:

https://doc.qt.io/qt-6/qlocale.html

The issue may be resolved by using an explicit comparison of the locale properties relevant to Cutter's translation selection logic.