The Toggle Is the Easy Bit: Shipping a Welsh-First App Without Doubling Your QA

Every team that ships into Wales has the same first idea: put a toggle in settings, send the strings to a translator, done. The toggle is genuinely easy. It's the six weeks after the toggle that hurt — truncated buttons, English push notifications, error messages that never left the server, and a release notes field nobody translated because it lives in a completely different tool.

If your organisation falls within the scope of the Welsh Language Standards, treating Cymraeg as a post-launch nice-to-have is a compliance risk as well as a UX one. But compliance is the least interesting reason to get this right. The better reason is that bilingual users in Wales switch constantly, and every time they hit an English-only dead end, the app feels unfinished.

Where bilingual apps actually break

Almost never on the settings screen. The damage happens in the small, unglamorous places:

• Error messages on failed payments, expired sessions and validation failures.
• Push notifications fired from a marketing platform that has never heard of your localisation files.
• Store listings, screenshots and release notes, which live outside the app entirely.
• Date formats, plural rules and currency strings rendered by the device rather than your copy.
• Accessibility labels, which are often written last, by whoever is free, in one language.
• Sorting and search. Welsh treats ll, dd, ff, ch, ng, ph, th and rh as single letters for collation purposes, and diacritics like ŵ and ŷ need normalising if people are typing quickly on a phone keyboard.

There's also the length problem. Welsh is frequently longer than English — Gosodiadau where you had Settings, Hysbysiadau where you had Alerts. A tab bar designed around English will wrap, clip or shrink text on a device you didn't test.

Design the switch, not just the setting

Start with the language names themselves: English and Cymraeg. Labelling Welsh as Welsh is a small tell that the feature was bolted on.

Then decide the hierarchy. Most phones now let users set a language per app at the OS level, so your in-app preference should mirror that rather than fight it. Read the device language on first launch, respect an explicit choice afterwards, and never silently reset it on an update — that's the kind of bug that generates a one-star review in two languages.

Skip the full-screen language modal on first open. It adds friction for the majority and irritates the minority who already set their phone up correctly.

One trap worth naming: the choice has to survive logout, account switching and a reinstall within reason. If a user toggles to Cymraeg and your session refresh quietly reverts them, you've built a toggle that lies.

Content governance beats heroic translation

Two things prevent the fire drill. The first is a single canonical string set with two locales, a translation memory so you're not paying twice for the same sentence, and a glossary that settles the arguments before they start. Is account cyfrif everywhere, or does it drift? Does your brand name get a Welsh form, or stay as it is?

The second is a named owner. Ideally a first-language reviewer with authority to sign off, not a developer with a GCSE and good intentions. Budget their time into the sprint before submission, not the afternoon of.

Machine translation is fine as a first draft for low-stakes UI copy. It is not fine for legal text, safety information, payment instructions or anything a regulator might read.

The gaps nobody QAs

This is where most bilingual releases leak. Server-side strings are the classic offender: your app is beautifully translated, then the payment gateway returns Card declined in English and drops it straight into a Welsh screen. Fix it with error codes mapped client-side, or localise the server strings properly.

Push notifications deserve their own line in the release checklist. The template usually lives in a campaign tool, owned by a different team, with its own approval flow. If nobody has added a Welsh version to the template, the notification arrives in one language regardless of what the app is set to.

Then there's the store. Two listings, two sets of screenshots, release notes in both. It's unglamorous work and it's the first thing a Welsh-speaking user sees.

Finally, accessibility labels. Welsh screen-reader voices exist but vary by platform, so test pronunciation rather than assuming it. A label that reads place names with English phonetics is worse than no label at all.

A compact QA routine that actually fits a sprint

You don't need to double your test matrix. You need to move the checks earlier and automate the boring ones.

Pseudo-localise first. Before the translations land, build a version where every string is stretched by roughly 30 per cent and peppered with diacritics. Run it on your smallest supported screen width. Every clipped button and wrapped tab reveals itself in an hour, without waiting for a translator.

Keep a twenty-minute bilingual smoke suite. Toggle on cold start. Force-quit and relaunch to confirm persistence. Send one push in each language. Trigger one error path — a declined card is perfect. Check a date, a currency value and a sorted list. That's the whole thing, and it catches most regressions.

Screenshot diff per locale. Store goldens of your key screens in both languages and compare on every build. Layout drift is the most common bilingual defect and the most invisible to a developer who only ever runs the English build.

Make the regression trigger explicit. Any new string, any new notification template, any new error path reopens the bilingual question. A pull-request checkbox that asks both locales added? owner assigned? costs ten seconds and saves a release.

Tag bilingual defects in your tracker. Review them monthly. If the same screen keeps breaking, the problem is your string pipeline, not the tester.

What release day really looks like

Two store listings, two screenshot sets, bilingual release notes. A support inbox that can actually answer a Welsh email, or an honest published policy about when it will. And a short internal note recording what language versions exist and who owns them — the kind of document that's tedious to write and invaluable when someone asks.

The teams that get this right aren't doing double the work. They've just stopped treating translation as a final coat of paint and started treating it as part of the build. Half a day per release, moved earlier in the cycle, beats a fortnight of panic every time the Commissioner's office or an unhappy user gets in touch.