Release Notes Translation: The Unseen Text of App Updates

The most frequently written and least considered text in the app stores is the release note. It is filled in afresh with every update, is usually written at the last minute and is often left in the source language. Yet the translation of release notes is the most tangible sign a user has that the app is still being maintained.

Contents

Jiménez-Crespo shows that this field appears in store listings as a requirement in its own right. On the App Store side there is a what’s new in this version field, on the Google Play side a recent changes field, and a limit of 4,000 characters is given for both (2024, p. 228).

This article looks at why the release note needs to be translated, how it has to be written to be of any use, and how to set up a translation arrangement for frequently updated apps.

Where does the release note sit in the store?

The release note appears in the middle section of the app page and in update lists. Users usually look here before they update the app. Even when automatic updates are switched on, a user who notices that a behaviour has changed comes here for the explanation.

The size of the field is misleading. Four thousand characters is a generous allowance, but the store interface shows only the first few lines. The rest stays behind a link. In practice, then, the amount of effective text that can be written is well below the limit.

This affects the translation decision as well. If the source text has been written as a long list, the most important item has to be moved to the top in the Turkish version. Changing the order here is not unfaithfulness; it is preserving the function.

The field is also specific to each version. The content changes with every new release and the previous text passes into the history. That means a rhythm different from the store description: the description can stay unchanged for months, while the release note is produced afresh with every release.

Why does it need to be translated?

The first reason is visibility. The book states that store ranking is determined by updates as well as by download numbers, ratings and reviews (Jiménez-Crespo 2024, p. 229). Publishing an update is a signal; presenting the text of that update in the target language completes the signal.

The second reason is consistency. In an app whose interface and store description are in Turkish, a release note left in English gives the impression that the localisation was abandoned halfway. The impression looks slight, but it erodes trust.

The third reason is the support burden. When a behaviour changes, the user either reads the note or writes to support. A clear note in Turkish closes off part of the incoming questions before they even form.

The fourth reason is internal use. Over time, release notes build up a short history of the app. When the team changes, or when the app opens up to a new market, this record is the most practical document showing which feature arrived when. It makes the work easier if the Turkish version carries the same history.

How is a good release note written?

A good release note speaks the user’s language. Bug numbers, component names and internal terms are of no use in store text. The user wants to learn what has changed and what it means for them, not where the code was fixed.

Approach	Developer language	User language
Bug fix	Component name and ticket number	Which operation now works properly
New feature	Technical name	The name shown in the interface
Performance	Measurement terms	What has become faster
Compatibility	Version numbers	Which devices it runs on
Removed feature	Passed over in silence	Stated openly

The last row of the table matters. Hiding a removed feature in the release note is the fastest route to negative reviews. Owning the change and giving a brief reason for it usually draws less reaction than silence does.

From the translation side, this means the source text can be questioned. A note written in developer language stays just as incomprehensible when it is carried word for word into Turkish. The right course in that case is to ask the person who wrote it before translating the text.

An arrangement for release notes translation under frequent releases

The release note is the highest-frequency work item in app localisation. For a team that ships weekly, it means more than fifty small packages a year. Producing a separate quote, a separate order and a separate invoice for each package is not manageable.

Release notes are therefore usually handled through a standing arrangement. A monthly framework agreement, a fixed turnaround time and a single channel of communication are set up. What determines the cost is not how small the work is, but how regular it is.

The turnaround time also has to fit the release schedule. Changing the text after the app has been submitted for review usually means a fresh submission. A reasonable rule is that the translation of the note should be ready at least one day before submission.

The book notes that app files can be sent either directly or through cloud platforms (Jiménez-Crespo 2024, p. 228). The second route suits release notes better; moving small pieces of text around by exchanging files creates needless friction. You can look at our knowledge centre for the process options.

Repeated sentences and the use of memory

Release notes are highly repetitive texts. Sentences such as stability improvements, minor bug fixes and better performance stay almost identical from one version to the next. This is one of the content types on which translation memory works most efficiently.

The book notes that separating localisable content into resource files allows translation memory to be shared and speeds the process up (2024, p. 229). The same logic holds for store texts; once a shared memory is in place, repeated sentences become free of charge.

In practice this brings the cost of release note translation down markedly after a few versions. The memory fills up over the first three or four releases; after that, only the genuinely new sentences are translated. It is worth discussing this arrangement with your supplier from the outset.

