Does Google Play Auto-Translate Your App Listing?

Two separate things happen under that one phrase, and only one of them is automatic — so the first job is working out which one is running on your listing. Teams see their app described in a language they never wrote and conclude that localisation is handled. It is not, and the difference between the two mechanisms is the difference between a translated listing and a translated impression of a listing.

Google's Translate and localize your app help page separates them cleanly.

The second mechanism is the one that fools people. Your listing appears readable in a market you never targeted, installs from it are not zero, and nobody files a localisation ticket. What is actually happening is that Google is papering over a gap on the fly, with a visible label telling the user the text was machine-produced.

Google ranks the options in its own copy: "While it's best to use translations by native speakers, automated translations of your app's store listing will be available to Google Play users." That sentence concedes the fallback exists and tells you not to rely on it, in the same breath.

There is also a gap in the fallback itself worth knowing before you plan around it. Google states that "Automated translations aren't available in Armenian, Raeto-romance, Tagalog, and Zulu." If one of those is a market you care about, there is no safety net at all — an untranslated listing stays untranslated.

Across the 300+ apps we have managed since 2013, the most common localisation misdiagnosis is exactly this: a team believes it is localised in eleven markets because the listing reads in eleven languages, when it has supplied copy for one.

Store listing text and in-app product text, into ten named languages, and Google states plainly that the output is not reviewed by a human. It is much narrower than the phrase "free translation" makes it sound.

The wording from the help page is: "Using our free machine translation service, you can order instant, high-quality machine translations for your store listing and in-app products." Note the verb. You order it. Nothing happens to your listing until someone opens Play Console and asks for it.

The languages Google lists for this service are Arabic (ar), French (France) (fr-FR), German (de-DE), Indonesian (id), Italian (it-IT), Japanese (ja-JP), Portuguese (Brazil) (pt-BR), Spanish (Latin America) (es-419), Spanish (Spain) (es-ES) and Thai (th). That is ten. Read that list against your own install distribution before assuming your priority market is on it.

Notice what is absent. Not your screenshots. Not your feature graphic. Not the strings inside the app. Not your support inbox or your privacy policy. The free service moves the words on the store page and the words attached to your in-app products, and stops.

For a market where you are testing demand, that boundary is fine — the listing is the only asset a browsing user sees before deciding. For a market you intend to operate in, treating the listing as the whole of localisation is how you end up with a translated store page leading to an English-only app, which converts installs into uninstalls. Our store localisation strategy guide covers where the line usually sits.

Google shows users an automated translation of your listing with a notification explaining what it is — and your graphic assets fall back to your default language regardless. The text problem gets a patch. The image problem does not.

This is the sentence that decides how your listing behaves in every market you have not explicitly supplied copy for: "If you add text translations without localized graphic assets, your app's graphic assets show from the default language." The same fallback applies with even more force when you have supplied nothing at all.

Picture what a user in an unprepared market sees. A translated title and description carrying a badge saying a machine produced them, and directly beneath, a feature graphic and a full carousel of screenshots in English. The listing reads as half-finished because it is, and the missing half occupies most of the screen.

There is a second-order effect that is easy to miss. The machine translation is generated against your English copy, which means every keyword decision you made — every phrase you chose because it is what users in that category actually search for — was made in English and translated literally. Search behaviour does not survive that transformation: the obvious query in one language is frequently not the direct translation of the obvious query in another, which is why translated listings routinely rank for nothing in particular. Our piece on how Play's ranking system reads a listing goes into why the text field choices matter.

The honest reading of the fallback: it stops your listing being incomprehensible. It does not make it competitive, and Google positions it as what happens when you have not done the work, not as the work.

Google's Play Console page states that "Ordering takes minutes, costs as little as USD 0.07 per word, and translations are completed within seven days" — and "as little as" is doing real work in that sentence. That figure is a floor, not a rate card.

The service itself is described as: "Using our paid human translation service, you can order translations for your store listing and in-app products from a professional third-party vendor." So the same two content types as the free service, routed through a vendor instead of a model.

Two conditions travel with the price and must not be dropped when you quote it internally. The USD 0.07 is explicitly a minimum, not a rate. And Google notes that "Translations aren't available for all source and target language combinations" — so the pair you need may not be orderable at any price.

Google's own Intro to the App Translation Service page gives figures that do not match the Play Console page: it says "translating a typical app and store description into one language may cost around USD50", that "the translation price is calculated on a per-word basis", that "A typical translation order is completed within 4-5 business days, but the completion time depends on many factors", and that "Prices may also vary by language pairs and the vendor you select."

The paid service bills updates well. Google states: "When you place an order, we compare the text with your previous orders. Any existing text will be excluded from the order so you only pay for the new text." You can disable that reuse if you want everything re-translated. For a team shipping listing changes regularly, this is the difference between a per-release cost and a one-off one.

Supply context when you order. Google notes that "Adding a screenshot gives linguists context on how the text is displayed in your app." Translators working from a bare spreadsheet guess at context; translators looking at the screen do not.

The listing services do not, but Play Console has a separate, opt-in feature that translates app strings with Gemini models at no charge — and it has to be switched on before it does anything. This is the newest piece of the picture and the one most teams have not looked at.

Google describes it as continuous app string translation using Gemini, at no cost. The mechanism is that once you have enabled it, whenever a new app bundle is uploaded to a draft release, translations are automatically generated using Gemini models and integrated into the app bundle. Translations stay consistent across versions, changing only when the source text is altered or new text appears.

The conditions that come with it matter as much as the offer:

