An administrator chooses which languages this instance offers #120

New issue

Closed

opened 2026-09-08 18:05:04 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-09-08 18:05:04 +00:00

Owner

Observation

on the administrator side, the administrator chouse using a checkmark which languages are
available to the regular user

Companion to the picker issue, which is what this narrows.

What exists

SiteSettings holds default_language: the language a new account starts in, offered in
Server settings → Defaults. Nothing anywhere narrows the list a person may then choose
from. accounts/forms.py::language_choices() offers every language whose catalogue somebody
has begun — the rule #70 set, so that a language is never offered with an English interface
behind it — and that is the only filter there is.

So an operator running an instance for one Portuguese team is handed a menu of thirty-nine
languages, and has no way to say that this instance speaks two of them.

What this asks for

A checkbox per language in Server settings, and language_choices() reading it. One
stored list, one place that consults it, and the picker, the API and a document's language
field all narrow together because they all go through the same function.

Worth being careful about

Empty means all, and it has to. An instance whose operator never opens this page keeps
offering everything, and a language added in a later release appears by itself. Storing "all
of them" as an explicit list instead would silently freeze the list at whatever it was on the
day somebody first saved the form.

The default language cannot be unchecked. It is what a new account starts in and what a
rendered document falls back to. Refuse it in the form with a message that says why, rather
than accepting the save and quietly ignoring it. Same for unchecking everything.

Somebody already using a language that is then withdrawn. Their profile still holds that
code. Rewriting it is the wrong answer — the operator may re-enable it tomorrow, and having
silently rewritten a hundred people's settings is not undoable. Show them the instance
default while the language is not offered and leave the stored value alone, so re-enabling
restores it.

An administrator is not exempt. This says what the instance offers, not what
non-administrators are permitted; an administrator who wants a language offers it. Two rules
where one will do is how the two drift apart.

It is not a tier. Postulo is never paywalled, and nothing here may become a gate that
"unlocks": this is an operator curating a list for their own instance, and the code should
read as curation — no entitlement check, no per-account language permission.

Where it lives. Defaults is where default_language already is, and putting a
thirty-nine-row checklist on that page buries the four settings around it. Its own section,
beside the default rather than inside it, with the default's row marked as the one that
cannot be turned off.

## Observation > on the administrator side, the administrator chouse using a checkmark which languages are > available to the regular user Companion to the picker issue, which is what this narrows. ## What exists `SiteSettings` holds `default_language`: the language a **new** account starts in, offered in *Server settings → Defaults*. Nothing anywhere narrows the list a person may then choose from. `accounts/forms.py::language_choices()` offers every language whose catalogue somebody has begun — the rule #70 set, so that a language is never offered with an English interface behind it — and that is the only filter there is. So an operator running an instance for one Portuguese team is handed a menu of thirty-nine languages, and has no way to say that this instance speaks two of them. ## What this asks for A checkbox per language in *Server settings*, and `language_choices()` reading it. One stored list, one place that consults it, and the picker, the API and a document's language field all narrow together because they all go through the same function. ## Worth being careful about **Empty means all, and it has to.** An instance whose operator never opens this page keeps offering everything, and a language added in a later release appears by itself. Storing "all of them" as an explicit list instead would silently freeze the list at whatever it was on the day somebody first saved the form. **The default language cannot be unchecked.** It is what a new account starts in and what a rendered document falls back to. Refuse it in the form with a message that says why, rather than accepting the save and quietly ignoring it. Same for unchecking everything. **Somebody already using a language that is then withdrawn.** Their profile still holds that code. Rewriting it is the wrong answer — the operator may re-enable it tomorrow, and having silently rewritten a hundred people's settings is not undoable. Show them the instance default while the language is not offered and leave the stored value alone, so re-enabling restores it. **An administrator is not exempt.** This says what the instance offers, not what non-administrators are permitted; an administrator who wants a language offers it. Two rules where one will do is how the two drift apart. **It is not a tier.** Postulo is never paywalled, and nothing here may become a gate that "unlocks": this is an operator curating a list for their own instance, and the code should read as curation — no entitlement check, no per-account language permission. **Where it lives.** *Defaults* is where `default_language` already is, and putting a thirty-nine-row checklist on that page buries the four settings around it. Its own section, beside the default rather than inside it, with the default's row marked as the one that cannot be turned off.

tiagoagueda added this to the 0.3.0 milestone

2026-09-08 18:05:04 +00:00

tiagoagueda added the

labels

2026-09-08 18:05:04 +00:00

tiagoagueda added

tier

and removed

tier

labels

2026-09-09 11:49:01 +00:00

tiagoagueda referenced this issue from a commit

2026-09-09 12:45:07 +00:00

Let an instance offer fewer languages than Postulo speaks

tiagoagueda commented

2026-09-09 12:46:02 +00:00

Author

Owner

Server settings → Defaults now carries the list of languages the instance offers.

Empty means all of them, deliberately: storing every code ticked today would freeze the set on the day somebody first opened the form, and a language a later release adds would never appear. Ticking them all stores nothing.

Narrowing leaves stored choices alone — the middleware declines to apply a language the instance no longer offers and touches nothing, so offering it again brings those people back. Blanking profiles instead would have been shorter and irreversible.

Refused, each with a sentence: offering nothing, and withdrawing the language new accounts start in (the message names it). An administrator is not exempt from the narrowing. Fourteen tests, and the wiki section under Configuration.

Shipped in 5b47eb2 on 0.3.0, with main kept level.

*Server settings → Defaults* now carries the list of languages the instance offers. Empty means all of them, deliberately: storing every code ticked today would freeze the set on the day somebody first opened the form, and a language a later release adds would never appear. Ticking them all stores nothing. Narrowing leaves stored choices alone — the middleware declines to apply a language the instance no longer offers and touches nothing, so offering it again brings those people back. Blanking profiles instead would have been shorter and irreversible. Refused, each with a sentence: offering nothing, and withdrawing the language new accounts start in (the message names it). An administrator is not exempt from the narrowing. Fourteen tests, and the wiki section under *Configuration*. Shipped in `5b47eb2` on `0.3.0`, with `main` kept level.

tiagoagueda closed this issue

2026-09-09 12:46:02 +00:00

tiagoagueda referenced this issue

2026-09-15 18:39:32 +00:00

Server settings → Defaults: show each language's flag, as the language picker does #208