What Does It Take to Translate a Desktop App Into 30 Languages?

Translating a desktop utility into 30 languages is a project that looks small and is not. The string count is the easy part. The hard parts are right-to-left layout, plural forms, system locale defaults, font fallbacks, and screenshots in documentation that break the moment the UI language changes. This case study walks through what a 30-language internationalisation effort actually involves, based on the patterns that have emerged in 2026 from solo-maintained Electron and Tauri apps. For related reading, see donations, stores, and keeping a free app alive, accessibility bar for overlay utilities, what local-first software means for clipboard apps, and why some clipboard apps will never sync.

The string count is the easy part

A typical desktop utility has 200–600 user-visible strings: button labels, menu items, tooltips, error messages, settings descriptions, and onboarding text. Extracting these into a JSON or YAML file, replacing the hard-coded strings in the source with t('settings.behaviour') calls, and shipping the file to a translation platform is a weekend's work. Tools like i18next, formatjs, and fluents make this straightforward in JavaScript and TypeScript.

The hard part is everything else. The string count is the floor, not the ceiling.

RTL layout: Arabic, Hebrew, Persian, Urdu

Right-to-left languages break layouts that assumed left-to-right. The breakage is not just text direction; it is the entire spatial model of the UI.

• Icons that pointed right now need to point left. A "back" arrow that points left in English points right in Arabic.
• Padding and margin are flipped. padding-left: 8px becomes padding-right: 8px. Most CSS frameworks handle this with logical properties (padding-inline-start); older code does not.
• Shelf position is mirrored. An edge shelf that sits on the left in English may need to sit on the right in Arabic, because the user's reading direction affects where they expect the shelf to appear.
• Drag direction is mirrored. A drag from the shelf into a target app goes left-to-right in English; in Arabic, the same drag may go right-to-left.

For an overlay utility like Edge-Drop, RTL is a real design problem. The shelf's position, the drag direction, and the icon set all need to handle RTL. The honest approach is to test with native speakers, not to assume the layout works.

Microsoft's official guidance on RTL is linked in Sources. The short version: use logical CSS properties, mirror icons explicitly, and test with both LTR and RTL strings during development.

Plural forms: English is the easy case

English has two plural forms: "1 item" and "2 items." Most languages are not that simple.

• Arabic: six plural forms, depending on the number's grammar.
• Russian, Polish, Ukrainian: three plural forms, with different endings for 1, 2–4, and 5+.
• Japanese, Korean, Vietnamese: one plural form; the count is a separate word.
• French, Portuguese: two plural forms, but the rule for "0" differs from English (French uses the singular for 0).

A translation system that hard-codes if (count === 1) { return 'item' } else { return 'items' } will produce wrong output in most of the world's languages. The correct approach is to use the Unicode CLDR plural rules, which i18next, formatjs, and fluents all support.

For each language, the translation file needs entries for each plural form the language uses. For Arabic, that is six entries per string. For English, two. The translation platform should handle this; the developer's job is to make sure the source code calls the right function.

System locale: the default that surprises users

A desktop utility should default to the system locale, not to English. Most desktop apps do this; some do not, and the result is a jarring experience where the OS is in French, the browser is in French, and the clipboard manager is in English.

