Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.15.0
-
None
-
Mac OS X 10.14.6, Qt 5.15.0
-
-
8
-
8df2bf04917e742470bbd1ff69e003811c5975ff (qt/qtbase/dev) 2537b5c6c34a360f943fd79327eee7a7ba6c3fc8 (qt/qtbase/6.0) e6e23d061cb8ac81007119603f8e7c64fc572e04 (qt/qtbase/5.15)
-
Qt6_Foundation_Sprint 23
Description
The search algorithm used by the QTranslator::load() methods will select a non-preferred (but available) language if there happens to be an exact translation match. This leads to unexpected behaviour of picking a non-preferred language. For example, demonstrated this on a mac with available UI language options:
- en-GB // British English is selected region and language
- pt-BR // Brazilian regional Portugês available but not preferred
On an application with available translations:
- app_en.qm
- app_pt_BR.qm
The search algorithm first searches through all UI languages for an exact match. If no exact match is found, it then tries removing the region from any regionalised UI languages and comparing those.
So in the case above, it finds an exact match for Brasil in the first pass, and returns that.
This is almost certainly contrary to user expectation. In general language preference is more important to the user than regionalisation, but specifically in this case, the generic "en" translation should be considered a match for "en-GB" since it makes no specification on region.
I would propose that the correct behaviour should be:
- A generic region-free language translation should be considered a match for a UI language with a specified region.
The 'fuzzy' matching can be otherwise unchanged.