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

i18n: decide the localization approach before extracting UI strings

Aperta
  • Qualcosa non va?
#350 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
desktop, documentation, internationalization

Direzione di ricerca

Read the existing placeholder-string precedent in src/LageBuch.Persistence/MasterData/MasterDataSet.cs:163 and inspect the German literals in src/ and the 23 .axaml files. Compare the listed localization mechanisms, scope, fallback, translator workflow, and migration options; the issue does not specify an implementation choice. Done means recording the decision in docs/ or this issue and converting one view end to end as a reference.

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

Descrizione

help wanted i18n

The org profile says applications "can be translated into other languages". The
code cannot, yet. There is no localization infrastructure at all:

  • zero .resx files under src/
  • no ILocalizer, no localization service, no string keys in DynamicResource
  • German sits as literal Text="…" and Content="…" in 23 .axaml files, and
    in German string literals inside view models and domain code

The one partial precedent is AnonymizedExampleData in
src/LageBuch.Persistence/MasterData/MasterDataSet.cs:163, which centralizes
placeholder strings as constants and is bound from XAML with {x:Static md:…}.
Ten view files already use it.

Why this is a design issue and not a chore

It is tempting to start extracting literals into constant classes view by view,
and that is exactly the trap. Constants are not translatable. Doing the
extraction first means doing it twice, and the second pass has to touch every
file the first one did.

So: decide the approach, then extract. That is why this issue exists and why the
per-view extraction tasks are not filed yet.

What needs deciding
  • Mechanism. .resx with the standard .NET ResourceManager, an Avalonia
    DynamicResource based scheme so the language can change without a restart,
    or a third-party library. Each has a different story for XAML binding, for
    designer support, and for how a translator supplies a file.
  • Scope. UI strings only, or also the German wording that reaches the PDF
    report and the ETB entries. The domain layer currently produces German text
    directly, for example Formatting and CoMeasurementLabels. Some of that is
    arguably domain vocabulary rather than UI copy.
  • Fallback and default. German stays the default. What happens for a missing
    key in another language.
  • Translator workflow. A plain file in the repo, or a platform such as
    Weblate. This decides whether a non-developer can contribute a translation,
    which is the whole point.
  • Migration order. Which view goes first as the proof of concept.
Output

A short design note in docs/, or a decision recorded in this issue, plus one
view converted end to end as the reference implementation. The remaining views
then become genuine good-first-issues that all follow the same pattern.

Opinions from anyone who has localized an Avalonia app are very welcome.

New here?

Comment to claim this issue and it is yours. If no pull request appears within
seven days it goes back in the pool, no hard feelings.

Before you open the PR, please skim CONTRIBUTING.md:
commits need DCO sign-off (git commit -s) and a Conventional Commit subject.
Changes under src/ additionally need an entry under ## [Unreleased] in
CHANGELOG.md — CI fails the PR otherwise.

Questions are welcome right here or in
Discussions.

Lingua principale
C#
Stelle
1
Fork
3
Merge medio
4h 15m
PR unite (30g)
181

Preparare l'ambiente

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 CodeForFire/lagebuch

Tutte le issue di CodeForFire/lagebuch

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.