Gramps Restart-and-Restore Mechanism, including Language Preference

[dsblank]

Motivation

Gramps currently determines its UI language purely from LANG/LANGUAGE
environment variables, resolved once at process-import time
(gramps/gen/const.py:252, via GrampsLocale). There is no config/preference for
it, and no --lang CLI flag either — the only documented way to change language is
LANGUAGE=fr_FR gramps from a shell (see usage example at cli/argparser.py:140).

We want to make language a real Preferences-dialog setting. Doing so surfaced a
broader, pre-existing problem worth solving at the same time: Gramps already has 4
settings in the Preferences dialog marked * Requires Restart
(preferences.date-format, preferences.age-display-precision,
preferences.age-after-death, interface.sidebar-text), but today that label is
purely cosmetic — changing them just pops a warning telling the user to restart
manually. A language preference would be a natural 5th member of this family, and a
naive "just restart" flow has its own failure mode: behavior.autoload defaults to
False (gen/config.py:153), so a plain restart would land most users on the
welcome screen instead of the tree/view they were just working in — arguably more
jarring than the current do-nothing warning.

So the scope grew from "add a language preference" to "add a language preference,
and build a real restart-and-restore mechanism that all 5 restart-required settings
can share."

Considerations and rejected alternatives

Live in-process reload (no restart at all), Blender-style. Rejected. Blender can
hot-swap its UI language because it's an immediate-mode UI that re-translates every
string on every redraw. Gramps's GTK3 widget tree is retained-mode: once a
Gtk.Label.set_text() or Gtk.Builder-parsed .glade XML string has been resolved,
the widget holds a plain str, not a reference back to gettext. Making this work
would require two independent, both-necessary pieces of new infrastructure:

