GitLab i18n Guidelines for Developers and Designers

A lot of localization specialists think they’re “not technical enough.” I hear this all the time: “I don’t know how to code.” But localization professionals are already solving complex systems every day. You manage ambiguity. You understand structure, context, edge cases, scalability, quality, workflows, human behavior, and product experience across languages and markets. Those are technical skills. What many people is missing is permission to ask “probably stupid” questions until things click. And this is exactly why I started my new blog series on vibe coding for localization specialists. Over 5 posts, we’ll build 4 small practical artifacts together. Not and over-engineered SaaS platform to scale and start a startup. Just small local tools that solve real problems because most people in localization just need small artifacts that: save time, reduce repetitive work and help them think better.

Building a feature in 2 days but waiting 2 weeks for translations? 🌍 That bottleneck sparked a rethink at GoDaddy — and led engineers to build “Localizer,” an internal tool designed to simplify and speed up localization workflows. The story is a great reminder that some of the biggest engineering wins come from solving the friction around the product, not just the product itself. Read more 👉 https://lnkd.in/exQ9CtJa

A few months ago, I kept running into the same problem in almost every project I worked on: Managing translations was painful. Developers updated translation keys in JSON files. Translators worked in spreadsheets. And sooner or later, everything became out of sync. Some keys existed in the app but not in translation files. Some translations were outdated. I also noticed another issue. Many existing localization platforms like weblate or WebTranslateIt and similar tools are powerful, but they can become expensive for small teams or growing startups. And in many cases, non-developer teams still struggle because updating translations often requires understanding project structure, JSON files, or developer workflows. So I decided to build something simpler. I created HATA — a lightweight Translation Management System (TMS) built with Golang that syncs translation keys between codebases and Google Sheets using a simple CLI workflow. Interestingly, “HATA” means “word” in Indonesia (Kata). I chose the name because translations are fundamentally about words, communication, and helping applications speak multiple languages more naturally. Repository: https://lnkd.in/g7UfNbRA The goal was not to build another enterprise-heavy localization platform. I wanted something: - lightweight - developer-friendly - easy for translators - affordable for small-medium teams - easy to integrate into React, Next.js, React Native, Vue, or Golang projects What HATA does: - Push translation keys from base.json → Google Sheets - Pull translations back into locale JSON files - Detect missing or unused translation keys - Support nested and flat JSON - Work with Service Accounts or OAuth - Keep translators away from codebases One thing I learned while building this: A lot of internal engineering problems are repetitive, but many teams still solve them manually every day. Instead of accepting repetitive work, I’ve been trying to build small tools that improve developer workflows and collaboration between technical and non-technical teams. This project also helped me deepen my understanding of: Golang CLI architecture Google Sheets API OAuth & Service Accounts config-driven systems developer experience (DX) localization workflows CI/CD integration Still improving it step by step, but I’m happy to finally open-source it 🚀 How does your team currently manage i18n/localization workflows? #golang #opensource #github #softwareengineer #developer #i18n #translation #cli #webdevelopment #reactjs #nextjs #devtools

#MondayCoffee 💡 The DRY Principle That Separates LSPs from GCS Providers. Software developers live by a simple creed: Don't Repeat Yourself (DRY). Every piece of knowledge should have a single, unambiguous, authoritative representation within a system. Duplication creates bugs, inconsistency, and technical debt. But here's the nuance that the Nimdzi Consumer Software Report highlights: while DRY is powerful, reusing the same string across multiple contexts can backfire spectacularly. The Classic Example: The Word "Open." In English, "open" works as both a verb ("Open the file") and an adjective ("The store is open"). In many languages, these are completely different words (different genders, different grammatical cases, different everything). If a developer reuses one "open" string for both contexts, the translator is forced to pick one version. It will be wrong in one context. Every single time. Now multiply this across dozens of languages, hundreds of strings, and years of product updates. The result isn't efficiency. It's a localization nightmare. 👀 The DRY Paradox for Localization. DRY applied inside the codebase: essential. DRY applied across unrelated UI contexts: dangerous. The smart approach: ✅ Create separate strings for separate contexts, even if the English looks identical. ✅ Give each string a unique key so updates don't cause regressions elsewhere. ✅ Provide translators with context (screenshots, character limits, part of speech) so they can make the right linguistic choice. This is the difference between intelligent reuse and lazy reuse. A GCS provider educates clients on where reuse serves them and where it harms them. It flags the "open" problem before it reaches translation. It architects content governance so that shared terminology lives in one place, while context-specific strings remain independent. Our question for you: Where in your content ecosystem are you dealing with the consequences of "lazy reuse" and how would you fix it at the source? #DRY #Localization #Nimdzi #GCS #ContentArchitecture #GlobalContentSolutions #StringLocalization

