Lect - Multilingual Content JSON

Key Features

Everything you need to build multilingual applications with structured content

JSON Structure

Clean, standardized JSON format that's easy to parse, validate, and integrate with any application or API.

Multilingual Support

Native language key support for all content fields. Store translations using standard language codes like 'en', 'zh-hans', etc.

Attributes

Scalar field values (string, number, boolean) that don't require translation. Perfect for metadata like price, date, status, and other universal data.

Collections

Support for arrays of multilingual content objects like comments, related posts, and other grouped content structures.

Entity Relationships

Built-in pointer system for references to authors, categories, and related content with relevance scoring.

Advantages

Superior to traditional POT/PO files - single unified structure, native JSON format, direct database storage, and no compilation steps required.

See It In Action

Example Lect object structure for a multilingual blog post

blog_post.json

{
  "_type": "blog_post",
  "_pointers": {
    "author": "user_123",
    "category": "category_456"
  },
  "date": "2025-06-22T02:30:00Z",
  "published": true,
  "featured": false,
  "view_count": 0,
  "title": {
    "en": "Introduction to LionRockJS",
    "zh-hans": "LionRockJS简介"
  },
  "excerpt": {
    "en": "Learn the basics of this powerful CMS framework",
    "zh-hans": "学习这个强大的CMS框架"
  },
  "content": {
    "en": "<p>LionRockJS is a modern content management system...</p>",
    "zh-hans": "<p>LionRockJS是一个现代的内容管理系统...</p>"
  },
  "comments": [
    {
      "date": "2025-06-22T03:00:00Z",
      "approved": true,
      "author_name": {
        "en": "John Doe"
      },
      "email": {
        "en": "[email protected]"
      },
      "content": {
        "en": "Great article! Very helpful."
      }
    }
  ],
  "related_posts": [
    {
      "_pointers": {
        "post": "post_789"
      },
      "relevance_score": 0.85
    }
  ]
}

Attributes vs Multilingual Fields

Understanding when to use scalar attributes vs multilingual objects

attributes.json

Scalar Values

{
  // Universal scalar values (no translation needed)
  "price": 29.99,
  "currency": "USD",
  "date": "2025-06-22T02:30:00Z",
  "published": true,
  "featured": false,
  "view_count": 1247,
  "rating": 4.5,
  "status": "active",
  "category_id": "tech_123"
}

multilingual.json

Translatable Content

{
  // Content that needs translation
  "title": {
    "en": "Product Launch",
    "zh-hans": "产品发布",
    "es": "Lanzamiento del Producto"
  },
  "description": {
    "en": "Amazing new features",
    "zh-hans": "令人惊叹的新功能",
    "es": "Características increíbles"
  }
}

Key Principle

Use Attributes For

Numbers, dates, booleans, IDs, status codes, and other universal data that means the same across all languages

Use Multilingual Objects For

Text content, descriptions, titles, and any human-readable content that needs translation

Working with Collections

Arrays of multilingual content objects for complex data structures

comments_collection.json

Comments Array

{
  "comments": [
    {
      "date": "2025-06-22T03:00:00Z",
      "approved": true,
      "author_name": {
        "en": "John Doe",
        "zh-hans": "约翰·多伊"
      },
      "content": {
        "en": "Great article!",
        "zh-hans": "太棒了！"
      }
    },
    {
      "date": "2025-06-22T04:15:00Z",
      "approved": true,
      "author_name": {
        "en": "Maria Garcia",
        "es": "María García"
      },
      "content": {
        "en": "Very helpful tutorial",
        "es": "Tutorial muy útil"
      }
    }
  ]
}

related_posts.json

Relations Array

{
  "related_posts": [
    {
      "_pointers": {
        "post": "post_789"
      },
      "relevance_score": 0.85,
      "title": {
        "en": "Advanced Features",
        "zh-hans": "高级功能"
      }
    },
    {
      "_pointers": {
        "post": "post_456"
      },
      "relevance_score": 0.72,
      "title": {
        "en": "Getting Started Guide",
        "zh-hans": "入门指南"
      }
    }
  ]
}

Array Structure

Collections are arrays containing multiple objects, each with their own multilingual fields

Mixed Languages

Each item in the collection can have different language combinations as needed

Flexible Schema

Mix attributes (scalars) and multilingual objects within each collection item

Lect vs POT/PO Files

A comprehensive comparison between Lect objects and traditional GNU gettext POT/PO files for multilingual content management

Lect Format (JSON)

{
  "welcome_message": {
    "en": "Welcome to our website",
    "fr": "Bienvenue sur notre site web",
    "zh-hans": "欢迎访问我们的网站"
  },
  "learn_more": {
    "en": "Learn more about our services",
    "fr": "En savoir plus sur nos services",
    "zh-hans": "了解更多我们的服务"
  }
}

Single unified structure

Native JSON - no parsing overhead

Direct database storage

API-friendly format

POT/PO Files (GNU gettext)

# POT file (template)
#: src/home.js:10
msgid "Welcome to our website"
msgstr ""

# PO file (French translation)
#: src/home.js:10
msgid "Welcome to our website"
msgstr "Bienvenue sur notre site web"

# Separate files needed:
# messages.pot, fr.po, zh.po...

Industry standard (30+ years)

Extensive tooling ecosystem

Separate files per language

Requires compilation step

Lect Workflow

// Direct manipulation
content.title.fr = "Nouveau titre";
await database.save(content);

// Access pattern
const message = content.welcome_message[currentLanguage];

Simple, direct manipulation with no compilation step needed

POT/PO Workflow

# Extract translatable strings
xgettext src/*.js -o messages.pot

# Update existing translations
msgmerge fr.po messages.pot -o fr.po

# Compile for runtime
msgfmt fr.po -o fr.mo

// Access pattern
const message = gettext("welcome_message");

Multi-step workflow with extraction, merging, and compilation

When to Use Each Approach

Lect is Better For:

CMS/Dynamic Content - Blog posts, product descriptions
API-Driven Applications - Mobile apps, SPAs
Database-Centric Systems - Content stored in NoSQL/SQL
Real-time Editing - In-app content editing
Hybrid Content - Mix of multilingual and non-multilingual fields

POT/PO is Better For:

Software/App Localization - UI strings, messages, labels
Translation Teams - Professional translators prefer PO tools
Complex Pluralization - Languages with complex plural rules
Static Content - Content that doesn't change frequently
Large Translation Projects - Enterprise-level localization

Storage

Lect: Database-native
POT/PO: File-based

Performance

Lect: Direct object access
POT/PO: Compiled binary lookup

Tooling

Lect: JSON editors, APIs
POT/PO: Poedit, Weblate, Crowdin

Structure

Lect: Nested JSON objects
POT/PO: Linear key-value pairs

Best of Both Worlds

Many modern applications use a hybrid approach - POT/PO files for UI localization and JSON-based formats like Lect for content management. This gives you the professional translation workflow for static UI elements and the flexibility of structured data for dynamic content.

Ready to Build Multilingual?

Start using Lect objects in your next project and unlock the power of seamless multilingual content management.

Download Spec Read Documentation

Lect Object