The short version
Your localized UI ships on schedule, with strings that fit, placeholders that don’t break, and terminology that stays consistent across screens, help text, and release notes.
We’ll take your resource files in, translate and edit in a CAT tool, then review in the product and run an LQA test pass to catch what breaks. You’ll ship a localized build that reads naturally and still compiles. If you’d like to move ahead, we’ll line up languages, timeline, and a clean handoff.
We run localization like a release lane with clear inputs and checks. We start by confirming file formats and string rules, lock terminology and UI voice early, translate with an editor pass, then validate in your staging build. We log issues in a bug tracker, re-test fixes, and keep engineering unblocked with round-trippable files.
About us
We do software localization for product teams who need more than translated text. We started in the part of the work where releases go sideways: resource files that don’t round-trip, UI copy that looks fine in a spreadsheet, and last-minute fixes that miss the build. Our team covers translation, engineering, and QA so you are not stitching vendors together during a release.
Teams pick us when they need localization to behave like engineering work. We check formats up front, we translate with the same constraints your UI is built on, and we validate in a running product instead of stopping at a file export. We keep decisions visible with a termbase, a style guide, and an issue log you can hand to engineering without rewriting it.
Who you will work with
You’ll have named owners for each part of the lane, so questions land fast and decisions stick through the release.
Team
Elena Marquez, Localization program manager. Elena runs the schedule and handoffs, keeps scope tied to builds, and makes sure each language is ready when your release branch is.
Daniel Rios, Software localization engineer. Daniel handles file formats, pseudoloc checks, and round-tripping so engineers get back what they expect, with placeholders and escapes intact.
Priya Shah, QA test lead. Priya leads LQA in the product, logs issues with reproduction steps, and re-tests fixes so the bug list burns down before ship day.
Morgan Kelley, Lead translator. Morgan leads translation and editing, keeps UI tone consistent, and makes sure terminology stays the same across screens and key flows.
Selected work
These are the kinds of software localization engagements we run: file-safe translation, in-product review, and QA that protects the release.
Portfolio
First-market app launch. Localized UI resource files and onboarding flow, then reviewed in a staging build to catch truncation and broken variables before release cut. Final handoff included a cleaned translation memory and glossary for the next cycle.
Multi-language settings refresh. Translated settings and account screens during a UI redesign, keeping terminology stable across new and legacy screens. LQA focused on plural rules, date formats, and validation messages that trigger support tickets.
Release-cycle localization lane. Ran localization alongside a monthly release cadence: intake, term updates, translation, in-context checks, and LQA every cycle. Engineering received round-tripped files and a single issue list per build.
“They caught the UI issues before launch, and engineering stayed unblocked.”
Product manager, a SaaS team shipping their first new language
Localized resource files
Translated UI strings returned in the same format you send, with placeholders, escapes, and line breaks preserved so the build round-trips without manual cleanup.
TERMBASE AND UI STYLE GUIDE
A product-specific glossary and short UI style guide, agreed early, so translators and reviewers make the same choices across screens and future releases.
TRANSLATION MEMORY AND GLOSSARY PACKAGE
A cleaned TM and glossary export from the CAT tool, ready for the next release cycle, including deduped terms and consistent key translations.
In-context review notes
Findings from reviewing translations inside your staging build, including screenshots and exact string identifiers, focused on fit, tone, and meaning in real UI.
LQA BUG LOG AND RETEST RESULTS
A tracked list of linguistic and functional issues found in the localized build, with steps to reproduce and a confirmed retest status for each fix.
RELEASE HANDBACK BUNDLE
A final package with delivered files, change notes, and open items if any remain, so you can hand off cleanly to engineering and support.
What it costs
Choose based on how much in-product time you want us to cover before handback. Final pricing follows the first-day format check and string-count.
Priced items
Getting started
If you want this localization lane running for the next release, we can lock dates and start intake as soon as the proposal is signed.
1. Sign this proposal to book the slot in our schedule. 2. Pay the 40% booking invoice so we can start intake and term lock-in. 3. Send your string kit and a staging build link, and we’ll begin day-one checks.
WHAT FILE FORMATS DO YOU TAKE, AND CAN YOU ROUND-TRIP WITHOUT DEV CLEANUP?
We can take the common UI resource formats and we verify round-trip on day one. Daniel checks placeholders, escapes, and encoding rules, then we return files in the same structure so you can drop them into the build.
HOW DO YOU HANDLE VARIABLES, PLURALS, AND GENDER FORMS SO WE DON’T BREAK STRINGS?
We lock string rules during intake and we translate against those rules. We keep variables exactly as required, we use the correct plural categories for each language, and we flag any source strings that are ambiguous before translation starts.
Signature
Fee summary
Can you review in the product, not just in a spreadsheet?
Yes. We plan an in-context review window on your staging build, then we check for truncation, collisions, layout issues, and meaning changes that only show up in real screens and flows.
WHAT DO YOU NEED FROM US TO HIT OUR RELEASE DATE?
We’ll ask for the source string freeze point, the file export method, a staging build link for in-context review, and one person who can answer product intent questions quickly. With those, we can schedule translation and QA around your release branch.
Payment
We take 40% to book the work when you sign, and 60% when we hand back the finished work. Invoices are due within 14 days of the invoice date.
Changes. If the source strings change after the freeze point, we will log the delta and confirm the impact on schedule and price before we translate or re-test the changed strings.
What we need. To hold the schedule, we need a source string freeze point, the export method for your resource files, a staging build link for in-context review, and one fast point of contact for intent questions.
File handling. We work in your UI resource formats and return files in the same structure. If the files fail round-trip on day one because of format or encoding issues, we will pause and agree the fix before translation starts.
Build access
In-context review and software localisation QA depend on access to a staging build that matches the release branch. If access is delayed, we will shift the review window and confirm any date impact in writing.
Bug log and retest. We log localisation QA issues in a bug list you can hand to engineering. Retest covers fixes to items from that list. New features or new strings outside that list are treated as changes.
Ownership. Once the final invoice is paid, you own the localized resource files, termbase and UI style guide, translation memory and glossary package, and the release handback bundle we deliver for the project.
