Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

i18n: decide the localization approach before extracting UI strings

Đang mở
  • Có gì không ổn?
#350 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp
Lĩnh vực
desktop, documentation, internationalization

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C#
Star
1
Fork
3
Merge trung bình
4 giờ 34 phút
Pull request đã merge (30 ngày)
182

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CodeForFire/lagebuch

Tất cả issue của CodeForFire/lagebuch

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.