A translated Polish subscription screen ships. QA signed off. A user on the 3-month plan sees "Otrzymaj 3 miesięcy dostępu Premium" — and it reads wrong, the way "3 childs" would in English. Grammatically, it should be "Otrzymaj 3 miesiące dostępu Premium." Same English source, same intended meaning, one wrong word. This is a pluralization bug, and it's a genuinely old, well-studied problem — not something this post is claiming to have discovered. Android has had quantity strings for over a decade. iOS has .stringsdict. ICU MessageFormat and i18next both handle plural categories natively. Several localization platforms and design-tool plugins already offer some form of plural-aware preview or resource management. None of that is new. What this post walks through is narrower and more practical: how to catch this specific bug at the point where the text is actually designed, using Translations for Figma's Variant inspector — and, along the way, why the "obvious" fix (translate the existing resource file entry by entry) doesn't actually work, even though a lot of real localization work still does exactly that. A quick primer: what's a "plural form," really? If you've only ever shipped an English-only product, this might be new to you, and that's fine — it's worth thirty seconds to get straight before anything else here makes sense. English plurals are deceptively simple: one item, or "other." "1 month" / "2 months." Two forms, always. It's easy to assume every language works the same way — translate the word, ship it. It doesn't. The Unicode CLDR plural rules define up to six grammatical categories per language (zero, one, two, few, many, other), and which ones a language actually uses varies: Language Plural categories for whole numbers English one, other (2) Polish one, few, many (3) Arabic zero, one, two, few, many, other (6) One wrinkle worth flagging now so it doesn't look like a contradiction later: "categories a language's grammar actually distinguishes" and "entries a resource file needs" aren't quite the same count. Android and iOS both treat other as a mandatory fallback bucket regardless of language, so even Polish's resource ends up with a fourth other entry alongside its three real ones — more on that when it comes up. Both Android and iOS resource formats already know about this — a <plurals> block in Android or a .stringsdict entry in iOS is built to hold one string per category, and the OS picks the right one at runtime based on the actual count and the device's locale. So the file format isn't the problem. Filling it in correctly is. The mistake that ships anyway: translating a resource file literally Here's where a lot of real-world localization goes wrong, and it's worth being blunt about it: translating a plural resource entry by entry, the way you'd translate a normal string, is fundamentally incorrect — and some translators, translation tools, and even careless engineers still do exactly that. Take the English source: <!-- Android: strings.xml --> <plurals name="premium_access_months"> <item quantity="one">Get %d month of Premium access</item> <item quantity="other">Get %d months of Premium access</item> </plurals> Two entries: one, other. A literal, entry-by-entry translation into Polish — translate what's there, keep the same structure — produces this: <!-- WRONG: a literal, entry-by-entry translation --> <plurals name="premium_access_months"> <item quantity="one">Otrzymaj %d miesiąc dostępu Premium</item> <item quantity="other">Otrzymaj %d miesięcy dostępu Premium</item> </plurals> This looks reasonable if you don't already know Polish needs three categories, not two. But Polish's plural rule says a count like 3 resolves to few — and this resource has no few entry. Android's plural resolution doesn't error out when a category is missing; it silently falls back to other. So for a count of 3, the app renders the other string — "Otrzymaj 3 miesięcy dostępu Premium" — which is exactly the wrong, ungrammatical text from the top of this post. The bug isn't a typo. It's a direct, mechanical consequence of translating the file the way you'd translate any other string, instead of re-deriving the entire category set for the target language. A correct Polish version needs entries the English source never had anything to translate from: <!-- Android: strings.xml (Polish) --> <plurals name="premium_access_months"> <item quantity="one">Otrzymaj %d miesiąc dostępu Premium</item> <item quantity="few">Otrzymaj %d miesiące dostępu Premium</item> <item quantity="many">Otrzymaj %d miesięcy dostępu Premium</item> <item quantity="other">Otrzymaj %d miesięcy dostępu Premium</item> </plurals> Four entries, not two — even though Polish grammar only ever selects one, few, or many for a whole-number count. other is included anyway because Android treats it as the one mandatory fallback bucket every locale falls back to, regardless of what that language's own grammar needs; for an integer-only count like this it'll realistically never be chosen at runtime, so it's given the same text as many. Leaving it out is exactly the kind of gap that looks harmless until an edge case nothing anticipated hits it. Keep this in mind — it's exactly what the walkthrough below produces. Where this is easiest to catch: at design time Nobody writing the Figma design ever sees any of this. A text layer holds one static string. Nobody notices that Polish "miesięcy" is visibly longer than English "months," or that a short one form leaves a button looking oddly empty, until a real build, on a real device, with a real count, finally exposes it — usually well after the design was signed off, and usually to whoever's translating or QA-ing the build, not the person who designed the screen. The rest of this post is a walkthrough of doing two things — checking the layout, and generating the actual resource — from the same place and the same data, using the Variant inspector in Translations for Figma. Step 1: add samples to preview the layout Select the text layer and open the Variant inspector. Add a few samples — plain, realistic alternate values the count could actually take: "Get 1 month of Premium access" "Get 3 months of Premium access" "Get 12 months of Premium access" (1/3/12 happen to land on Polish's one/few/many categories too — convenient for this walkthrough, though at this stage a sample is still just plain text, added to stress-test the layout, nothing more.) Click through the samples on canvas. This immediately shows whether the layout survives the range — a short "1 month" button next to a much wider "12 months" one, say. This is the layout half of the problem, solved, before a single line of code exists. One aside, since it's easy to conflate: samples aren't only for plural counts. The same mechanism also covers a text layer whose content varies for unrelated reasons — a shared button showing "Next," "Continue," or "Add to cart" depending on which screen it's on. That's a real, separate use of samples, but it's out of scope for this post; here, every sample on this layer is the same sentence with a different count. Step 2: generate the resource pattern, don't hand-author it Samples aren't just for the visual check — they're also what the plugin uses to derive the actual resource entry, so nobody has to separately author the plural rule by hand. The Variant inspector has an "Add pattern" button for typing an entry from scratch, and an "✨ AI generate" button that derives the pattern automatically from the samples already on the layer. Pick your target platform (iOS, Android, or both) and a resource id — auto-generated from the text and kept in sync with it, becoming the exact key your app's code will reference. are visible (one and other)"/> Click AI generate. For English, this produces exactly the two-entry pattern shown earlier — one/other — because that's all English's grammar needs. Unremarkable on its own. The interesting part happens once you translate. A quick note on cost, since it's easy to gloss over in a post like this and get called out for it later: a pattern can always be typed by hand in a plain text field — that stays free, and isn't going anywhere. "AI generate" currently calls out to the plugin's own backend and isn't separately charged for today. If that ever changes, manual authoring remains the baseline either way; AI generation is a convenience layer on top of a workflow that still works without it. Step 3: translate the interface, then generate the target pattern Using the plugin menu, translate the interface into Polish. Reopen the Variant inspector on the same layer. Its samples are already translated — translation applies to samples the same as any other text in the plugin — but the pattern is not. Patterns don't auto-translate, because a plural resource entry isn't a translation of a sentence, it's a distinct grammatical artifact that has to be derived for the target language specifically. There's also a "Copy source + translate" button here, and it's worth pausing on exactly what it does: it machine-translates each existing source entry, one at a time, keeping the same entries the source had. That's useful for a pattern that genuinely doesn't need restructuring — but for a plural pattern going from English (one/other) to Polish (one/few/ many, plus the mandatory other fallback), it reproduces precisely the "literal translation" mistake from earlier in this post: two entries in, two entries out, few and many both missing. It's the right tool for some jobs and the wrong one for this one. Click AI generate instead. It doesn't copy or translate the existing entries — it derives a fresh pattern for Polish, from the samples, using Polish's own plural rule: <!-- Android: strings.xml (Polish) --> <plurals name="premium_access_months"> <item quantity="one">Otrzymaj %d miesiąc dostępu Premium</item> <item quantity="few">Otrzymaj %d miesiące dostępu Premium</item> <item quantity="many">Otrzymaj %d miesięcy dostępu Premium</item> <item quantity="other">Otrzymaj %d miesięcy dostępu Premium</item> </plurals> Four entries, correctly — one/few/many because that's what Polish grammar actually distinguishes for a whole-number count, plus other as the mandatory fallback the resource format itself requires — not because anyone copied, translated, or hand-fixed the English version. Switch platforms to check iOS's .stringsdict shape too; same categories, different format. Step 4: compare source and target, then export The Variant inspector's own language switch lets you flip between the source language's samples/patterns and the target's, right inside the same panel — a quick way to visually compare the two without leaving the inspector. When you're done, open Plugins → Translations for Figma → Tools → Resources and download the generated files for each target platform — real Android strings.xml/<plurals> and iOS .strings/.stringsdict output, plural rules already resolved, ready to hand to engineering. Why bother, if this is a solved problem? To be fair to the question: pluralization itself isn't solved here for the first time, and this post isn't pretending otherwise. What changes is where it happens. The layout check and the resource generation both run from data (samples) a designer was already going to create to test the screen, in the same tool the screen was designed in, without a separate localization engineer, a separate platform account, or a round trip back to whoever designed the screen once a bug like the cover image's finally gets noticed. For a small team without dedicated localization tooling already in place, that's mostly a matter of saved time and one fewer place for the mistake from earlier in this post to sneak back in — not a new capability nobody's ever had. Try it The plugin is Translations for Figma on the Figma Community, free tier included. If you've run into a shipped plural bug like this one, we'd genuinely like to hear how it got caught (or didn't) — comment below.