The Translation Trap: What Building a Multilingual Site Taught Me About Respect

Growing up in Brazil, I learned English watching American TV shows with subtitles. I remember the awkward translations. "Cool" became "legal." Slang got flattened into textbook Portuguese. The words were correct. The feeling was wrong.

Twenty years later, I built a translation script for my portfolio. Within an hour, it converted "Next.js dashboard" into "painel do Next.js."

I cringed. No Brazilian developer says "painel." We just say dashboard.

I was doing the same thing those subtitle translators did. Converting words instead of adapting meaning.

Why this matters

Research shows 75% of internet users prefer content in their native language, even when they understand English. It's not about comprehension. It's about trust. The feeling of "this was made for someone like me."

For a portfolio, that feeling matters. When a hiring manager in Tokyo lands on my site, I want them evaluating my work, not translating in their head. When someone in Paris reads about my projects, I want them thinking about ideas, not language.

An English-only portfolio sends a message: "This is for English speakers first, everyone else second." I wanted to flip that.

What the localization community taught me

That "dashboard" mistake sent me into the localization rabbit hole. I read blog posts from i18n engineers, dug through GitHub discussions, and studied how major tech companies handle translation.

The pattern was consistent across every source.

Technical audiences share a vocabulary that crosses borders. Brazilian developers say "data pipeline," not "canalização de dados." Japanese engineers keep "TypeScript" as TypeScript. French marketers use "growth marketing," not the textbook French equivalent.

These terms were learned in English. They're discussed in English. Translating them creates confusion, not clarity.

My script was too thorough. It was translating things that should stay in English.

Translation versus localization

This distinction became the core insight of the project.

Translation converts words. Localization adapts experiences.

A translated site says "painel de controle" because the dictionary says so. A localized site says "dashboard" because that's what Brazilian developers actually say.

A translated site converts every term. A localized site knows when to stop. A developer in Japan needs navigation in Japanese but expects technical terms in English. That balance makes content feel native rather than translated.

I rewrote my approach. Navigation labels translate. Product names stay English. Technical terms stay English. Explanatory content translates naturally.

The rules I built

After fixing enough mistakes, patterns emerged. I documented them:

Keep in English: Product names like Next.js, TypeScript, Claude. Industry terms like dashboard, data pipeline, growth marketing, e-commerce. Skills sections and certification names.

Translate: Navigation items, form labels, narrative content, section headers.

Language-specific adaptations:

For Portuguese, use "dashboard" not "painel," use "template" not "modelo." Brazilian developers learned these terms in English and use them daily.

For Spanish, use "dashboard" not "cuadros de mando," use "marketers" not "vendedores," use "data pipelines" not "canalizaciones de datos."

For Japanese, keep product names in English (Next.js, not ネクストジェイエス). Katakana works for common loanwords like ダッシュボード (dashboard).

For French, use "dashboard" not "tableaux de bord," use "marketers" not "spécialistes du marketing."

These rules live in my project documentation now. Every time I translate content, I check against them.

The moment it clicked

The first time I loaded my site in Japanese, something shifted.

I don't speak Japanese. I can't read it beyond a few characters. But there it was: my portfolio, my projects, rendered in a language I don't know.

The navigation said "プロジェクト" (projects). The body text flowed in Japanese. But "Next.js" stayed "Next.js." "TypeScript" stayed "TypeScript." The balance felt right.

Content written for each audience, not translated at them. That distinction captures everything I learned.

The cost of not doing this

Most portfolios I see are English-only. That's fine. English is the lingua franca of tech.

But when someone lands on your site and has to do mental translation work, you've added friction. They might bounce faster. They might understand less. They might trust less. That cognitive load is invisible but real.

A multilingual site says: "I thought about you. I made this for you. Your context matters."

In a field where every portfolio runs on the same frameworks and shows similar projects, that consideration stands out.

The technical part, briefly

The system uses next-intl for routing and DeepL's API for initial translation. I wrote scripts that process MDX files, preserve frontmatter, and apply localization rules. The whole pipeline runs in under 30 seconds.

But automated translation is just the first pass. After DeepL generates the initial version, I ask Claude to review each translation against localization best practices. Claude catches terms that should stay in English, fixes awkward phrasing, and ensures technical vocabulary matches what developers actually use in each locale.

That combination of speed and quality matters. If localization took hours of manual work, I'd stop doing it.

For technical details, see the project page. This post is about the journey.

What I learned

I started thinking about reach. More languages, more visitors, better SEO. Those things are true, but they're not the point.

The real lesson was empathy. Building for a global audience forced me to think about people whose context I don't share.

For Portuguese, I had an advantage. I'm a native speaker. I can spot awkwardness immediately. For Japanese and French, I had to rely on what the localization community has documented. What blog posts and style guides say about how technical audiences actually communicate.

That reliance on external knowledge is humbling. You can't assume your defaults are universal. You have to meet people where they are.

A standing invitation

The translations on this site aren't perfect. Automated translation is a starting point. Native speakers catch nuances that algorithms miss.

If you read something in Portuguese, Spanish, Japanese, or French that sounds off, let me know through the contact form. I'd appreciate it.

Localization is never finished. It's an ongoing conversation between builder and audience. Building for a global audience means staying open to feedback from people who know their context better than you ever will.