表单是本地化问题最集中的地方

表单同时涉及语言、格式、验证、错误和个人信息。开始设计时，要先确认每个字段为何需要，以及能否晚一点再收集。

姓名

不同文化的姓名结构不完全相同。若业务只需要称呼或显示姓名，可以考虑一个完整姓名字段。若法律、税务、银行或证件流程要求拆分，字段名称、顺序和字符范围要按实际制度确认，不能把所有姓名强制套入「First name / Last name」。

地址

国家或地区会影响行政区、城市、街道、门牌和邮政编码的顺序与必填性。地址表单应允许相应变化，并避免对所有地区使用同一正则表达式。邮政编码查询可以减少输入，但要保留无法查询时的手动路径。^[1]

电话与登录

国家代码、号码格式、短信送达、验证码、账号恢复和默认登录方式都需要真实市场验证。把某种登录方式放在首位，是产品决策，不是关于国民习惯的结论。^[1]

日期与时间

11/12/2024 在不同格式中会产生歧义。界面可以使用 Locale 对应格式，并在高风险场景写出月份名称或采用清楚的标准形式。还要处理 12／24 小时制、时区、夏令时、星期起点和跨日事件。^[1]

表单标签放在控件上方，通常更能容纳语言长度变化。内联标签、固定高度按钮和极窄双列表单，在翻译后更容易截断。错误文案也要进入翻译和测试范围，不能只翻译默认状态。

让界面容纳语言长度变化

语言之间很少保持相同长度。按钮和导航若依赖固定宽度，翻译后会被截断；过度依赖一行展示，也会让窄屏失效。

设计时可以准备语言压力测试：

• 将常见短标签扩展到原长度的约一倍半；
• 使用长产品名、长金额和长日期；
• 检查中文、英文以及一种目标长文本语言；
• 检查复数变化和带变量的句子；
• 确认换行以后层级、点击区域和阅读顺序不变。

翻译字符串不要把词语拆成难以重排的片段。已购买 {数量} 个项目 应让本地化系统处理整句和复数规则，避免把中文语序硬拼到其他语言。

图中包含文字时，也要决定是否制作多语言版本。关键说明放在 HTML 或可本地化图层中，通常比把文字烙在图片里更容易维护和访问。

从右向左书写需要真正的双向检查

阿拉伯语、希伯来语等界面可能采用从右向左的阅读方向。把文本右对齐只解决了很小一部分。

需要检查：

• 页面和组件的逻辑起止方向；
• 导航、面包屑、步骤和翻页顺序；
• 返回、前进和方向性图标；
• 表单标签、输入内容和错误位置；
• 数字、网址、代码和电话号码形成的双向混排；
• 图表、时间轴和媒体控制是否应镜像；
• 浮层、动画和滑动手势的方向。

实现时优先使用逻辑属性和平台方向能力，减少把 left、right 写死在组件中。仍要由熟悉目标文字系统的人检查，因为某些图标和数据方向不应机械镜像。

图片、图标和案例也要本地化

多语言产品中的视觉素材可能包含手势、地图、货币、节日、服饰和特定文化背景。它们需要按目标场景审核，不能用刻板印象替换真实用户。

案例本地化也不等于换一张当地人物照片。用户更关心案例是否与自己的角色、工作流、法规和购买条件相关。若产品尚未在该市场交付，应准确说明可用范围，不能用图片暗示已经拥有当地客户。

图标要与文字配合。某些图标在一个产品中很熟悉，换到另一文化或专业场景可能难以理解。对关键行动保留文字标签，通常比依赖无文字图标更安全。

把可访问性和本地化合并测试

两类工作分别测试仍会留下交叉问题。屏幕阅读器读取的可访问名称需要翻译，错误消息需要与本地化字段关联，RTL 页面也需要正确焦点顺序，放大文字会进一步增加长语言的布局压力。

可以为每个关键流程建立一张组合矩阵：

