Automatically translate and sync App Store metadata (description, keywords, what's new, subtitle) to multiple languages using LLM translation and asc CLI. Use when asked to localize an app's App Store listing, translate app descriptions, or add new languages to App Store Connect.

asc localize metadata Use this skill to pull English (or any source locale) App Store metadata, translate it with LLM, and push translations back to App Store Connect — all automated. Command discovery and output conventions Always confirm flags with help for the exact asc version: asc localizations help asc localizations download help asc localizations upload help asc apps info edit help Prefer explicit long flags ( app , version , version id , type , app info ). Output defaults are TTY aware: table in interactive terminals and JSON in CI or other non interactive contexts. Use explicit output when the format matters. Prefer deterministic ID based operations. Do not "pick the first row" via head 1 unless the user explicitly agrees. Preconditions Auth configured ( asc auth login or ASC env vars) Know your app ID ( asc apps list to find it) At least one locale (typically en US) already has metadata in App Store Connect Supported Locales App Store Connect locales for version and app info localizations: Two Types of Metadata Version Localizations (per release) Fields: description , keywords , whatsNew , supportUrl , marketingUrl , promotionalText App Info Localizations (app level, persistent) Fields: name , subtitle , privacyPolicyUrl , privacyChoicesUrl , privacyPolicyText Workflow Step 1: Resolve IDs Notes: Version localization fields (description, keywords, whatsNew, etc.) are per version. App info fields (name, subtitle, privacy URLs/text) are app level and use type app info . If you only have names (app name, version string) and need IDs deterministically, use asc id resolver . Step 2: Download source locale This creates files like ./localizations/en US.strings and ./app info localizations/en US.strings . If download is unavailable, read fields individually: Step 3: Translate with LLM For each target locale, translate the source text. Follow these rules: Translation Guidelines Tone & Register : Always use formal, polite language. Use formal "you" forms where the language distinguishes them (Russian: «вы», German: «Sie», French: «vous», Spanish: «usted», Dutch: «u», Italian: «Lei», Portuguese: «você» formal, etc.). App Store descriptions are professional marketing copy — never use casual or informal register. description : Translate naturally, adapt tone to local market. Keep formatting (line breaks, bullet points, emoji). Stay within 4000 chars. keywords : Do NOT literally translate. Research what users in that locale would search for. Comma separated, max 100 chars total. No duplicates, no app name (Apple adds it automatically). whatsNew : Translate release notes. Keep it concise. Max 4000 chars. promotionalText : Translate marketing hook. Max 170 chars. This can be updated without a new version. subtitle : Translate or adapt tagline. Max 30 chars — this is very tight, may need creative adaptation. name : Usually keep the original app name. Only translate if the user explicitly asks. Max 30 chars. LLM Translation Prompt Template For each target locale, use this approach: Step 4: Upload translations Option A: Via .strings files (bulk) Create a .strings file per locale in the appropriate directory. Version localization example: Then upload version localizations: App info localization example: Then upload app info localizations: Option B: Via individual commands (fine control) For app level fields: Step 5: Verify Character Limits (enforce before upload!) Field Limit Name 30 Subtitle 30 Keywords 100 (comma separated) Description 4000 What's New 4000 Promotional Text 170 Always validate translated text fits within limits before uploading. Truncated text looks unprofessional. If translation exceeds the limit, shorten it — do not truncate mid sentence. Full Example: Add nl NL and ru to Roxy Math Agent Behavior 1. Always start by reading the source locale — never translate from memory or assumptions. 2. Check existing localizations first — don't overwrite existing translations unless the user asks to update them. 3. Version vs app info is different — version fields live under version "VERSION ID" ; subtitle/name/privacy live under app ... type app info . 4. Prefer deterministic IDs — do not select IDs via head 1 unless explicitly requested; use output table for selection or asc id resolver . 5. Validate character limits before uploading. Count characters for each field. If over limit, re translate shorter. 6. Keywords are special — do not literally translate. Research locale appropriate search terms. Think like a user searching the App Store in that language. 7. Show the user translations before uploading — present a summary table of all fields × locales for approval. Do not push without confirmation. 8. Process one locale at a time if translating many languages — easier to review and catch errors. 9. If upload fails for a locale, log the error, continue with other locales, report all failures at the end. 10. For updates to existing localizations — download current, show diff of what will change, get approval, then upload. Notes Version localizations are tied to a specific version. Create the version first if it doesn't exist. promotionalText can be updated anytime without a new version submission. whatsNew is only relevant for updates, not the first version. Use asc id resolver skill if you only have app/version names instead of IDs. Use asc metadata sync skill for non translation metadata operations. For subscription/IAP display name localization, use asc subscription localization skill instead.

asc-localize-metadata