Localizely is now the winner of the Top Performer award from SourceForge for more than 2 years in a row, the world’s largest software reviews and comparison website. 🚀 #WinnerClub #winner

Designer: "The button fits perfectly." German: Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz OK, that one was the name of a law and it got repealed in 2013. But "Settings" is "Einstellungen", and your 80 px button is still done for.

Did you know "i".toUpperCase() isn't "I" everywhere? In Turkish it's "İ" (dotted), and "I".toLowerCase() is "ı" (dotless). It has broken Java, .NET and Android apps for decades. Also: "ß".toUpperCase() is "SS". Two characters. Your fixed-width field just overflowed.

💡 Did you know the single word "Book" needs two different translations depending on whether it's a noun or a button? That's why translators ask for screenshots

Did you know 💡 Spanish is official in 20 countries and Switzerland has 4 official languages? A flag is a country, not a language. Language pickers shouldn't use flags.

AI translation in Localizely is now 3× cheaper 🚀 100K characters into a new language: $5.40 (was $16.19). Same context-aware translations: descriptions, screenshots, glossary, plurals, placeholders, ICU. Nothing to configure, existing MT characters just go 3× further.

Did you know 76% of online shoppers prefer to buy products with information in their own language, and 40% will never buy from a website in another language? CSA Research, 8,709 consumers, 29 countries. "English is enough" is a bet against 4 in 10 of your potential customers.

A request we heard more often than we'd like at Localizely had a one-word answer: no. "Can we keep our Android app and our iOS app in one project? It's the same app." It sounds trivial. It wasn't, and the reason is one character. - Android writes a placeholder as %1$s. - iOS writes it as %@. - Flutter writes it as {name}. - The web team writes {{name}}. Same sentence, same translation, four different strings. Upload the iOS file over the Android one and every key looks changed, translations get flagged for review, and the team stops trusting the tool. So we built one neutral form. In the editor a placeholder is simply {name}. When Android pulls the file it gets %1$s. When iOS pulls it, %@. Translators never see either. Two things we learned building it: 1. Conversion is the easy part. Proving the round trip is lossless is the hard part, so switching it on and later off gives you back byte-identical files. 2. Nobody trusts a black box. Once we showed a before and after diff of every string the switch would touch, "is this safe?" stopped being a question. If you ship the same app on two platforms, how do you keep the two translation projects in sync today?

Shipped: one Localizely project for your Android app and your iOS app. Same key, same translation. Android pulls %1$s, iOS pulls %@, translators only ever see {name}.

Day 1: "We'll add translations later. Just hardcode the strings for now." Day 900: 12,000 hardcoded strings and numbers/dates formatting, a big lead from Japan, and a very quiet standup.

Translation is 10% of localization. The other 90% is everything your English-only codebase silently assumed. A short list from bugs we've seen more than once: 1. "You have 3 new messages" was built with string concatenation. Japanese puts the number in the middle of the sentence. 2. A dialog asked "Are you sure?" In French that's "sûr" or "sûre" depending on who is asking. The app had no idea. 3. The date 03/04/2026 shipped to the UK. Half the users read March, half read April. 4. Sorting used the English collator. A Swedish customer asked why Ö was filed between O and P instead of at the end of the alphabet. 5. A "Back" icon pointed left in Arabic. The whole screen was mirrored, the arrow wasn't. 6. An uppercase comparison broke login on phones set to Turkish. Nobody could reproduce it in the office. None of these are translation problems. All of them show up the week after you launch in a new market. What would you add to the list?

"1 file", "2 files". Two forms. Easy. Russian: 1 файл, 2 файла, 5 файлов. Arabic: six plural forms. Japanese: one form, no plural at all. If your code says count == 1 ? "file" : "files", you shipped a bug to most of the planet.

Which placeholder syntax should be retired first?

The cheapest way to double translation quality is not a better translator or a better model. It is context. Words a translator cannot get right without seeing the screen: - Free: gratuit (no cost) or libre (available)? - Book: the noun or the verb? - Left: "3 left" or the direction? - Close: a button, or "close to you"? - Back: navigation, or the body part? - Order: sort order, or a purchase? A key named `home_free_label` with no screenshot gets you a coin flip. A screenshot, a one-line description and a character limit gets it right the first time, whether the translator is a person or a model.

The same "Hello, name" on seven platforms: Android: Hello, %1$s iOS: Hello, %@ Flutter ARB: Hello, {name} i18next: Hello, {{name}} Rails: Hello, %{name} .NET resx: Hello, {0} gettext / Py: Hello, %(name)s Every one of these is a crash or a garbled string when a translator adds a space, drops a $ or "translates" the name. Treat placeholders as protected tokens and validate every translation against the source before it reaches a build.