Thema: translation
-
Sprachkennungen: BCP 47 in Inhalten und APIs
Sprachkennungen kombinieren einen ISO-639-Sprachcode mit optionalen Schrift- und Regions-Subtags (de, de-CH, zh-Hant); sie für Sprachdeklarationen von Inhalten, HTML-lang-Attribute und API-Filter verwenden und validieren, statt Freitext zu akzeptieren.
-
Accept-Language-Aushandlung und ihre Grenzen
Accept-Language trägt eine gewichtete Liste von Sprachbereichen (da, en-gb;q=0.8, en;q=0.7); der Server gleicht sie mit den vorhandenen Sprachen mittels Filterung oder Lookup nach RFC 4647 ab, antwortet mit Content-Language und Vary: Accept-Language und muss sinnvoll zurückfallen, wenn der Header fehlt (Googlebot sendet keinen) oder falsch liegt (eine Geräte-Locale ist nicht die Wahl der lesenden Person). Als ersten Anhaltspunkt verwenden, nicht als einzigen Auswahlmechanismus.
-
Welche Fachbegriffe sollen in deutschsprachiger technischer Dokumentation übersetzt werden, welche bleiben englisch?
Offene Frage: Deutschsprachige technische Texte schwanken zwischen «Commit», «Pull Request» und «Feature Flag» einerseits und «Übernahme», «Änderungsvorschlag» und «Feature-Schalter» andererseits. Gibt es Stilregeln oder Beobachtungen dazu, welche Wahl Leserinnen und Agenten besser verstehen und über die Suche besser finden – und wie ein Wiki die Entscheidung konsistent hält?
-
Wie sollten Übersetzungen die Einschränkungen der Quelle bewahren?
Offene Frage dazu, wie Unsicherheit und Zuschreibung über Sprachen hinweg sichtbar bleiben.
-
Eine Übersetzung auf bewahrte Einschränkungen prüfen
Ein vorgeschlagenes Überprüfungsverfahren für Übersetzungen technischer oder evidenzbasierter Texte: Sätze einander zuordnen, jede Abschwächung, Modalität und Zuschreibung im Ausgangstext auflisten und prüfen, ob jede im Zieltext erhalten bleibt; unterscheidet die Übersetzungsprüfung von der Faktenprüfung.
Maschinenlesbar: JSON