• It is opt-in. You turn it on in Play Console under Grow users, then Translations, then App strings. Nothing happens to an app that has not enabled it.
• Selecting a language overrides what is already there. Google states that existing translations for the languages you select will be overridden. If you have paid for professional strings in Japanese, do not casually tick Japanese.
• Right-to-left is your problem, not the feature's. Google's note is direct: "If you select Right-to-Left (RTL) languages, ensure your app is RTL-ready." Translating the strings does not mirror the layout.
• Preview has a prerequisite. Google states that "Preview is available once you have an uploaded bundle in a draft release." You cannot evaluate the output before you have something to run it against.
• You keep editorial control. Translated strings can be edited directly, and specific strings can be excluded from translation by unchecking the Translate checkbox — which is how you protect brand names and legal wording.
• Size is not the objection. Google states that app strings translation using Gemini "doesn't affect the installable APK size."

None of it removes the engineering prerequisite. The Localize your app guide is unambiguous that a string must be a resource before anything can translate it, and attaches a hard consequence to getting the defaults wrong: "If an app is missing even one default resource, it doesn't run on a device that is set to an unsupported locale." Hardcoded strings are invisible to every translation route — and invisible in your own testing, because you read them fine.

Because nothing in the translation pipeline touches images — Google states that graphic assets show from the default language unless you supply localised ones. This is the largest gap between what teams think they bought and what they actually bought.

Screenshots are not decoration; for most visitors they are the listing. A user scrolling a category page decides in a second or two, almost entirely on the icon, the first screenshot and the star rating. If the screenshots are in a language they do not read, the translated description underneath is arguing with an audience that has already gone.

Google's Add preview assets to showcase your app page sets the requirements and the expectation together. You must provide a minimum of two screenshots across different device types to publish your store listing, and the guidance repeatedly says to localise the assets appropriately for different markets and languages. It also draws a sensible line for games: "In-game UI does not need to be localized per market, but any additional taglines or text overlays should be localized."

That line generalises well beyond games, and it is the practical shortcut. The expensive part of localising screenshots is re-capturing the app in every language; the part that moves conversion is the caption overlay. Localise the overlays first, re-capture the screens later or never, and you capture most of the gain for a fraction of the cost. Our screenshots guide covers how to build the caption layer so it is cheap to re-render per language.

For evidence rather than argument about which version wins in a market, Play's own store listing experiments will tell you, and localised assets are among the cleanest things to test.

Layout, right-to-left rendering, per-app language settings, pricing and support — a list of things no translation order covers and every one of which is visible to the user. The listing is the shop window; these are the shop.

Text expansion breaks layouts silently. Translated strings are frequently longer than the English original, and a button that fits at one length clips at another. Android ships a testing mechanism for exactly this. The pseudolocales guide describes English (XA), which adds Latin accents to base English UI text, expands the original text, and brackets each message unit to expose issues caused by the expansion, and AR (XB), which sets the text direction of original left-to-right messages to right-to-left. Google lists what these surface: hardcoded strings, UI layout issues caused by text expansion, string concatenation showing as one message split across brackets, bidirectional text problems, and right-to-left problems such as elements not being mirrored or misplaced punctuation. We are not quoting an expansion percentage because that page does not publish one, and the figures circulating online are not sourced to Google.

Users cannot choose your app's language unless you declare it. Android's per-app language preferences documentation is direct about the consequence of skipping this on Android 13 and higher: "Omitting the android:localeConfig manifest entry signals that users shouldn't be able to set your app's language independent of their system language within their system settings." In markets where people run a device in one language and prefer apps in another — most of India — that omission quietly costs you the users you just translated for.

Price is a localisation decision, not a currency conversion. A translated paywall showing a price calibrated to a different economy converts badly no matter how good the translation is; we treat that as its own problem in purchasing-power-based pricing.

Support does not translate itself. Localising a listing invites reviews, emails and tickets in that language, and no Play Console feature answers them. This is the cost line left out of every localisation business case we review, and the one that recurs monthly.

Prove demand with the cheapest possible listing translation, then spend real money only on the markets that responded. The sequence matters more than the budget, because the expensive assets should follow evidence rather than ambition.

If you want to go further than language, Google's custom store listings allow a different listing per segment: you can create up to 50 custom store listing pages, targeted by criteria including country or region, install state, search keywords, pre-registration status and Google Ads campaigns, with app name, icon, descriptions and graphic assets all customisable. The constraint to plan around is that you can target multiple countries with one custom store listing, but you can only target a country with one custom store listing at a time.

When the text is descriptive and the stakes of a slightly wrong word are low — and it stops being good enough at exactly the point where the words are load-bearing. Google's own framing supports both halves of that: it offers the free service and simultaneously states that translations by native speakers are best.

The useful test is what a given string is for.

The asymmetry is that the highest-value text in your listing is also the shortest. The 80-character short description does enormous work relative to its length, and it is precisely the dense, deliberate copy that literal translation flattens. Paying a human for a few dozen words at the top of the funnel while machine-translating the body copy underneath is not a compromise — it is the correct allocation.

There is one habit worth building regardless of which route you take: have somebody who actually speaks the language read the published listing on a real device. Not the spreadsheet, not the Play Console preview — the listing as a user in that market encounters it, screenshots included. In our portfolio that single check has caught localisation defects every process step around it missed, and it costs one conversation.

If you are weighing which markets justify the human spend, or your listing is being auto-translated in places you never chose and you want to know whether that is costing you anything, tell us which markets you are seeing installs from. Localisation sequencing is part of how we approach a listing in our ASO work, and you can see the market-entry cases in our results.