Translation Is the Cheap Part

Sending your strings file to a translation vendor costs $0.10 to $0.25 per word. A companion app with 1,200 strings translates into five languages for a few thousand dollars. That number lulls founders into thinking localization is a line item. Then the German build ships and every button label overflows, the app crashes on a French phone because a decimal comma broke a number parser, the Japanese store listing gets rejected, and the device keeps reporting temperature in Fahrenheit to a customer in Milan.

Localization is an engineering property of the product, not a translation purchase. Retrofitting it into a shipped app typically costs three to five times what building it in would have, and for a connected product the cost lands in three places at once: the app, the firmware, and the cloud.

What a Complete Localization Covers

  • Units. Celsius and Fahrenheit, kilograms and pounds, millimeters and inches, liters and fluid ounces, kPa and psi, km/h and mph. Store one canonical unit internally and convert only at the display layer. Never store what the user last saw.
  • Number and date formats. 1.234,56 in much of Europe, day-month-year almost everywhere outside the US, 24-hour clocks by default in most markets, week starting Monday. Use platform formatters; hand-rolled string building is where these bugs live.
  • Text expansion. German and Russian run 20 to 35 percent longer than English; Chinese and Korean run shorter but need different line-break rules. Design layouts that flex rather than fixed-width buttons.
  • Right-to-left layouts. Arabic and Hebrew mirror the whole interface: navigation, icons with direction, progress bars, sliders. Both platforms support RTL well if you used leading and trailing constraints instead of left and right.
  • Pluralization and gender. English has two plural forms; Arabic has six, Polish has four. Use the platform plural resources rather than concatenating a number onto a noun.
  • Sorting and search. Locale-aware collation matters the moment a user has a device list with accented names.
  • Icons, colors, and imagery. Hand gestures, animals, and colors carry different meanings across markets, and a photo of a US kitchen outlet reads as wrong hardware in Europe.
  • Legal and support content. Privacy policy, warranty terms, and safety warnings usually must be in the local language to be enforceable.

Build For It Even If You Launch in English Only

The decisions that make later localization cheap cost almost nothing on day one. Externalize every user-visible string from the first commit, with descriptive keys and translator comments explaining context. Never concatenate sentence fragments; use full parameterized templates, because word order changes between languages. Leave 30 percent slack in text containers. Use the platform locale APIs for everything formatted. Keep a pseudo-localization build target that replaces every string with an accented, lengthened version, and run it in CI so a hardcoded string fails a build rather than surfacing in a Spanish release.

That discipline costs maybe a week across a normal build cycle. Doing it later means re-auditing every screen. It also interacts with your framework choice: cross-platform stacks centralize the string catalog nicely but sometimes lag on RTL and plural support, a tradeoff worth weighing alongside the others in native vs cross-platform development, and one that shows up in the estimate lines discussed in mobile app development cost.

The Store Listings Are Their Own Project

Both stores localize independently of your binary: title, subtitle, keyword field, description, screenshots, and preview video, per locale. Screenshots with English text baked in are the most common miss, and they measurably depress conversion in non-English markets. Keyword research does not translate either; the term a German buyer searches for your product category is often not the German word for the English term you rank on. Budget separate research per market. The submission mechanics and metadata rules are covered in publishing to the app stores, and which market to enter first is a business question worked through in choosing your first international market.

The Hardware and Cloud Side

A connected product localizes below the app too. Firmware carries strings if the device has a display, and those strings need a font with the right glyph coverage, which is a real flash-budget question when Chinese support adds hundreds of kilobytes. Device-side defaults matter: a unit shipped to a European customer should default to Celsius on first boot, ideally derived from the locale the app reports during provisioning rather than from a hardcoded build variant. Radio regulatory profiles differ by region and are set at manufacture or at provisioning, not by the language picker.

On the cloud side, store timestamps in UTC and render in the user's zone, keep translated content out of the code and in a content service you can update without a release, and localize transactional emails and push notification bodies, which teams forget until a customer receives an alert in the wrong language at 3 a.m. Any string that ships inside firmware also has to be updatable, which is one more reason the OTA update path should exist before launch.

Managing Translations Without Chaos

Use a translation management platform rather than spreadsheets. Connect it to your repository so new strings are pushed automatically and completed translations come back as pull requests. Maintain a glossary of product terms that must never vary, and a style guide covering tone and formality, because German and Japanese both require an explicit decision about how formally you address the user. Give translators screenshots or a live build; the same English word translates three different ways depending on whether it is a button, a heading, or a status. Machine translation is a reasonable first pass for long-form help content and a poor choice for interface strings and safety text.

Budget ongoing cost, not a one-time cost. Every release adds strings, and untranslated strings fall back to English inside an otherwise localized screen, which reads as broken. That recurring line belongs in the plan described in app maintenance costs after launch.

Testing Is Where It All Surfaces

Run a device farm pass per locale with the system language and region actually switched, not just an in-app language picker. Check the longest string in every layout, RTL mirroring on real Arabic text, number entry with a comma decimal separator, sorting, and the unit round-trip between app, cloud, and device. Then have a native speaker who understands the product review the running app, not the spreadsheet. Translators working from a string list produce grammatical text that is sometimes wrong for the context, and only a person holding the product catches it.

Take Your Product Global Without a Rewrite

Projects House builds companion apps, firmware, and cloud backends as one system, so units, locales, and regional defaults are consistent from the device up. Tell us which markets you are targeting through our contact form and we will scope what localization means for your product specifically.