Message architecture & MessageFormat

Structured messages, variables, selection logic, and authoring rules for grammatical, safe, maintainable multilingual interfaces. In practice, the work is bounded by a defined product or model decision, named audiences and locales, representative inputs, and acceptance criteria that can be reviewed.

Concatenated fragments and presentation-only placeholders cannot express plural, gender, case, agreement, or locale-dependent variants reliably—and can expose injection and fallback failures. The useful starting point is the smallest representative flow that can expose the cause, impact, and ownership of the problem.

Audit message construction: Find concatenation, overloaded keys, untyped variables, unsafe markup, missing variants, and runtime fallback behavior. Define the message contract: Specify schemas, selectors, annotations, escaping, fallback, translator context, lint rules, and versioning. Migrate and prove: Convert representative flows, add parser and rendering tests, validate difficult languages, and sequence adoption.

The most useful inputs are representative repositories and builds, architecture and content-flow documentation, supported and planned locales, design-system components, and known defects and release constraints. Admas can begin with a partial package, but missing context, rights, access, owners, or acceptance criteria will be made visible in the plan rather than treated as harmless assumptions.

Typical outputs include message-system architecture, variable and selector conventions, migration examples and lint rules, and multilingual message regression suite. Deliverables are adapted to the team that must use them, with decisions, evidence, limitations, owners, and next actions made explicit.

Quality is measured against the real task and risk. Relevant evidence can include locale-sensitive test coverage, severity and recurrence of internationalization defects, script and format correctness, time needed to add a locale, and reduction in one-off code paths. Sampling, severity rules, reviewers, adjudication, and pass or fail thresholds should be agreed before the result is used as a release decision.

Static analysis, pseudolocalization, property tests, visual regression, and locale-aware fixtures can expose repeatable failures. Engineers and language specialists still have to interpret ambiguous behavior, test real scripts and user journeys, and decide whether the product experience is correct. The right allocation depends on consequence, content stability, available references, language coverage, reversibility, and the cost of a plausible but wrong result.

The estimate changes with system and repository size, number of platforms and surfaces, architecture access, locale and script risk, depth of implementation or testing, and required documentation and enablement. Pricing should distinguish setup and discovery, repeatable units, specialist or engineering time, independent review, management, and external costs. A low unit price is not comparable if it excludes the QA cycle or shifts rework back to the buyer.