# `PhoenixKitCatalogue.Web.SettingsLive`
[🔗](https://github.com/BeamLabEU/phoenix_kit_catalogue/blob/v0.44.2/lib/phoenix_kit_catalogue/web/settings_live.ex#L1)

Settings → Catalogue.

The module had no settings page at all, so everything it stores was either
unreachable (the whole AI-translation sweep, four keys whose only writer was
an operator calling `update_*` from a console) or lived on whichever list
page happened to write it. The owner noticed the gap from the other end —
`/admin/settings` simply had no Catalogue entry (boss via Max, 2026-09-21).

Every key the module owns that a person can meaningfully change is here;
`PhoenixKitCatalogue.Web.Settings` is where they are read and written.

Two things deliberately NOT here:

* **The module kill switch** (`catalogue_enabled`) — Admin → Modules owns
  it, and a copy of it on this page would be a switch that hides the page
  it lives on, since the tab is gated on the module's permission.
* **The per-scope list sort** (`catalogue_sort_*`) — the sort selector on
  each list writes it, which is the place a person is standing when they
  decide what "sorted" means. A second control here would disagree with it.

# `on_mount`

# `picked_langs`

```elixir
@spec picked_langs(map(), [String.t()]) :: [String.t()]
```

The languages a posted checkbox group names, kept to the ones on offer.

An unticked group posts nothing at all, so an absent `"langs"` key means
"none" — not "unchanged". A code that is not an enabled language is
dropped, so a crafted post cannot store a language the sweep would then
target. Public for its tests: the LiveView only offers this group when a
second language is enabled, which a test database may not have.

---

*Consult [api-reference.md](api-reference.md) for complete listing*