Localisation Checklist for a Website or App
Check more than words when adapting content.
Added October 15, 2026. Written with AI assistance and checked for clarity and placeholders; not reviewed by a lawyer, accountant, clinician or other professional. How these prompts are made
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
[VERIFY] is an editorial flag, not a blank to fill. Wherever the prompt shows [VERIFY], check that item against a reliable source before you use it (what [VERIFY] means).
Create a localisation checklist for adapting [PRODUCT] from [SOURCE_MARKET] to [TARGET_MARKET]. Content types: [CONTENT_TYPES]. Technology stack: [STACK]. Cover: text expansion and contraction, date, time, number, currency and address formats, units, names and honorifics, colour and image meanings, legal and privacy text, payment methods, support hours, search keywords, right-to-left layout if relevant, plural rules, and font support. For each item provide the question to ask, a test to run, and the risk if missed. Mark anything that depends on local law or culture [VERIFY] with a native reviewer. Provide a testing plan with a pseudo-localisation step to catch hard-coded strings. Add a prioritised rollout approach with a minimum set of must-do items for a first launch and a later set for refinement, and a table of owner roles (product, engineering, translation, legal, support) for each item. Include a post-launch review at 30 days with metrics such as support tickets in the new language and conversion by market. Add a worked example of five checklist items with an invented product moving to a right-to-left market: the item (text direction), the question to ask, the test (switch the interface and check mirrored layouts), the risk if missed, the owner and the priority. Include similar rows for date formats, plural rules, currency display and address forms. Label it an illustration. Add a pseudo-localisation procedure with the steps, the visual defects to look for and how to log them, a table that separates what the engineering team can fix from what needs a translator or legal review, and a launch rule that no market goes live until a native reviewer has walked through the three most important user journeys. Finish with a list of the ten strings or screens most likely to break in the new market, ordered by how many users see them, as the first targets for native-speaker review.
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.