1. A lazy-_() proxy (à la Django's gettext_lazy()) so cached translated strings —
   e.g. gen/plug/_pluginreg.py:68-132's module-level dicts, or
   gen/datehandler/__init__.py:84's locale binding, all resolved once at import
   time today — re-resolve against the current locale on each read instead of being
   frozen forever. This alone doesn't touch already-built GTK widgets.
2. A comprehensive, correctly-ordered teardown/rebuild of the entire live widget
   tree (every open window, all ~50 gramplets, sidebar plugins, GLib.timeout_add
   callbacks, signal handlers) — none of which was ever written with "may be
   destroyed and rebuilt mid-session" in mind. Getting this wrong produces
   leaked GObject refs and stale-object crashes that are much harder to diagnose
   than a clean process restart.

Both pieces are real, substantial engineering efforts with a long tail of
third-party-plugin risk. Not pursued further here.

os.execv self-relaunch. Chosen instead. Gets a guaranteed clean slate from the
OS/interpreter (no leaked refs, no half-updated caches) at the cost of having to
explicitly re-establish only the state that's deliberately passed forward across the
restart boundary — a much smaller, auditable surface than "correctly tear down the
entire live object graph." There's no existing os.execv/relaunch precedent
anywhere in the Gramps codebase, but there is a directly analogous precedent for
"read a flag from raw sys.argv before any Gramps module is imported":
grampsapp.py:41-46 already does this for -S/--safe mode, setting
os.environ["SAFEMODE"] before gen/const.py (and therefore GrampsLocale) is
ever imported. The language part of this plan is a direct copy of that pattern.

How to carry session state across the restart. A JSON file (path passed via a
new --restore-state <path> CLI flag) rather than inline CLI text, and rather than
routing it through the existing ConfigManager/ini system (gen/config.py) — the
state is a one-shot process-handoff blob, not a durable user preference, so it
doesn't belong in the persistent config file. os.execv builds argv directly with
no shell involved, so there's no quoting/injection risk either way; a file is chosen
mainly because it scales better than argv length if the captured state grows, and is
easy to inspect while debugging.

What's actually worth restoring. Framed against what Gramps already persists
continuously and durably, independent of this feature:

• Window size/position (gui/viewmanager.py:884, :888-890, restored at
  :304-305) and full gramplet/sidebar layout (~/.gramps/gramplets.ini,
  gui/widgets/grampletpane.py) are already saved to disk as you use the app —
  no need to duplicate these in the restore-state JSON.
• What genuinely only lives in memory and would otherwise be lost: which tree was
  open, which view/category was active, which record was selected, which
  Person/Family/etc. editors were open.
• Search/filter bar text has no existing persistence mechanism to build on — judged
  low value relative to the new machinery it would require, and dropped from scope.
• Hard limitation, not solved by any of this: editors don't commit
  incrementally — saves only happen on OK click
  (gui/editors/editperson.py:914-986, inside a DbTxn). An open editor's
  in-memory edits are the entire form, not a few keystrokes, and no restart
  mechanism can recover typed-but-unsaved field values. The plan handles this by
  reusing Gramps's existing per-editor unsaved-changes prompt
  (gui/editors/editprimary.py:244-274, SaveDialog) — forcing a save/discard
  decision before the restart happens, exactly as already happens when a user
  closes one editor manually. Never silently lost, never silently carried forward.

Scope decisions confirmed with the team:

• The restart flow is triggered only from the Preferences dialog, when the user
  changes one of the 5 flagged settings and closes the dialog.
• It applies generically to all 5 settings (the 4 existing ones plus the new
  language preference), not just language — same mechanism, same prompt.

Implementation plan

1. New preferences.language config key

gramps/gen/config.py, in the preferences.* block near preferences.date-format
(around line 299):

register("preferences.language", "")

Empty string = use system default (no env override) — consistent with
gen/utils/grampslocale.py:244-258, which only overrides LANG/LC_MESSAGES when
LANGUAGE is actually present in the environment.

2. Preferences UI: language combo + restart-tracking on all 5 settings

All in gramps/gui/configure.py.

Language widget — add to add_general_panel (configure.py:2140-2397, the
"General" tab, which already hosts sidebar-text), near the top of the
"Environment Settings" section (:2149-2160). Mirror the existing date-format
combo pattern (:1711-1721, Gtk.ComboBoxText), populated from
glocale.get_language_dict() (gen/utils/grampslocale.py:750-759, returns
{display_name: code}) — the same API already used for report-language pickers in
gen/plug/report/stdoptions.py:64,80. Build a sorted list of (display_name, code),
track codes in parallel to map get_active() back to a code, set active index from
config.get("preferences.language"). Label: _("Language *"), tooltip matching the
existing sidebar-text wording (configure.py:2230-2234,
"Requires Gramps restart to apply.").

Restart-change tracking — ConfigureDialog (configure.py:173-243) is
single-response (Gtk.ResponseType.CLOSE, wired at :218 to self.done), all
settings apply immediately (tooltip confirms: "Any changes are saved immediately",
:219-220). done(self, obj, value) (:238-243) is the one choke point all 5
settings' changes eventually flow through — this is where the restart offer belongs.

• GrampsPreferences.__init__ (configure.py:701 area): add
  self._restart_settings = set() before the base ConfigureDialog.__init__ call.
• Add GrampsPreferences.mark_restart_required(self, key, *_args):
  self._restart_settings.add(key). Compatible with add_checkbox's
  extra_callback signature (callback(widget)), called via a small lambda per
  site.
• Wire each of the 5 settings to call it on change:
  • date-format combo (:1718, date_format_changed, :2008-2021): add
    self._restart_settings.add("preferences.date-format"), and remove the
    existing passive OkDialog popup at :2014-2021 — the new dialog-level prompt
    supersedes it.
  • age-display-precision combo (:1735-1740, currently a bare lambda): convert
    to a bound method that both config.set(...)s and marks the key.
  • age-after-death checkbox (:1758-1765) and sidebar-text checkbox
    (:2223-2235): both use add_checkbox — add
    extra_callback=lambda o: self.mark_restart_required("interface.sidebar-text")
    (and the age-after-death equivalent).
  • new language combo: same extra_callback pattern.
• Override done() in GrampsPreferences:

  def done(self, obj, value):
      if value == Gtk.ResponseType.HELP:
          return
      if self._restart_settings:
          self.offer_restart()
      ConfigureDialog.done(self, obj, value)

  Keep calling the base done() afterward regardless of the user's restart choice,
  so on_close=update_constants (existing "apply immediately" behavior, :701)
  still runs — declining a restart should not block the normal apply-and-close flow.

3. offer_restart() — orchestration

New method on GrampsPreferences, plus a new module gramps/gui/restartstate.py
for the reusable, non-GTK pieces (state capture/serialize, so it's independently
testable).

def offer_restart(self):
    self._resolve_unsaved_editors()
    dlg = QuestionDialog2(
        _("Restart Gramps?"),
        _("Some changes require Gramps to restart to take effect. "
          "Restart now?"),
        _("Restart Now"), _("Restart Later"),
        parent=self.window,
    )
    if dlg.run():   # QuestionDialog2.run() -> bool, gui/dialog.py:172-177
        from .restartstate import capture_state, write_state_file, restart_gramps
        state = capture_state(self.dbstate, self.uistate, self._vm)
        path = write_state_file(state)
        restart_gramps(path)

QuestionDialog2 (gui/dialog.py:139-177) confirmed: takes (msg1, msg2, label_msg1, label_msg2, parent=None), .run() shows the dialog synchronously and
returns True/False (response == Gtk.ResponseType.ACCEPT) — exactly what's
needed here, no subclassing required.

Unsaved-editor resolution, _resolve_unsaved_editors:

def _resolve_unsaved_editors(self):
    from .editors.editprimary import EditPrimary
    for item in list(self.uistate.gwm.id2item.values()):
        if isinstance(item, EditPrimary) and item.data_has_changed():
            item.close()

• uistate.gwm.id2item (gui/managedwindow.py:121) is the existing window
  registry, window_id → ManagedWindow. Snapshot with list(...) first since
  close() mutates this dict during iteration (managedwindow.py:215).
• EditPrimary.data_has_changed() / .close() (gui/editors/editprimary.py:244-274)
  are reused as-is — close() already checks config.get("interface.dont-ask")
  and, if there are changes, pops the existing SaveDialog (gui/dialog.py:62-96,
  blocking .run()) offering save-or-discard. By the time this loop finishes, every
  editor is either closed-and-committed, closed-and-discarded, or (if
  interface.dont-ask is set) force-closed per existing app-wide behavior — never a
  new prompt style, just reusing what already exists for individual-editor close.

State capture, gramps/gui/restartstate.py:

def capture_state(dbstate, uistate, viewmanager) -> dict:
    ...

• language: config.get("preferences.language") (already set by this point).
• tree: dbstate.db.get_save_path() if dbstate.is_open() else None — same
  directory-path shape -O/arg_h.open already accepts
  (cli/arghandler.py:354-359).
• active_view: add a small new ViewManager.get_active_view_ids() helper next to
  goto_page/get_category (gui/viewmanager.py:1084-1115) that mirrors the
  existing reverse-lookup view_changed() already does (:1184-1198) to return
  (category_id, view_id) strings — the same id vocabulary already stored in
  preferences.last-view/last-views.
• selected: {nav_type: history.present() for (nav_type, nav_group), history in uistate.history_lookup.items() if nav_group == 0} (gui/displaystate.py:573-577).
• open_editors: iterate uistate.gwm.id2item.values(), filter to EditPrimary
  instances with a real (non-None) obj.get_handle() — skip brand-new/unsaved
  objects (window_id == id(self) per editprimary.py:131-135, nothing meaningful
  to restore). Record {"object_type": obj.__class__.__name__, "handle": handle}.

write_state_file(state): json.dump to a tempfile.NamedTemporaryFile(delete=False, suffix=".json"), return its path. Use stdlib json, not orjson — this is a tiny,
one-shot handoff blob, not a fit for gen/lib/json_utils.py's object-serialization
use case, and not a fit for ConfigManager/ini (gen/config.py) either, since
that's for durable persistent prefs, not a one-shot process-handoff.

restart_gramps(path):

def restart_gramps(path):
    os.execv(sys.executable, [sys.executable] + sys.argv + ["--restore-state", path])

Use sys.argv (not a hardcoded Gramps.py/gramps path) so this works whether
launched via python Gramps.py, an installed gramps script, or python -m gramps
— sys.executable + sys.argv reproduces however this process was actually
invoked.

4. Consuming --restore-state: three separate points, three separate times

(a) Language — before gen/const.py is even imported

gramps/grampsapp.py, immediately after the existing -S/--safe raw-sys.argv
scan (:41-46) and before from .gen.const import APP_GRAMPS, ... (:53) — this
is the exact precedent to copy, since gen/const.py:252 constructs the
GRAMPS_LOCALE singleton at import time, before normal getopt parsing
(cli/argparser.py) ever runs:

if "--restore-state" in sys.argv:
    idx = sys.argv.index("--restore-state")
    if idx + 1 < len(sys.argv):
        import json
        try:
            with open(sys.argv[idx + 1], encoding="utf-8") as _f:
                _restore_language = json.load(_f).get("language")
        except (OSError, ValueError):
            _restore_language = None
        if _restore_language:
            os.environ["LANGUAGE"] = _restore_language
            os.environ["LANG"] = _restore_language

Confirmed gen/utils/grampslocale.py:244-258 reads LANGUAGE (overrides
LANG/LC_MESSAGES) during GrampsLocale.__init__.

(b) Tree — flows through the existing -O machinery, zero new tree-opening code

• gen/const.py:310 LONGOPTS: add "restore-state=". No short opt needed
  (SHORTOPTS, :356, untouched).
• cli/argparser.py, __init__ defaults (near self.open = None): add
  self.restore_state_path = None.
• cli/argparser.py, options loop (:287-289, alongside the existing
  -O/--open handling), add:

  elif option in ["--restore-state"]:
      self.restore_state_path = value
      try:
          with open(value, encoding="utf-8") as f:
              _state = json.load(f)
      except (OSError, ValueError):
          _state = {}
      if _state.get("tree"):
          self.open = _state["tree"]

  Setting self.open here reuses ArgHandler.__init__ (cli/arghandler.py:188,
  self.open = self.__handle_open_option(parser.open, parser.create)) unchanged,
  and gui/grampsgui.py:605's if arg_h.open or arg_h.imp_db_path: branch
  naturally wins over the paths.recent-file/behavior.autoload fallback
  (:608-619) — identical priority to a manually-passed -O, no new branching
  required.
• Add --restore-state=PATH to the two help-text blocks (argparser.py around
  :74 and :161) for consistency.

(c) Active view / selection / open editors — after the tree is fully loaded

gui/grampsgui.py, Gramps.__init__ (:568-625), after arg_h.handle_args_gui()
(:604) has returned and the tree-opening branch has resolved (confirmed
DbLoader.read_file, invoked via CLIManager._read_recent_file,
cli/grampscli.py:274, blocks synchronously until the tree is loaded):

if getattr(argparser, "restore_state_path", None):
    from .restartstate import apply_post_init_state
    apply_post_init_state(argparser.restore_state_path, dbstate, self._vm)

apply_post_init_state(path, dbstate, viewmanager):

1. Re-read the JSON file (intentionally independent of consumption points (a)/(b),
   which run at different times/processes-of-the-startup-sequence).
2. active_view: cat_num = viewmanager.get_category(state["active_view"]["category"])
   (viewmanager.py:1108-1115); find view_num by scanning
   viewmanager.views[cat_num] for matching pdata.id; call
   viewmanager.goto_page(cat_num, view_num) (viewmanager.py:1084) — the exact
   call views_to_show()-driven startup already makes (viewmanager.py:1996-2023).
3. selected: for each (nav_type, handle), call
   dbstate.db.method("has_%s_handle", nav_type)(handle) to verify it still exists
   (tree may have changed since the snapshot was taken — e.g. edited from another
   Gramps instance), then viewmanager.uistate.set_active(handle, nav_type)
   (displaystate.py:596-603) — pushes into History; for the active view this
   immediately triggers goto_handle via the "active-changed" signal
   (navigationview.py:184); for other nav_types it resolves next time that view
   becomes active, matching existing behavior.
4. open_editors: for each {object_type, handle}, verify existence via the same
   has_<type>_handle check, then call the existing generic editor-opening
   helper — EditObject(dbstate, uistate, [], object_type, prop="handle", value=handle) (gui/editors/__init__.py:86-123). This is a direct reuse
   discovery: EditObject already does the handle→object lookup
   (dbstate.db.method("get_%s_from_%s", obj_class, prop)(value)) and editor
   construction generically for all primary types, and already logs-and-skips
   missing objects instead of raising — no bespoke per-type dispatch needed.
5. Wrap all lookups defensively (skip on HandleError/missing, per existing
   precedent gui/displaystate.py:721-748) — never block startup on stale state.

Verification

Manual end-to-end

1. Launch Gramps against a test tree, navigate to People, select a person, open
   that person's editor and edit a field (don't save).
