Eines Tages gab mir der Präsident den Befehl: „Lasst uns unsere Website mehrsprachig machen. Anscheinend gibt es da so etwas wie die Google Cloud Translation API, die automatisch während des Build-Prozesses übersetzen kann!“
Unsere Website ist eine statische Website (SSG), die mit Astro erstellt wurde. Ich habe mich dazu entschlossen, Astro im Rahmen meiner Recherchen zur Google Cloud Translation API zu implementieren.
Voraussetzungen: Aktivierung eines API-Schlüssels und Erstellung eines Dienstkontos
Aktivierung der Cloud-Übersetzungs-API
Google Cloud ConsoleGehen Sie zu „APIs und Dienste“ und wählen Sie „Cloud Translation API“ aus.Aktivieren
Erstellung eines Dienstkontos und Schlüssels
Um die API nutzen zu können, müssen Sie ein Dienstkonto erstellen und den JSON-Schlüssel herunterladen.
Dieser JSON-Schlüssel enthält Ihren privaten Schlüssel, daher sollten Sie ihn unter keinen Umständen preisgeben.
Zugriff auf das Dienstkonto gewähren
Gehen Sie zu IAM und fügen Sie die E-Mail-Adresse des Dienstkontos als Prinzipal und die Rolle „Cloud Translation API-Benutzer“ hinzu.
Wie man mehrsprachige Seiten erstellt
Als Erstes habe ich versucht, die Astro-Datei zu kopieren, die Übersetzungs-API direkt aufzurufen und automatisch mehrsprachige Astro-Dateien zu generieren.
Obwohl die Seite generiert wurde, gab es einige Probleme, die einfach nicht funktionierten, wie zum Beispiel ein defekter Code-Zaun, die fehlende Unterstützung importierter Komponenten und Probleme beim Schreiben von Tags innerhalb von Attributen. Deshalb habe ich meine Vorgehensweise geändert.
Am Ende entschied ich mich für einen einfachen Postbuild-Prozess, der „die Übersetzungsverarbeitung des nach dem Build generierten statischen HTML durchführt“.
Die Spracheinstellungen sind mit der i18n-Konfigurationsdatei von Astro verknüpft.
Zur Verwaltung der mehrsprachigen Struktur der Website habe ich die originale Astro i18n-Konfigurationsdatei verwendet (LOCALES_SETTINGIch habe dies als "Konfigurationsdatei" für das Übersetzungsskript verwendet.
Um eine Sprache hinzuzufügen, fügen Sie sie einfach hier hinzu.
export const LOCALES_SETTING: LocaleSetting = {
ja: {
label: '日本語',
lang: 'ja',
oglocale: 'ja_JP',
path: 'ja',
},
en: {
label: 'English',
lang: 'en',
oglocale: 'en_US',
path: 'en',
},
de: {
label: 'Deutsch',
lang: 'de',
oglocale: 'de_DE',
path: 'de',
},
es: {
label: 'Español',
lang: 'es',
oglocale: 'es_ES',
path: 'es',
},
cn: {
label: '简体中文',
lang: 'zh-CN',
oglocale: 'zh_CN',
path: 'zh-cn',
},
tw: {
label: '繁體中文',
lang: 'zh-TW',
oglocale: 'zh_TW',
path: 'zh-tw',
},
};
Implementierung des Sprachwechsels
Das Dropdown-Menü zur Sprachauswahl wird ebenfalls aus der i18n-Konfigurationsdatei generiert. Die Bezeichnung entspricht dem Namen des Auswahlelements, daher möchten wir sie nicht übersetzen. Aus diesem Grund fügen wir einen Prozess hinzu, der sie mit dem Wert der Bezeichnung überschreibt. (Die Option „translate="no"“ funktioniert nicht mit der Cloud Translation API.)
Übrigens wurde mir geraten, eine Nationalflagge in das Dropdown-Menü einzufügen, was ich auch versucht habe. Es scheint aber, dass die Verwendung einer Nationalflagge in einem Sprachauswahlmenü nicht optimal ist. Wenn beispielsweise ein deutschsprachiger Nutzer aus Österreich die Seite verwendet, könnte er durch die deutsche Flagge verwirrt werden, da diese verdeutlicht, dass Land und Sprache nicht immer zusammenpassen. Jetzt, wo Sie es erwähnen, stimmt das. In manchen Fällen könnte das tatsächlich ein heikles Thema sein.
Zwischenspeicherung zur Minimierung der API-Nutzung.
Der Mechanismus zur Generierung mehrsprachiger Texte ist mittlerweile nahezu fertiggestellt. Das Problem sind jedoch die Kosten.
Da ich verschiedene Dinge ausprobiert und es viele Male nachgebaut habe, überstiegen die API-Nutzungsgebühren schnell 10.000 Yen.
Daher wird während des Build-Prozesses die Kombination aus Japanisch und der von der API verarbeiteten Übersetzung als Cache verwendet.translate-cache.jsonBeim nächsten Build-Vorgang wird diese JSON-Datei angewendet. Falls sie fehlt, wird die API aufgerufen und das Ergebnis der JSON-Datei hinzugefügt.
Es wird so gespeichert.
{
"en:UIデザイン": "UI Design",
"en:私たちについて": "About Us",
"en:サービス": "Service",
...
}
Dadurch werden die Kosten erheblich reduziert! Je nach Aktualisierungshäufigkeit betragen die laufenden Kosten nur wenige hundert Yen pro Monat.
Betriebshinweise
Beim Hinzufügen von Artikeln über ein CMS und dem anschließenden Build über einen Deployment-Hook kann der Server nur auf die alten Cache-Dateien in Git zugreifen. Daher haben wir uns entschieden, die Regel strikt durchzusetzen, dass bei jedem Hinzufügen von Inhalten lokal gebaut und die aktualisierten Cache-Dateien in Git übertragen werden.
Kontrolle fehlerhafter Übersetzungen
Es handelt sich schließlich um eine maschinelle Übersetzung, und hier und da finden sich einige merkwürdige Übersetzungen.
Es gab auffällige Unstimmigkeiten bei der Schreibweise von Eigennamen, wie zum Beispiel wurde der Firmenname „Liberogic“ manchmal als „Liberogic“ oder „Liberogic“ geschrieben, und die Angabe des Gesellschaftsstatus (Inc., Ltd. usw.) war nicht standardisiert.
Die Cloud Translation API verfügt zwar über eine Glossarfunktion, unterstützt aber lediglich die maschinelle Übersetzung und bietet keine vollständige, detaillierte Steuerung. Darüber hinaus erfordert sie nicht nur das Hochladen einer CSV-Datei, sondern auch die Ausführung von Befehlen zur Neuerstellung der Ressourcen bei jeder Übersetzung, was für Mitarbeiter ohne Webkenntnisse schwierig ist.
Zuverlässige Steuerung durch Tabellenkalkulationsintegration
Daher haben wir die Sprache und die Informationen zu korrekten/falschen Angaben in einer Tabelle zusammengefasst, diese Tabelle während des Build-Prozesses im CSV-Format abgerufen und eine Textersetzung durchgeführt, um die Notation zu überschreiben und zu korrigieren.
Das bedeutet, dass Administratoren Übersetzungen bis zu einem gewissen Grad steuern können, indem sie einfach eine Tabellenkalkulation aktualisieren, ohne dafür Code bearbeiten zu müssen.
Zusammenfassung
Nach vielen Versuchen und Irrtümern konnte ich mit der Google Cloud Translation API ein praktischeres System für die automatische Übersetzung entwickeln, als ich erwartet hatte. Ich denke, es ist für eine einfache und kostengünstige Mehrsprachigkeit ausreichend!
(Der CEO sagt, er wolle RTL-Arabisch kompatibel machen, aber das wäre ein großes Unterfangen.)
Er wechselte von Desktop-Publishing in die Webwelt und entwickelte sich schnell zu einem wahren Meister seines Fachs mit umfassenden Kenntnissen in Markup, Frontend-Design, Webentwicklung und Barrierefreiheit. Seit der Gründung von Liberogic ist er in verschiedenen Bereichen aktiv und gilt im Unternehmen mittlerweile als wandelndes Lexikon. In letzter Zeit beschäftigt er sich intensiv mit Effizienzsteigerungen durch den Einsatz von Eingabeaufforderungen und fragt sich: „Können wir uns bei der Barrierefreiheit stärker auf KI verlassen?“ Seine Technologien und sein Denken entwickeln sich stetig weiter.
Futa
IAAP-zertifizierter Spezialist für Webzugänglichkeit (WAS) / Markup-Ingenieur / Frontend-Entwickler / Webdirektor