Hoe communiceert de actie met Azure?
Via Microsofts officiële @azure-rest/ai-translation-text SDK, bovenop @azure/core-rest-pipeline. Dat levert automatische herhalingen op 408/429/5xx, getypte verzoek- en responsmodellen, en gratis afhandeling van authenticatieheaders — alles wat vroeger een handgeschreven axios oproep was. Het publieke actieoppervlak (invoer, uitvoer, bestandsuitvoer) is ongewijzigd.
Waarom zijn vertalingen soms niet passend of niet in de toon?
Machinevertaling gebruikt standaard een algemeen model. Drie knoppen helpen: een Verklarende woordenlijst voor harde term-overrides, een Custom Translator-categorie voor fijn afgestelde modellen die getraind zijn op je toon en woordenschat, en profanityAction om grof of grof te schrapen.
Hoe voorkom ik dat ik hetzelfde bestand twee keer moet vertalen?
Activeer de workflow op paths die alleen overeenkomen met je bron-locatiebestanden, bijvoorbeeld **/*.en.resx. De actie bevat ook een eigen per-trigger bestandsfilter wanneer GITHUB_TOKEN is ingesteld, waardoor het werk wordt beperkt tot bestanden in de nieuwste commit.
Kan ik de actie offline uitvoeren?
Niet precies — Azure AI Translator is het runtime-brein. Maar je kunt met dryRun: true draaien om parsing en config te valideren zonder HTTP-verzoeken voor vertaling te hoeven doen.
Op welke Node-versie draait de actie?
v3 draait op de GitHub Actions node24 runtime. De meegeleverde JavaScript is compatibel met Node 20, 22 en 24, wat CI test.
Waar komt de gebundelde dist/ vandaan?
GitHub JS-acties leveren hun gecompileerde JS in de repository. De dist-build workflow bouwt het na elke merge opnieuw op om te main of het zou driften, en blokkeert dist-check PR's die verouderde output zouden belanden.
Hoe zit het met andere bronformaten?
Vandaag: .resx, .xliff, .po, .json, .ini, .restext. Open een probleem als je nog een optie nodig hebt — de parserinterface is klein (parsen → kaart → vertalingen → formaat toepassen) en bijdragen zijn welkom.