All articles
·6 min read

Multi-language screenshots at scale: localized marketing assets without the matrix

Localized screenshots scale quadratically. Here is how to keep the cost flat as you ship more locales.

Localized marketing assets are one of those problems that scales quadratically and gets ignored until it bites. Three locales and ten screenshots is fine. Twelve locales and forty screenshots is four hundred and eighty PNGs to maintain — and the moment your product changes, that number resets. Most teams quietly stop localizing screenshots past the third language. The marketing page in French stays in English; the help center in German shows English UI; the app store listing in Japanese never updates.

The economics of manual localization are brutal. The fix is to remove the matrix entirely — make locale a parameter, not a separate workflow.

Why translated UI breaks screenshots

When you ship a new locale, every text node in your product gets replaced. Buttons change width, layouts shift, dates format differently, currencies render with different separators. A screenshot captured in English no longer accurately represents the German user experience. Even small visual differences — a date in13. Mai 2026 format vs May 13, 2026 — change how a prospect reads your product.

For help-center and onboarding content, the problem is worse: a tutorial screenshot showing English UI when the article is in French breaks the reader's flow and signals that the localized experience is half-baked.

The locale matrix problem

The math is unforgiving. For each screenshot, you need:

  • N locales
  • × M devices (mobile, tablet, desktop)
  • × T themes (light, dark)
  • = N × M × T captures

For a product shipping in 6 locales, 3 devices, 2 themes, that is 36 captures per screenshot. With 30 marketing screenshots, you are at 1080 assets to keep in sync. Manual maintenance is impossible at that scale; teams either skip the matrix (mono-locale screenshots everywhere) or accept that some locales will always be stale.

One preset, every locale

The trick is to express locale as a parameter of the capture, not as a separate job. A single preset describes which UI to capture and which interactions to perform; the runner expands it across every locale at runtime. AutoKap does this via the SET_LOCALE opcode in the deterministic execution program — the same program runs once per locale, swapping the language setting between captures.

The output is N captures per preset, indexed by locale, served from the same asset URL with a ?lang=de query parameter. Your marketing CMS, your help-center articles, your app-store listing all reference the same canonical URL with the appropriate locale flag. Add a new locale next quarter? Update one config line and re-run. Every screenshot now exists in the new language.

Auto-generated alt text per locale

The detail most teams overlook is alt text. Localizing the visual content is half the work; localizing the accessibility metadata is the other half. Manual translation of alt text for every screenshot in every locale is the kind of work that gets perpetually deprioritized because it is invisible to most users.

An LLM step at the end of the capture pipeline reads the screenshot and the locale, generates appropriate alt text in the target language, and stores it alongside the asset. The cost is a few cents per capture. The benefit is that screen-reader users in every locale get a first-class experience without anyone explicitly remembering to write alt text.

The right-to-left edge case

Arabic, Hebrew, and Farsi screenshots have an extra wrinkle: the entire layout flips. Captures need to be re-run with the correctdir="rtl" setting and re-verified visually. AutoKap handles this as part of the locale parameter — if the locale is flagged as RTL, the preset adjusts. The output is a screenshot that reads correctly for RTL users without a separate workflow.

Where to start

If your product already ships in three or more locales and you have ever skipped a screenshot localization because it was "not worth it," you have already paid the cost of the matrix problem — in lost conversion, in degraded localized experience, in dev hours arguing about whose responsibility it is. Wire one preset through a locale-aware capture pipeline, watch it generate the full matrix on the next deploy, and the case for the rest writes itself.

Tags

screenshotsi18nlocalization