Raj Gupta

Posted on Feb 23 • Edited on Feb 24

🌍 Lingo Canvas

#opensource #beginners #webdev #ai

Building Lingo Canvas: From Local Project to Global Thinking

Most of us build applications in English. Not because everyone speaks English. But because it’s convenient. Framework documentation is in English. Error messages are in English. Most open-source ecosystems default to English. So naturally, our apps do too.

But here’s the uncomfortable truth:

🌐 The internet is global.
🧩 Most applications are not.

That realization slowly shaped the foundation of my project : Lingo Canvas.

🧠 What Is Lingo Canvas?

Lingo Canvas is an AI-powered canvas application built with:

⚡ Next.js
🖌️ tldraw
🌍 Lingo.dev

It allows users to:

🎨 Generate dynamic content visually on a canvas
🔁 Switch between multiple languages instantly
🌐 Experience both UI and generated content adapt to the selected language

At first glance, it might look like a simple AI canvas tool. But underneath, it became something deeper. It became an experiment in designing software that does not assume a single language.

🎯 The Motivation Behind the Project

Originally, I wanted to build something interactive and AI-driven. Something visual.

Something dynamic.

But while designing it, I asked myself:

What if someone who doesn’t speak English opens this app?

Will they feel included?

Or will they feel like they’re visiting someone else’s space?

That question changed everything.

Because it made me realize:

Localization is not just about translating words.

It’s about shaping user experience.

🔄 The Shift in Thinking

Instead of building everything first and worrying about translations later, I decided to treat multilingual support as part of the architecture from the beginning.

That meant:

🧱 Structuring text intentionally
🔁 Planning for runtime language switching
↔️ Considering right-to-left layout behavior
🧩 Separating static UI from dynamic AI-generated content

Lingo Canvas stopped being just a canvas experiment.

It became a study in building global-ready applications.

📚 What This Series Will Cover

In the upcoming parts, I will break down:

❌ Why traditional localization approaches fail in dynamic apps
🏗️ The architectural decisions behind Lingo Canvas
🔀 How I separated deterministic UI localization from AI content regeneration
⚙️ The role of lingo.dev in creating a structured localization workflow
📈 Lessons learned while building a multilingual AI product

This is not just a project showcase.

It is a journey from:

"Let’s add translations later"

"Localization is infrastructure."

⚠️ Why Traditional React Localization Breaks at Scale

When I first thought about making Lingo Canvas multilingual, I assumed the solution was simple:

📦 Install an i18n library
📁 Create translation JSON files
🔤 Wrap text in a t() function
✅ Done

That approach works. Until it doesn’t.

🪤 The “It Works for Two Languages” Trap

For small projects, traditional localization looks fine.

You create:

// en.json
{
  "welcome": "Welcome",
  "generate": "Generate"
}
// de.json
{
  "welcome": "Willkommen",
  "generate": "Generieren"
}

Then you switch language state and everything updates.

Clean. Simple. Efficient.

But here’s what starts happening as your app grows:

📈 Translation keys multiply
🏷️ Naming becomes inconsistent
❗ Some keys are missing in certain languages
🔨 Refactoring UI breaks translations silently
😬 Adding a new language feels risky

And suddenly, localization becomes technical debt.

🔍 The Hidden Problem: Localization Is Tightly Coupled to Components

In many React apps, text is defined directly inside components.

Example:


<button>{t("generate")}</button>

At first glance, this is fine.

But over time:

🧱 Components grow
🎨 UI changes
🔁 Keys get reused incorrectly
🌀 Context-specific translations get mixed

The result?
You stop trusting your translation system.

🤖 Now Add Dynamic Content

Static UI is one problem. Dynamic content is another level. Lingo Canvas generates content inside a canvas dynamically.

So I had to think:

Should I translate generated content word-by-word?
Or regenerate it contextually in the selected language?

Traditional i18n systems are designed for deterministic UI. They are not designed for AI-generated experiences. That’s where things start breaking conceptually.

🏗️ Designing a Hybrid Localization Architecture

At this point, I knew one thing clearly:

