Messagevisor

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? When this is informal - "ask Sarah on Slack" - changes to critical copy slip through without the right review, and nobody is automatically notified when content they own changes.

Because Messagevisor definitions are YAML 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 YAML 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:

.github/CODEOWNERS
# 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:

Hard to govern - flat
messages/
├── signin.yml
├── invoice.yml
├── terms.yml
├── onboarding-step1.yml
└── onboarding-step2.yml

Namespace-aligned structures map cleanly to CODEOWNERS rules:

Easy to govern - namespaced
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.

Using meta for authoring-time ownership signals

In addition to CODEOWNERS for PR enforcement, meta on a message can carry authoring-time ownership metadata that appears in the catalog and CSV exports. This is useful for documentation purposes - who requested this copy, which team is responsible for keeping it current:

messages/billing/invoice.yml
description: Invoice download button label
meta:
  owner: billing-team
  slack: "#billing-eng"
  lastReviewedBy: ada@yourcompany.com
  lastReviewedAt: "2025-11-15"
translations:
  en: Download invoice
  nl: Factuur downloaden

Meta fields do not affect evaluation or build output shape, but they are included in the built datafile and accessible via getMessageMeta() in the SDK. If your application shows a translation management interface internally, meta can surface ownership information in that UI.

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:

.github/CODEOWNERS
# 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:

.github/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.

Communicating ownership through the catalog

The catalog is a useful shared reference for non-engineers who want to understand content ownership without reading Git files. The description field on messages, and meta fields, both surface in the catalog. You can establish an informal convention like:

messages/legal/gdprConsent.yml
description: GDPR consent checkbox label - owned by legal team, any changes require legal sign-off
meta:
  owner: legal-team
  complianceRequired: true
translations:
  en: I agree to the terms of service and privacy policy
  nl: Ik ga akkoord met de servicevoorwaarden en het privacybeleid

This gives anyone browsing the catalog enough context to understand that this message has special approval requirements before they open a pull request.

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/:

.github/CODEOWNERS
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.

.github/CODEOWNERS
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.