Multiple linux bug fixes

[AhegaoZKun]

Fixed an undeclared variable
Fixed the interface language not updating to what the user saved in settings in real time
Fixed an issue where the setup wizard on linux would not update the shown language when the dropdown box was selected to something other than russian. (It used to stay russian despite the selection.)
Added a function to find the users locale and use that as the shown language first, fallsback to russian if the locale can't be read or doesn't map the three supported languages.

[AhegaoZKun]

Rechecking for the lint and test error

[Yumash]

Thanks — this is a real gap and three of the four things you fixed had been broken since the GTK frontend landed. I've reviewed it and pushed a commit onto this branch (09dd423) rather than sending you round again for something I could do in one pass. Everything below is either a defect I found or a reason for a change I made; nothing here is a request for more work from you.

The one defect

_guess_locale_lang() was called inside the block that opens the wizard, and that block runs on more than a first run:

if not os.path.exists(CONFIG_FILE) or not any_configured(config.providers):

The second half is not a first run. It's true whenever no provider is configured — an expired key does it, and so does a config file written before providers became a registry in 3.4.0. Such a file exists, and it names a language its owner chose. Guessing there isn't just a mislabelled window: the welcome page now seeds its dropdown from tr.get_language() (correctly — that's your change), and _finish() writes that dropdown back to c.ui_language. So a Spanish user whose key expired would open the wizard in German, click Next four times, and find their language saved as German.

The condition is now split, and the rule lives in one function both entry points call:

def startup_ui_language(*, config_exists: bool, saved: str) -> str:
    return saved if config_exists else guess_ui_language()

What else changed, and why

The guess moved to app/i18n.py. Two reasons. It was carrying a fourth copy of the supported-language list — ("RU", "EN", "ES") is already UI_LANGUAGES there, and _UI_LANGS twice more in the GTK wizard and settings window; a fourth translation would have been silently unreachable from the guesser. And in main_gtk.py it couldn't be tested: that module imports gi at the top, so CI can't import it at all, which is why 173 lines arrived without a test. It's 25 tests now.

Environment variable order. You had LC_ALL, LC_MESSAGES, LANG, LANGUAGE. gettext resolves LANGUAGE first, not last — it's the variable people set precisely to override LANG, and checking it last means never honouring it. It's also a colon-separated preference list (de:es:ru), which the old parse would have read as a language called de:es:ru. Both handled, both tested. An unsupported language in one variable also no longer ends the search: LANGUAGE=de LANG=es_ES gets Spanish rather than the Russian default.

Windows gets the first-run guess too. app/main.py had the same "Russian for everyone on first launch" behaviour, and its wizard already seeds from tr.get_language(), so it needed nothing but the shared call.

Three small ones in your diff. self._title_label, self._settings_button and self._quit_button are assigned and never read — the title is a brand name and the other two are glyphs, so apply_language has no use for them; removed. The resize grip's tooltip (overlay.resize_hint) was the one translated string apply_language missed; added. And _run_validation's done() callback re-enables the button it started from, which a language switch may have destroyed in the meantime — guarded with btn.get_parent() is not None.

Two things I left alone

_start_pipeline_if_ready. It can't fire in a normal build: control only reaches it after the wizard, and _finish always writes the keyless MyMemory entry, so any_configured is true by then. Harmless as a failsafe if provider registration ever fails, so I kept it — but it's the one part of this PR that isn't a Linux bug fix, and it puts GTK out of step with Qt, where pipeline.start() is unconditional. Worth knowing it's there.

The Qt overlay still doesn't relabel itself. settings_dialog.py calls tr.set_language() and no Windows widget hears about it — exactly the bug your apply_language() fixes on GTK. That's a bigger job than this PR and I've queued it separately rather than growing yours.

Released as 3.5.0

New behaviour (locale detection), so a minor bump: pyproject.toml, the TOC, Config.lua's fallback, about_dialog.py, and both changelogs. CI's test floor goes 1015 → 1040 for the new tests. Suite is 1114 passing, 3 skipped; ruff clean.

[Yumash]

Reviewed my own commit above and found two defects in it. Both are fixed in 53a5aa0; neither ever shipped, so 3.5.0 stays 3.5.0.

The locale guess didn't work on Windows at all — including for the case that motivated it. locale.getlocale() doesn't return an ISO code there; it returns the C runtime's name for the locale. Measured on this machine:

getlocale()        -> ('Russian_Russia', '1252')
getdefaultlocale() -> ('ru_RU', 'cp1252')          # deprecated for removal
GetUserDefaultUILanguage() -> 1049 -> 'ru_RU'

So _codes_in produced RUSSIAN, never matched UI_LANGUAGES, and every Windows first run fell through to the Russian default — the exact behaviour the change claims to fix. My test passed only because it mocked ("es_ES", "UTF-8"), a shape Windows never produces. It now asks Win32 for GetUserDefaultUILanguage and maps it through locale.windows_locale, which is also the better question: Windows keeps the interface language separate from the formats locale, and it's the former we want.

os.path.exists(CONFIG_FILE) was the wrong question for "is this a first run". AppConfig.load also reads config.json.bak. With only the backup present it hands back a real saved ui_language that startup_ui_language discards a line later as a first run — and on GTK the wizard opens too and writes the guess back on finish, so the recovered choice is destroyed. Which is precisely what that function's docstring says it prevents; I'd fixed the reported instance of this bug and left another one next to it.

It's config.py's question now:

def saved_config_exists(path: str = CONFIG_FILE) -> bool: ...

sharing _config_candidates() with load() so the two can't come to look at different files. It parses rather than stats, which also gets the corrupt-config case right: a config that won't parse, with no backup, makes load() return defaults, so treating the file's presence as a saved preference would show a Russian wizard to someone who has never run the app.

Twelve tests added for the two, the fixture now neutralises the Windows lookup as well (CI runs on an English Windows runner, so leaving it live would have had the runner answering the "no locale anywhere" tests), and there's an AST guard so neither entry point can go back to statting the config path. 1126 passing, 3 skipped; ruff clean.

[Yumash]

Merged and released as v3.4.1. Thank you — this started as four Linux fixes and turned out to be the thread that unravelled the same defect on four different windows.

First, a correction to my two earlier comments: the version is 3.4.1, not 3.5.0. I bumped the minor number on the grounds that locale detection was a new feature. It is not: the app has offered three interface languages since long before this branch and opened in Russian regardless, on both platforms. Fixing that is a patch. The changelog entry lost its Added section along with the number, and lost two bullets describing defects that only ever existed inside this branch — a changelog is for what changed for the people running it.

What your PR turned up

The defect you reported on Linux — the wizard not following its own dropdown — had three siblings, all of the same shape: one frontend fixed, the other described as fixed.

	before	now
Saved language applied at startup	Qt only	both
First run follows the OS locale	neither	both
Overlay relabels on change	GTK (your fix)	both
Tray menu translated at all	Qt only	both
Tray menu relabels on change	neither	both
Wizard keeps typed input across a language change	GTK (your fix)	both

The one that would have hurt most was in the first version of my own fix: locale.getlocale() does not return an ISO code on Windows, it returns the C runtime's name for the locale — measured here, ('Russian_Russia', '1252'). Nothing matched, every Windows first run fell through to Russian, and the test passed because it mocked the POSIX shape Windows never produces. GetUserDefaultUILanguage answers properly, and is the better question anyway: Windows keeps the interface language separate from the formats locale.

Notes on your diff specifically

Everything you wrote is in the release. Three things I changed and one I removed:

• The locale guess moved to app/i18n.py. It was carrying a fourth copy of the supported-language list, and in main_gtk it could not be tested at all — that module imports gi, so CI cannot import it, which is why 173 lines arrived without a test.
• Environment order is gettext's now: LANGUAGE first rather than last, parsed as the colon-separated preference list it is.
• The guess is consulted only when no config file exists. Your version ran it whenever no provider was configured, which also happens with an expired key — and since the welcome page seeds its dropdown from the language on screen and finish writes that back, a Spanish user clicking through would have found it saved as German.
• _start_pipeline_if_ready is gone. It could not fire, and it would have been wrong if it could: TranslationPipeline builds its TranslatorService in __init__ and update_config never rebuilds it, so the one case it existed for would have started a pipeline that cannot translate.

Four review passes, 1015 → 1146 tests, and the pattern is now written into the suite: anything both frontends do is asserted against both modules, so the next half-fix fails the build instead of the changelog.

Released to GitHub, CurseForge and Wago. Nothing further needed from you — thanks again for finding the loose thread.