The check is straightforward: on first run, read the system locale (navigator.language in Electron, LocaleName on Windows, app.getLocale() in Electron's main process), and use it as the default. If a translation for that locale is available, use it; otherwise fall back to English.

Edge-Drop uses this pattern. The settings UI lets the user override the language, but the default is the system locale, and the override persists across restarts.

Font fallbacks: not every font has every glyph

A string in Japanese needs a font that has Japanese glyphs. A string in Arabic needs a font that has Arabic glyphs and the correct shaping. Most desktop apps rely on the OS's font fallback chain, which is usually correct but not always.

For an Electron app, the renderer is Chromium, which has its own font fallback chain. This is usually correct but can produce surprising results: a Japanese string in a font that was designed for Latin text may render with a different fallback than the same string in a Japanese-native font.

The practical fix is to specify a font stack that includes fonts for each script the app supports. For a 30-language app, that means a stack like:

font-family: 'Inter', 'Noto Sans Arabic', 'Noto Sans Devanagari', 'Noto Sans CJK JP', sans-serif;

This is not glamorous work, but it is the difference between a translated UI that looks right and one that looks broken.

Screenshots break first

The first thing that breaks when a UI is translated is the documentation. A screenshot of the settings UI in English does not match the same UI in Japanese, because the labels are different lengths, the layout may wrap, and the icons may be mirrored.

The realistic patterns:

1. Take screenshots in one language only, and accept the mismatch. This is the most common approach, and it is honest if the docs say "screenshots are in English; your UI may differ."
2. Take screenshots in multiple languages, and serve the right one based on the user's locale. This is more work but produces a better experience. It requires a screenshot automation pipeline, which is non-trivial.
3. Use fewer screenshots, more diagrams. A diagram that shows the layout without specific labels translates better than a screenshot. This is the approach the Edge-Drop docs take for the settings UI.

For a solo developer, option 1 is the realistic default. Option 3 is the next step up. Option 2 is for projects with a documentation team.

Translation platforms

The platforms most solo developers use:

• Crowdin. Free for open-source projects. Supports the file formats Electron and Tauri apps use (JSON, YAML, Gettext). Has a translator UI that handles plural forms and context.
• Weblate. Self-hostable, free software. Same file format support. Better for projects that want to keep translation data on their own infrastructure.
• Transifex. Commercial, with a free tier for small projects. Similar feature set to Crowdin.
• GitHub PRs. The simplest option: accept translations as PRs against a JSON file. Works for small projects; does not scale to 30 languages.

For a 30-language effort, Crowdin or Weblate is the realistic choice. Both handle the plural forms, the context, and the translator workflow that a solo developer cannot build themselves.

A summary of the work

The work of translating a desktop utility into 30 languages:

The total is roughly two weeks of developer time to set up, plus ongoing community management. The ongoing part is the hard part: keeping translations up to date as the UI changes, recruiting native speakers for new languages, and handling the edge cases that come back from real users.

The honest case for Edge-Drop

Edge-Drop's translation effort is in progress as of mid-2026. The source code uses i18next; the translation files are JSON; the system locale is the default. The README and the in-app settings let the user pick a language. RTL support is partial: the layout flips, the icons mirror, but the testing with native speakers is not yet complete for every supported language.

This is honest. A 30-language effort is not a switch that gets flipped; it is a project that gets better over time. The realistic expectation is that the first 10 languages are solid, the next 10 are functional but less polished, and the last 10 are community-maintained with varying quality. The user who cares about a specific language should check the translation file's last-commit date and the translator count, both of which Crowdin and Weblate expose.

For more on the broader scope of solo-maintained desktop utilities, see donations, stores, and keeping a free app alive and accessibility bar for overlay utilities. For the local-first angle, see what local-first software means for clipboard apps.

Background for this constraint is What a Good Clipboard Changelog Looks Like.

Related reading

• Accessibility Bar for Overlay Utilities
• What a Good Clipboard Changelog Looks Like
• What Local-First Software Means for Clipboard Apps
• How to Enable Clipboard History in Windows 11

Sources

• Unicode CLDR — Plural rules — official CLDR documentation for the plural rules that i18n libraries use
• i18next — Documentation — official documentation for the i18n library used in many Electron and React apps
• Microsoft Learn — Bidirectional UI support — official Windows guidance on RTL layout, useful for desktop utilities
• W3C — Internationalization — official W3C internationalization activity, with references for RTL, plural forms, and font fallback
• Crowdin — Documentation — official Crowdin documentation, the translation platform most solo developers use for open-source projects

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support