2. Preferences → General tab → change Language (and separately, in another pass,
   Data tab → Date format, and General tab → sidebar-text) — confirm the
   SaveDialog appears for the dirty editor, and confirm both the Save and Discard
   paths work.
3. Confirm the "Restart Gramps?" prompt appears; confirm "Restart Later" just
   closes Preferences normally (setting still applied, just not restarted).
4. Confirm "Restart Now" actually re-execs (verify via os.getpid() before/after,
   or ps), and that the new process: reopens the same tree without hitting the
   welcome/Tree Manager screen, lands on the same category/view, has the same
   person selected/highlighted, reopens that person's editor automatically, and
   shows the new UI language in menu strings.
5. Multiple changes in one Preferences session (e.g. language + sidebar-text)
   should produce a single restart prompt, not one per setting —
   _restart_settings is a set() accumulated across the whole dialog session.
6. Edge cases: no tree open when Preferences is invoked (restart should land
   cleanly on the welcome screen, no crash); a selected/open-editor handle deleted
   from another Gramps instance between capture and restore (should silently
   skip, not crash); a brand-new unsaved Person editor open at restart time (must
   not attempt to reopen — no valid handle to restore by).

Automated tests

• gramps/cli/test/argparser_test.py (existing pattern at :39-80): add cases
  for --restore-state <path> setting ap.open from the JSON's "tree" key,
  setting ap.restore_state_path regardless of contents, tolerating a
  missing/invalid file without raising, and leaving ap.open untouched when
  "tree" is absent.