并非每次小改动都要手工跑遍所有组合。团队可以把基础规则交给自动化，把关键组件加入回归，把高风险流程安排人工测试，并在重大版本中邀请真实用户。

设计交付需要留下规则

设计稿只展示最终画面时，开发者仍需猜测内容变长、错误发生和屏幕变窄后的行为。交付材料可以补充：

• 页面任务和主要行动；
• 字体、颜色和间距角色；
• 容器、最大宽度和断点逻辑；
• 组件状态与交互；
• 焦点顺序、键盘行为和动态通知；
• 字符串、变量、复数和格式规则；
• 空、错、加载和权限状态；
• 哪些内容可以镜像，哪些不能；
• 已完成的设备、语言和辅助技术测试；
• 尚未验证的风险。

设计 Token 可以把颜色、字体、间距和圆角连接到代码，但 Token 本身不会解释使用目的。名称应表达角色，例如 text-secondary、surface-error，比 gray-500 更容易在主题和市场变化时保持语义。

模板和 AI 需要同样的验收

高质量模板能提供成熟的布局、字体和组件样例。拆解模板时，可以记录父容器、Gap、Padding、Max Width、字号、字重、字距、行高、组件和响应式模式，再替换成真实内容进行验证。^[2]

模板参数来自一个具体项目。96px 的区块间距、某个圆角和一种 tracking 不能直接变成所有产品的规则。模板也可能没有完整的加载、错误、键盘、本地化和数据边界状态。

AI 生成页面通常能快速产出结构完整的初稿，仍需接受同样检查：

• 信息顺序是否符合真实任务；
• 文案、链接、价格和案例是否准确；
• 父子布局能否承受内容变化；
• 组件状态和表单是否完整；
• 键盘、语义和辅助技术是否可用；
• 多语言和 RTL 是否经过测试；
• 生成素材和字体是否具有适当使用权。

生成结果「没有明显错误」，不代表它已经形成品牌，也不代表可以交付。^[3][2]

一套可直接执行的验收流程

第一轮：任务与结构

• 写明用户、入口、任务和主要行动；
• 检查标题、解释、行动和反馈的顺序；
• 删除无法说明作用的视觉重点；
• 为真实流程列出加载、空、错和成功状态。

第二轮：视觉系统

• 按层级、对齐、间距检查页面；
• 确认颜色角色、对比和一致性；
• 检查字体角色、行高、字距和缩放；
• 检查组件全部状态，而非只看默认画面。

第三轮：响应式与内容

• 缓慢改变窗口尺寸，找出内容真正失效的位置；
• 测试长标题、长按钮、空数据、错误和大字号；
• 检查固定高度、绝对定位和不可换行内容；
• 在真实移动设备上验证触摸、键盘和滚动。

第四轮：可访问性

• 用键盘完成主要任务；
• 检查焦点、语义、名称、错误和动态通知；
• 使用自动工具发现基础问题；
• 用目标屏幕阅读器和浏览器验证关键流程；
• 对照项目采用的当前 WCAG 成功标准记录结果。^[4][5]

第五轮：本地化

• 使用真实翻译和 Locale 数据；
• 检查姓名、地址、电话、日期、时间、数字和货币；
• 检查语言长度、复数、变量和错误文案；
• 验证 RTL 和双向内容；
• 让目标语言使用者完成真实任务。^[1][6]

第六轮：交付与回归

• 记录问题、影响、证据、负责人和状态；
• 把基础规则加入自动检查；
• 把关键组件和流程加入回归测试；
• 保存浏览器、设备、辅助技术和语言组合；
• 上线后继续观察失败、放弃和客服问题。

设计质量最终体现在任务是否顺利完成。视觉秩序帮助用户理解，语义和键盘让更多人能够操作，Locale 和本地化让产品在目标市场中保持准确。三者一起进入组件、测试和交付流程，页面才有机会在真实环境中继续成立。