EMCD is a global crypto platform combining a mining pool, wallet, P2P exchange, and other tools for managing digital assets. As the company expanded into new markets, localization went from “nice to have” to a core part of the product experience.
Victoria Franskevich is the Localization Team Lead at EMCD, with 7 years of experience in localization and project management across industries. At EMCD, Victoria built the localization process from scratch. The infrastructure she created now supports the product’s global expansion.
We sat down with Victoria to talk about what it actually takes to build an expandable localization capability at a fast-moving fintech company and why most localization problems have nothing to do with translation.
Tell us about yourself and EMCD. What’s your mission?
I lead the localization team at EMCD. My job is to ensure users have the same clarity, confidence, and understanding of the product, regardless of language or market.
I’ve worked on pretty much every kind of localization project you can imagine, from small AR/VR apps and websites to video games with millions of players worldwide. Different industries, different content types, different complexities. That range gives you a certain perspective: you stop thinking about localization as just translation and start seeing it as an engineering discipline. So when EMCD came along with a blank slate and no localization infrastructure yet, it was an easy yes.
Localization is not a finishing touch; it’s part of the product experience. And in fintech, especially, trust is everything. If something reads awkwardly or a key term is translated inconsistently, users notice. In a category where people are trusting you with their money, that matters.
When I joined, there was no localization infrastructure at all, just five languages held together by spreadsheets and good intentions. We had 25 locales in mind, so we needed a system that could actually get us there without having to rebuild everything every time we added a new one.
What did localization look like before Crowdin?
If I’m being honest, it looked like organized chaos, with the emphasis on chaos.
We had an old TMS with a very limited feature set, and only several product teams used it for UI strings. Everything else – emails, push notifications, blog posts, landing pages, and yes, even chunks of interface text – was handled in Google Sheets, Google Docs, and other content systems. No shared translation memory. No glossary. No unified process.
We had a growing team producing content across the company. The output was predictably inconsistent, updates were hard to track, and coordination took more time than the actual translation work.
"The old workflow worked until it didn’t. And then it worked mostly by people working late.
What were the biggest pain points?
They fell into two categories: operational and technical.
On the operational side, the company was growing fast, and localization simply hadn’t been designed yet. Ownership at each stage was implicit rather than defined, handoffs were informal, and there were no structured quality gates. Totally normal for a fast-growing company, but at some point, “we’ll figure it out as we go” stops working, and you need an actual system.
On the technical side, it was messier. In the old tool, we couldn’t even upload basic file formats like .xlsx or .docx. But the deeper issue was the localization architecture, or the lack of it. Content was scattered everywhere: an old TMS that only some teams actually used, Strapi, Customer.io, Google Docs, and Google Sheets. No single source of truth. Change something in the source, and good luck tracking what needs to be updated downstream.
We had a lot of hardcoded text showing up in English during LQA because it had never been properly externalized. And we had strings split across multiple keys in ways that made correct translation structurally impossible. Some keys contained a single preposition. A single particle. Things like:
key_1: {completed}key_2: "out of"key_3: {total}key_4: "transactions completed"In English, you can concatenate those, and it reads fine. In Turkish, Chinese, or Arabic, you can’t. Things like word order, grammatical agreement, and inflection depend on the full sentence. When developers split strings for technical convenience without thinking about translation, they’re not just creating an inconvenience; they’re creating errors that no translator can fix, because the fix has to happen at the code level, before the string ever reaches translation.
That was the real challenge. Not translation. Localization architecture.
Why Crowdin? What were your non-negotiables?
We needed a platform built for scale that could handle automation, integrate with engineering workflows, and support governance as content volume grew.
The non-negotiables were automation and structure. I needed a system that could grow with the company without having to grow the team at the same pace. Crowdin was the clearest fit.
Strong workflow structure and role-based responsibility, API access, integration flexibility, reliability at high volume, and built-in AI pipelines. Crowdin had all of it. And one thing that doesn’t always make it onto the checklist but turned out to matter a lot: genuinely fast support via online chat.
"We weren’t looking for a translation tool. We were looking for a localization system that could support company growth without breaking.
What does the current workflow look like?
The current setup covers content from creation through production, with localization built into the pipeline rather than bolted on at the end.
On the content side, we’re integrated with Strapi for SEO and the blog, Customer.io for user-facing communications like emails and push notifications, and Intercom for support articles. On the product side, we have a localization panel built in-house that lets us update text in production without waiting for a release cycle. And then there’s the n8n-based internal bot that automates AI pre-translation and pushes new UI keys to Crowdin – I’ll get to that one, I promise; it deserves its own spotlight.
Everything is centralized, repeatable, and predictable, and localization is no longer the bottleneck.
Crowdin built a custom JSON export feature for you. What was that about?
Our i18n logic requires plural forms to be exported as an object. Crowdin did offer several pluralization options – JSON Array, ICU, and Concat – but none of them matched what we needed out of the box.
The Crowdin team worked with us and implemented JSON plural export in object format, so we could keep our existing i18n logic intact without expensive refactoring. Here’s what that looks like in practice using the same key in English, Spanish, and Ukrainian:
EN
"p2p|user_profile|was_online_minutes_ago": { "one": "Online {minutes} minute ago", "other": "Online {minutes} minutes ago"}ESP
"p2p|user_profile|was_online_minutes_ago": { "one": "En línea hace {minutes} minuto", "other": "En línea hace {minutes} minutos"}UK
"p2p|user_profile|was_online_minutes_ago": { "one": "Онлайн {minutes} хвилину тому", "few": "Онлайн {minutes} хвилини тому", "many": "Онлайн {minutes} хвилин тому", "other": "Онлайн {minutes} хвилини тому"}Notice how Ukrainian requires four plural forms where English and Spanish need only two; that’s exactly why the export format has to be flexible enough to handle the full structure for each language.
This protected product stability and avoided a significant engineering effort. It also happened to be a feature that didn’t exist in Crowdin before we needed it; the team built it for our use case.
That kind of responsiveness is rare. It’s the difference between a vendor and a partner.
(For anyone curious about the implementation: the setting is the JSON String Exporter with plural serialization set to JSON Object.)
"Crowdin helped us keep our i18n logic intact and still scale localization. That’s not something you find easily.
Do you use AI in your workflow?
Yes, and honestly, with everything happening in the AI space right now, it’d be hard not to. Once we had the structure in place, the natural next question was, “Where are we still doing things by hand that we shouldn’t be?”
We use Crowdin’s built-in AI features – pre-translation workflows and Crowdin Copilot, which handle a lot of the routine work right inside the translation pipeline. But beyond that, we’ve been building our own agents on top.
One of them is an n8n-based bot that covers the pre-translation step for new UI keys. First, it pulls visual context from design mockups in Figma to see if the string belongs to a button, a notification, or an error message, then translates the key accordingly. After that, it cross-references the output against our glossary, style guides, and TM before anything gets uploaded to Crowdin. Once it’s uploaded, the bot creates a task notifying the loc team that new strings were added and are ready to be checked.
The localization team doesn’t touch any part of the pre-translation step; we only review the bot’s output. The product team gets back verified translations in all target languages without needing to know anything about Crowdin or the localization process.
"The goal was never AI for its own sake. It was, “What can we stop doing by hand?”
What advice would you give to a company that wants to localize at scale?
Start with structure before you start with tools.
Document the rules early. Define ownership for every stage. Build workflows that match how your company actually ships content. Then automate everything that can be automated.
And treat i18n architecture as a localization responsibility, not just an engineering topic. Most localization problems are born long before a translator ever sees a string. If you wait until translation to fix structural problems, you’ve already lost; you’re just cleaning up something that should never have been broken. Crowdin can help you build that foundation right: the workflow tools, the AI features, and the integrations are all designed with this in mind. Getting the structure right from the start is a lot easier when your tooling supports it.
Victoria’s background
Victoria Franskevich is the Localization Team Lead at EMCD. She built the localization process from zero: designing the architecture, establishing company-wide engineering standards, and leading implementation across product, design, engineering, and content. The infrastructure she created now supports EMCD’s global expansion and enables rapid, multi-language delivery.
Localize your product with Crowdin
