Back to Details

localize

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Localize — Design Across Cultures

本地化——跨文化设计

Overview

概述

Localization is not translation. Translation converts words; localization adapts the experience.
When a product enters a new market, everything is in play: information density, navigation patterns, color meaning, icon comprehension, date formats, trust signals, payment flows, legal compliance, and the fundamental assumptions about how people make decisions. A checkout flow designed for US consumers doesn't become a Japanese experience by translating the strings. A trust-building pattern that works in Germany may be irrelevant in Brazil and offensive in Saudi Arabia.
Design for localization from the start, or pay for it exponentially later. Retrofitting RTL support, plural rules, and cultural adaptation into a product that assumed English-speaking Western users is one of the most expensive kinds of design debt.
When to activate this skill: International expansion planning, i18n readiness audits, new market entry design, RTL adaptation, cultural review of existing designs, localization testing strategy, or anytime someone says "just translate it" and the problem is deeper than language.
本地化不等于翻译。翻译只是转换文字，而本地化是适配整个体验。
当产品进入新市场时，所有环节都需要考量：信息密度、导航模式、色彩含义、图标理解、日期格式、信任信号、支付流程、合规要求，以及人们做决策的基本假设。为美国消费者设计的结账流程，不会因为翻译文字就变成适合日本用户的体验。在德国有效的信任构建模式，在巴西可能无关紧要，在沙特阿拉伯甚至可能冒犯用户。
从一开始就为本地化做设计，否则后续会付出指数级的成本。为原本假设面向英语母语西方用户的产品， retrofit RTL支持、复数规则和文化适配，是最昂贵的设计债务之一。
激活该技能的场景： 国际扩张规划、i18n就绪审计、新市场进入设计、RTL适配、现有设计的文化审查、本地化测试策略，或者每当有人说“只需翻译一下”但问题远不止语言层面的时候。

Skill family

技能体系

Localize works alongside the full Intent skill system:
  • /articulate
    : Everything they write will be localized. Content strategy must design for translation from the start — sentence structure, concatenation, tone, humor, idiom. If the English copy is clever, the localized copy may be incomprehensible. Articulate designs translatable content; localize ensures it survives translation.
  • /organize
    : Navigation and labeling may need cultural adaptation. Category structures that make sense in one culture may be arbitrary in another. Menu labels that are concise in English may expand to unwieldy lengths in German or Finnish.
  • /fortify
    : i18n technical readiness — text expansion breaking layouts, RTL rendering bugs, date/number format parsing failures, character encoding issues. Fortify maps the failure modes; localize defines the requirements that prevent them.
  • /strategize
    : Market analysis and audience definition per locale. Which markets, in what order, with what level of adaptation? 
    /strategize
    defines the business case; 
    /localize
    defines the design implications.
  • /investigate
    : Cultural research methods for unfamiliar markets. When your assumptions about a market are based on stereotypes rather than evidence, investigate plans the research to validate or challenge them.
  • /philosopher
    : A cross-cutting cognitive mode for confronting invisible assumptions. Invoke when: your design team is monocultural and can't see its own biases, the "obvious" user flow is obvious only to people from your culture, or you need the question: "What cultural assumptions are invisible to us because we're inside them?"
Localize与完整的Intent技能系统协同工作：
  • /articulate
    ：产出的所有内容都将被本地化。内容策略必须从一开始就为翻译做设计——句子结构、拼接方式、语气、幽默表达、习语。如果英文文案过于巧妙，本地化后的文案可能会让人难以理解。Articulate设计可翻译的内容；Localize确保内容在翻译后仍能传递原意。
  • /organize
    ：导航和标签可能需要文化适配。在一种文化中合理的分类结构，在另一种文化中可能显得随意。英文中简洁的菜单标签，在德语或芬兰语中可能会变得冗长不堪。
  • /fortify
    ：i18n技术就绪性——文本扩展导致布局破裂、RTL渲染bug、日期/数字格式解析失败、字符编码问题。Fortify梳理故障模式；Localize定义预防这些问题的需求。
  • /strategize
    ：针对各地区的市场分析和受众定义。优先进入哪些市场，以何种顺序，适配程度如何？
    /strategize
    定义商业案例；
    /localize
    定义设计影响。
  • /investigate
    ：针对陌生市场的文化研究方法。当你对某个市场的假设基于刻板印象而非证据时，investigate会规划研究以验证或挑战这些假设。
  • /philosopher
    ：用于应对隐性假设的跨领域认知模式。在以下场景调用：设计团队单一文化背景，无法看到自身偏见；“显而易见”的用户流程仅对来自自身文化的人来说显而易见；或者你需要提出问题：“哪些文化假设因为我们身处其中而无法察觉？”

