Offer to apply archinstall language to target system locale and timezone#4495
Open
Softer wants to merge 2 commits intoarchlinux:masterfrom
Open
Offer to apply archinstall language to target system locale and timezone#4495Softer wants to merge 2 commits intoarchlinux:masterfrom
Softer wants to merge 2 commits intoarchlinux:masterfrom
Conversation
After picking an installer language with a known locale mapping, prompt the user to apply sys_lang, sys_enc, console_font, and (where the country maps to a single IANA zone) timezone to the target system. Each row is shown only when its target value differs from the current setting, so re-picking a language with fewer mappings resets stale fields too. default_timezone is set in languages.json only for unambiguous single mainland zones; multi-zone countries (en_US, ru_RU, es_ES, pt_BR, ...) and codes that span countries are left without a default. Timezone candidates are validated against list_timezones().
MenuItem.yes() and .no() cached their first-call result on the class, so labels stayed stuck in the language active at first call. With the new locale-apply Confirmation firing right after a language switch this became user-visible. Drop the cache and construct fresh items per call - allocation cost is negligible and equality continues to work via the dataclass __eq__.
Contributor
Author
|
Up front: I understand this is a big PR, and Python isn't my strongest language yet. Any feedback is very welcome :) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
After picking an archinstall language that maps to a known system locale, prompt the user to apply that locale (and matching console font / timezone, where unambiguous) to the target system. Confirms with a single Yes/No dialog listing every field that will change.
Single confirmation dialog. Lists only the fields that would actually change; if all three already match the target, the prompt is skipped silently.
Builds on #4469 (console font in Locales menu): that PR added the
console_fontmapping and a manual selector; this PR wires the same data into the language picker so a user who picks Ukrainian once gets the locale, font, and timezone offered together rather than having to find each menu separately.What changes
sys_langmapping (e.g.uk->uk_UA.UTF-8), offer to setsys_lang/sys_enconLocaleConfiguration.default_timezonefield onLanguage, populated for ~30 unambiguous single-zone country mappings (uk_UA->Europe/Kyiv,de_DE->Europe/Berlin,ja_JP->Asia/Tokyo, ...). Multi-zone countries (en_US,es_ES,pt_BR, ...) are intentionally left without a default and fall through unchanged.sys_lang,console_font,timezone) is offered whenever its target value differs from the current setting, so picking English after Ukrainian resetsconsole_fonttodefault8x16andtimezonetoUTCinstead of leaving stale Ukrainian values behind.list_timezones()- the same source the timezone menu reads - so we never offer a value the user could not have selected manually.MenuItem.yes()/.no()cache their translated text on the class. With the new prompt firing right after a language switch, the cached labels stayed in the previous language. AddedMenuItem.invalidate_yes_no()and a call fromTranslationHandler.activate()to drop the singletons on language change.Test plan
uk_UA.UTF-8,Lat2-Terminus16,Europe/Kyiv. Accept -> all three applied.en_US.UTF-8,default8x16,UTC.sys_langmapping -> prompt does not appear.