Papermark es una plataforma de intercambio de documentos de código abierto. Cuando el equipo decidió localizar su documentación, se topó con el problema que frena a la mayoría de los equipos de herramientas para desarrolladores: lograr que i18n funcione bien en una aplicación Next.js es más difícil que traducir.

El reto de implementación#

"Probé todos los paquetes de automatización y herramientas caseras que existen", recuerda Iuliia Shnai, fundadora de Papermark. "El mayor dolor ni siquiera era la traducción, sino lograr que i18n funcionara bien con la estructura de nuestra app."

Es un patrón bastante común. La mayoría de las herramientas de localización asumen que la infraestructura de i18n ya está resuelta. Se encargan de traducir, pero no de la configuración, la estructura de archivos, el procesamiento de MDX ni de los casos complejos que varían según el framework. Para un proyecto de código abierto con un equipo pequeño, invertir tiempo de ingeniería en montar la localización es un costo directo para el producto.

Los archivos MDX —documentación escrita en Markdown con componentes de React integrados— añaden otra capa de complejidad. Las herramientas de i18n convencionales manejan archivos JSON de idioma y cadenas simples. Pero el contenido MDX con interpolaciones de componentes, frontmatter y etiquetas personalizadas requiere un enfoque distinto.

Qué cambió#

Max, fundador de Lingo.dev, se acercó directamente y ayudó a configurar el proyecto Next.js de Papermark. La implementación resolvió los casos complejos que tenían bloqueado al equipo: el procesamiento de archivos MDX, la interacción entre next-intl y la estructura de archivos de la app, y la extracción de cadenas traducibles en documentación cargada de componentes.

"La implementación resolvió muchísimos casos complejos que no habíamos considerado", dice Shnai. "Quedó claro que habían pensado en todas las complejidades de la localización, especialmente en los archivos MDX, que para nosotros eran un punto especialmente doloroso."

Desde el primer día: 80 páginas de documentación traducidas. El motor de localización —configurado con la terminología de producto de Papermark y conectado a su repositorio— se encargó automáticamente de todo el conjunto de documentación.

Cómo funciona ahora#

El motor de localización de Papermark corre con cada push de código. Cuando se agrega nueva documentación o se actualiza contenido existente, el motor traduce los cambios automáticamente. Los ingenieros escriben la documentación en inglés; las versiones localizadas aparecen sin pasos adicionales.

La persistencia marca la diferencia aquí. Como el motor de localización conserva la terminología de producto de Papermark en cada solicitud, términos específicos del producto como "Data Room", "Link tracking" y "NDA flow" se traducen de forma consistente en todos los idiomas. Tanto la primera página de documentación que pasa por el motor como la número cien aplican el mismo vocabulario de producto.

"Cero esfuerzo continuo de ingeniería para las traducciones" es el resultado medible, pero la razón de fondo es que la localización dejó de ser una tarea recurrente para convertirse en infraestructura.

Resultados#

• 80 páginas de documentación traducidas desde el primer día
• Cero esfuerzo continuo de ingeniería para la localización
• Gestión automática de documentación MDX compleja
• Traducción continua con cada push, tanto de contenido nuevo como actualizado
• Terminología consistente en todos los idiomas

En un proyecto de código abierto, la ecuación económica importa. Cada hora que no se dedica al mantenimiento de la localización es una hora que se puede invertir en el producto. Papermark sigue ampliando su motor de localización para abarcar la optimización SEO en distintos idiomas.