产品进入新市场/做国际扩张时…

适用于国际扩张规划、i18n 就绪审计、RTL 适配、文化假设审查、本地化测试计划及跨市场合规影响 UX 的场景。

适用场景

解决思路

1. 用文化维度框架生成设计假设而非刻板印象：分析目标市场在高低语境沟通上的倾向，并据此调整 onboarding 流程、帮助文本密度、社交功能、引导与自主平衡。
2. 分析权力距离：高权力距离市场用正式语气、层级导航、权威文案（如“Approved by Dr. [Name]”）、机构信任信号；低权力距离市场用非正式语气、扁平导航、同伴信任信号（如“1,000 users like you chose this”）、平等信息；影响称呼、语气、错误信息、权威信号。
3. 分析个人主义与集体主义：个人主义市场用个人账户、个人偏好、“我的”仪表盘、独自决策流程；集体主义市场用家庭/群体账户、共同决策、社交功能、送礼流程、团购模式；影响账户模型、分享功能、决策流程、社会证明。
4. 分析不确定性规避：高不确定性规避市场用详细解释、确认步骤、进度指示、安全网、明确保证；低不确定性规避市场容忍模糊、减少确认步骤、鼓励探索、容忍不确定；影响引导量、确认步骤数、错误预防与错误恢复的取舍。
5. 分析长期导向：长期导向市场用忠诚计划、订阅模式、逐步建立信任、关系优先 onboarding；短期导向市场用即时价值、试用优先、快速收益、即时满足模式。
6. 记住这些是频谱和倾向而非规则：每个个体不同、每个市场有亚文化；不要为刻板印象设计；用这些维度生成假设，再用 `/investigate` 研究和 `/measure` 数据在目标市场真实用户中验证。
7. 确定 RTL 中需要翻转的项：布局方向内容从右到左；文本默认右对齐；导航顺序后退箭头指右、前进指左；进度指示从右向左填充；滑动方向下一页为左到右、上一页为右到左；滑块方向最小值在右、最大值在左；暗示方向的图标（箭头、回复、分享）翻转。
8. 确定 RTL 中不翻转的项：数字和电话号码（在其容器内始终 LTR）；媒体播放控制（播放/暂停/跳过通用）；时钟方向；品牌 logo；通用图标（播放、暂停、关闭、添加）；对勾和开关（有争议但通常不翻转）。
9. 处理双向文本：当 RTL 与 LTR 内容混合（阿拉伯语文本与英文品牌名、代码片段、URL、电子邮件地址）时，Unicode Bidirectional Algorithm 处理大多数情况，但边缘情况需要手动用方向标记干预；用真实混合方向内容测试，不用 lorem ipsum。
10. RTL 的 CSS 实现原则：使用逻辑属性 `inline-start`/`inline-end` 代替 `left`/`right`，`block-start`/`block-end` 代替 `top`/`bottom`；在根元素使用 `dir="rtl"` 而不是 CSS transforms；Flexbox 和 Grid 配合逻辑属性自动处理方向；绝对定位和 transforms 需要手动关注。
11. 测试 RTL：用真实 RTL 用户测试，不只是镜像截图；用真实阿拉伯语/希伯来语内容测试，不反向英文；测试双向内容：含英文术语、数字、URL 的阿拉伯语段落；测试表单输入：光标位置、文本选择、复制粘贴行为。
12. 处理文本扩展和收缩：德语从英语扩展约 30%，芬兰语约 40%，有些复合词创建 30+ 字符的单个词；中文和日文可比英语字符数压缩 30-50%，但可能因字符复杂度需要更多垂直空间；布局必须容纳扩展不破损；用伪本地化字符串至少 150% 长度测试。
13. 避免字符串拼接：`"Hello {name}, you have {n} items in your cart"` 在几乎每种语言都会出问题；词序变化、复数规则不同、需要性别一致；使用正确的 i18n 库和 `ICU MessageFormat`；绝不用拼接变量构建句子。
14. 处理复数规则：英语 2 种形式；阿拉伯语 6 种（zero, one, two, few, many, other）；波兰语 4 种复杂规则；中文/日文/韩文 1 种（无语法复数）；使用 `CLDR` 复数规则，不用 `if count != 1, add 's'`。
15. 处理日期和时间：MM/DD/YYYY（美国）vs DD/MM/YYYY（世界大部分）vs YYYY-MM-DD（ISO/东亚）；12 小时制（美国、英国、澳大利亚）vs 24 小时制（世界大部分）；周一开始（ISO、世界大部分）vs 周日开始（美国、以色列、部分中东国家）；使用 locale-aware 格式化库；不要硬编码日期格式。
16. 处理数字：1,000.00（美国、英国）vs 1.000,00（德国、巴西）vs 1 000,00（法国、瑞典）；小数和千位分隔符不同；使用 locale-aware 数字格式化。
17. 处理货币：符号位置变化：$1,000.00 vs 1.000,00 EUR vs 1 000 kr；有些货币没有小数位（JPY、KRW）；汇率显示需按 locale 仔细格式化。
18. 处理地址：格式因国家差异大；日本：邮政编码、都道府县、城市、区、街区、建筑、房间；美国：街道、城市、州、邮编；英国：门牌、街道、城镇、郡、邮编；绝不要假设 street/city/state/zip 结构；使用 locale-aware 地址表单或灵活自由输入。
19. 处理姓名：不是每个人都有名+姓；中文、日文、韩文：姓氏在前；冰岛：父名，不是家族姓；印度尼西亚：很多人只有单名；西班牙语：两个家族姓（父系+母系）；不要强制西方姓名结构；尽可能用“全名”单一字段，带可选结构化字段。
20. 处理颜色含义（起点非规则）：红色：中国=好运繁荣，西方=危险警告，南非=哀悼，印度=新娘；绿色：中东=伊斯兰，西方=自然/通行，部分拉美=嫉妒，美国=金钱；白色：西方=纯洁婚礼，东亚/部分南亚=哀悼死亡；黄色：泰国=皇室，西方=警告，印度教=神圣；蓝色：信任和企业（近乎普遍，但关联深度不同）；不要假设你的调色板在所有地方传达相同情感，要测试。
21. 处理图标和符号：邮箱图标因国家而异（美国邮箱 vs 欧洲邮筒 vs 日本邮戳）；垃圾桶：美式垃圾桶不通用；竖大拇指：多数西方积极，部分中东和西非冒犯；对勾：西方=正确/是，日本和韩国可能=错误/不正确（他们用圆圈表示正确）；手势：到处都有文化含义，避免或充分测试；动物：文化意义差异巨大（猫头鹰=西方智慧，印度厄运；猪在伊斯兰和犹太语境有问题）。
22. 处理图像：根据市场体现多元代表性；符合语境的服装、建筑、食物、景观；避免为非西方市场使用西方默认库存照片；避免在目标市场可能政治敏感的图片；展示本地语境：本地设备、本地环境、本地人。
23. GDPR（EU/EEA）合规：同意必须自由给予、具体、知情、明确——没有预勾选框；cookie 同意横幅要有真正的退出选项（不只是“接受”按钮）；数据可携带：用户必须能导出数据；删除权：用户必须能删除账户和数据；隐私 by design：数据最小化、目的限制。
24. CCPA/CPRA（加州）合规：需要“Do Not Sell or Share My Personal Information”链接；退出必须和加入一样容易；数据收集的财务激励披露。
25. PIPL（中国）合规：数据本地化：中国公民个人数据存储在中国；每个数据处理目的单独同意；跨境传输需要安全评估或认证；对产品架构有重大影响。
26. 无障碍法律（选摘）：EAA — European Accessibility Act (EU)：产品和服务 WCAG 2.1 AA，2025 年起执行；ADA (US)：无明确数字标准，但 WCAG 2.1 AA 是事实要求；AODA (Canada/Ontario)：要求 WCAG 2.0 AA；JIS X 8341-3 (Japan)：与 WCAG 对齐但有日本特定指南；不同标准、不同执行、不同处罚。
27. 年龄验证：因国家和内容类型而异；COPPA (US)：13 岁以下限制；UK Age Appropriate Design Code：儿童特定数据保护；酒精、赌博、烟草：年龄门因司法管辖区而异。
28. 支付法规：PSD2/SCA (EU)：在线支付强客户认证；本地支付方式：iDEAL（荷兰）、Boleto（巴西）、UPI（印度）、WeChat Pay/Alipay（中国）；分期期望：Klarna（欧洲）、Afterpay（澳大利亚）、先买后付因市场而异。
29. 伪本地化：在任何真实翻译之前运行；用重音/扩展字符版本替换所有字符串（例如 `"[Ħéĺĺö Ŵöŕĺð!!!]"`）以发现：绕过 i18n 系统的硬编码字符串；将在其他语言中破损的字符串拼接；文本扩展导致的布局问题（伪扩展 30-50%）；扩展文本被截断；字符编码问题。
30. 语言 QA：母语者在上下文中（实际 UI 中，不是电子表格）审查翻译；检查：意义保留、语气合适、无机器翻译痕迹、技术术语处理正确；文化审查：本地市场专家审查流程、图像、模式、隐喻。
31. 功能测试：所有功能在启用 RTL 布局时工作；所有功能在扩展文本（德语、芬兰语测试字符串）下工作；日期、数字、货币格式按 locale 正确；表单验证支持本地格式（邮政编码、电话号码、地址）；搜索支持本地字符集（CJK、阿拉伯语、西里尔语）；排序按 locale 正确（字母顺序不同）。
32. 众包测试：目标市场真实用户端到端测试流程；非主持测试用于广泛覆盖；主持测试用于文化洞察；按市场覆盖设备和 OS（Android 主导 vs iOS 主导市场）。
33. 产出本地化就绪清单：对照 i18n 要求审计当前设计和代码库：字符串外部化、布局灵活性、格式处理、RTL 支持、文化假设。
34. 产出文化适配简报：按目标市场：文化维度分析、具体设计适配需求、图像和符号变化、语气和声音调整、合规要求。
35. 产出市场特定需求矩阵：跨市场比较：每个市场变化什么（法律、文化、技术、内容）和什么保持一致。
36. 产出本地化测试计划：按市场的测试策略：伪本地化、语言 QA、功能测试、众包测试、合规验证。
37. 保持谦逊：你不是每种文化的专家，但可以建立尊重文化差异并通过研究验证假设的框架；文化框架是探究起点，不是设计规范。
38. 绝不刻板：说“日本用户偏好密集界面”是要测试的假设，不是要实施的设计决策；始终将文化维度分析与通过 `/investigate` 的研究验证和通过 `/measure` 的测量配对。
39. 具体说明需要改什么及为什么：不说“为德国市场适配”，而说哪些元素需要适配（文本扩展容纳、正式称呼语气、逗号作小数格式、GDPR 同意流程）及为什么每个重要。
40. 从第一天就为本地化设计：改造 i18n 支持的成本比内置高几个数量级；每个字符串外部化、每个布局灵活、每个格式 locale-aware——从第一次提交开始。
41. 与 `/articulate` 协同：内容策略必须从一开始就为翻译设计——句子结构、拼接、语气、幽默、习语；如果英文文案巧妙，本地化文案可能无法理解；`/articulate` 设计可翻译内容，localize 确保其经翻译后存活。
42. 与 `/organize` 协同：导航和标签可能需要文化适配；一个文化中合理的分类结构在另一个文化中可能任意；英文简洁的菜单标签可能扩展成德语或芬兰语中难处理的长度。
43. 与 `/fortify` 协同：i18n 技术就绪——文本扩展破坏布局、RTL 渲染 bug、日期/数字格式解析失败、字符编码问题；`/fortify` 映射故障模式；localize 定义防止它们的需求。
44. 与 `/strategize` 协同：按 locale 的市场分析和受众定义；哪些市场、以什么顺序、什么适配水平；`/strategize` 定义商业案例；`/localize` 定义设计含义。
45. 与 `/investigate` 协同：针对不熟悉市场的文化研究方法；当对市场的假设基于刻板印象而非证据时，`/investigate` 规划研究以验证或挑战它们。
46. 与 `/philosopher` 协同：跨领域认知模式，用于面对不可见假设；当设计团队是单一文化、看不到自身偏见时，或“显而易见的”用户流程只对来自你文化的人显而易见时，或需要问：“哪些文化假设因为我们在其中而不可见？”
47. 明确本技能负责：文化适配策略和框架、i18n UX 模式和需求（RTL、文本扩展、格式处理）、本地化测试方法和测试计划、市场特定合规意识（影响 UX 时）、跨市场设计适配指导。
48. 明确本技能不负责：实际翻译（翻译团队和语言学家）、技术 i18n 实现（工程）、市场研究和一手文化研究（`/investigate` + `/strategize`）、视觉适配细节（视觉设计）、按市场的无障碍实现（`/include`）、法律合规决策（法务团队——本技能标记需求，不解释法律）。

适用边界 · 注意事项

• 不适用于只需要逐字翻译、不涉及文化或体验适配的任务；实际翻译应由翻译团队和语言学家执行。
• 不适用于替代技术 i18n 实现、法律合规决策、视觉设计细节或无障碍实现；这些分别由工程、法务、视觉设计和 `/include` 负责。
• 当无法获得目标市场用户研究、本地专家验证或数据时，不应仅凭文化维度刻板印象直接落地设计。