Core capabilities

核心能力

1. Cultural dimension analysis for UX

1. UX文化维度分析

Cultural frameworks provide starting hypotheses for design adaptation — not stereotypes to design by. Use them to generate questions, then validate with research.
High-context vs. low-context communication:
  • High-context cultures (Japan, China, Arab countries, Korea): communication is implicit, relationships matter before transactions, visual density is expected (not cluttered), social proof and authority signals carry weight, indirectness is politeness.
  • Low-context cultures (US, Germany, Scandinavia, Netherlands): communication is explicit, task-first flows are preferred, minimal UI is valued, direct calls to action work, users expect to self-serve.
  • UX implications: onboarding flows, help text density, social features, the balance between guidance and autonomy.
Power distance:
  • High power distance: formal tone, hierarchical navigation, respect for authority in copy ("Approved by Dr. [Name]"), institutional trust signals.
  • Low power distance: informal tone, flat navigation, peer trust signals ("1,000 users like you chose this"), egalitarian messaging.
  • UX implications: form of address, tone of voice, error messages, authority signals.
Individualism vs. collectivism:
  • Individualist cultures: personal accounts, individual preferences, "my" dashboard, solo decision-making flows.
  • Collectivist cultures: family/group accounts, shared decision-making, social features, gift-giving flows, group purchase patterns.
  • UX implications: account models, sharing features, decision-making flows, social proof patterns.
Uncertainty avoidance:
  • High uncertainty avoidance (Japan, Germany, Greece): detailed explanations, confirmation steps, progress indicators, safety nets, explicit guarantees.
  • Low uncertainty avoidance (Singapore, Denmark, UK): tolerance for ambiguity, fewer confirmation steps, willingness to explore, comfort with uncertainty.
  • UX implications: how much guidance to provide, number of confirmation steps, error prevention vs. error recovery.
Long-term orientation:
  • Long-term oriented cultures: loyalty programs resonate, subscription models accepted, trust built gradually, relationship-first onboarding.
  • Short-term oriented cultures: immediate value expected, trial-first models, quick wins, instant gratification patterns.
IMPORTANT: These are spectrums and tendencies, not rules. Every individual is different. Every market has subcultures. Never design for a stereotype. Use these dimensions to generate hypotheses, then validate with 
/investigate
research and 
/measure
data from real users in the target market.
文化框架为设计适配提供初始假设——而非刻板设计依据。用它们生成问题，再通过研究验证。
高语境vs低语境沟通：
  • 高语境文化（日本、中国、阿拉伯国家、韩国）：沟通含蓄，交易前先建立关系，视觉密度是预期的（而非杂乱），社交证明和权威信号重要，间接表达是礼貌。
  • 低语境文化（美国、德国、斯堪的纳维亚、荷兰）：沟通直接，优先任务导向流程，推崇极简UI，直接行动号召有效，用户期望自助服务。
  • UX影响：引导流程、帮助文本密度、社交功能、引导与自主的平衡。
权力距离：
  • 高权力距离：正式语气、层级化导航、文案中体现对权威的尊重（如“经[姓名]博士批准”）、机构信任信号。
  • 低权力距离：非正式语气、扁平化导航、 peer信任信号（如“1000名和你一样的用户选择了这个”）、平等主义信息。
  • UX影响：称呼方式、语气、错误提示、权威信号。
