Contents
Outline
On the Google Play Console, the “What’s new in this release” field is capped at 500 characters per language. If you write English release notes with one line per change, it’s easy to exceed this limit. If you try to upload through fastlane supply or other automation tools while over the limit, the upload itself will fail — so you need the discipline to keep the limit in mind while writing the notes.
This post walks through the trimming strategy I used in a real case where Korean notes went from 512 → 482 characters and English notes from 890 → 406 characters, all to fit multilingual release notes within the limit.
The 500-Character Limit on Google Play Release Notes
The “What’s new in this release” field on the Google Play Console allows up to 500 characters per language (whitespace and newlines included). If you exceed the limit, the console UI shows an immediate red warning, and uploading via fastlane / Play Developer API fails with an error like the following:
The release notes for language 'en-US' are too long. Limit is 500 characters.The limit is applied independently for each language. Even if your Korean notes are within the limit, the entire release will be rejected if the English notes go over — so all languages must be verified at the same time.
Character Count Asymmetry Across Languages
When you maintain notes in Korean and English simultaneously, you quickly notice that English takes much more space to express the same meaning. Here’s a comparison of the same change written as a single line:
# Korean (one line)
복습 결과 화면에서 정답 단어의 한자 상세 정보를 바로 확인할 수 있도록 개선했습니다.
# → about 42 characters
# English (one line)
Improved the review result screen to let you view kanji details of the correct word directly.
# → about 95 charactersEnglish is roughly 2 to 2.5 times longer than Korean. As a result, English hits the limit first as the number of items grows. In the actual case, the Korean notes were 512 characters for 12 items (slightly over the limit), but the English notes were 890 characters for the same 12 items (1.78× the limit).
This asymmetry directly shapes how you write the notes:
- Korean: removing 1–2 items is enough to fit → keep the “one line = one item” rule
- English: removing items isn’t enough → you need to group related items together
How to Count Characters
First you need to know exactly how many characters your notes currently have. The wc -m command on macOS / Linux returns the character count including newlines, which is exactly what you need to verify against the limit.
# Character count per language
for f in release_notes/*.txt; do
printf "%-25s %4d chars\n" "${f}" "$(wc -m < "${f}")"
doneExample output:
release_notes/en.txt 890 chars
release_notes/ja.txt 431 chars
release_notes/ko.txt 512 charsUse wc -m (character count), not wc -c (byte count) — this counts each Korean or Japanese character as one. In a UTF-8 environment, wc -m may return the byte count if the locale is set to a non-UTF-8 English locale, so verify that a UTF-8 locale like LANG=en_US.UTF-8 is set.
Trimming Strategies
Hitting 500 characters isn’t just about cutting items — it’s an editing job that preserves user value while shrinking the length. I combine two strategies.
Strategy 1. Drop Items With Low User Impact
If you’re only slightly over the limit (like the Korean case), removing one or two items is the simplest fix. To decide which items to drop, I use this priority:
- Start with locale-specific changes that don’t affect users of other languages.
- Next, drop internal changes users can’t easily notice (label normalization, minor wording adjustments).
- Try to keep bug-fix items. Release notes also serve as a channel for users to check whether the new version solves their particular issue.
In the actual case, I dropped this Korean line: 한국어 문제 유형 라벨 표기 형식을 통일했습니다. (“Unified the format of quiz type labels in Korean”). It satisfies both conditions: it’s a ko-only change, and users can’t really tell the difference in label format.
Strategy 2. Group Related Items
If you’re way over the limit (1.5× or more, like the English case), dropping items isn’t enough. You need to bundle multiple semantically related items into a single line. Some grouping criteria:
- Group by feature: “Three new review-screen options” → one line
- Group by platform: “Three iOS audio fixes” → one line
- Group by category: “Compatibility / stability / crash fixes” → one line
In the actual case, the English notes shrank from 12 items / 890 characters to 6 items / 406 characters. Here’s how the conversion looked:
# Before — one line per item
- Added per-quiz-type descriptions and display options to the review screen.
- Improved the review result screen to let you view kanji details of the correct word directly.
- Added an option to hide the pronunciation under the speaker in listening quiz types.
# After — grouped by feature
- New review options: per-quiz-type descriptions, kanji details on correct answer,
listening pronunciation hide.# Before — three separate iOS audio items
- Improved the voice filter to make more voices available on iOS.
- Fixed an issue on iOS where audio could cut off during auto-repeat playback.
- Fixed an issue where ads containing speech blocked the app's voice.
# After — grouped by platform
- iOS audio: more voices, no auto-repeat cut-off, ad blocking fix.Grouping is a powerful technique — it can cut length by more than half without losing information. That said, bundling too aggressively makes lines abstract and harder for users to grasp what actually changed, so cap each line at roughly 3–4 items.
Adding a Character-Count Gate to CI
Manually checking the 500-character limit every time invites mistakes. By adding a gate to CI that automatically verifies the length of all language notes, you can catch overruns before the release workflow is triggered.
#!/usr/bin/env bash
# scripts/verify_release_notes_length.sh
LIMIT=500
FAIL=0
for f in release_notes/*.txt; do
len=$(wc -m < "${f}")
if [ "${len}" -gt "${LIMIT}" ]; then
echo "FAIL: ${f} ${len} chars (> ${LIMIT})"
FAIL=$((FAIL + 1))
else
echo "OK: ${f} ${len} chars"
fi
done
if [ "${FAIL}" -eq 0 ]; then
echo "RESULT: PASS"
exit 0
else
echo "RESULT: FAIL (${FAIL} files over limit)"
exit 1
fiPlace this verification step just before the release build in your GitHub Actions workflow:
# .github/workflows/release_android.yml
- name: Verify release notes length
run: bash scripts/verify_release_notes_length.shWith this in place, if someone adds a new item that pushes the notes over the limit, CI fails before the release proceeds — giving much faster feedback than discovering the overrun at the fastlane upload step after a tag has already been pushed.
Wrap-Up
The per-language 500-character limit on Google Play is a constraint you frequently run into when automating release notes. To summarize what we covered:
- The limit is independent per language, so all languages must be verified at the same time.
- English takes roughly 2× the space of Korean / Japanese for the same meaning, so it’s common for English to bust the limit even when Korean passes.
- Use
wc -mto count characters accurately. Verify your UTF-8 locale. - Slightly over the limit: drop items with low user impact (locale-only, internal changes) first.
- Way over (1.5× or more): group related items by feature / platform / category. Cap each line at 3–4 items.
- Don’t rely on manual counting — add a character-count gate to CI so overruns are caught before the release proceeds.
Release notes are the most direct channel for telling users what changed in a new version. Maximizing information value within 500 characters isn’t just a length-cutting exercise — it’s an opportunity to reorganize change priorities from the user’s perspective.
References
- Google Play Console — Add release notes
- fastlane supply — Upload metadata, screenshots and binaries to Google Play
Was my blog helpful? Please leave a comment at the bottom. it will be a great help to me!
App promotion
Deku.Deku created the applications with Flutter.If you have interested, please try to download them for free.
