peter
4379f76747
A refusal code or reason with no sentence fell through to the generic "couldn't carry out that action" unnoticed: the parity test is green when EN and HU miss the same key. One did (an edit refused for a file that is not video or audio). - lib/api/refusalCodes.ts: which sentence answers each code, as data; localizeDetail says a refusal through it, unchanged for every reader. - backendIds contract: every detail code the backend sends is in exactly one record, every reason it can carry has its sentence in EN and HU, and no family names a reason the backend cannot send. - The reasons that travel in a variable are Literal types (edit, move, cookies, quota), so the type checker refuses an unknown one too. - downloads.errors.edit.not_media in EN and HU.
40 lines
2.1 KiB
Python
40 lines
2.1 KiB
Python
"""A request the app refuses, said in a way the UI can put in the reader's language.
|
|
|
|
Every refusal the API answers carries a structured `detail` — `{code, reason, …params}` — and the client
|
|
translates it (`lib/api/refusalText.ts` `localizeDetail`). A bare English string reached the Hungarian UI
|
|
verbatim: the blocking error dialog, and every inline surface that printed `HttpError.detail`, showed
|
|
whatever sentence the route happened to hand-write. `refused` is the generic family
|
|
(`errors.refused.<reason>`, the params interpolated into the sentence); the older specific codes
|
|
(`not_found`, `youtube`, `playlist`, the admin refusals, …) stay, since each is already translated.
|
|
|
|
A test (`test_http_details.py`) reads every `HTTPException` in the app and fails on a string detail,
|
|
and the frontend's contract test (`i18n/backendIds.contract.test.ts`) requires every `code` a detail
|
|
carries to be in one record of `lib/api/refusalCodes.ts`, and every reason it can be sent with — a
|
|
literal, or a `Literal` type when it travels in a variable — to have its sentence in both languages.
|
|
So the rule is enforced, not described.
|
|
"""
|
|
|
|
from fastapi import HTTPException
|
|
|
|
|
|
def refused(status: int, reason: str, **params: object) -> HTTPException:
|
|
"""The refusal to raise: `raise refused(409, "view_name_taken", name=name)`. `params` travel in
|
|
the detail for the sentence to interpolate (`{{name}}`); keep them to values the reader may see."""
|
|
return HTTPException(status_code=status, detail={"code": "refused", "reason": reason, **params})
|
|
|
|
|
|
# `sysconfig.InvalidSetting.reason` → the refusal it answers as. A dict of literals, so the frontend's
|
|
# contract test can read every reason this can produce.
|
|
_SETTING_REASONS = {
|
|
"not_a_number": "setting_not_a_number",
|
|
"too_low": "setting_too_low",
|
|
"too_high": "setting_too_high",
|
|
"not_a_choice": "setting_not_a_choice",
|
|
"no_encryption_key": "no_encryption_key",
|
|
}
|
|
|
|
|
|
def setting_refused(exc) -> HTTPException:
|
|
"""A value the admin entered that `sysconfig.set_value` refused (`exc`: its `InvalidSetting`)."""
|
|
return refused(400, _SETTING_REASONS[exc.reason], key=exc.key, **exc.params)
|