个人主义vs集体主义：
  • 个人主义文化：个人账户、个人偏好、“我的”仪表盘、单人决策流程。
  • 集体主义文化：家庭/群组账户、共享决策、社交功能、送礼流程、团购模式。
  • UX影响：账户模型、分享功能、决策流程、社交证明模式。
不确定性规避：
  • 高不确定性规避（日本、德国、希腊）：详细说明、确认步骤、进度指示器、安全保障、明确承诺。
  • 低不确定性规避（新加坡、丹麦、英国）：容忍模糊性、更少的确认步骤、愿意探索、适应不确定性。
  • UX影响：提供多少引导、确认步骤数量、错误预防vs错误恢复。
长期导向：
  • 长期导向文化：忠诚度计划有共鸣，订阅模式被接受，信任逐步建立，关系优先的引导流程。
  • 短期导向文化：期望即时价值，试用优先模式，快速见效，即时满足模式。
重要提示： 这些是范围和趋势，而非规则。每个个体都不同，每个市场都有亚文化。永远不要基于刻板印象做设计。用这些维度生成假设，然后通过
/investigate
的研究和
/measure
的目标市场真实用户数据验证。

2. RTL and LTR design

2. RTL与LTR设计

Right-to-left layout is not mirroring. It requires understanding what flips, what doesn't, and what needs rethinking.
What flips:
  • Layout direction: content flows right-to-left
  • Text alignment: right-aligned by default
  • Navigation order: back arrow points right, forward points left
  • Progress indicators: fill from right to left
  • Swipe directions: next is left-to-right, previous is right-to-left
  • Slider direction: min on right, max on left
  • Icon direction: icons that imply direction (arrows, reply, share) flip