For the memory to be of use, the source text has to be written consistently too. A source that expresses the same meaning with a different sentence in every version lowers the match rate. A simple template reduces both writing time and translation cost at once.

The link between the release note and the interface

The name of a new feature introduced in the release note has to be exactly the same inside the app. If one name is used in the note and another in the menu, the user will not find the feature where they look for it. This is the basic reason why release note translation cannot be done independently of interface translation.

The sequence matters as well. If the release note is written before the interface strings are approved, the name used in the note may change later. The right sequence is for the interface terms to be settled first, and for the note to be written and translated afterwards.

The same principle holds for support content. Help pages and frequently asked questions have to refer to the new feature by the same name. If a user moving from the release note to a help page meets a different term, they cannot be sure they are on the right page.

This link takes in the store description too. If the new feature is going into the description as well, the same name is used a third time. Tying all three texts to a single term record removes the corrections that would otherwise have to be made later.

What happens when no note is written?

The release note cannot be left empty, but it can be filled with nothing. The common solution is to repeat the same generic sentence in every version. Technically that is a faultless release; in communication terms it is saying nothing at all. After a while the user stops reading the field.

The second and more damaging scenario is the note being left in the source language. Seeing an English update text in a Turkish listing gives the impression that the Turkish version of the app is not a priority in its own right. Once that impression is voiced in the reviews, it is hard to put right.

The third risk is getting the note out of the way with machine translation. With short, formulaic sentences the result often looks acceptable, but when feature names are translated wrongly the link with the interface breaks. The user cannot find the name read in the note anywhere in the menu.

The fourth risk is the note being copied from the source text and never updated. When the previous version’s text is left as it stands, the user learns the content of the published update wrongly. This mistake is seen especially in teams that release often, and it produces no warning at all on the store side; only the user notices.

What these three scenarios have in common is that the problem looks small. Taken one at a time, none of them is critical; accumulated, they form an impression of the localisation quality of the app.

The Türkiye context

In Turkish user reviews, the reaction to changes made after an update is quick. When a button moves in the interface, a single line of note announcing it usually prevents a drop in the rating. In this market the release note is a tool for managing expectations.

On the language side, set phrases call for care. The short, cheerful register of the source language can sound artificial when it is carried word for word into Turkish. Taking a separate decision about register for the release note makes it possible to strike a more natural tone without disturbing the register of the interface.

The third subject is changes concerning personal data. If the app begins asking for a new permission, or if the scope of data processing changes, this has to be stated comprehensibly in the release note. The principal obligation under the KVKK lies in the privacy notice; silence in the release note, however, can turn into a problem of trust.

Lastly there are date and number formats. Dates appearing in the release note should be set out according to Turkish writing conventions, while version numbers should be left exactly as they are. The distinction looks small, but applied inconsistently it makes the text look careless.

What does this mean for you?

The release note is one of the localisation items that returns the most for the smallest budget. The sequence below makes the work sustainable.

1. Create a permanent template for the release note and use the same structure in every version.
2. Have the note written from the user’s point of view, not from the developer log.
3. Do not send the note for translation before the interface terms are settled.
4. Set up a shared translation memory for the sentences that repeat.
5. Fix a set turnaround time through a monthly framework agreement.
6. State changes to permissions and to the scope of data openly in the note.

Setting this arrangement up is a few hours of preparation. For regular release notes translation you can request a quote, and you can look at how we work on our services page.

Frequently asked questions

Which field holds the release note in the store?

On the App Store side the what’s new in this version field is used, and on the Google Play side the recent changes field. In the listing given in the book, a limit of 4,000 characters is stated for both fields.

Is translating the release note really necessary?

The book states that store ranking is related to updates as well. The note is also the only place where a user sees that the app is being maintained. Left untranslated, the localisation looks incomplete.

Is a new translation needed for every version?

Most of the text repeats from one version to the next. When translation memory is used, only the new sentences are translated, which brings both cost and time down markedly.

Should we put technical details in the release note?

Usually not. The user is interested not in the bug number but in whether the problem has been solved. The technical breakdown should stay in internal records, and the store note should be written in the user’s language.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 228–229.
• Google Play Console Help, documentation on release notes and release management (2024).
• Apple App Store Connect Help, version information fields (2024).

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