QSettings Language

Perdrix

The following code on Linux returns "C" whereas I expected it to return (e.g. en_GB):

// Try to load each language file - allow failures though (due to issue with ro and reloading en translations)
	QSettings settings;
	const QString language = settings.value("Language").toString();

What am I not doing, or doing wrong?

Thanks

JonB

@Perdrix said in QSettings Language:

My humble apologies. Do we delete the thread?

:) Noooo, never delete (sensible) threads like this, they are always potentially useful to the future, and it upsets (people like me) who have posted answers to see them reduced to cinders :) But do mark this topic as "solved".

So whatever your issue is it no longer has anything to do specifically with QSettings, right?

Pl45m4

@Perdrix

Would you like to post the post then? :D

Perdrix

Now added missing part of the post

JonB

@Perdrix said in QSettings Language:

The following code on Linux returns "C" whereas I expected it to return (e.g. en_GB):
QSettings settings;
const QString language = settings.value("Language").toString();

QSettings settings creates an empty settings. And hence settings.value("Language").toString(); returns an empty string, "", not "C". So it is not clear what else you are doing in whatever extra code you have beyond what you show or what you might have in some .ini file/Windows registry key.

Perdrix

All I know is what the debugger tells me and the value returned is most definitely "C" clearly this is the default locale for this Linux system. If I want to default to en_GB I suppose I could add a hack that says it C make it en_GB

This code is about to load the translation files for the user and because the language is C I get:
Loading translator file [ "qt_C" ] from path: "/opt/Qt/6.8.0/gcc_64/translations"
*** Failed to load file [ "qt_C" ] into translator
Loading translator file [ "DeepSkyStacker_C" ] from path: ":/i18n/"
*** Failed to load file [ "DeepSkyStacker_C" ] into translator
Loading translator file [ "DeepSkyStackerKernel_C" ] from path: ":/i18n/"
*** Failed to load file [ "DeepSkyStackerKernel_C" ] into translator

David

Perdrix

maybe I'm not doing things the "right way"

ChrisW67

QSettings will return the value in the settings location (an INI file, Windows registry etc.). If you wrote value "C" to key "Language" earlier then that is what you will get back. If the key does not exist then you get back an empty value or the default you gave QSettings::value() (nothing in your case).

The name and location of the settings storage is driven by the arguments given to the constructor (none in your case), the values set in QCoreApplication::setOrganizationName() and friends, and search path.

How have you configured QCoreApplication?
How did you create the settings you are trying to read?

Perdrix

You are all barking up the wrong tree this is all controlled by the Linux Locale which was set to C for some reason.

QCoreApplication reads the locale and sets the Language setting

Christian Ehrlicher

@Perdrix said in QSettings Language:

QCoreApplication reads the locale and sets the Language setting

Maybe, but you can not read it thorugh a QSettings object like you're doing above...

Axel Spoerl

Sorry, but can we take a step back here: The thread says “QSettings Language”.
What’s the problem you are trying to solve?
I can only see a settings file being read.
Where is it written?

JonB

@Perdrix said in QSettings Language:

You are all barking up the wrong tree

Thanks! May I suggest it is you who are either barking up the wrong tree or misleading us/yourself with the minimal code you present :)

// Try to load each language file - allow failures though (due to issue with ro and reloading en translations)
	QSettings settings;
	const QString language = settings.value("Language").toString();

As I wrote earlier (and as per @ChrisW67's post too), these two lines of code do not produce either C or en_GB. They produce the empty string, as there are no items in settings. If you tried it for yourself in a standalone program you would see that. This code as shown does not even read any .ini file or Windows registry entries, because you have not set necessary properties on the QCoreApplication nor passed parameters to QSettings() to tell it do so --- what .ini file/registry entry would it look at?

This means that prior to what you show --- perhaps in preceding "Try to load each language file" or elsewhere --- something is setting up QCoreApplication to tell QSettings what to read (.ini/registry) when it is created. And that is where there is a key Language=C for the C you say it outputs.

QCoreApplication reads the locale and sets the Language setting

No, it does not. As in, it does not set anything in any QSettings for a Language key. It may use the current locale for whatever purposes, but this has nothing to do with QSettings.

So you have two things to determine:

Where in earlier code is QCoreApplication changed (as per https://doc.qt.io/qt-6/qsettings.html#QSettings) to cause QSettings to read .ini/registry from, and why does that have a Language=C in it if that's not what you want/expect?
Given this, how/where is this setting in the constructed QSettings used to influence the translations, which you are presumably not happy with? Maybe that uses a QSettings::value("Langauge") if one is present, or maybe that is purely set from the current locale and it is the latter which influences translations so the QSettings is an effect but not a cause, I don't know. If Qt's own code does not construct a default QSettings and look for a Language key to affect translations then this whole question being about QSettings is "barking up the wrong tree" :)

Perdrix

My, that crow is tasty!!!

You are right, and I was operating on some false assumptions.

My humble apologies. Do we delete the thread?

D

JonB

@Perdrix said in QSettings Language:

My humble apologies. Do we delete the thread?

:) Noooo, never delete (sensible) threads like this, they are always potentially useful to the future, and it upsets (people like me) who have posted answers to see them reduced to cinders :) But do mark this topic as "solved".

So whatever your issue is it no longer has anything to do specifically with QSettings, right?

Perdrix

@JonB Nothing to do with QSettings. It was a Unix locale issue. It turns out that the QSettings stuff was left there by the original developer of that code to allow testing without switching the language of his system. It mightily confused me ...