What does NOT flip:
  • Numbers and phone numbers (always LTR within their container)
  • Media playback controls (play/pause/skip are universal)
  • Clock direction
  • Brand logos
  • Universal icons (play, pause, close, add)
  • Checkmarks and toggles (debated, but generally don't flip)
Bidirectional text: When RTL and LTR content mix — Arabic text with English brand names, code snippets, URLs, email addresses — the Unicode Bidirectional Algorithm handles most cases, but edge cases require manual intervention with directional markers. Test with real mixed-direction content, not lorem ipsum.
CSS implementation principles:
  • Use logical properties: 
    inline-start
    /
    inline-end
    instead of 
    left
    /
    right
    , 
    block-start
    /
    block-end
    instead of 
    top
    /
    bottom
  • Use 
    dir="rtl"
    on the root element, not CSS transforms
  • Flexbox and Grid handle direction automatically with logical properties
  • Absolute positioning and transforms need manual attention
Testing RTL:
  • Test with actual RTL users, not just mirrored screenshots
  • Test with real Arabic/Hebrew content, not reversed English
  • Test bidirectional content: Arabic paragraphs with English terms, numbers, URLs
  • Test form inputs: cursor position, text selection, copy-paste behavior
从右到左（RTL）布局不是简单镜像。需要理解哪些元素要翻转，哪些不要，以及哪些需要重新设计。
需要翻转的元素：
  • 布局方向：内容从右到左流动
  • 文本对齐：默认右对齐
  • 导航顺序：返回箭头指向右，前进箭头指向左
  • 进度指示器：从右到左填充
  • 滑动方向：下一页是左滑，上一页是右滑
  • 滑块方向：最小值在右侧，最大值在左侧
  • 图标方向：带有方向含义的图标（箭头、回复、分享）翻转
不需要翻转的元素：
  • 数字和电话号码（在容器内始终为LTR）
  • 媒体播放控件（播放/暂停/跳过是通用的）
  • 时钟方向
  • 品牌标志
  • 通用图标（播放、暂停、关闭、添加）
  • 勾选标记和切换按钮（存在争议，但通常不翻转）
双向文本： 当RTL和LTR内容混合时——阿拉伯文本搭配英文品牌名、代码片段、URL、电子邮件地址——Unicode双向算法会处理大多数情况，但边缘案例需要使用方向标记手动干预。用真实的混合方向内容测试，不要用占位文本。
CSS实现原则：
  • 使用逻辑属性：用
    inline-start
    /
    inline-end
    代替
    left
    /
    right
    ，用
    block-start
    /
    block-end
    代替
    top
    /
    bottom
  • 在根元素上使用
    dir="rtl"
    ，而非CSS变换
  • Flexbox和Grid配合逻辑属性可自动处理方向
  • 绝对定位和变换需要手动调整
RTL测试：
  • 与实际RTL用户一起测试，不要只看镜像截图
  • 用真实的阿拉伯语/希伯来语内容测试，不要用颠倒的英语
  • 测试双向内容：带有英文术语、数字、URL的阿拉伯语段落
  • 测试表单输入：光标位置、文本选择、复制粘贴行为

3. Content adaptation beyond translation

3. 超越翻译的内容适配

Translation converts words. Content adaptation converts meaning, structure, and formatting.
Text expansion and contraction:
  • German expands ~30% from English. Finnish ~40%. Some compounds create single words that are 30+ characters.
  • Chinese and Japanese can compress 30-50% from English character count (but may need more vertical space due to character complexity).
  • Layout MUST accommodate expansion without breaking. Test with pseudo-localized strings at 150% length as a minimum.
String concatenation is the enemy: "Hello {name}, you have {n} items in your cart" breaks in almost every language. Word order changes. Pluralization rules differ. Gender agreement is required. Use proper i18n libraries with ICU MessageFormat. Never build sentences by concatenating variables.
Pluralization:
  • English: 2 forms (1 item, 2 items)
  • Arabic: 6 forms (zero, one, two, few, many, other)
  • Polish: 4 forms with complex rules
  • Chinese/Japanese/Korean: 1 form (no grammatical plural)
  • Use CLDR plural rules, not "if count != 1, add 's'"
Date and time:
  • MM/DD/YYYY (US) vs. DD/MM/YYYY (most of world) vs. YYYY-MM-DD (ISO/East Asia)
  • 12-hour (US, UK, Australia) vs. 24-hour (most of world)
  • Week starts Monday (ISO, most of world) vs. Sunday (US, Israel, some Middle Eastern countries)
  • Use locale-aware formatting libraries. Never hardcode date formats.
Numbers:
  • 1,000.00 (US, UK) vs. 1.000,00 (Germany, Brazil) vs. 1 000,00 (France, Sweden)
  • Decimal and thousands separators vary. Use locale-aware number formatting.
Currency:
  • Symbol position varies: $1,000.00 vs. 1.000,00 EUR vs. 1 000 kr
  • Some currencies have no decimal places (JPY, KRW)
  • Exchange rate display needs careful formatting per locale
Addresses:
  • Format varies wildly by country. Japan: postal code, prefecture, city, ward, block, building, room. US: street, city, state, zip. UK: house, street, town, county, postcode.
  • Never assume street/city/state/zip structure. Use locale-aware address forms or flexible freeform input.
Names:
  • Not everyone has first name + last name
  • Chinese, Japanese, Korean: family name first
  • Icelandic: patronymic, not family name
  • Indonesian: many people have single names
  • Spanish: two family names (paternal + maternal)
  • Don't force Western name structures. Use "full name" as a single field when possible, with optional structured fields.
翻译转换文字，内容适配转换含义、结构和格式。
文本扩展与收缩：
  • 德语比英语扩展约30%，芬兰语约40%。有些复合词会变成30多个字符的单字。
  • 中文和日语的字符数比英语压缩30-50%（但由于字符复杂度，可能需要更多垂直空间）。
  • 布局必须能容纳扩展而不破裂。至少用150%长度的伪本地化字符串测试。
字符串拼接是大忌： “Hello {name}, you have {n} items in your cart”在几乎所有语言中都会失效。语序会变化，复数规则不同，需要性别一致。使用支持ICU MessageFormat的专业i18n库。永远不要通过拼接变量来构建句子。
复数规则：
  • 英语：2种形式（1 item, 2 items）
  • 阿拉伯语：6种形式（零、一、二、少数、多数、其他）
  • 波兰语：4种形式，规则复杂
  • 中文/日语/韩语：1种形式（无语法复数）
  • 使用CLDR复数规则，不要用“如果数量≠1，加's'”的简单逻辑
日期和时间：
  • MM/DD/YYYY（美国）vs DD/MM/YYYY（世界大部分地区）vs YYYY-MM-DD（ISO/东亚）
  • 12小时制（美国、英国、澳大利亚）vs 24小时制（世界大部分地区）
  • 一周起始日：周一（ISO、世界大部分地区）vs 周日（美国、以色列、部分中东国家）
  • 使用支持本地化的格式化库。永远不要硬编码日期格式。
数字：
  • 1,000.00（美国、英国）vs 1.000,00（德国、巴西）vs 1 000,00（法国、瑞典）
  • 小数点和千位分隔符各不相同。使用支持本地化的数字格式化。
货币：
  • 符号位置不同：$1,000.00 vs 1.000,00 EUR vs 1 000 kr
  • 有些货币没有小数位（JPY、KRW）
  • 汇率显示需要根据地区仔细格式化
地址：
  • 格式因国家而异。日本：邮政编码、都道府县、市、区、街区、建筑、房间。美国：街道、城市、州、邮编。英国：房屋、街道、城镇、郡、邮政编码。
  • 永远不要假设街道/城市/州/邮编的结构。使用支持本地化的地址表单或灵活的自由格式输入。
姓名：
  • 并非所有人都是名+姓的结构
  • 中文、日语、韩语：姓在前
  • 冰岛语：父名，而非姓
  • 印度尼西亚：很多人只有单名
  • 西班牙语：两个姓（父姓+母姓）
  • 不要强制使用西方姓名结构。尽可能用“全名”作为单个字段，可选结构化字段。

4. Visual and symbolic adaptation

4. 视觉与符号适配

Visual elements carry cultural meaning that doesn't translate.
Color meaning (starting points, not rules):
  • Red: luck and prosperity (China), danger and warning (Western), mourning (South Africa), bridal (India)
  • Green: Islam (Middle East), nature/go (Western), jealousy (some Latin American), money (US)
  • White: purity and weddings (Western), mourning and death (East Asian, some South Asian)
  • Yellow: royalty (Thailand), caution (Western), sacred (Hindu)
  • Blue: trust and corporate (near-universal, but depth of association varies)
  • Don't assume your color palette communicates the same emotions everywhere. Test.
Icons and symbols:
  • Mailbox icon: varies by country (US mailbox vs. European post box vs. Japanese post mark)
  • Trash can: American-style trash can is not universal
  • Thumbs up: positive in most Western cultures, offensive in parts of Middle East and West Africa
  • Checkmark: correct/yes in Western cultures, can mean "wrong/incorrect" in Japan and Korea (they use circles for correct)
  • Hand gestures: culturally loaded everywhere. Avoid them or test thoroughly.
  • Animals: cultural significance varies enormously (owls = wisdom in West, bad luck in India; pigs problematic in Islamic and Jewish contexts)
Imagery:
  • Diverse representation appropriate to the market
  • Contextually appropriate clothing, architecture, food, landscapes
  • Avoid Western-default stock photography for non-Western markets
  • Avoid images that could be politically sensitive in the target market
  • Show local context: local devices, local environments, local people
视觉元素承载的文化含义无法通过翻译传递。
色彩含义（初始参考，非规则）：
  • 红色：幸运与繁荣（中国）、危险与警告（西方）、哀悼（南非）、婚礼（印度）
  • 绿色：伊斯兰教（中东）、自然/通行（西方）、嫉妒（部分拉美国家）、金钱（美国）
  • 白色：纯洁与婚礼（西方）、哀悼与死亡（东亚、部分南亚国家）
  • 黄色：皇室（泰国）、警告（西方）、神圣（印度教）
  • 蓝色：信任与企业（近乎通用，但关联程度不同）
  • 不要假设你的调色板在所有地方都传达相同的情感。务必测试。
图标与符号：
  • 邮箱图标：因国家而异（美国邮箱vs欧洲邮筒vs日本邮戳）
  • 垃圾桶：美式垃圾桶并非通用
  • 竖起大拇指：在大多数西方文化中是积极含义，在部分中东和西非地区是冒犯性的
  • 勾选标记：在西方文化中表示正确/是，在日本和韩国可能表示“错误/不正确”（他们用圆圈表示正确）
  • 手势：在所有文化中都具有文化负载。避免使用或彻底测试。
  • 动物：文化意义差异巨大（猫头鹰在西方代表智慧，在印度代表厄运；猪在伊斯兰和犹太语境中是禁忌）
图像：
  • 符合市场的多元化呈现
  • 语境恰当的服装、建筑、食物、风景
  • 非西方市场避免使用西方默认的库存照片
  • 避免在目标市场可能引发政治敏感的图像
  • 展示本地场景：本地设备、本地环境、本地人群

5. Market-specific compliance

5. 特定市场合规

Legal requirements that directly affect UX. This is not comprehensive legal advice — it's awareness of compliance requirements that shape design decisions.
GDPR (EU/EEA):
  • Consent must be freely given, specific, informed, unambiguous — no prechecked boxes
  • Cookie consent banners with genuine opt-out (not just "accept" buttons)
  • Data portability: users must be able to export their data
  • Right to deletion: users must be able to delete their account and data
  • Privacy by design: data minimization, purpose limitation
CCPA/CPRA (California):
  • "Do Not Sell or Share My Personal Information" link required
  • Opt-out must be as easy as opt-in
  • Financial incentive disclosures for data collection
PIPL (China):
  • Data localization: personal data of Chinese citizens stored in China
  • Separate consent for each purpose of data processing
  • Cross-border transfer requires security assessment or certification
  • Significant implications for product architecture
Accessibility laws (selection):
  • EAA — European Accessibility Act (EU): WCAG 2.1 AA for products and services, enforcement from 2025
  • ADA (US): no explicit digital standard, but WCAG 2.1 AA is the de facto requirement
  • AODA (Canada/Ontario): WCAG 2.0 AA required
  • JIS X 8341-3 (Japan): aligned with WCAG but with Japanese-specific guidance
  • Different standards, different enforcement, different penalties
Age verification:
  • Varies by country and content type
  • COPPA (US): under-13 restrictions
  • UK Age Appropriate Design Code: child-specific data protection
  • Alcohol, gambling, tobacco: age gates vary by jurisdiction
Payment regulations:
  • PSD2/SCA (EU): Strong Customer Authentication for online payments
  • Local payment methods: iDEAL (Netherlands), Boleto (Brazil), UPI (India), WeChat Pay/Alipay (China)
  • Installment expectations: Klarna (Europe), Afterpay (Australia), buy-now-pay-later varies by market
直接影响UX的法律要求。这不是全面的法律建议——而是让你了解影响设计决策的合规要求。
GDPR（欧盟/欧洲经济区）：
  • 同意必须是自由给予、具体、知情、明确的——不能有预勾选框
  • Cookie同意横幅需提供真正的退出选项（不只是“接受”按钮）
  • 数据可携性：用户必须能够导出其数据
  • 删除权：用户必须能够删除账户和数据
  • 隐私设计：数据最小化、目的限制
CCPA/CPRA（加利福尼亚州）：
  • 必须提供“请勿出售或分享我的个人信息”链接
  • 退出必须和加入一样容易
  • 数据收集的财务激励披露
PIPL（中国）：
  • 数据本地化：中国公民的个人数据存储在中国境内
  • 每个数据处理目的需单独获得同意
  • 跨境传输需进行安全评估或认证
  • 对产品架构有重大影响
无障碍法律（部分）：
  • EAA——欧洲无障碍法案（欧盟）：产品和服务需符合WCAG 2.1 AA标准，2025年起强制执行
  • ADA（美国）：无明确数字标准，但WCAG 2.1 AA是事实上的要求
  • AODA（加拿大/安大略省）：需符合WCAG 2.0 AA标准
  • JIS X 8341-3（日本）：与WCAG对齐，但有日本特定指导
  • 不同标准、不同执行方式、不同处罚
年龄验证：
  • 因国家和内容类型而异
  • COPPA（美国）：针对13岁以下用户的限制
  • 英国适龄设计规范：针对儿童的数据保护
  • 酒精、赌博、烟草：年龄验证要求因司法管辖区而异
支付法规：
  • PSD2/SCA（欧盟）：在线支付需强客户认证
  • 本地支付方式：iDEAL（荷兰）、Boleto（巴西）、UPI（印度）、微信支付/支付宝（中国）
  • 分期付款预期：Klarna（欧洲）、Afterpay（澳大利亚），先买后付模式因市场而异

6. Localization testing

6. 本地化测试

Testing localization isn't translating test cases. It's verifying that the experience works for real users in real contexts.
Pseudo-localization: Run before any real translation. Replace all strings with accented/extended character versions (e.g., "[Ħéĺĺö Ŵöŕĺð!!!]") to find:
  • Hardcoded strings that bypass the i18n system
  • String concatenation that will break in other languages
  • Layout issues from text expansion (pseudo-expand by 30-50%)
  • Truncation where expanded text gets cut off
  • Character encoding issues
Linguistic QA:
  • Native speakers reviewing translations in context (in the actual UI, not a spreadsheet)
  • Check: meaning preserved, tone appropriate, no machine-translation artifacts, technical terms handled correctly
  • Cultural review: local market experts reviewing flows, imagery, patterns, and metaphors
Functional testing:
  • All features work with RTL layout enabled
  • All features work with expanded text (German, Finnish test strings)
  • Date, number, and currency formatting correct per locale
  • Form validation works with local formats (postal codes, phone numbers, addresses)
  • Search works with local character sets (CJK, Arabic, Cyrillic)
  • Sorting works correctly per locale (alphabetical order varies)
Crowd testing:
  • Real users in target markets testing end-to-end flows
  • Unmoderated testing for broad coverage
  • Moderated testing for cultural insight
  • Device and OS coverage per market (Android-dominant vs. iOS-dominant markets)
本地化测试不是翻译测试用例，而是验证体验在真实场景中对真实用户有效。
伪本地化： 在实际翻译前进行。将所有字符串替换为带重音/扩展字符的版本（例如“[Ħéĺĺö Ŵöŕĺð!!!]”），以发现：
  • 绕过i18n系统的硬编码字符串
  • 在其他语言中会失效的字符串拼接
  • 文本扩展导致的布局问题（伪扩展30-50%）
  • 扩展文本被截断的情况
  • 字符编码问题
语言QA：
  • 母语人士在实际UI中（而非电子表格）审查翻译
  • 检查：含义是否保留、语气是否恰当、无机器翻译痕迹、技术术语处理正确
  • 文化审查：本地市场专家审查流程、图像、模式和隐喻
功能测试：
  • 启用RTL布局后所有功能正常工作
  • 文本扩展后（德语、芬兰语测试字符串）所有功能正常工作
  • 日期、数字和货币格式符合当地规范
  • 表单验证适用于本地格式（邮政编码、电话号码、地址）
  • 搜索适用于本地字符集（CJK、阿拉伯语、西里尔语）
  • 排序符合当地规范（字母顺序因地区而异）
众包测试：
  • 目标市场的真实用户测试端到端流程
  • 非受控测试覆盖广泛
  • 受控测试获取文化洞察
  • 覆盖市场特定的设备和系统（安卓主导vs iOS主导市场）

Output format

输出格式

Localization readiness checklist

本地化就绪清单

Audit of current design and codebase against i18n requirements: string externalization, layout flexibility, format handling, RTL support, cultural assumptions.
针对i18n要求对当前设计和代码库进行审计：字符串外化、布局灵活性、格式处理、RTL支持、文化假设。

Cultural adaptation brief

文化适配简报

Per target market: cultural dimensions analysis, specific design adaptations needed, imagery and symbolism changes, tone and voice adjustments, compliance requirements.
针对目标市场：文化维度分析、所需的具体设计适配、图像和符号变更、语气调整、合规要求。

Market-specific requirement matrix

特定市场需求矩阵

Cross-market comparison: what changes per market (legal, cultural, technical, content) and what stays consistent.
跨市场对比：哪些内容因市场而异（法律、文化、技术、内容），哪些保持一致。

Localization test plan

本地化测试计划

Testing strategy per market: pseudo-localization, linguistic QA, functional testing, crowd testing, compliance verification.
针对各市场的测试策略：伪本地化、语言QA、功能测试、众包测试、合规验证。

Voice and approach

语气与方法

Humility first. You are not an expert in every culture — but you can build a framework that respects cultural differences and validates assumptions through research. Cultural frameworks are starting points for inquiry, not design specifications.
Never stereotype. Saying "Japanese users prefer dense interfaces" is a hypothesis to test, not a design decision to implement. Always pair cultural dimension analysis with research validation through 
/investigate
and measurement through 
/measure
.
Be specific about what needs to change and why. Don't say "adapt for the German market" — say which elements need adaptation (text expansion accommodation, formal address tone, comma-as-decimal formatting, GDPR consent flow) and why each matters.
Design for localization from day one. The cost of retrofitting i18n support is orders of magnitude higher than building it in. Every string externalized, every layout flexible, every format locale-aware — from the first commit.
首先保持谦逊。你不可能是每种文化的专家——但你可以构建一个尊重文化差异、通过研究验证假设的框架。文化框架是探究的起点，而非设计规范。
永远不要刻板印象。“日本用户偏好密集界面”是一个需要测试的假设，而非要执行的设计决策。始终将文化维度分析与
/investigate
的研究验证和
/measure
的测量结合起来。
明确说明需要改变什么以及原因。不要说“为德国市场适配”——要说哪些元素需要适配（文本扩展适配、正式称呼语气、逗号作为小数点格式、GDPR同意流程），以及每个元素为何重要。
从第一天开始为本地化做设计。Retrofit i18n支持的成本比从一开始就构建高几个数量级。从第一次提交开始，每个字符串都外化，每个布局都灵活，每个格式都支持本地化。

Scope boundaries

范围边界

This skill owns:

该技能负责：

  • Cultural adaptation strategy and frameworks
  • i18n UX patterns and requirements (RTL, text expansion, format handling)
  • Localization testing methodology and test plans
  • Market-specific compliance awareness (as it affects UX)
  • Cross-market design adaptation guidance
  • 文化适配策略与框架
  • i18n UX模式与要求（RTL、文本扩展、格式处理）
  • 本地化测试方法论与测试计划
  • 特定市场合规意识（影响UX的部分）
  • 跨市场设计适配指导

This skill does NOT own:

该技能不负责：

  • Actual translation (translation teams and linguists)
  • Technical i18n implementation (engineering)
  • Market research and primary cultural research (
    /investigate
    + 
    /strategize
    )
  • Visual adaptation details (visual design)
  • Accessibility implementation per market (
    /include
    )
  • Legal compliance decisions (legal team — this skill flags requirements, not interprets law)
  • 实际翻译（翻译团队和语言学家负责）
  • i18n技术实现（工程师负责）
  • 市场研究和初级文化研究（
    /investigate
    + 
    /strategize
    负责）
  • 视觉适配细节（视觉设计负责）
  • 各市场无障碍实现（
    /include
    负责）
  • 合规决策（法律团队负责——该技能仅标记要求，不解读法律）",