Multilingual Portfolio: Reaching a Global Audience

Why Language Matters

Here's a number that changed how I think about the web: 75% of internet users prefer to buy products in their native language. Even when they understand English, they trust content in their own language more. They stay longer. They engage more deeply.

For a portfolio, this insight carries weight. A hiring manager in São Paulo scanning my work shouldn't have to mentally translate while evaluating my skills. A potential collaborator in Tokyo should feel like the site was built with them in mind. Language isn't just about comprehension. It's about respect, trust, and the feeling that you belong here.

An English-only portfolio sends an unintentional message: "This is for English speakers first, everyone else second." I wanted to flip that. I wanted visitors from Brazil, Spain, Japan, and France to land on my site and think, "Oh, this person gets it."

Translation vs. Localization: A Critical Distinction

Early in this project, I learned something that most people miss: translation and localization are not the same thing.

Translation converts words from one language to another. It's mechanical. "Contact me" becomes "Contáctame" in Spanish. Done.

Localization adapts the entire experience for a specific culture. It considers context, expectations, and conventions. A localized site doesn't just swap words. It feels native.

Here's where this distinction matters in tech: a Brazilian developer reading about "data pipelines" expects to see "data pipelines," not "canalizações de dados." The English term is standard in the industry. Translating it would feel awkward, even condescending. Similarly, "dashboard" stays "dashboard" because that's what developers in São Paulo, Tokyo, and Paris actually call it.

Localization means knowing when NOT to translate. It means understanding that Japanese readers expect "Next.js" and "TypeScript" in English, but navigation labels in Japanese. It means recognizing that a French marketer uses "growth marketing" in conversation, not "marketing de croissance."

This insight shaped the entire system. I wasn't building a translation tool. I was building a localization engine that uses translation strategically.

The Challenge

Manual localization doesn't scale. Hiring translators for every blog post, project update, and UI change would create a bottleneck. Worse, it would slow me down enough that I'd stop publishing in multiple languages altogether. The maintenance burden would win.

I needed a system with three properties:

1. Speed. New content should be localized in minutes, not days.
2. Intelligence. The system should know what to translate and what to preserve.
3. Resilience. Incomplete translations should never break the site.

The Solution

The architecture combines next-intl for locale-aware routing with DeepL's translation API for high-quality automated translation. A custom translation pipeline handles the nuances.

The visitor experience:

When someone arrives, the system detects their browser language. If they're set to Portuguese, they see /pt-BR/blog with Portuguese content. Japanese visitors see /ja/projects with Japanese text. The URL structure is clean, readable, and search-engine friendly.

If a specific page hasn't been translated yet, visitors see the English version instead of an error. This fallback happens silently. No broken pages, no "translation coming soon" messages. Just content.

The content workflow:

I write everything once in English. A translation script processes the content through DeepL, applies localization rules, and generates locale-specific files. The entire pipeline runs in under 30 seconds.

How the translation script works

The script handles both UI strings (buttons, navigation, error messages) and long-form content (blog posts, project descriptions, the about page). It preserves frontmatter structure, maintains Markdown formatting, and leaves code blocks untouched.

The process:

1. Read English source files (MDX or JSON)
2. Extract translatable content while preserving structure
3. Send text to DeepL API with target language
4. Apply localization rules (preserve tech terms, product names)
5. Write locale-specific files (e.g., post.pt-BR.mdx)

Localization Rules in Practice

The system follows explicit rules about what to translate and what to preserve:

Always translate:

• Navigation and UI labels
• Article content and descriptions
• Form fields and error messages
• Calls to action

Always preserve in English:

• Product names: Next.js, TypeScript, DeepL, Cursor
• Company names: Nike, Meta, Rocket Internet
• Technical terms: API, dashboard, data pipeline, template
• Code examples and file paths

Language-specific adaptations:

• Portuguese (Brazil): "dashboard" not "painel," "template" not "modelo"
• Spanish: "marketers" not "vendedores," "data pipelines" not "canalizaciones de datos"
• Japanese: Product names in English, common loanwords in katakana
• French: "dashboard" not "tableaux de bord," natural CTAs like "Contactez-moi"

These rules produce translations that feel natural to tech-savvy readers in each locale. The content reads like it was written for them, not translated at them.

Results

For visitors:

• Content available in 5 languages from day one
• Automatic language detection based on browser settings
• Consistent experience across all pages and languages
• No dead ends, broken pages, or "content not available" messages

For search engines:

• Unique, indexable URLs for each language (/en/blog, /ja/blog, /pt-BR/blog)
• Proper hreflang tags for accurate language indexing
• Better visibility in local search results across multiple countries

For ongoing maintenance:

• New content localized in under 30 seconds
• Single source of truth in English
• No manual file management per language
• Safe to publish while translations are in progress

What I Learned

Building this system taught me that localization is a product decision, not just a technical one. Every choice about what to translate (and what not to) reflects an understanding of the audience.

The biggest insight: respect your users' expertise. A developer in Japan doesn't need "TypeScript" translated into Japanese. They need the content around it to feel natural in their language. Getting this balance right is the difference between a site that feels translated and one that feels native.

This portfolio now reaches a global audience without the overhead of maintaining separate codebases for each language. More importantly, it shows visitors that their language and context matter to me. In a field where everyone's portfolio looks the same, that matters.

A Note on Translations

The translations on this site are generated using DeepL's API, then reviewed and refined based on the localization guidelines described above. Automated translation is a starting point, not a finished product.

If you notice something that reads awkwardly in your language or have suggestions for improvement, I'd welcome your feedback through the contact form. Localization is an ongoing process, and native speakers catch nuances that automation misses.