App Store Listing Text: Name, Description and Character Limits

Localising a mobile app usually starts with the interface strings. Yet users never see the interface before they download the app. All they see is the store page: the name of the app, the short pitch, the long description and the screenshots. If the app store listing text has not been localised, how carefully the interface was translated makes little practical difference.

Contents

Jiménez-Crespo treats store listings as a distinct type of asset in app localisation and lists the fields required by the two major stores one by one (2024, p. 228). Each of those fields has its own character limit. The limits are not the same in the two stores, and that difference bears directly on translation decisions.

Below we look at which fields these texts consist of, how the limits constrain the translation, and which decisions have to be taken in advance when carrying them into Turkish.

Why are app store listing texts a separate item of work?

Interface strings come out of the source files, go into the translation tool and return to the compiled app. Store texts sit outside that chain. They are typed by hand into the developer console, they are not compiled with the app itself, and they are usually the responsibility of the marketing team. That separation means the two kinds of content are translated by different people and at different times.

The result is terminological inconsistency. A feature is called one thing in the store description and another inside the app. Once users have downloaded it, they cannot find the button they are looking for. The book further stresses that consistency with the platform’s standard terminology has to be maintained for the listing to be accepted by the store (Jiménez-Crespo 2024, p. 229).

Store texts should therefore be tied to the same term list as the interface translation. Using the same translator, or at the very least the same termbase, costs far less than the corrections that would otherwise follow.

Two stores, two different field lists

According to the list given in the book, the App Store and Google Play ask for similar information under different names and with different limits. The most striking difference is in the app name: the App Store allows 255 characters, while Google Play caps the title at 30. The description field, on the other hand, is 4,000 characters in both stores.

Field	App Store	Google Play
Name / Title	255 characters	30 characters
Description	4,000 characters	4,000 characters
Release note	4,000 characters	4,000 characters
Short description	No separate field	80 characters
Keywords	100 characters	No separate field
In-app purchase	Title 75 characters	Name and description

On its own the table is not a translation brief, but it is a warning. The same pitch cannot be written once for both stores. A 30-character title produced for Google Play is far too narrow for the App Store; a long name written for the App Store will be cut off on Google Play.

In practice, preparing two separate sets of text is the soundest route. You start from a shared source text and then shorten it separately for each store. If this twofold structure is not flagged at the point of requesting the translation, it comes back as an extra cost.

The app name: the narrowest and most expensive field

Thirty characters is roughly three words in Turkish. The brand name already takes up part of that. What is left is one or two words to say what the app actually does. This field calls not for translation but for rewriting; trying to preserve the syntax of the source text almost always leads to an overrun.

In Turkish, words expressing a function are longer than their English counterparts. A short English verb, for instance, can turn into a long suffixed noun in Turkish. In that case it is safer to keep the brand name fixed and shorten the descriptive part than to try it the other way round.

Counting characters is not enough when preparing the name. You have to see how the text is actually truncated on a real device screen. On store listing screens the name appears at different widths in search results and under the icon. The space under the icon is the narrowest of all and often carries the brand name alone.

The name is therefore not a decision the localisation team can take on its own. The brand owner, marketing and the translator have to sit at the same table. An app name changed after the event can also reset the search ranking and the user habits that have built up.

The description: the first three lines of four thousand characters

The description field is generous, but users do not read all of it. The store app shows only the first few lines of the text; the rest stays behind a link. The translation therefore does not have to follow the order of information in the source text. In the Turkish version it is often better to move the strongest benefit into the first sentence.

The second function of the long description is search visibility. The book notes that store optimisation requires the localisation of elements such as the app name, the keywords and the description (Jiménez-Crespo 2024, p. 229). In other words, the description is written for the ranking algorithm as much as for the human reader.

That dual purpose weakens word-for-word translation. The search terms of the source language are different in Turkish. A description translated without researching those terms may be flawless grammatically and useless in terms of visibility. For more detail you can read the relevant articles in our knowledge centre.

The form of the description matters as well. Long paragraphs go unread on a mobile screen; short blocks and bullet points work better. If the source text has been written as a single block, you are free to break it up in the Turkish version. The aim here is not fidelity but performing the same function in the target market.

The short description and the keyword field

