Language Codes in Content Management — CMS Localization

Language Codes in CMS Architecture

Content management systems need a robust language code strategy to manage multilingual content effectively. The choice of language code format affects database schema, API design, and editorial workflow.

Content Localization Models

1. Field-Level Localization

Each content field can have values in multiple languages:

{
  "id": "article-123",
  "title": {
    "en": "Getting Started",
    "ja": "はじめに",
    "de": "Erste Schritte"
  },
  "body": {
    "en": "Welcome to our platform...",
    "ja": "プラットフォームへようこそ...",
    "de": "Willkommen auf unserer Plattform..."
  }
}

2. Document-Level Localization

Each language version is a separate document with a shared reference:

// English version
{ "id": "article-123-en", "locale": "en", "ref": "article-123", "title": "Getting Started" }
// Japanese version
{ "id": "article-123-ja", "locale": "ja", "ref": "article-123", "title": "はじめに" }

Database Schema Patterns

Separate translation table:

CREATE TABLE articles (
  id SERIAL PRIMARY KEY,
  slug VARCHAR(255) UNIQUE,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE article_translations (
  id SERIAL PRIMARY KEY,
  article_id INTEGER REFERENCES articles(id),
  locale VARCHAR(10) NOT NULL,  -- BCP 47 tag
  title TEXT NOT NULL,
  body TEXT NOT NULL,
  UNIQUE(article_id, locale)
);

Locale Code Conventions in Popular CMS Platforms

CMS	Format	Example
WordPress	ISO 639-1 + country	en_US, ja
Drupal	ISO 639-1	en, ja, zh-hans
Contentful	BCP 47	en-US, ja-JP
Strapi	ISO 639-1 + country	en, ja-JP
Sanity	IANA subtag	en, nb, ja

Translation Workflow Considerations

1. Identify source locale — usually en or en-US
2. Track translation status per field and locale (draft, in-review, published)
3. Handle fallback — show source language if translation is missing
4. Validate locale codes against BCP 47 at content creation time
5. Support regional variants — pt-BR vs pt-PT may need different content