Translation providers

Fully backward compatible: provider defaults to azure, so existing Azure workflows keep working unchanged — no edits required.

Selecting a provider

Set the provider input to azure (default), aws, or google, then supply that provider's credentials. Only one provider is used per action call; the action deterministically delegates to the matching SDK behind a factory.

Provider comparison

Azure AI Translator (default)

The default provider. Provision an Azure AI Translator resource and pass subscriptionKey, endpoint, and optionally region. This is the same configuration existing workflows already use.

Official Azure docs

• Azure Translator documentation
• Translate API reference
• Custom Translator overview
• Language support

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5

      - id: translator
        uses: IEvangelist/resource-translator@v3
        with:
          provider: |
            azure:
              subscriptionKey: ${{ secrets.TRANSLATOR_KEY }}
              endpoint: ${{ secrets.TRANSLATOR_ENDPOINT }}
              region: ${{ secrets.TRANSLATOR_REGION }}
          sourceLocale: en
          toLocales: '["es","fr","de"]'

AWS Translate

Uses @aws-sdk/client-translate. Prefer OIDC via aws-actions/configure-aws-credentials so no long-lived secrets are stored — the action reads the AWS SDK default credential chain. Alternatively, pass awsAccessKeyId and awsSecretAccessKey explicitly. A region is always required, via awsRegion or the AWS_REGION environment variable.

Official AWS docs

• Amazon Translate overview
• TranslateText API reference
• Setting formality
• Using brevity
• Custom terminology
• Parallel data
• Supported languages

OIDC (recommended)

permissions:
  id-token: write # for aws-actions/configure-aws-credentials OIDC
  contents: write
  pull-requests: write

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gh-actions-translate
          aws-region: us-east-1

      - id: translator
        uses: IEvangelist/resource-translator@v3
        with:
          provider: |
            aws:
              region: us-east-1 # or rely on AWS_REGION from the step above
              formality: FORMAL
              brevity: true
          sourceLocale: en
          toLocales: '["es","fr","de"]'

To use static keys instead of OIDC, drop the aws-actions/configure-aws-credentials step and pass awsAccessKeyId / awsSecretAccessKey (via secrets) plus awsRegion.

Google Cloud Translation

Uses @google-cloud/translate (v2). Authenticate with either an API key (googleApiKey) or a service-account JSON credential (googleCredentials). Supply exactly one; an optional googleProjectId is inferred from the credential when omitted.

Official Google docs

• Cloud Translation documentation
• Cloud Translation setup
• Translating text
• Supported languages

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5

      - id: translator
        uses: IEvangelist/resource-translator@v3
        with:
          provider: |
            google:
              # Provide EITHER a service-account JSON credential...
              credentials: ${{ secrets.GCP_TRANSLATE_CREDENTIALS }}
              # ...OR an API key:
              # apiKey: ${{ secrets.GCP_TRANSLATE_API_KEY }}
              model: nmt
          sourceLocale: en
          toLocales: '["es","fr","de"]'

Intent-specifier mapping

Provider-specific specifiers are mapped where an equivalent exists. Everything else falls back to sensible defaults so behavior stays consistent.

Locale codes differ per provider

Each provider uses its own locale codes (for example Simplified Chinese is zh-Hans on Azure, zh on AWS, and zh-CN on Google). Codes pass through as-is and drive the output file names, so choose toLocales values your selected provider supports.