When you turn a template into a bilingual site, the first instinct is usually to add a switcher.
But the hard part is not the switcher. The hard part is everything behind it: how navigation preserves the current language, how list pages keep linking into the right version, how detail pages find the paired entry on the same route, and how the CMS continues to edit all of that without drift.
That is why this pass puts structure ahead of styling. Posts and notes no longer assume a single language. Each entry now has a shared slug and translationKey, with Chinese and English stored as separate Markdown files while still resolving through the same front-end route.
That choice pays off in two ways. First, authors keep a normal Markdown workflow instead of pushing long-form content into awkward JSON fields. Second, the site never has to guess which translation belongs where. The route can simply look up the paired entry by translationKey.
Singleton content takes a different shape. Navigation, homepage copy, and explanatory pages behave more like site configuration than long-form writing, so those stay in JSON. Their fields now exist as explicit zh/en pairs so Decap CMS can keep editing them cleanly.
In other words, the bilingual layer is not just a visual toggle. Language is now part of the content model itself, which is what keeps the front-end and the CMS aligned after the first round of changes.