Add Ability to Choose State/Regions Abbreviations

[C3GPS]

Problem Statement

I prefer my states in my columns to be abbreviated to save column space. Unless I'm not seeing it, I don't see where I can tell OSAK to abbreviate them. When I tell OSAK to update location info, it changes my previously abbreviated states (that came from GSAK) to the full state name.

Proposed Solution

Give us the ability to choose how we want our states shown. Also include default abbreviations but also the ability to add our own. GSAK has the US, Canada and Australia built in. Also, as an aside, the settings window is getting tall. Making it wider rather than taller would be preferred since most monitors are wider than they are tall so having the window cut off at the bottom will be not great.

[AgreeDK]

Region/State Abbreviation Support — Data Model & Implementation Proposal
Design notes collected for #784. Not scoped to a specific release — captured here so the plan exists when this is picked up.
Background
GSAK has a built-in "Abbreviations" tab (Options → Abbreviations) that lets users convert full state/region names (e.g. "California") to a short code ("CA"), primarily to reduce column width. It ships with default sets for US, Canada, and Australia, plus free-text add/edit, and an "auto-convert on import" option that GSAK applies by mutating the stored data.
Original ask for #784 was purely about saving column width for one or two countries. Scope was deliberately widened: OpenSAK's userbase is not centered on any single country the way GSAK's Country/State abbreviation feature assumes, so the feature should support every country our users might have caches from — now and as the project grows — not just a fixed US/CA/AU set.
Important distinction: this has nothing to do with the 8 UI languages (da, en, fr, nl, pt, cs, se, de). A Danish-speaking user can have caches from the US, Germany, and Australia in the same database. Region-abbreviation sets must be modeled per country, independent of interface language.
Key design decision: display-only transform (no data mutation)
Cache.state (and country/county) are stored as plain text, taken verbatim from the GPX (gs:state) at import time (src/opensak/importer/init.py). StateFilter and the state sort key both operate on that stored full-text value (src/opensak/filters/engine.py).
Proposal: abbreviation is applied only at render time, never written back to the database. This differs deliberately from GSAK's "convert (abbreviate) state names on import" option, which permanently rewrites the stored value. A pure view-layer transform:
costs nothing to reverse (toggle a setting, not run a batch conversion)
requires zero changes to StateFilter, sorting, GPX export, or GGZ export — they keep working against the untouched full name
follows the same pattern already used for corrected coordinates (an overlay applied consistently across column / header / context menu / detail panel, without touching the underlying stored coordinate)
Filter/search matching on the abbreviated form (typing "CA" to find "California") is a possible later enhancement, not required for a first version.
Data model
One JSON file per country, not per UI language:
src/opensak/geo/regions/
├── init.py # AVAILABLE_REGION_SETS registry, load_region_set()
├── us.json
├── ca.json
├── au.json
├── de.json
└── ...

Each file, keyed by ISO 3166-1 alpha-2 country code as the filename:
{
"country": "United States",
"regions": {
"Alabama": "AL",
"Alaska": "AK",
"Arizona": "AZ"
}
}

src/opensak/geo/regions/init.py mirrors the existing lang/init.py pattern:
AVAILABLE_REGION_SETS: dict[str, str] = {
"us": "United States",
"ca": "Canada",
"au": "Australia",
}

Lookups are scoped by country, never a flat global dict — "Georgia" is both a US state and a country, so an unscoped table would produce wrong matches.
Where the data lives
County boundary packs (geo/packs.py, geo/boundaries.py) are fetched on demand from OpenSAK-Data releases because they're large (geojson polygons). Region-abbreviation tables are a few KB per country — no reason to reuse that download/manifest/versioning machinery. Proposal: bundle region-set JSON files directly in the OpenSAK repo (src/opensak/geo/regions/), shipped with the app like the language files are.
If the list of community-contributed countries grows large enough that it stops making sense to tie updates to app releases, revisit moving it to OpenSAK-Data later — same precedent as boundary data, just not needed for a first version.
Settings
Global display preference (not per-database — this is a rendering style choice, not database content, so it should not go through _db_key()):
display.region_abbrev.enabled — bool, master on/off
display.region_abbrev.active_sets — list of country codes the user has turned on, e.g. ["us", "de"]
User-added custom entries/sets live in the app's user-data directory (not the bundled, git-tracked JSON), so local edits never get overwritten by an app update and never need to be committed upstream.
No "convert on import" checkbox (see display-only decision above) — nothing to opt into at import time, since nothing is mutated.
UI plan
New Abbreviations tab under Settings, similar placement to GSAK's:
Checklist of available region sets ("United States", "Canada", "Australia", "Germany", …) — user enables the ones relevant to them
Per enabled set: a two-column table (full name read-only on the left, abbreviation editable on the right) so users can tweak individual entries without touching the bundled file
Advanced: "Add custom region set" for a country not yet bundled — stored locally as described above; not required for a first version, but the data model already supports it without changes
Optional nice-to-have: when a newly imported cache has a country value for which a bundled set exists but isn't yet enabled, surface a one-time suggestion to turn it on
Rendering
New helper, e.g. opensak.geo.regions.abbreviate(country: str, state: str) -> str: looks up the country's active set (falls back to the full state string if the set isn't enabled or the state isn't found in it). Called at render time in:
cache_table.py — state column data() (currently ~line 1044-1046)
cache_detail.py — wherever state is displayed
No changes needed to the underlying Cache.state field, StateFilter, sorting, or export code paths.
Validation
Lightweight per-file check (own small pytest, not tied to the language-file tests):
no duplicate abbreviation values within a single country's set
no empty abbreviation values
Suggested phased rollout
Bundle US / CA / AU (matches GSAK's defaults, covers the largest known need), global enable/disable, render-only in cache_table.py + cache_detail.py
Settings UI: per-set enable/disable, per-entry override, add custom set locally
Community-contributed sets for additional countries (DE, DK, NL, …); revisit hosting in OpenSAK-Data if the file count/size grows enough to justify it
Optional: allow StateFilter to also match against the abbreviated form
Open questions
Authoritative abbreviation source per country — ISO 3166-2 subdivision codes are a reasonable starting point for many countries, but GSAK's US/CA/AU sets use conventional postal abbreviations, not ISO codes, so these won't always line up and may need manual curation per country.
Whether region-set files need their own update/versioning path eventually, or stay tied to app releases indefinitely (proposal: stay tied to releases until proven otherwise).

[C3GPS]

It should be noted that, although saving column width is one reason that I personally abbreviate, I also prefer the abbreviations in filters, especially when using the In List filter option. I would much rather type CA,OR,WA than California,Oregon,Washington. I'm going to submit another issue on github to possibly resolve this issue and you may not have to account for abbreviations in filters at all in the future.