Papermark is an open-source document sharing platform. When the team decided to localize their documentation, they hit the problem that stops most developer tools teams: getting i18n working correctly with a Next.js application is the harder problem than translation itself.

The setup problem#

"I tried every automation package and self-made tool out there," recalls Iuliia Shnai, Founder of Papermark. "The biggest pain wasn't even the translation step – it was getting i18n working properly with our app structure."

This is a familiar pattern. Most localization tools assume the i18n infrastructure is already in place. They handle translation. They don't handle the configuration, file structure, MDX parsing, or the edge cases that differ by framework. For an open-source project with a small team, spending engineering time on localization setup is a direct cost to the product.

MDX files – documentation written in Markdown with embedded React components – add another layer. Standard i18n tools handle JSON locale files and simple strings. MDX content with component interpolations, frontmatter, and custom tags requires a different approach.

What changed#

Max, Lingo.dev's founder, reached out directly and helped configure Papermark's Next.js project. The implementation handled the edge cases the team had been blocked on: MDX file processing, the interaction between next-intl and the app's file structure, and extraction of translatable strings from component-heavy documentation.

"The implementation handled so many edge cases we hadn't considered," says Shnai. "It was clear they had thought through all the complexities of localization, especially for MDX files which were a particular pain point for us."

On day one: 80 documentation pages translated. The localization engine – configured with Papermark's product terminology and connected to their repository – handled the entire documentation set automatically.

How it works now#

Papermark's localization engine runs on every code push. When new documentation is added or existing content is updated, the engine translates the changes automatically. Engineers write documentation in English; localized versions appear without any additional steps.

The statefulness matters here. Because the localization engine persists Papermark's product terminology across every request, product-specific terms like "Data Room," "Link tracking," and "NDA flow" translate consistently across all languages. The first documentation page through the engine and the hundredth both apply the same product vocabulary.

"Zero ongoing engineering effort for translations" is the measurable outcome – but the underlying reason is that localization became infrastructure rather than a recurring task.

Results#

• 80 documentation pages translated on day one
• Zero ongoing engineering effort for localization
• Automatic handling of complex MDX documentation
• Continuous translation on every push, covering new and updated content
• Consistent terminology across all languages

For an open-source project, the economics matter. Every hour not spent on localization maintenance is an hour available for the product. Papermark continues to extend its localization engine to cover SEO optimization across locales.