Polytype

A designer draws a button that reads “Save changes.” Then localization happens. French turns it into “Enregistrer les modifications” — nearly twice as wide. German stacks compound words. Hebrew and Arabic flip the whole layout right-to-left. Japanese does not break lines on spaces. The usual remedy is to ship it and hope CSS survives.

Polytype is an experiment in reversing that assumption. It treats script, locale, direction, line breaking, font coverage, and text expansion as inputs to the design system — not bugs discovered after translation.

The engine sits above the browser's text shaping. It does not reimplement HarfBuzz, Unicode bidi, or rasterization; it makes the product and design decisions below that layer the browser has no opinion about — which font a script should use, how much leading it needs, and whether a label will overflow once it is translated.

A deterministic pipeline: content → locale and script analysis → typographic policy → font and fallback resolution → line-break and width behavior → direction and punctuation → responsive adaptation. Each stage is a small, inspectable, pure function; the engine exposes a resolve() that returns a concrete TypographyPolicy for a given context.

The core object is a TypographyContext — locale, content type, density, and the sample text — resolved to a TypographyPolicy: font stack, size, line-height, letter-spacing, text-align, hyphenation, line-break mode, and overflow strategy. A component stops hardcoding font-size: 16px; line-height: 1.5 and instead asks the engine for values correct for the script and the content type.

Script analysis inspects actual character usage by Unicode block rather than trusting the locale, so a string mixing Latin, Hebrew, and numerals resolves per run and the coverage audit reports exactly which faces each run will fall back to. Line-height is script-dependent, because equal numbers do not read as equal rhythm across scripts — the kind of value a script-aware design token should carry.

Expansion forecasting measures rendered width with canvas and compares each translation to the component's budget, so overflow is caught before anyone opens the app in that language. Everything in the core is deterministic and inspectable — there is deliberately no model in the decision path. That is the point: it shows where a model does not belong.

A working engine that makes multilingual typography testable: a locale matrix that flags overflow, a coverage audit that names missing glyphs, and pseudo-localization that exposes layout assumptions before translation begins. The core is small enough to read in one sitting and deterministic enough to trust — a portfolio piece that is genuinely built, not described.