• gramps/gen/utils/test/grampslocale_test.py: add a case constructing
  GrampsLocale with LANGUAGE pre-set in os.environ and asserting it's picked
  up — validates the underlying mechanism consumption point (a) relies on,
  independent of the grampsapp.py module-level scan itself (which is a startup
  side effect, not practically unit-testable in isolation).
• New gramps/gui/test/restartstate_test.py: pure-function tests for
  capture_state/write_state_file schema round-tripping with mocked
  dbstate/uistate/viewmanager objects (no live GTK needed for the JSON
  shape).

Run via the project's standard single-module test invocation:

export GDK_BACKEND=- GRAMPS_RESOURCES=build/share LANGUAGE= LANG=en_US.utf-8
python3 -m unittest gramps.cli.test.argparser_test
python3 -m unittest gramps.gen.utils.test.grampslocale_test
python3 -m unittest gramps.gui.test.restartstate_test

Do not run the full unittest discover suite locally — let CI handle it.

Critical files

• gramps/gen/config.py — new preferences.language key
• gramps/gui/configure.py — language widget, restart-tracking, offer_restart(),
  _resolve_unsaved_editors()
• gramps/gui/restartstate.py — new file: capture_state, write_state_file,
  restart_gramps, apply_post_init_state
• gramps/gen/const.py — LONGOPTS addition
• gramps/cli/argparser.py — --restore-state parsing, help text
• gramps/grampsapp.py — pre-import language env-var scan
• gramps/gui/grampsgui.py — post-init call to apply_post_init_state
• gramps/gui/viewmanager.py — new get_active_view_ids() helper
• Reused as-is (no changes needed): gui/editors/__init__.py (EditObject),
  gui/editors/editprimary.py (data_has_changed/close), gui/managedwindow.py
  (gwm.id2item), gui/displaystate.py (set_active, history_lookup),
  gui/dialog.py (QuestionDialog2, SaveDialog)