A fellow founder asked me last week why we made Tolgee open-source. I gave him the short version on the call. Here's a bit longer one. We believe developers should be able to treat localization like infrastructure. Read the code. Fork it. Run it where they want. Shape it to their workflow, not the other way around. Your data stays where you want it. Because teams building interesting products shouldn’t have to trust a black box to ship in their users’ language. So we open-sourced the core under Apache 2.0. What open-source changes in practice: ▪️ Built in public. You can see what we ship, why we ship it, and what’s broken. That creates a different relationship than “trust us, it’s on the roadmap.” ▪️ Community-shaped. Some of the best features in Tolgee came from people running self-hosted instances, hitting real edge cases, and telling us about them ▪️ No vendor lock-in. Your translations and your setup are yours ▪️ Developer-first by default. We think about localization the way developers do: as part of the stack, not a separate portal you log into We offer a self-hosting option because some teams genuinely need it. Regulated industries, air-gapped environments, compliance requirements. But for most teams? Self-hosting is a tax. You’re spending engineering hours running a translation tool instead of shipping product. So yes: We open-sourced Tolgee for the long-term reasons: trust, transparency and community. We offer self-hosting because some teams truly need it. We run a cloud product because most teams shouldn’t be running this themselves. Being open-source isn't about pushing self-hosting. It's about giving you the choice and being honest about which choice usually fits.

Vibe Coding in Localization... What Stands Out For You? Here are some of the most powerful takeaways I came away with from last week’s GenAI in Localization: The Builders Playbook for the Future of Localization Vibecoding workshop with Julia Díez López , Jourik Ciesielski and Lev Berezhnoy. 🔥🔥🔥⬇️ 1. You can build fast now. But can you ship it?  Julia walked through real issues she found in her own app, including security gaps that could have been a problem in production. Getting something to run is one thing. Getting it to hold up is another. How far would you take something before trusting it in a live environment? 2. AI doesn’t fix bad structure. It amplifies it.   One sentence formal, the next informal. Terminology drifting. Without guardrails, things fall apart quickly. Her focus on foundational assets made that very clear. 3. A glossary is not enough anymore. A list of words doesn’t explain relationships, context, or market differences. It’s a starting point, not a system. 4. The real gain isn’t saving money. It’s buying back time.  Instead of rushing through cycles, the idea is to reinvest that time into proper QA, real user testing, and catching issues that machines won’t see. Where would you spend that time if you had it back? 5. What if your system learned from every correction you make?  Jourik showed how post-edits can become signals. Patterns get picked up. Resources get updated automatically. Over time, the system starts adapting. If your system learned from you, what would it fix first? 6. You don’t need to code to build anymore, or do you? Three prompts. A working solution. Watching that unfold changes how you think about getting started. Have you tried building something yourself yet? 7. The system can fix its own mistakes. Run, break, correct, try again. You’re watching it work through the problem in real time. It’s a different way of interacting with software. 8. Production still needs human judgment. You can build without coding. You can’t ship without understanding. No shortcuts here. If it goes live, it gets reviewed properly. That part stays.   9. The “wow” moment doesn’t last. The first time feels magical. After that, it’s work again, according to Lev. At first it feels effortless. Then you realize the real work is guiding, checking, refining. 10. The role is changing, even if the responsibility isn’t. Less time writing. More time deciding what matters and when something is good enough. Where do you feel your role evolving right now? 11. You still own the outcome. AI helps. You’re still responsible. The tools help, but they don’t carry the responsibility. That part doesn’t move. 12. Can 1 person now really build what used to take a team? What do you think? There’s a lot to unpack in all of this. Different levels of experience, different ways of approaching it. But one thing feels clear. More people are starting to build. Where are you in this?

🇵🇱🇺🇸 I spent 10 months building software for Polish people… in English only. And today I finally admitted how stupid that was. hck_GPT already speaks Polish stable. It understands “dlaczego RAM jest wysoko?”, “co się dzieje z moim PC?” and dozens more without any Google Translate nonsense, 854 lines of real bilingual vocabulary. But the rest of the app? Everything still English only. Built by a Polish developer. Monday Grind Blueprint 8 For Polish users who are starting to actually care about PC Workman. That felt wrong for way too long. This week I’m fixing: 1️⃣ Full Polish language support Real localization. Not machine translation. Written by someone who actually thinks in Polish. Dashboard, navigation, key pages, all coming. 2️⃣ Settings page final polish Language toggle (EN/PL), TURBO thresholds, notifications, appearance, data & privacy controls. Making the app feel complete. The project is dangerously close to leaving Alpha. Now it’s time to make it feel like home for the people who will actually use it every day. Friday will tell the truth. #BuildInPublic #Python #OpenSource #AI

Learn how to use the Locale class in Java to manage language, region, and cultural settings for seamless internationalization and localization

 🔍 Translating i18next JSON files requires more than language quality. In React and Next.js projects, interpolation tokens, plural suffixes, nested keys, and inline markup all need to remain structurally intact. If they do not, the result can be broken builds, missing strings, or silent runtime issues. In this article, we explain what makes i18next JSON translation different and how to automate it more safely at scale. 👇 https://lnkd.in/d-HdhAJ8 #React #Nextjs #i18next #Localization #SimplePoTranslate

Three languages can still run on improvisation. Twelve usually cannot. A feature ships. The UI gets localized. The help article follows three weeks later. The error message doesn't make it into the next sprint. At three languages, teams can patch things manually – a spreadsheet for strings, a message thread for terminology. At twelve, those gaps are built into the product. What usually goes undesigned: which content tiers follow a release, and which can wait. If that decision is not explicit, it has already been made, by default and too late. Who owns that call in your team today? #SaaSLocalization #ProductLocalization #InternationalGrowth #LocalizationStrategy