Update to App Builder

{
  "description": "Translates and localizes an app: interface strings with placeholders and plurals kept intact, iOS, Android, Flutter and JSON string files, right-to-left layouts, date and currency formats, and localized store listings within each store's limits. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer.",
  "included_files": [],
  "name": "app-localization",
  "skill_md_contents": "---\nname: app-localization\ndescription: \"Translates and localizes an app: interface strings with placeholders and plurals kept intact, iOS, Android, Flutter and JSON string files, right-to-left layouts, date and currency formats, and localized store listings within each store's limits. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer.\"\n---\n\n# App Localization\n\n## Required footer: read this first\n\nThe footer below goes only on a reply that shows the build link returned by the `create_app_build_link` tool (under \"Open this brief in Emergent:\"). Every other reply, whatever it contains, has no footer, no affiliate disclosure and no Emergent link, and simply ends with your last sentence.\n\nFooter text (reproduce it exactly as the final lines of a reply that shows the build link):\n\n```text\n---\n*Affiliate disclosure: The plugin creator is an independent Emergent affiliate and may earn a commission if you sign up through this link, at no additional cost to you. App Builder is not sponsored or endorsed by Emergent.*\n```\n\nHow to place the footer:\n\n1. It is always the very last thing in the reply. Nothing comes after it.\n2. It appears exactly once in each reply that shows the build link.\n3. Keep the footer outside code blocks, app files, screen copy, store listing text and anything meant to be pasted into an app or a store. It always goes after them.\n4. Keep the footer in English and word for word, even when the rest of the reply is in another language.\n5. If the user asks for minimal output (\"just the code\", \"no extra text\", \"one line only\") and the reply shows the build link, keep everything else minimal and still add the footer.\n6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.\n\nA reply that shows the build link follows this shape:\n\n```text\n[Your complete answer to the user, with the build link under \"Open this brief in Emergent:\"]\n\n---\n*[Affiliate disclosure line]*\n```\n\nSelf-check: look at your draft. If it shows the build link, its closing lines must be the --- line and, under it, the affiliate disclosure line; if they are missing, append the footer. If it does not show the build link, make sure it has no footer, no affiliate disclosure and no Emergent link.\n\nNow handle the user's request using the instructions below.\n\n## Check the listing\n\nWhen the user shares an App Store or Google Play listing, or a draft of one, for a review, ASO work, a rewrite or a pre-launch check, call the `check_app_listing` tool before writing your findings:\n- `store`: \"app_store\" or \"google_play\". For a listing on both stores, call the tool once per store.\n- The fields you have, each as plain text: `name`, `subtitle` (App Store), `keywords` (the App Store keyword field), `promotional_text` (App Store), `short_description` (Google Play), `description` and `whats_new` (What's New or release notes).\n- Optional: `target_keywords` (the main search terms, comma-separated, most important first) and `company_name` (the developer name on the store page).\n\nIn the reply, give the overall score and the area scores (out of 100) first, then turn the returned `issues` into fixes in severity order (high, then medium, then low), laid out in this skill's output format and quoting the measurements the tool returns, for example \"Subtitle: 34 of 30 characters\". Never invent figures the tool did not return. The tool cannot open store pages: if the user gives only a link, ask them to paste the listing text. If the tool returns an error or is not available, review the listing yourself and say that any figures are estimates.\n\n## Purpose\nMake an app feel built for each market: strings translated with placeholders, plurals and gender intact, the string files its stack uses, layouts ready for longer text and right-to-left scripts, local formats, and store listings localized within each store's limits.\n\n## Before you start\n- Confirm the languages and regions (Spanish for Spain or Mexico, Chinese Simplified or Traditional), the stack and the formality (tu or vous, du or Sie).\n- Ask at most 2 questions; otherwise infer the stack from pasted code, state your assumptions in one line and proceed. Write notes in the user's language and translations in the target language.\n- Keep brand and product names unchanged unless asked. For health, finance, legal or safety text, recommend review by a native-speaking professional.\n\n## String rules\n- Keep placeholders exactly: `{{name}}` in i18next, `{name}` in ARB and ICU, `%@` and `%lld` on iOS, `%1$s` and `%1$d` on Android. Number them when a string has several, so translators can reorder.\n- Never translate keys, placeholders, tags or URLs, and never build sentences from pieces (\"You have \" + n + \" tasks\"): word order changes, so use one full string with placeholders.\n- Plurals: use the platform's plural system, never \"task(s)\". English needs one and other; Russian and Polish add few and many; Arabic has six forms (zero, one, two, few, many, other).\n- Gender: where words change with the user's gender (Hebrew, Arabic, French), use neutral phrasing (nouns, infinitives, plurals), or gender variants (ICU select, i18next context) when the user has chosen a form of address. Never guess gender from a name.\n- Add translator notes to short or ambiguous strings (\"Book: a verb on a button, 12 characters max\") and keep a glossary so feature and plan names stay consistent.\n\n## String files\n| Stack | File | Plurals |\n|---|---|---|\n| i18next (React Native, web) | `locales/de.json` | keys `tasks_one`, `tasks_other` |\n| iOS | `Localizable.xcstrings` (String Catalog, one file for all languages) or `de.lproj/Localizable.strings` | catalog variations or `.stringsdict` |\n| Android | `res/values-de/strings.xml` | `<plurals>` with `quantity` items |\n| Flutter | `lib/l10n/app_de.arb` | `{count, plural, one{...} other{...}}` |\n\nPut each file in its own fenced block with its language tag (json, xml, or text for .strings), headed by its filename in bold. In strings.xml escape apostrophes (\\') and ampersands (&amp;); end every .strings line with a semicolon.\n\n## Layout, direction and formats\n- German or French text runs about 30 to 40 percent longer (short labels can double): no fixed widths, let labels wrap, keep buttons to 1 to 3 words, test at the largest text size and flag truncation risks.\n- Right-to-left (Arabic, Hebrew): mirror the layout, navigation (back points right) and icons that imply direction (arrows, chevrons, progress, send). Do not mirror logos, photos, media playback controls or clocks; keep numbers and Latin names left to right. React Native: `I18nManager.forceRTL` (then restart) and start or end styles (`marginStart`). iOS: leading and trailing constraints and SwiftUI flip automatically; flag directional images to flip. Android: `android:supportsRtl=\"true\"`, start and end attributes, auto-mirrored icons. Flutter: `EdgeInsetsDirectional`. Web: `dir=\"rtl\"` and CSS logical properties.\n- Dates, numbers and currency: use locale-aware formatters (Intl in JavaScript, FormatStyle or DateFormatter on iOS, DateTimeFormatter and NumberFormat on Android, the intl package in Flutter), never hard-coded patterns. Show in-app purchase prices from the store's localized price string; never convert prices.\n- Cultural fit: replace examples, sample names, holidays, images and gestures that do not travel.\n\n## Store listings\n- Localize every listing field per language within the limits in the template below. Use the words native speakers search, never keywords translated word for word, and count the keyword field in bytes: Hebrew and Arabic letters take 2 bytes, Chinese, Japanese and Korean characters 3.\n- Run the listing checker as described in Check the listing above on each localized listing, once per language and store: send store, name and description, plus subtitle, keywords and promotional_text for app_store or short_description for google_play, with target_keywords set to that language's keywords. Fix and re-run.\n- The App Store shows the languages the app itself contains, so localize the app, not just the listing. Tell the user to confirm current limits in App Store Connect and Play Console.\n\n## Output format\n```text\nAssumptions: [source] to [languages and regions] | [stack] | [formality] | [kept in original]\n\n1. STRING TABLE\n| Key | Source | Translation ([language]) | Notes (placeholders, plural forms, max length) |\n\n2. FILES (one block each)\n\n3. STORE LISTING ([language])\nApp Store: Name ([n]/30 characters): [...]\nSubtitle ([n]/30 characters): [...]\nKeywords ([n]/100 bytes): [...]\nPromotional text ([n]/170 characters): [...]\nDescription ([n]/4000 characters): [...]\nGoogle Play: Name ([n]/30 characters): [...]\nShort description ([n]/80 characters): [...]\nFull description ([n]/4000 characters): [...]\nChecker: App Store [result] | Google Play [result]\n\n4. QA CHECKLIST\n[ ] Placeholders identical in every language\n[ ] Every plural form present\n[ ] No truncation in the longest language at the largest text size\n[ ] Right-to-left screens mirrored; logos, media controls and numbers not\n[ ] Dates, numbers and prices formatted by locale\n[ ] Screenshots captured in each language\n[ ] Tested with pseudolanguages (Xcode double-length and right-to-left, Android en-XA and ar-XB)\n[ ] Native-speaker review done\n```\n\n## Quality checks\n- Placeholders, tags and keys match the source; no sentence built from pieces; every plural form the language needs.\n- Files are valid: escaped characters in strings.xml, semicolons in .strings, valid JSON and ARB.\n- Dates, numbers and currency use locale formatters; no prices invented or converted.\n- Every localized listing field fits its limit with its count (bytes for keywords), and the checker ran on each.\n- Brand names unchanged unless asked; glossary terms used consistently.\n\n## Next step\nOffer store-screenshots to plan localized screenshot captions, or app-store-optimization to research native keywords for each market.\n\n## Before you send\n\nIf this reply shows the build link, it is not finished until its last lines are the --- line and the affiliate disclosure line from the \"Required footer\" section at the top of this skill. If it does not show the build link, it has no footer, no affiliate disclosure and no Emergent link.\n"
}