[emyoulation]

Will the locale selector have both the English Exonym (since English is the lingua franca of Gramps) and the locale endonym ?

While building a gramplet for a (Rosetta Stone style) 3-language triptych of Gramps Glossary terms, I realized that at least 1 of the languages was likely to be foreign to the user. (Finding the equivalent term in a foreign language was the main reason for the gramplet.) So the selection menu and titles needed to show the English exonym and endonym for each locale. And since so many features choose locale by the ISO 639 code that Gramps uses, it seemed reasonable to show that too and to use the ISO code as a reliable sorting index.

The experimental Environment Inspector could be used for sanity checks for the Locale and environmental variable values too.

[dsblank]

Follow-up: Locale Settings Are the Wrong Grain for a Genealogy App

Status

Follow-up to LANGUAGE_PREFERENCE_RESTART_PLAN.md
(the preferences.language + restart-and-restore feature, implemented). Not scoped
or scheduled — captured here so we can come back to it.

Where this came from

While implementing the language-preference restart mechanism, a colleague pointed out:

• LANGUAGE selects message-catalog language only.
• LANG sets the default for all locale categories unless a more specific LC_*
  var overrides it.
• LC_* variables (LC_TIME, LC_COLLATE, LC_MESSAGES, ...) let you customize
  individual aspects (dates, collation, messages) independently.
