KSP-CKAN
All text is in Chinese after update
I updated CKAN to the current version and it changed the program language to chinese. I cannot change it back to english and do not know where to fix this.
Open the second menu, first option to get to the settings, then there's a language dropdown towards the bottom. Change it and restart.
I was able to find the config file under AppData after some digging and change it there. I don't know how it got changed in the first place. :/
Yeah somebody reported the same on Discord a couple of days ago. No clear pattern yet.
It's interesting that this is linked to CKAN upgrades. That vaguely suggests a timing or race condition in which the old CKAN has not finished saving its settings somehow when the new CKAN is started.
But after auditing the config saving/loading/parsing and language setting code, I do not see any way that it could randomly get set to zh-CN in a typical en-US or en-GB environment. If the config.json file doesn't exist, it falls back to the old registry if applicable, or instantiates a new object in which config.Language would be null, which would cause it to use the culture inherited from the environment.
Is there some way that Thread.CurrentThread.CurrentUICulture could be set to Chinese by mono at startup on a non-Chinese PC? Very doubtful.
Maybe Autofac is to blame somehow? It is involved in loading the settings, and the only piece of this that I am not confident I understand. The code in ServiceLocator is... weird, a little awkward, hard to follow. Not inconceivable that there would be bugs there, I suppose.
Another case reported on the r/KSP Discord. Only information I was able to get was
Not sure. I tried to install another mod when I received an error message. I restarted the application and noticed the language change
Another case reported on Discord, yet again Chinese. No CKAN update, but a hard shutdown by killing ckan.exe with Alt+F4. Still no idea how this could make CKAN switch language...
It wouldn't install mods so I just restarted it Yes. It sait something like "unable to install mods." "retry?" And I just Clicked or Alt +F4d the window and restarted the CKAN.exe
This comment might be useless, but anyway: it seems that the language gets switched to the last one on the list.
People got Chinese, until French was added at the end of the list and now people get French (I assume Toke got French, since CKAN is not translated in Spanish).
I have absolutely no idea what the reason is code-wise (since I have little coding knowledge), but it seems to be related
This comment might be useless
No, it's a good insight, you might be completely right about that. So if we can't figure out a full fix, a workaround would be to rearrange the list to put en-GB or en-US at the end. :grin:
In my previous audit of the i18n code, I looked at how the setting is handled on startup. I've checked that code again a couple of times since, and it still looks rock-solid to me.
That leaves the settings window language dropdown. For this to be the cause, each user reporting this must have opened and closed the settings window in the session before the problem started, without having chosen a language before, and just didn't mention it. I don't think that's too much of a stretch, since they'd have no reason to remember having done that.
Loading the combobox:
https://github.com/KSP-CKAN/CKAN/blob/303c47c318ee99768b271f901a9f9a226bce034f/GUI/Dialogs/SettingsDialog.cs#L106-L114
Setting SelectedIndex calls the change handler, which has a null reference bug hidden in it:
https://github.com/KSP-CKAN/CKAN/blob/303c47c318ee99768b271f901a9f9a226bce034f/GUI/Dialogs/SettingsDialog.cs#L544-L547
That will throw if LanguageSelectionComboBox.SelectedItem is null, which it will be if the user has never selected a language:
The object that is the currently selected item or null if there is no currently selected item.
But before we even get to that point, there may be some funny business with SelectedIndex. The FindStringExact call will return -1 if config.Language isn't in the language list. But SelectedIndex only supports -1 as a value if FormattingEnabled is true:
SelectedIndex, SelectedValue, and FormattingEnabled are related as follows:
- If FormattingEnabled is false, SelectedIndex will not be set to -1 when SelectedValue is blank.
- If FormattingEnabled is true, SelectedIndex will be set to -1 when SelectedValue is blank.
FormattingEnabled is not set:
https://github.com/KSP-CKAN/CKAN/blob/303c47c318ee99768b271f901a9f9a226bce034f/GUI/Dialogs/SettingsDialog.Designer.cs#L556-L565
And the default is false!
true if formatting of the DisplayMember property is enabled; otherwise, false. The default is false.
That means our combobox isn't using an index of -1 to represent null, but the documentation doesn't say what it represents instead in that case.
In Python, array[-1] refers to the last element in the array. Meanwhile here we have a -1 value of unknown meaning, and a value is being set to the last element of a list? Maybe that's not just a coincidence...
Purging the language field from my config.json, I get en-US when I first open the settings:
So that's being pulled from my environment. Maybe the people having this problem had a locale setting that isn't in our list?
Purging the JSON again and temporarily commenting en-US out of Utilities.AvailableLanguages gives me a blank combobox:
After that, config.json says:
"Language": null,
... and that seems to be stable. With a null value in the JSON, the combobox stays empty, and the JSON value stays null.
The JSON file is pretty well protected from corruption:
https://github.com/KSP-CKAN/CKAN/blob/303c47c318ee99768b271f901a9f9a226bce034f/Core/Configuration/JsonConfiguration.cs#L182-L203
A user reported this today on Discord. Their output from Get-WinSystemLocale:
LCID Name DisplayName
---- ---- -----------
1045 pl-PL Polish (Poland)
I did open the settings before but didn't change anything
That somewhat supports the theory that the settings window changes the setting accidentally sometimes.
That same user did some more poking around, and they have identified a possible cause for unintended setting changes:
If the user thinks the dialog may be scrollable, they may flick the mouse wheel to try to expose more settings. If the mouse cursor happens to be hovering over the language dropdown, this changes its value, even without clicking it.
That's pretty surprising, but it's also default WinForms behavior. We'll have to investigate to see whether it can be suppressed.
https://stackoverflow.com/questions/1882993/c-sharp-how-do-i-prevent-mousewheel-scrolling-in-my-combobox