Op een dag gaf de president me de opdracht: "Laten we onze website meertalig maken. Blijkbaar is er een Google Cloud Translation API die automatisch kan vertalen tijdens het bouwproces!"
Onze website is een statische site (SSG) gebouwd met Astro. Ik besloot Astro te implementeren tijdens mijn onderzoek naar de Google Cloud Translation API.
Voorbereiding: Activeer de API-sleutel en maak een serviceaccount aan.
De Cloud Translation API inschakelen
Google Cloud ConsoleSelecteer bij "API's en services" de optie "Cloud Translation API".Inschakelen
Een serviceaccount en -sleutel aanmaken
Om de API te gebruiken, moet u een serviceaccount aanmaken en de JSON-sleutel downloaden.
Deze JSON-sleutel bevat uw privésleutel, dus wees uiterst voorzichtig en maak deze niet openbaar.
Verleen toegangsrechten tot het serviceaccount.
Ga naar IAM en voeg het e-mailadres van het serviceaccount toe als principal en de rol als "Cloud Translation API User".
Hoe genereer je meertalige pagina's?
De eerste methode die ik probeerde was om "het Astro-bestand te kopiëren, direct de vertaal-API aan te roepen en automatisch meertalige Astro-bestanden te genereren."
Hoewel de pagina gegenereerd werd, stuitten we op verschillende problemen, zoals kapotte codeblokken, incompatibiliteit met geïmporteerde componenten en problemen bij het schrijven van tags binnen attributen. Daarom hebben we onze aanpak gewijzigd.
Uiteindelijk heb ik gekozen voor een eenvoudig nabewerkingsproces dat de statische HTML die na de build is gegenereerd, vertaalt.
De taalinstellingen zijn gekoppeld aan het i18n-configuratiebestand van Astro.
Om de meertalige structuur van de site te beheren, heb ik het Astro i18n-configuratiebestand gebruikt (LOCALES_SETTINGIk heb dit gebruikt als "configuratiebestand" voor het vertaalscript.
Om een taal toe te voegen, kunt u deze hier invoeren.
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',
},
};
Implementatie van taalwisseling
De keuzelijst voor de taalselectie wordt ook gegenereerd op basis van het eerder genoemde i18n-configuratiebestand. Omdat het label de naam van het geselecteerde item wordt, willen we het niet vertalen. Daarom hebben we code toegevoegd om het te overschrijven met de waarde van het label. (Het lijkt erop dat `translate="no"` niet werkt met de Cloud Translation API.)
Trouwens, ik kreeg de instructie om "nationale vlaggen in het dropdownmenu te plaatsen", dus dat heb ik geprobeerd, maar het blijkt dat het gebruik van nationale vlaggen voor taalwisseling een averechts patroon is. Als een Duitstalige gebruiker bijvoorbeeld Oostenrijks is, kan diegene in de war raken door de Duitse vlag. Landen en talen komen dus niet per se overeen. Nu je het zegt, klopt dat. Het kan in sommige gevallen een gevoelig punt zijn.
Cache om het API-gebruik te minimaliseren.
Het mechanisme voor het genereren van meertalige tekst is op dit moment bijna voltooid. Het probleem zit hem echter in de kosten.
Door vallen en opstaan en herhaalde builds liepen de API-gebruikskosten al snel op tot meer dan 10.000 yen.
Daarom wordt tijdens het bouwproces de combinatie van Japans en de door de API verwerkte vertaling als cache gebruikt.translate-cache.jsonDe volgende keer dat je een build uitvoert, wordt deze JSON toegepast. Als deze ontbreekt, wordt de API aangeroepen en het resultaat aan de JSON toegevoegd.
Het wordt als volgt opgeslagen.
{
"en:UIデザイン": "UI Design",
"en:私たちについて": "About Us",
"en:サービス": "Service",
...
}
Dit verlaagt de kosten aanzienlijk! Afhankelijk van de updatefrequentie bedragen de gebruikskosten slechts een paar honderd yen per maand.
Operationele notities
Wanneer je een artikel toevoegt aan het CMS en dit bouwt met een deploy hook, kan de server alleen verwijzen naar het oude cachebestand op Git. Daarom hebben we besloten om de operationele regel strikt te handhaven: lokaal bouwen bij het toevoegen van content en het bijgewerkte cachebestand naar Git pushen.
Vreemde vertalingen onder controle houden
Zoals te verwachten bij machinale vertaling, zitten er hier en daar wat vreemde vertalingen tussen.
Er waren opvallende inconsistenties in de spelling van eigennamen, zoals de bedrijfsnaam "Liberogic" die soms als "Liberogic" of "Liberogic" werd geschreven, en de aanduiding van de rechtsvorm van een bedrijf (Inc., Ltd., enz.) was niet gestandaardiseerd.
De Cloud Translation API beschikt over een woordenlijstfunctie, maar deze ondersteunt alleen machinevertaling en biedt geen volledige, gedetailleerde controle. Bovendien vereist het niet alleen het uploaden van een CSV-bestand, maar ook het uitvoeren van commando's om de resources telkens opnieuw aan te maken, wat het lastig maakt voor operationeel personeel dat niet bekend is met het web.
Spreadsheetintegratie voor betrouwbare controle
Daarom hebben we de taal en de correcte/onjuiste informatie in een spreadsheet verzameld, deze spreadsheet tijdens het bouwproces in CSV-formaat opgehaald en een tekstvervanging uitgevoerd om de notatie te overschrijven en te corrigeren.
Dit geeft medewerkers in de operationele afdeling de mogelijkheid om enige controle over vertalingen te hebben door simpelweg een spreadsheet bij te werken, zonder code aan te raken.
samenvatting
Na wat experimenteren is het me gelukt om een praktischer systeem voor automatische vertaling te creëren met behulp van de Google Cloud Translation API dan ik had verwacht. Voor kosteneffectieve en eenvoudige meertalige ondersteuning vind ik het perfect geschikt!
(De president zegt dat hij Arabische taalondersteuning aan RTL wil toevoegen, maar dat zal een omvangrijk project zijn.)
Hij maakte de overstap van DTP naar de webwereld en ontwikkelde zich al snel tot een "meester in zijn vak" met een beheersing van markup, front-end design, richting en toegankelijkheid. Sinds de oprichting van Liberogic is hij actief geweest in diverse vakgebieden en is hij nu een wandelend woordenboek binnen het bedrijf. De laatste tijd is hij geobsedeerd door het onderzoeken van efficiëntieverbeteringen met behulp van prompts, met de vraag: "Kunnen we meer op AI vertrouwen voor toegankelijkheid?" Zijn technologie en denkwijze blijven zich ontwikkelen.
Futa
IAAP-gecertificeerde specialist in webtoegankelijkheid (WAS) / Markup-engineer / Front-end-engineer / Webdirecteur