❌ Traditional localization alone wasn’t enough.
🖌️ Lingo Canvas wasn’t just a static dashboard.
🤖 It was an interactive AI-powered canvas.

That meant I was dealing with two very different types of text:

📌 Predictable interface text (buttons, labels, menus)
✨ Unpredictable, AI-generated content inside the canvas

Treating both the same would be a mistake. So instead of forcing everything into one system, I designed a hybrid model.

🧩 Separate Static UI from Dynamic Content

This was the turning point. I divided localization into two layers:

Layer 1 : Deterministic UI

This includes:

🧭 Navigation labels
🔘 Buttons
🛠️ Toolbars
⚙️ Settings
🏷️ Static headings

This text is predictable. It doesn’t change contextually. It just needs to exist in multiple languages reliably. This layer is where structured localization belongs.

Layer 2 : Dynamic AI Content

This includes:

📝 Generated canvas text
🧠 AI-created explanations
🔄 Context-aware content blocks

This text is not predictable.

It changes based on:

👤 User input
🧾 Prompts
📌 Context
🔁 Interaction flow

Trying to pre-translate this would be impossible. Instead of translating it…
I regenerate it in the selected language. That distinction changed everything.

🔤 Translation vs Regeneration

This became the core philosophy of the project.

Translation

🔁 Word substitution
📚 Deterministic
📖 Dictionary-based
✅ Works well for static UI

Regeneration

🧠 Context-aware
🎯 Meaning-driven
🤖 AI-based
✨ Ideal for dynamic content

If I tried to translate AI-generated English text into German, I would lose nuance. Instead, I generate directly in German when the language is switched. That preserves intent, not just vocabulary.

Why This Hybrid Model Works❓

By separating responsibilities:

UI remains stable and structured
AI content remains contextual and natural
Adding a new language doesn’t break the app
Language switching feels intentional

Instead of forcing localization into one bucket, I allowed the system to reflect reality.

Some text is static. Some text is alive. And they deserve different strategies.

🧠 The Architectural Mindset Shift

Before this project, I thought:

“Localization is about translation files.”

After building this hybrid system, I realized:

Localization is about system boundaries.

It’s about deciding:

📌 What should be deterministic?
🔄 What should be contextual?
📚 What belongs in dictionaries?
🤖 What belongs in generation logic?

That architectural clarity made everything simpler.

Not easier , but cleaner.

🧱 Structuring the UI Layer with a Proper Localization Workflow

Once I separated static UI from dynamic content, the next question was obvious:

How do I make the UI localization reliable and scalable?

Because here’s the truth:

Most localization problems are not caused by translation.
They are caused by poor structure.

⚠️ The Mistake Most Projects Make

In many React apps, localization starts like this:

📁 Create a locales folder
➕ Add en.json
➕ Add de.json
🔤 Use a t() function
🚀 Ship it

That works for small projects.

But when the app grows:

🏷️ Keys become inconsistent
🗂️ Files become cluttered
🔨 Refactoring breaks translations silently
😬 Adding new languages feels risky

Localization slowly turns into hidden technical debt. I didn’t want that. So instead of thinking about translation files…

I thought about workflow.

🏗️ Designing Localization as a System

For the deterministic UI layer, I needed:

🧩 Structured translation keys
🏷️ Clear naming conventions
🔁 Predictable fallback behavior
🌍 A clean way to manage multiple locales
🛡️ Confidence when adding new languages

This is where a structured localization tool becomes important. Not because it translates automatically. But because it enforces discipline.

🔁 Making Language Switching Feel Instant (Without Breaking the Canvas)

Adding multiple languages is one thing. Making language switching feel smooth is another. In Lingo Canvas, users can change language at runtime.

⚡ No refresh.
🚫 No reload.
🧠 No disruption.

But making that work required careful thinking.

🏁 The Core Challenge

When a user switches language, three things must happen:

⚡ The UI must update immediately.
↔️ The layout must adapt (especially for RTL languages).
🖌️ The canvas content must remain stable.

If even one of these fails, the experience feels broken. So I had to design the system carefully.

🧭 Step 1: Centralized Language State

