Choosing a workflow

Workflow recommendations for Lingo.dev CI/CD

Introduction

Lingo.dev CI/CD is designed to be flexible and can integrate with any existing workflows. As a starting point though, this page provides some recommended workflows to consider.

Note: There is no "best" workflow. Each workflow has a different set of trade-offs and will appeal to different users based on their preferences, team size, and established ways of working.

Option 1: Commit to main branch

When content changes are merged into your main branch, translations are automatically generated and committed directly back to the main branch.

Best for

Teams that want invisible, zero-friction translation updates with minimal developer involvement.

Advantages

  • Completely automated - no human intervention required
  • Translations are immediately available in the main branch
  • Simplest setup and maintenance
  • No additional branches or pull requests to manage

Trade-offs

  • No review process for translations
  • Potential for translation commits to trigger additional CI runs
  • Changes appear directly in main without visibility into what was translated
  • Less control over when translations are deployed

Option 2: Pull request from main branch

After content is merged into main, translations are generated and submitted as a new pull request from the main branch.

Best for

Teams that want translation visibility and review capabilities while keeping the process centralized on the main branch.

Advantages

  • Translation changes are visible and reviewable before merging
  • Clear audit trail of what content was translated
  • Ability to make manual adjustments before accepting translations
  • Maintains clean main branch history with explicit translation commits

Trade-offs

  • Requires manual pull request approval (unless auto-merge is configured)
  • Slight delay between content changes and translation availability
  • Additional pull requests to manage in your workflow

Option 3: Commit to feature branch

When content changes are made in feature branches, translations are automatically generated and committed directly to those same branches.

Best for

Teams working with long-lived feature branches who want translations to be part of the feature development process.

Advantages

  • Translations are ready when the feature is ready
  • No separate translation work needed during feature review
  • Complete features include both content and translations
  • Works well with feature flag deployments

Trade-offs

  • Translation commits appear in feature branch history
  • Potential merge conflicts if multiple developers work on the same branch
  • Translations tied to feature completion rather than content readiness
  • May generate translations for experimental features that never ship

Option 4: Pull request from feature branch

When content changes occur in feature branches, translations are generated and submitted as separate pull requests from those branches.

Best for

Teams that want maximum control and visibility over translations while maintaining feature branch workflows.

Advantages

  • Full visibility into translation changes at the feature level
  • Ability to review and adjust translations before feature completion
  • Clean separation between feature development and translation integration
  • Flexible timing for accepting translation updates

Trade-offs

  • Most complex workflow to manage
  • Multiple pull requests per feature (feature + translations)
  • Potential for translation pull requests to become stale if features change
  • Requires coordination between feature and translation pull requests