Translations

Translations

src/i18n.h, src/i18n.cpp

German and English. Everything that reaches the screen is in both.

Strings sit at the call site

const char* T(const char* de, const char* en);

if (ImGui::Button(T("Dateien wählen ...", "Choose files ..."))) { … }

There is no table of numbered strings and no resource file. With a UI this size that trade is worth it three times over:

• The two languages cannot drift apart. Adding a string in one language without the other is a compile error, not a missing entry discovered by a user.
• Every string is greppable where it is used. Finding what a piece of text belongs to is one search, not a search followed by a lookup.
• There is no id bookkeeping to get wrong. No renumbering, no stale entries, no two call sites accidentally sharing an id.

The cost is that both languages are compiled into the binary and a third would mean touching every call site. For two, that has not been a problem.

Switching

void SetLanguage(Language language);
Language CurrentLanguage();

T() returns whichever pointer matches the current setting. Both strings are string literals with static storage, so returning a const char* is safe and there is no allocation anywhere in the path — which matters, because T() is called hundreds of times per frame from an immediate-mode UI.

The setting takes effect immediately. Nothing is cached, so there is nothing to invalidate.

Where language is decided late

Two places do not call T() where the text is produced, and both for the same reason: the work happens on a background thread and the language can change between the failure and the moment somebody looks at it.

Update errors carry an UpdateError enum and are turned into a sentence by UpdateErrorText() at display time. See Updates.

Capture and audio failures carry their own status codes for the same reason.

The general rule: if a string crosses a thread boundary or is stored for later, it stores the reason, not the sentence.

What the log is in

CAP_LOG and friends write German only. The log is a development artefact, not user-facing output, and translating it would double the noise in the source for no reader's benefit.

Keyboard names

Not translated by CapView at all. HotkeyText() reads key names from the keyboard layout through the OS, so a French keyboard reads its own labels rather than a translation of the American ones. See Shortcuts.