• There's also the question of what languages are actually installed for gettext.

Chasing that down surfaced a real bug in the initial implementation (fixed): the
restart mechanism was setting both LANGUAGE and LANG to the same bare gettext
code (e.g. "fr", from glocale.get_language_dict(),
gen/utils/grampslocale.py:750-759, which lists directory names under the locale
dir — not full OS locale identifiers). LANGUAGE accepts bare codes by design
(gen/utils/grampslocale.py:244-258 already splits it on : and checks each
segment). LANG does not — it feeds locale.setlocale(LC_ALL, "")
(grampslocale.py:200), which expects a real OS locale name like fr_FR.UTF-8.
Setting LANG to a bare code risked setlocale() failing and falling back to
"C" (grampslocale.py:208-213), degrading LC_TIME/LC_COLLATE along with the
message language it was actually trying to change. Fix applied: only set
LANGUAGE; leave LANG/LC_* alone so date/number/collation keep following the
user's real system locale.

That fix is sufficient for the current feature. But working through it raised a
bigger question worth revisiting on its own: is a single global, env-derived,
restart-gated locale even the right model for a genealogy app, where a single
tree — or even a single session — routinely contains records from multiple
countries and naming conventions?

The three-bucket reframing

LANG bundles five independent concerns (LC_MESSAGES, LC_TIME, LC_COLLATE,
LC_NUMERIC, LC_MONETARY) into one process-wide knob. For Gramps specifically,
these concerns actually belong at three different granularities:

1. Per-record — already solved correctly

Calendar type (Gregorian, Julian, Hebrew, French Republican, Islamic, ...) is a
property of the individual Date object in the data model, editable per field in
the date editor. A Swedish birth record and a French-Republican-calendar record can
coexist in the same tree because the calendar is data, not environment. Nothing
to change here — this is the right pattern, and it deliberately has nothing to do
with LANG/LC_TIME.

2. Per-tree — an existing pattern, underused

Name display format already works this way. gui/configure.py (around the name
format panel) says outright: "Custom name display options are unique to each
family tree." It's stored via the tree's own database metadata
(db.get_name_group_mapping, gen/display/name.py), not the global
ConfigManager ini file everything else uses. This is the established mechanism
for "a setting should follow the tree, not the app session."

Collation (LC_COLLATE) is the strongest candidate to move here. It isn't
currently exposed as a preference at all — it's silently derived from LANG
(grampslocale.py:226-239). But sort order for names/places is exactly the kind of
thing a genealogist would want fixed per tree (a tree about Swedish ancestors
should probably always sort Swedish-style), not tied to whatever the researcher's
OS locale happens to be, and not something that should require an app restart to
change.

Date input/display format (preferences.date-format, currently one of the 5
restart-required app-wide settings this feature covers) arguably belongs here too,
for the same reason — a researcher working a French-focused tree likely wants
DD/MM/YYYY input consistently in that tree, independent of their own UI language or
OS locale.

