Software & App Localisation

Plain JSON has no comments and no plural support — fine for English, fragile in production once translators add curly apostrophes (' vs '), narrow non-breaking spaces around French punctuation, or German guillemets (», «). A French translator who writes the correct L'application with a typographic apostrophe will pass linguistic QA and break a brittle JSON parser. We normalise apostrophes at import, validate UTF-8 BOM presence, and run a syntax pass before any locale ships.

Android stores apostrophes as \' and ampersands as &. Translators routinely paste in Microsoft Word's curly characters that look identical and ship — until the layout renders mojibake at runtime. We use a custom XLIFF round-trip for Android assets so the translator never sees raw XML, and re-escape on export.

The classic problem is plural rules. iOS uses CLDR plural categories (zero, one, two, few, many, other) through .stringsdict. A naïve translator will treat the file as one-to-one and lose plural variants — your German app then says "1 Nachrichten". We use a plural-aware editor that surfaces every CLDR category as required for the target locale and refuses export if any category is missing.

.resx accepts XML comments and embedded code references; .properties uses ISO-8859-1 by default (modern toolchains do support UTF-8, but the wrong combination still ships \uXXXX escapes that defeat translators). We force UTF-8 at import and emit native escapes only at build time.

Whenever possible, we extract source files to XLIFF 1.2 or 2.0, translate inside our editor with context attached, and re-merge. This lets translators see the source comment, the screenshot, and the constraint (character limit, ICU plural form, RTL mirroring flag) without ever touching the source file. The build pipeline merges back into the format your developers committed.

{count, plural,
  one {# friend}
  few {# friends}
  many {# friends}
  other {# friends}
}

This is fine in English, French and German. In Arabic you need zero, one, two, few, many, other. In Polish few covers 2-4 only when the last digit is 2-4 and the number isn't 12-14 — Polish has roughly 5 plural categories. Welsh has its own. We translate against the CLDR plural rule set for each locale, not against the English template.

Spanish, Italian and Russian all need to know whether the subject is masculine, feminine or neutral to inflect the verb. A naïve translation of "You are invited" defaults to masculine; a feminine user sees broken grammar in 50% of locales. ICU's select handles this:

{gender, select,
  female {Estás invitada}
  male {Estás invitado}
  other {Te han invitado}
}

If your data model doesn't track gender, the safe path is the gender-neutral other branch. We flag gendered strings in source review so your team can decide whether to capture gender, default to neutral, or ship variants — before the translation budget is committed.

App Store and Google Play reviews routinely call out broken plurals: "App is buggy, says '1 messages'". One-star reviews compound and demote ranking. Fixing plurals after launch costs more than ICU-aware translation up front.

The most common production bug: developers write margin-left: 16px instead of margin-inline-start: 16px. In a left-to-right locale they are identical. In Arabic, the first pins the margin to the left of the screen; the second flips correctly to the right. We audit your stylesheet for physical properties (left, right, padding-left, border-right) before we touch the strings.

An Arabic paragraph that mentions an English brand name, a URL, or a numeral becomes a mixed-direction string. Browsers handle this with the Unicode Bidirectional Algorithm, but the algorithm is heuristic and gets it wrong in predictable cases — most often when a sentence ends with a Latin number or punctuation. We insert U+202A/U+202C (LRE/PDF) marks or use <bdi> tags around opaque tokens like usernames and product IDs.

Arrow icons, the "back" chevron, undo and redo, slider directions, progress bars — every directional icon needs an RTL variant or a CSS transform. Lucide and Heroicons have RTL-aware variants; Material's icon set requires a mirror class. We catalogue every directional icon in your design system and flag any that aren't mirrored in the audit.

Western font stacks routinely lack Arabic glyphs — Helvetica Neue, Inter and Roboto all need an Arabic fallback. The system default (Geeza Pro on iOS, Noto Naskh Arabic on Android) renders, but the line-height is wrong and the kerning is poor. We test rendering on the actual devices your users have — not just Chrome on macOS — and flag font-stack fixes as part of pseudo-locale review.

Arabic is our largest single language pair. Our sister brand arabictranslation.co.uk has shipped Arabic localisation since 2012. The RTL surcharges most UK agencies add (20-30%) reflect that this is unusual work for them; it is the work we do most. We do not charge an RTL surcharge.

Suits most SaaS teams. A GitHub webhook fires on every push to main. Our service inspects the diff for new or changed strings, drafts the locales, sends them to a linguist for review, and opens a return PR. Branch protection ensures the PR can't merge before review. Typical end-to-end time: 18-24 hours for 35 languages on a 200-string commit.

If your team prefers locale changes to flow through your build system (CircleCI, GitHub Actions, GitLab Runners), we expose a CLI: lingosecure pull pulls the latest translations into your repo as a build step, lingosecure push uploads any source-string changes for translation. Used by teams who run release trains and don't want translation PRs in their flow.

If you already have a TMS we are happy to act as the linguist layer inside it — your developers continue to push strings to the TMS, our linguists translate inside the TMS, and the TMS sync runs as it always did. Zero workflow change for your engineers. The benefit: one supplier instead of stitching together a TMS subscription, a roster of freelancers, and a vendor for the regulated stuff.

All three patterns share one principle: your translation memory is yours. Every translated segment is logged into your TM, which we host inside LingoSecure or export to your TMS on demand. If you switch vendors next year, the TM goes with you. There is no lock-in.

We version-pin translation memory to product release. Your v4.2 will never accidentally ship with v4.1's translated strings. If your team needs to revert a release, the TM reverts with it. This matters for regulated products where a translated disclosure must match the version of English it was approved against.

• Truncation — buttons that fit "OK" but not "Aceptar"
• Hard-coded strings — anything not wrapped in t()
• Concatenation bugs — "Hello " + username will break in languages with different word order
• Fixed-width assumptions — date pickers, dropdowns, navigation tabs
• Font fallbacks — text that turns into rectangles because the font doesn't cover Latin Extended-A
• RTL flip bugs — every directional icon and layout flips in pseudo-RTL

We deliver the pseudo-locale build as a Storybook deployment or a feature branch your QA team can test against. The defect log goes straight into your Linear, Jira, or GitHub Issues. We fix the locale-side issues; your team fixes the product-side ones, before paying for a single word of human translation.

For mature products we run an additional pass: every screen is captured in English, pseudo-EN, German, Arabic, and Chinese, and the diffs are compared. Layout regressions show up immediately. The same workflow runs against every PR if you want it as a GitHub Action.

Every string passes under a qualified linguist before it leaves the portal. Our LingoSecure workspace accelerates the first draft so the linguist's time goes to nuance, terminology and tone — but no string ever ships without human signoff. If you only want unreviewed machine output for cost reasons, that is a different service we do not provide; we can point you to a pure-MT provider if it fits your use case.

A 50-string emergency fix in 4 hours is realistic across most major locales. A 5,000-string product launch in 24 hours is not realistic and we will not commit to it. We schedule backwards from your release date with built-in QA buffer; if your timeline is shorter, we will tell you what is actually achievable.

Most UK agencies route Arabic to a Cairo or Beirut studio. We translate in-house with named linguists. The same person who translated your v1 strings is the person who translates v4.7. Terminology consistency is a function of continuity; continuity requires not subcontracting.