Establishing ownership of translation content

Translation ownership is a common friction point as repositories grow. Who approves changes to the billing copy? Who is responsible for the onboarding flow? Which team owns the error messages that legal has signed off on?

Because Messagevisor definitions are files in a Git repository, they can be governed with exactly the same tools you already use for code ownership: CODEOWNERS files, branch protection rules, and pull request workflows. No separate system required.

Why file-based ownership works#

Every message in Messagevisor is a definition file at a predictable path derived from its key:

messages/billing/invoice.yml   → billing.invoice
messages/onboarding/step1.yml  → onboarding.step1
messages/legal/terms.yml       → legal.terms

Namespaces map to directory hierarchies. A team that owns the billing product owns the messages/billing/ directory. An ownership rule on that directory means every pull request that touches any billing message automatically requests review from that team.

GitHub CODEOWNERS#

Create a .github/CODEOWNERS file in your Messagevisor repository:

# Default owner for everything not otherwise covered
*                               @platform-team
# Billing team owns all billing copy
messages/billing/               @billing-team
# Legal team must approve all legal and compliance copy
messages/legal/                 @legal-team
messages/compliance/            @legal-team
# Onboarding team owns onboarding and trial messages
messages/onboarding/            @growth-team
messages/trial/                 @growth-team
# Marketing owns the landing and campaign messages
messages/landing/               @marketing-team
messages/campaign/              @marketing-team
# The locales directory is owned by the i18n platform team
locales/                        @i18n-team
# Segment definitions require platform team review
segments/                       @platform-team

With this in place, GitHub automatically requests a review from the appropriate team when a pull request touches any of these paths. Changes to messages/billing/invoice.yml will require approval from @billing-team before they can be merged.

Enabling required reviews#

For ownership to be enforced rather than advisory, enable branch protection on your main branch:

1. Go to repository Settings → Branches
2. Add a branch protection rule for main
3. Enable "Require a pull request before merging"
4. Enable "Require review from Code Owners"

With this configuration, a pull request that modifies messages/legal/terms.yml cannot be merged until someone from @legal-team approves it. The check is automatic and cannot be bypassed without repository admin access.

Namespace structure as an ownership signal#

Choose your namespace structure with team ownership in mind. Flat structures are harder to govern:

messages/
├── signin.yml
├── invoice.yml
├── terms.yml
├── onboarding-step1.yml
└── onboarding-step2.yml

Namespace-aligned structures map cleanly to CODEOWNERS rules:

messages/
├── auth/
│   └── signin.yml
├── billing/
│   └── invoice.yml
├── legal/
│   └── terms.yml
└── onboarding/
    ├── step1.yml
    └── step2.yml

The messages/legal/ directory is a single CODEOWNERS entry. The messages/onboarding/ directory is another. You can change ownership for an entire domain without updating multiple rules.

Ownership for sets-based projects#

When you use sets to model environments, ownership can be applied per-environment path. This is useful when the QA or release team has authority over what reaches production but not over dev:

# Billing team owns dev and staging billing content
sets/dev/messages/billing/      @billing-team
sets/staging/messages/billing/  @billing-team
# Production billing content requires QA sign-off too
sets/production/messages/billing/ @billing-team @qa-team

This pattern means promotion from staging to production on billing messages requires both the billing team's approval and QA's approval. Dev and staging changes only need billing team review.

Owning segments and locales#

Segments and locales are also files and can be governed with CODEOWNERS:

# Audience segments require data or analytics team review
# because they define who sees what
segments/                       @data-team @platform-team
# Locale files require i18n platform team review
# because format changes affect every message in that locale
locales/                        @i18n-team

Segments deserve ownership governance because they define behavioral targeting rules. A change to segments/plan-pro.yml that accidentally widens the audience can serve premium copy to free users. Having @data-team as a required reviewer catches this class of error before merge.

Ownership of test files#

Test files are also governed by CODEOWNERS. If the billing team owns messages/billing/, they should also own tests/messages/billing/:

messages/billing/               @billing-team
tests/messages/billing/         @billing-team

This matters because a test file that locks the exact text of a billing message is just as important as the message definition itself. If someone changes a billing message and also updates its test to pass, both changes go through billing team review. Ownership of the test enforces that the lock was intentionally updated, not circumvented.

Tracking ownership through promotions#

In a sets-based project, ownership applies at each set level. When content is promoted from sets/dev/ to sets/staging/, the CODEOWNERS rule for sets/staging/messages/billing/ triggers a review from the billing team on the staging path. This gives teams an additional checkpoint at each stage of the promotion flow.

sets/dev/messages/billing/         @billing-team
sets/staging/messages/billing/     @billing-team
sets/production/messages/billing/  @billing-team @qa-team

Production content requiring both billing team and QA approval means the promotion-to-production PR for billing messages cannot be merged until both teams have reviewed.

Related#

• Messages
• Segments
• Locales
• Sets
• Catalog
• GitOps
• GitHub Actions