Moving both to the per-tree metadata pattern would sidestep the restart problem for
them entirely — no env vars, no os.execv, no GrampsLocale singleton timing
constraints. It's a database-metadata read/write, not a process-locale change.

3. Per-app-session — genuinely restart-appropriate

UI message language (LC_MESSAGES/LANGUAGE) doesn't make sense per-record or
per-tree — menu labels and dialog chrome are a whole-window concern. This is the
one that legitimately needs the restart-and-restore mechanism already built.

A fourth, cheaper category (not urgent, just noted)

GTK text direction (RTL for Arabic/Hebrew, _RTL_LOCALES in grampslocale.py) is
a per-widget property (Gtk.Widget.set_direction()), not a process-level LANG
concern. A specific name-entry field could in principle render RTL without
touching locale or restarting anything. Not proposing this now — just noting it
doesn't belong in the LANG bucket either, and would be far cheaper than it looks
if we ever want it.

Recommendation (for when we pick this up)

• Don't fold this into the current restart-and-restore feature — it's a separate,
  larger redesign of which settings are global vs. per-tree.
• Scope a follow-up: move preferences.date-format and a new (currently
  nonexistent) collation/sort-order preference to per-tree storage, following the
  name-display-format precedent (gen/display/name.py, db.get_name_group_mapping
  and friends) instead of gen/config.py's global ConfigManager.
• If that lands, preferences.date-format would drop out of the "5 restart-required
  settings" list entirely, leaving language and the remaining interface-chrome
  settings (age-display-precision, age-after-death, sidebar-text) as the ones
  that actually need the restart mechanism.
• Open question to resolve when scoping: does per-tree collation need a UI
  affordance at tree-open time (so switching trees visibly re-sorts lists), or is
  it enough to expose it in the same place name-format options already live?

[Nick-Hall]

leave LANG/LC_* alone so date/number/collation keep following the
user's real system locale.

You will probably have to set the LANG environment variable to get the correct localisation of Gspell. I seem to remember that it ignores LANGUAGE.

[dsblank]

Will the locale selector have both the English Exonym (since English is the lingua franca of Gramps) and the locale endonym ?

Sure, why not?

[riskysnail]

Any thoughts on adding a command line override for language settings at the same time? This would ensure users and developers can set the language at runtime without modifying their preferences.

1. env vars - system level language setting (default)
2. app preference - lang preference saved in app settings (overrides env var)
3. command line arg - lang set at runtime via the command line (overrides app preference)

[dsblank]

Any thoughts on adding a command line override for language settings at the same time? This would ensure users and developers can set the language at runtime without modifying their preferences.

Yes, that is a good idea.

[dsblank]

@emyoulation, how is this?

[emyoulation]

