Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Give the backend's English prose a code the frontend can translate

Aperta
  • Qualcosa non va?
#1,967 6 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@ybai08 ci sta già lavorando.

Dal 2/10/2026.

  • #2290 di @ybai08 — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python, typescript
Ambito
backend-api-design, localization

Direzione di ricerca

Read the Backend text section of docs/architecture/localization.md, then compare chat-error-text.ts and license-error-text.ts with one producer, such as artifacts/service.py, and its route test. Start with a single producer and write a backend test for its code and a frontend test for translated text plus the unknown-code fallback. Done means the covered prose has a code, interface-language text, and keeps the backend English fallback.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

desktop frontend help wanted UX

The gap

docs/architecture/localization.md lists this under Known gaps:

Backend prose without a code stays English in every language: model install messages, fit verdicts, not_runnable_reason, a Studio format's unavailable_reason, and the disk-space detail that lib/api.ts wraps in a translated sentence.

Why it matters

Someone running the app in Japanese or German meets English at exactly the moments the app is refusing or explaining itself: why a Studio format is greyed out, why a model card is flagged "Won't fit", why a model cannot run, what an install is doing, and why an upload failed for space. Those are the sentences a user most needs to read.

The disk-space one reads worst, because it is half done: lib/api.ts already wraps the backend's English sentence inside a translated one, so a German user gets a German frame around an English clause. The app also already has the answer, in two features — the backend sends a code beside its prose, and the frontend shows its own text for the code and falls back to the backend's English for a code it does not know. Everything in this gap line is prose with no code to key on.

Where

What done looks like

  • Each of those surfaces reads in the interface language, through an id the translate skill's key shape allows.
  • The backend still sends its English prose. A code the frontend has not shipped text for must keep showing something, which is what translatedChatError()'s final fallback relies on.
  • Decide whether each producer gets an enum mirrored in TypeScript, the way ChatErrorKind in sse.ts mirrors modules/chat/errors.py with a "keep the two in sync" comment, or a looser string. That is yours to decide, and it is the decision this issue turns on.
  • The fit verdicts carry numbers. Send them raw and format them in the message with an ICU skeleton — copy.py's _gb() currently pre-formats "13.6 GB", which no other language can re-space or re-punctuate.
  • It is fine to land this one producer at a time. Say in each PR which producer it closes, and delete the Known gaps line only with the last.

What not to change

This is not a docs/contracts/ change: those four documents cover the license file, scraper API auth, the export bundle and the sunset flag. The desktop API is one tree talking to itself.

How to verify

surfsense_local/backend/tests/integration/artifacts/test_routes.py already asserts on unavailable_reason, and surfsense_local/frontend/src/lib/api.test.ts on the error body. Write the failing test first on whichever producer you start with: a route test that the response carries the code, then a frontend test that the code renders its own text and an unknown code falls through to the backend's.

cd surfsense_local/backend
uv run pytest -m unit
uv run pytest -m integration
uv run ruff check .
cd ../frontend
pnpm test

Before you start

Read CONTRIBUTING.md and the localization doc, whose Backend text section states the rule this follows. Interface strings in surfsense_local follow the translate skill described in AGENTS.md — it owns the <feature>_error_<code> key shape, the tone per language and the glossary. translations/en.json is generated from the defaultMessage in the code, so never hand-edit it; run pnpm translations and commit the result with the code. Open your PR against dev, not main. Comment here to claim this.

Lingua principale
Python
Stelle
16.3k
Fork
1.6k
Merge medio
13h 35m
PR unite (30g)
267

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MODSetter/SurfSense

Tutte le issue di MODSetter/SurfSense

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.