should we use message format's 2.0 spec to build a git-based localization framework?

[samuelstroschein]

Hi everyone,

We are working on one of the non-goals of Message Format 2.0:

Build a framework for localizing software. Instead, design the standard as a building block to be used by third parties to create localization frameworks.
Source

A git-based localization framework that offers tools for developers, an editor for translators (VSCode + Figma), and automation via CI/CD. Here is the RFC opral/monorepo#127.

Deeper explanation of inlang

Existing solutions break the single source of truth for messages by storing messages in a database to offer a CRUD editor for translators. However, even after adopting a localization solution, developers still act on the git repo while translators act on a database. The split requires synchronization and integration pipelines between both states. Furthermore, the workflows of developers and translators are overlapping, and dependent on each other. If a developer adds a new feature, the developer has to wait for the translator to create the corresponding translations. Vice versa does the translator need to know what changes developers conduct. But, the workflows of developers and translators are separated. Coming back to the two-state problem: Developers use git(hub) to create, manage and review changes, while translators use the provided localization software that adds another create, manage, and review layer. Both layers not only need to be synched for the actual state but also for the workflows.

Git provides all workflows that an editor for translators requires:

• version control
• review system
• automation

Thus, we are planning on building an entire git-based localization system that avoids the two-state and two workflow silo problems. Developers get tools to automate localization and translators get a git-based editor (think of VSCode + Figma).

We are wondering whether we should build on Message Format 2.0's spec in its current form.

MessageFormat 2.0 will most likely become the standard. We want to support standardization localization. Our concern revolves around the stability of productions. We would use the productions to design an AST that will be exposed to developers (hence, stability is important). Developers can use the AST to parse and serialize syntaxes (MessageFormat 1.0, Fluent, etc.).

Despite stage 1, the spec seems advanced. Small(er) breaking changes should not be an issue. But, does anyone expect major overhauls?