Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

i18n: decide the localization approach before extracting UI strings

Open
  • Is something wrong?
#350 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
desktop, documentation, internationalization

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
C#
Stars
1
Forks
3
Avg merge
5h 26m
Merged PRs (30d)
196

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CodeForFire/lagebuch

All issues in CodeForFire/lagebuch

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.