A PT/EN Toggle Without a Second Content Pipeline

The original assumption in SPEC.md was blunt: "all public content is in English, i18n is a future feature." That held until the actual ask surfaced — not "translate everything," but "let a Portuguese visitor read the site's own words in Portuguese without forcing every future post to be written twice."

Where the line got drawn

Site chrome — navigation, buttons, section headings, dates, empty states — is translated. It's a fixed, small set of strings that change rarely and are worth maintaining in two locales. Project descriptions and Post bodies are not translated automatically or manually by default: they stay single-language, because doubling every future piece of content is a tax on writing that never goes away, while chrome strings are a tax paid once per new UI element.

Why "one content pipeline" mattered more than "fully bilingual"

A second content pipeline — separate title_pt/title_en columns, or a locale-keyed content table — would have made every future Post or Project creation a two-language chore, permanently, for a personal site with one author. The chrome-only translation keeps the content model exactly as it was; only the UI strings around it gained a locale dimension.

What a Portuguese visitor actually gets

The site frame — labels, navigation, the blog's own UI — greets them in Portuguese. The posts and project descriptions themselves render in whatever language they were written in, which today is English. That's a real, bounded trade-off, not a half-finished feature: full content translation is explicitly out of scope until there's a concrete reason to double the writing cost, not a hypothetical one.