Ein String allein ist oft mehrdeutig. „Records“ kann Krankenakten, Schallplatten oder Datenbankzeilen bedeuten. In JSONC-Quelldateien wird ein Kommentar über einem Schlüssel als Kontext an die Engine übermittelt, damit die richtige Bedeutung übersetzt wird:
{
// Medical context: patient medical records
"records": "Records"
}Der Kommentar erscheint nie in der Ausgabe — er lenkt nur die Übersetzung.
Wo Hinweise funktionieren#
Hinweise für Übersetzer werden aus JSONC-Quelldateien (.jsonc) gelesen. Verweise mit einem files[]-Eintrag auf eine solche Datei:
{ "pattern": "content/en/app.jsonc" }JSON (.json) unterstützt keine Kommentare und kann deshalb keine Hinweise enthalten. Wenn du Hinweise verwenden möchtest, nutze für diese Datei JSONC.
Du kommst von der älteren CLI? Dort wurden Hinweise auch aus Xcode String Catalogs (.xcstrings) gelesen. Dieses Format wird von der aktuellen CLI nicht unterstützt, daher sind JSONC-Kommentare heute der richtige Weg, um Kontext mitzugeben.
Nützliche Hinweise schreiben#
Ein guter Hinweis liefert Kontext, den der String selbst nicht mitbringt:
{
// Button in the checkout flow — keep it short
"checkout.pay": "Pay now",
// "Set" here means a collection, not the verb
"library.set": "Set",
// Formal tone — shown in the legal footer
"footer.terms": "Terms of Service"
}| Hinweis | Warum es hilft |
|---|---|
// Appears in the top nav | teilt der Engine mit, wo der String erscheint und dass er kurz sein sollte |
// "Light" is the theme, not weight | klärt die Bedeutung eines mehrdeutigen Worts |
// Formal register | gibt den gewünschten Ton vor |
Hinweise, die den String nur wiederholen (// This says Welcome), bringen nichts — lass sie weg.
Hinweise vs. Engine-Konfiguration#
Hinweise für Übersetzer gelten pro String und stehen in deinem Quelltext. Regeln, die für eine ganze Sprache gelten — Terminologie, Ton, Markenstimme — solltest du stattdessen in der Engine festlegen, damit sie überall greifen, ohne dass du an jedem Schlüssel einen Hinweis ergänzen musst.