I think it will work for most conditions. (Even when you've accidentally selected a language with unfamiliar glyphs for its alphabet.)
Thank you!

A question... how will you make certain that the menu for language selection can be found when in that unfamiliar alphabet?
For example, if it is just labeled with the translated "Languages" {e.g., Kielet (fi), 言語 ( ja-JP), or שפות (he)} then the menu might be hard to find in a dialog.

I have not found (in Gramps) one of the typical icons used to indicate Language selection:

So far I've only found the following (which show in Linux but not Windows)

[emyoulation]

Whatever icon is used in Grampsm we'll want to carry it through to the Wordpress entry page on the website, the MediaWiki language selection (and translator pages), and the Discourse International pages. (Right now, our WordPress home page is not inviting to non-English speakers. It does not even suggest a path to discovering whether Gramps supports other languages.)

[dsblank]

@Nick-Hall said:

You will probably have to set the LANG environment variable to get the correct localisation of Gspell. I seem to remember that it ignores LANGUAGE.

Checked it — you are right, and I can show exactly where.

gui/spell.py:97 — Spell.init picks the Gspell dictionary via:

locale_code = glocale.locale_code()
...
spell_language = Gspell.language_lookup(locale_code[:5])

And glocale.locale_code() (gen/utils/grampslocale.py:658-662) is just return self.lang — the value derived from LANG/LC_MESSAGES/setlocale(), not self.language (the list derived from LANGUAGE, used for gettext message translation). These are two genuinely separate attributes on GrampsLocale, fed by two separate env vars, and Gspell's dictionary selection in Gramps only ever looks at the LANG-derived one.

What this means for the restart feature: since the relaunch only sets LANGUAGE and deliberately leaves LANG untouched, the restart now correctly changes UI message language but the spell-check dictionary stays on whatever the OS's real LANG is — completely decoupled from the preferences.language the user just picked. If they set Gramps to French, notes still get spell-checked against whatever dictionary their system LANG implies (probably English). That's very likely not what a user expects — picking a UI language reasonably implies "I'm about to type in this language," which spell-check should follow.

The fix doesn't reopen an earlier issue that I encountered: don't touch LANG again (that would risk setlocale() falling back to "C" and taking LC_TIME/LC_COLLATE down with it). Instead, fix it at the one call site that actually cares — gui/spell.py — so it prefers glocale.language (the LANGUAGE-derived list, already in the right short-code shape Gspell.language_lookup expects, e.g. "fr") over glocale.locale_code(), falling back to the latter only if no language override is set. That's a small, self-contained change to one file, unrelated to the os.execv/restore-state machinery.

Fixed!

[kulath]

(1) Will this work for Mac and Windows (does Windows really have an execv)?

(2) As well as the normal COLLATE language, there are also special collation variant options, for example in German there is the Phonebook variant, and also I think there is one for one of the scandinavian languages (might be Finnish I think), as well as some far eastern languages. Will this also work in these cases, and at least not prevent the variants being chosen. (I have a special interest in this, having implemented the ICU collation in Narrative Web).

Otherwise, a very interesting enhancement, just so long as the advantage is not overweighed by what seems like a very complicated change.

[dsblank]

1. os.execv on Windows and Mac

macOS is not a concern — Darwin is a true POSIX system, os.execv there is the real syscall (full in-place process-image replacement, same PID), identical to Linux.

Windows does have os.execv, but it's not a native syscall — CPython implements it via the MSVCRT _spawnv(_P_OVERLAY, ...) mode, which Microsoft documents as "destroys the calling process and replaces it with the new process; the identifiers of the calling process and the new process are the same." So it's a genuine in-place replacement, not spawn-and-wait — the current restart_gramps() (gramps/gui/restartstate.py:116-128) should work as-is. The real Windows-specific risk isn't "does exec exist," it's argument handling: _P_OVERLAY goes through MSVCRT's own argv quoting, and there's a documented history of CPython issues with os.exec* mishandling paths containing spaces (e.g. C:\Program Files\Gramps...), which is exactly what sys.executable/sys.argv will contain on a typical Windows install. I'd flag that as the one thing to actually test on Windows before relying on this, rather than the existence of execv itself — worth adding to the manual verification checklist in the plan alongside the existing Windows/Mac items.

2. Collation variants (German phonebook, Finnish, CJK, etc.)

Good news: this feature is completely orthogonal to collation, in both directions. glocale.collation is a wholly separate attribute from glocale.language, populated independently — from LC_COLLATE, or overridden by a distinct COLLATION env var when ICU is available (gen/utils/grampslocale.py:241-242, mirrored on mac/win32 in maclocale.py:200 / win32locale.py:196-197). The restart/language plumbing we built only ever sets LANGUAGE — never LANG, never COLLATION — so it can't clobber whatever collation setup you already have, and it doesn't let a user pick a collation variant either.

The ICU machinery underneath already supports exactly what you're describing: grampslocale.py:477-484 builds a Collator from Locale.createFromName(self.collation), and ICU locale strings support the @collation= keyword (de_DE@collation=phonebook, zh@collation=pinyin/stroke, ja@collation=unihan, etc.) — that's the same mechanism your Narrative Web ICU work relies on (plugins/webreport/common.py:639, alphabeticindex.py:198). It's also not just a report-time concern — plugins/db/dbapi/sqlite.py:122 uses locale.get_collation() to register the SQL COLLATE function for live in-app sorting too.