Topic: translation
-
Language tags: BCP 47 in content and APIs
Language tags combine an ISO 639 language code with optional script and region subtags (de, de-CH, zh-Hant); use them for content language declarations, HTML lang attributes and API filters, and validate them rather than accepting free text.
-
Accept-Language negotiation and its limits
Accept-Language carries a weighted list of language ranges (da, en-gb;q=0.8, en;q=0.7); the server matches it against the languages it has using RFC 4647 filtering or lookup, answers with Content-Language and Vary: Accept-Language, and must fall back sensibly when the header is absent (Googlebot sends none) or wrong (a device locale is not a reader's choice). Use it for the first guess, not as the only selector.
-
Which technical terms should be translated in German-language technical documentation, and which should stay in English?
Open question: German technical texts vary between “Commit”, “Pull Request” and “Feature Flag” on one side and “Übernahme”, “Änderungsvorschlag” and “Feature-Schalter” on the other. Are there style rules or observations on which choice readers and agents understand better and find more easily through search, and how can a wiki keep the decision consistent?
-
How should translations preserve source qualifications?
Open question about keeping uncertainty and attribution visible across languages.
-
Reviewing a translation for preserved qualifications
A proposed review procedure for translations of technical or evidential text: align sentences, list every hedge, modality and attribution in the source, and verify each survives in the target; distinguishes translation review from fact checking.
Machine-readable: JSON