Language selection is managed at a global level. Instead of passing language props everywhere, I used a centralized state approach.

When the language changes:

🔁 The localization provider updates
🔄 UI components re-render with new translations
↔️ Layout direction adjusts if needed

This ensures consistency across the entire application. No component is “out of sync.”

↔️ Step 2: Handling RTL Layouts

Supporting languages like Arabic is not just about translating text.

It affects:

📝 Text alignment
🔀 Flex direction
📐 Spacing
🧭 UI flow

So when the language switches to an RTL language:

The dir attribute updates to rtl
Layout adjusts automatically
Components remain readable and aligned

This small detail dramatically improves user comfort.

🛡️ Step 3: Protecting the Canvas State

Here’s where things get tricky.

The canvas contains:

🔷 Shapes
📍 Positions
🖱️ User interactions
🤖 AI-generated content

When language changes, I don’t want:

Shapes to reset
User work to disappear
The canvas to reinitialize

So I separated:

UI rendering logic
Canvas state logic

Language switching triggers UI re-rendering, but the canvas state remains intact. That separation preserves user work. Which is critical.

🔄 Step 4: Regenerating Dynamic Content (When Needed)

For AI-generated content:

If the user switches language, I don’t simply translate existing English text.

Instead, I regenerate it in the selected language.

This ensures:

🎯 Context stays accurate
🗣️ Tone feels natural
💡 Meaning remains intact

The UI updates instantly. The content regenerates intentionally. That distinction makes the experience feel thoughtful rather than mechanical.

🎯 The UX Goal

Language switching should feel:

⚡ Immediate
🌿 Natural
📏 Predictable
🛡️ Non-destructive

If users hesitate before switching languages, something is wrong.

The goal is confidence.

And that confidence comes from architectural separation, not hacks.

📚 Resources

If you're building a multilingual app and want a structured way to manage UI localization, you can explore:

🌍 Lingo.dev — https://lingo.dev

It provides tooling and workflow support for managing translations in modern web applications.

🧠 What Building a Multilingual AI App Taught Me About Architecture

When I started Lingo Canvas, I thought I was building a canvas tool. By the end of it, I realized I was redesigning how I think about software architecture. Localization was never supposed to be the “main challenge.” But it quietly became the most educational part of the project.

🏗️ Lesson 1: Localization Is Not a Feature

It’s easy to treat multilingual support as something you “add later.”

But once your app grows:

📝 Text lives everywhere
🧩 Components depend on language
↔️ Layout reacts to direction
🤖 Dynamic content behaves differently

Localization touches rendering, state, UX, and even performance. That makes it infrastructure. And infrastructure decisions must be intentional.

🔍 Lesson 2: Not All Text Is Equal

Some text is stable and predictable. Some text is contextual and alive. Trying to force both into one system leads to compromise.

Separating:

🧱 Deterministic UI localization
🔄 Dynamic AI content regeneration

made the system cleaner and more scalable.

Architecture improves when responsibilities are clearly divided.

🔁 Lesson 3: Language Switching Is a UX Signal

When a user switches language, they are telling you something:

“I want this experience in my space.”

If switching language:

🐢 Feels slow
💥 Breaks layout
🔄 Resets state
⚠️ Feels incomplete

The product loses trust instantly. Language switching should feel seamless. That only happens when localization is designed, not patched.

🌍 Lesson 4: Global Thinking Changes Design Decisions

Once I started thinking globally, I began asking different questions:

🏷️ Is this key structured clearly?
➕ What happens when we add five more languages?
↔️ Does this layout break in RTL?
🔤 Should this text be translated or regenerated?

Those questions improved more than just localization. They improved the entire architecture.

📌 Final Thoughts

Lingo Canvas started as an experiment in AI + canvas interaction. It ended up being a lesson in multilingual product design. If I had built everything first and “added translations later,” the app would work. But it wouldn’t feel intentional. Designing for multiple languages from the beginning forced clarity. And clarity always improves software.

If you're building something today, ask yourself:

Are you building for your language?
Or for the internet? 🌍

Because the difference between those two mindsets changes everything.

DEV Community