Google Play’s 80-character short description is the most-read text on the listing page. It is a one-sentence promise and it must not be cut off. Carrying it into Turkish means avoiding a pile-up of adjectives and building a plain predicate. Long chains of noun compounds both strain the limit and reduce readability in this field.

The 100-character keyword field on the App Store side, by contrast, is never seen; only the search engine reads it. You do not build sentences here, you write terms separated by commas. A direct translation of the source list usually gives the wrong result, because the words users actually search for are different.

These two fields want the same information in two different forms. One persuades, the other matches. Copying the same text into both means wasting both fields.

Repetition in the keyword field is wasteful too. Writing the same word both in the app name and in the keyword box spends the limited space twice over. Once the words that appear in the name are struck off the list, the same character count can cover a wider range of searches.

Screenshots and text inside images

Screenshots are part of the listing requirements as well. Most apps embed short pitch lines in these images. Those lines are not in a text file but inside the image file, and they call for a separate production flow. The book notes that images and videos are counted among the assets to be localised where necessary (2024, p. 232).

There are two risks with images. The first is that the embedded text is forgotten and English screens appear in the Turkish listing. The second is that the interface in the screenshot does not match the app’s actual Turkish interface. The second mistake creates a false expectation in the user.

The solution is to retake the screenshots once the interface translation is finished. Unless that step is written into the schedule from the start, it becomes the first job dropped on launch day. Keeping the text layer of the images in editable form also speeds the work up.

How do you send the texts for translation?

The book describes two general delivery routes in app localisation: sending the exported files directly, or sharing them through a cloud-based platform (Jiménez-Crespo 2024, p. 228). For store texts the distinction is simpler still, because the content is short and countable to begin with.

On small projects a spreadsheet is enough. The columns are set up as field name, source text, character limit and target text. When the limit column is visible, the translator spots the overrun while writing; the later rounds of shortening disappear.

On multilingual projects that are updated often, cloud platforms are more suitable. These platforms can show the same string in one place and keep a version history. Whichever route you choose, the field names have to match the source list exactly; otherwise there is a risk of pasting text into the wrong field in the console.

The Türkiye context

Türkiye occupies an interesting middle position in store listings. A substantial share of users search for apps in Turkish but write technology terms in English. That duality makes it hard to prepare a single-language keyword list. Letting an English term appear inside a Turkish description is often a deliberate choice.

The second issue is Turkish characters. The letters ç, ğ, ı, ö, ş and ü can be used in the title and short description fields; in search behaviour, however, writing them without their diacritics is also common. Both spellings have to be borne in mind when preparing the keyword list.

The third is the legal side. If the app processes personal data, the commitments made in the store description must not contradict the wording of the privacy policy. What will be assessed under the KVKK is the policy itself, not the marketing text; even so, an inconsistency costs trust.

What does this mean for you?

If you are opening your app up to Turkish, budget the store texts as an item separate from the interface. These texts look cheap because they are short; in fact, because of the character limits, they are among the jobs with the highest effort per unit. The sequence below works on most projects.

1. Prepare a table listing the fields and the character limit of each one.
2. Give the interface term list to the translation team before the store texts.
3. Brief the title and short description as adaptation work, not translation.
4. Set the keywords afresh according to Turkish search behaviour.
5. Reproduce the screenshots once the interface translation has been approved.
6. Check the texts for truncation on a real device before publication.

To decide which of these steps to outsource, all you need to do is clarify the scope. You can request a quote for app listing translation and look over what our service covers on the services page.

Frequently asked questions

Are app store listing texts translated together with the interface strings?

They are usually handled as a separate item of work. Interface strings come from the source files, whereas store texts are entered directly into the developer console. The terminology of the two must be the same, but their processes differ.

Are the App Store and Google Play character limits the same?

No. According to the listing given in the book, the App Store allows 255 characters for the app name and Google Play 30 for the title. The description field is 4,000 characters in both stores.

How much longer is Turkish text than English?

It would be wrong to give a fixed ratio. Because Turkish is an agglutinative language, it can be shorter in brief labels and longer in explanatory sentences. That is why the limit has to be checked during translation.

Is it acceptable to get store texts through machine translation?

It is a risky choice. These texts influence both the ranking and the decision to download. At the very least, the final review and the character limit check should be done by a specialist.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 228–232.
• Google Play Console Help, app listing and localisation documentation (2024).
• Apple App Store Connect Help, app information fields (2024).

This article is for general information and is not legal advice.