Most localization teams are still juggling Excel exports, tracking content across various repositories, only to be told they’re holding up the release.
But what if localization could be seamless?
What if it integrated cleanly into your CI/CD pipeline, aligned with design and dev teams, and delivered quality without friction?
In a new episode of The Agile Localization Podcast, host Stefan Huyghe sits down with Daniel Finck, Localization Manager, Consultant, and Solutions Architect at Loquatics Consulting, to explore how engineering-led localization setups can scale without turning localization into the next IT roadblock.
Listen to the new episode on:
The Real Problem with Internal Localization Workflows
Daniel doesn’t mince words: if you’re still relying on spreadsheet exports, it’s a sign your localization process is broken.
Manual handovers, unclear ownership, and siloed tooling are just the surface symptoms. The deeper issue is that most teams still treat localization as a reactive service, not a built-in system.
Product managers, IT teams, and marketing often operate within their own tooling ecosystems. Figma, GitHub, and CMS platforms without a shared pipeline. Localization, caught in the middle, becomes the bottleneck by default.
That’s where Daniel’s approach comes in.
The In-House Localization Playbook
Daniel outlines a playbook built on four essential principles:
- Transparency
- Integration
- Ownership
- Measurement
Let’s break each one down.
1. Transparency Is the Foundation
Localization doesn’t need to be perfect, it needs to be visible. Daniel advocates for a traffic-light model that gives stakeholders clarity at a glance:
Green? The system is working.
Yellow? There’s a delay.
Red? Something’s blocked.
This transparency builds trust and reduces unnecessary back-and-forth. It also helps product owners make informed decisions: delay the release for better quality, or ship faster with trade-offs.
2. Integration Across Teams and Tools
Too often, content moves from design (Figma) to dev (GitHub) with localization inserted awkwardly in between.
Daniel suggests a better way:
- Use your TMS (like Crowdin) as a shared hub
- Integrate directly with tools like Figma and GitHub
- Eliminate the Excel export/import loop entirely
The goal is for Localization to become part of the build, not an afterthought. Stakeholders don’t need to “handoff” content, they just use the system.
3. Take Ownership, Without Becoming IT
Localization teams should operate like an internal service provider: helpful, efficient, and visible, but not rigid.
Daniel advises setting up lightweight, self-service request forms (via Jira, Confluence, ClickUp, etc.) that automatically route localization tasks. This reduces friction and ensures all localization flows through one system.
It also prevents the “quick fix” mindset: marketing grabbing a native speaker for a banner, IT hard coding strings, or PMs bypassing the process, leading to broken UX and inconsistency across the board.
4. Measure What Matters
In engineering-led companies, metrics matter. Daniel recommends tracking localization KPIs that mirror business goals, turnaround time, translation reuse, bug rate, and even sales impact.
Localization doesn’t need to be “just a cost center”. With reporting dashboards and stakeholder-facing status updates, you can tie localization decisions directly to product performance.
Why This Matters for Agile Workflows
Traditional translation is linear. Agile is not.
Daniel’s experience shows that agile-friendly localization requires segmentation, automation, and validation, not a complete reinvention, but smart adaptation.
Using tools like Crowdin, you can:
- Segment and pre-translate strings
- Sync statuses back to your PM tool
- Run validation workflows before strings go live
- Let translators work in real-time with designers and developers
This makes localization compatible with sprints, not a blocker to them.
Security, Authority, and Getting Closer to the Source
One of Daniel’s strongest points: get as close to the source as possible. Every step between dev and localization is a risk, missed updates, old strings, and rework.
But that raises questions about access and control. Daniel walks through ways to establish localization authority without requiring language mastery, including:
- Centralizing reviews and feedback
- Flagging issues automatically
- Using smart QA tooling to detect inconsistencies
Why Crowdin Makes This Possible
Daniel’s toolkit includes platforms like Jira, ClickUp, and Confluence, but his integration backbone is Crowdin.
What makes it work?
- Figma integration – Designers can preview real translations in context
- GitHub sync – Devs don’t need to manually upload or check-in files
- Open API – Teams can create custom automations and status updates
- Webhook support – Push updates to PM tools in real-time
Localization is embedded directly into product workflows, not layered on top.
Final Thoughts From Daniel
The best localization systems are the ones people actually want to use. — Daniel says.
No more asking devs to upload files. No more chasing PMs for updates. No more hoping someone remembered to send over the latest copy.
Instead:
- A shared system
- Transparent reporting
- Integrated tools
- Clear accountability
That’s how localization earns a seat at the table and stays there.
Daniel’s Background
Daniel Finck is a Localization Manager, Consultant, and Solutions Architect at Loquatics Consulting, with deep expertise in game and entertainment localization. He specializes in designing lean, cross-functional workflows that connect dev, design, and localization teams, especially in Free-to-Play environments. Known for his hands-on approach and sharp reporting skills, Daniel brings together technical precision, language expertise, and business insight to help teams deliver at scale on time, on budget, and without the Excel chaos.
