Como comunica a acción con Azure?
A través do SDK oficial de @azure-rest/ai-translation-text de Microsoft, superposto @azure/core-rest-pipeline. Isto dáche intentos automáticos en 408/429/5xx, modelos de petición e resposta escritos, e xestión de cabeceiras de autenticación de balde — todo o que antes era unha chamada axios feita a man. A superficie pública de acción (entradas, saídas, saídas de ficheiros) permanece sen cambios.
Por que as traducións ás veces son de marca ou de mal ton?
A tradución automática opta por defecto nun modelo de propósito xeral. Tres botóns axudan: un Glosario para sobreescrituras de termos duros, un Categoría de tradutor personalizado para modelos afinados adestrados no ton e vocabulario, e profanityAction para eliminar ou sinalar termos profanos.
Como podo evitar traducir o mesmo arquivo dúas veces?
Activa o fluxo de traballo en paths que coincidan só cos teus ficheiros de orixe, por exemplo, **/*.en.resx. A acción tamén inclúe o seu propio filtro de ficheiro por disparador cando GITHUB_TOKEN está configurado, reducindo o traballo a ficheiros no último commit.
Podo executar a acción sen conexión?
Non exactamente — Azure AI Translator é o cerebro do runtime. Pero podes executar con dryRun: true para validar análise sintáctica e configuración sen facer ningunha petición HTTP para tradución.
En que versión de Node se executa a acción?
A v3 funciona no tempo de execución de GitHub Actions node24. O JavaScript incluído é compatible cos Nodos 20, 22 e 24, que é o que CI proba.
De onde veñen os dist/ agrupados?
As accións JS de GitHub inclúen o seu JS compilado no repositorio. O fluxo de traballo de dist-build reconstrúeo despois de cada fusión para main se derivaría, e dist-check bloquea PRs que terían saídas desactualizadas.
E que pasa con outros formatos de recursos?
Hoxe: .resx, .xliff, .po, .json, .ini, .restext. Abrir un problema se precisas outro — a interface do analizador é pequena (analizar → mapear → aplicar traducións → formato) e as contribucións son benvidas.