如何让网页布局适应翻译后变长的文字

如果界面依赖原始措辞恰好占据某个固定大小的空间，文字变长就会成为布局问题。简短的英文按钮放得下，较长的译文却被裁掉；原本整齐的一行标签页变得拥挤；或者卡片随内容长高，操作按钮却仍固定在原来的位置。

检查这种缺乏弹性的设计，不必等所有翻译都准备好。可以先用刻意加长的文字对初稿做压力测试，再用真实译文重新检查。第一步用于发现结构弱点，第二步则检查界面面对实际语言和含义时是否依然可用。

一个增长百分比为什么不够

没有哪个统一的增长百分比，能让界面适应所有语言。短标签、长句、复合词和不同文字体系，会带来不同形式的压力。字符数也不能精确告诉你，文字渲染后需要占据多少空间。

W3C 关于翻译中文字尺寸的说明解释了为什么紧凑的原文字符串可能显著变长，以及为什么字宽、词语结构和行高都很重要。这些例子是有用的提醒，不是计算你具体界面空间的工具。认定组件准备好之前，要检查实际内容与字体的组合。

设想一个虚构的活动看板，其中有一个标为“View details”（查看详情）的按钮。更长的标签可能需要更宽的按钮，或增加第二行。同时，活动标题也可能从两行变成三行。这是两种不同的变化，后果也不同。为每个元素都多留相同比例的空间，并不能决定它们各自该怎样应对。

先明确文字必须传达什么。如果标签用于区分查看预约与修改预约，这个区别就必须保留。如果警告是在说明某个操作无法撤销，就不能为了保持原来的卡片高度，而在缩短文字时删掉这一含义。布局的职责，是承载信息。

列出容易受影响的组件

先检查空间控制严格的地方。导航、标签页、按钮、徽章、表单标签、表头和小卡片，通常比宽裕的正文栏更能暴露问题。找出文字与图标、价格、状态或另一个操作并列的例子。

为每个组件记录以下四种行为：

1. 换行： 标签能不能多占一行？
2. 增长： 容器会不会随之变高或变宽？
3. 相邻元素： 图标和旁边的操作能不能安全地移动？
4. 限制： 如果限制行数，用户能到哪里阅读完整文字？

如果某个问题还没有答案，就说明相应的设计决定尚未做出；简短的英文标签可能只是把它藏住了。

接着，记录失败的代价。装饰性标签变高，与付款金额被标签盖住，是不同的问题。应优先检查承载决定、要求或操作的组件，避免本地化评审花了第一个小时打磨无害的差异，却让关键控件继续处于无法阅读的状态。

译文到来之前，Shopify 发现了什么

在Shopify 介绍产品国际化的文章中，团队描述了一个英文预览里很容易漏掉的问题：已抽取到翻译流程中的字符串，与写死在代码里的字符串，看起来完全一样。他们引入伪翻译，用仍可辨认的字符替换原字符，并把元音重复一遍。改变后的文字，既能帮助他们看出哪些字符串经过了翻译流程，也能用更长的单词检查界面。

伪翻译能较早发现一类很实用的缺陷：从未进入翻译系统的文字、依赖短词才能成立的控件，以及无法随内容增长的容器。但它不能判断一条法语说明是否自然，也不能判断阿拉伯语布局的阅读顺序是否正确。

值得观察截图里哪些内容仍然可以辨认。测试者看到不寻常的字符时，仍然能够理解屏幕，因此更容易完成正常任务，并在过程中发现破损。如果每个框都塞满随机字符串，虽然也能制造空间压力，却会让测试者无法判断操作与解释放在一起时是否仍然说得通。

借鉴 Shopify 的方法，把检查拆成四项：

• 覆盖范围： 有明显标记的伪文字，可以暴露从未被转换的字符串。
• 容纳能力： 加长措辞，用于测试控件和容器能否随内容增长。
• 渲染： 使用目标文字体系和回退字体，检查是否缺少字形，或行框是否裁切文字。
• 语言： 使用已批准的译文，让熟练掌握该语言的评审者判断含义与表达。

为一个界面准备实用的压力测试样本

选一个含有标题、标签页、状态徽章、两个操作和一条错误消息的页面。保持其中的数值和操作目的地不变，只替换正在检查的文字。

记录缺陷时，要把它与触发问题的具体字符串和状态联系起来。“校验后，在 390px 宽度下，法语的次要操作盖住了主要操作”，能让开发者知道从哪里着手；“法语需要更多空间”，则无法区分究竟是按钮宽度固定、操作行缺乏弹性，还是错误消息位置不当。

修复之后，也要重新测试短文字。全宽按钮可能解决了最长标签的问题，却在大屏幕上显得与周围内容脱节。较大的固定卡片高度也许能容纳某条译文，却让普通记录变得难以浏览。优先采用随内容增长的布局和明确的堆叠行为；只有确实受限的场景，例如嵌入式宿主界面，才保留固定容量。

语言评审前，要给译者提供操作的目的地和周围句子。“Open”既可能表示一种状态，也可能是一条命令；加宽按钮解决不了这种歧义。视觉检查与语言检查应当互相提供信息，而不要求任何一方为自己无法判断的工作背书。

保持测试可控

使用更长的活动标题、更长的地点名称，以及描述更充分的操作标签。首次比较时，保持日期和参与人数不变，让文字长度成为正在研究的变量。布局成立后，再单独检查本地化日期格式。

先用加长的英语发现布局压力，再用真实译文检查措辞是否自然、含义是否正确，以及特定文字体系的渲染表现。

按组件选择应对方式

同一条变长的字符串，不该在所有地方都采用同一种修法。按钮可以变宽，导航可以改变布局，卡片可能需要多容纳一行。先找出无论怎样变化都必须保留的关系。

按钮：变宽、换行、堆叠

按钮需要明确规定如何应对更长的标签。固定宽度有助于让一组按钮刻意对齐，但如果把宽度看得比标签更重要，布局就会变得脆弱。决定按钮应该增长、换行还是移动之前，先结合周围布局检查这个操作。

对于表单下方的一对操作，窄屏时上下堆叠，可能比挤在同一行更清楚。如果其中一个是主要操作，堆叠后也要保留它的突出程度。访客不应该根据已经不存在的桌面排列，去猜哪个操作更重要。

标签换行，并不自动意味着错误。 只要按钮有足够的高度、均衡的内边距，并与其所作用的内容保持清楚联系，就可能是可行方案。不过，一组小小的双行按钮可能变得难以浏览。如果多个操作都需要较长解释，就要重新考虑，它们是否都适合放在同一个紧凑的组里。

不要只为节省宽度，就把有意义的标签换成没有解释的图标。对于合适场景中的熟悉操作，图标可能适用，但改变呈现方式也会引入新的识别问题。要主动评估这个取舍，而不是把它当作让译文消失、又没有代价的中性办法。

为了具体检查尺寸，我测量了三个英文标签，采用 Albert Sans、32px 字号，并在左右各留 20px 内边距。“View details”共需 212px，“Review booking details”需 368px，“Review your booking details”需 440px。宽 220px 的固定按钮只剩 180px 给标签，因此第一项放得下，另外两项需要布局作出调整。这些英文压力测试标签是为了单独研究宽度压力，并非译文。每条横条的深色部分是测得的文字宽度，浅色部分是内边距。在窄页面上，应先比较总宽度与操作组的可用空间，再决定变宽、换行还是堆叠。

导航：在发生碰撞前调整布局

导航往往较早暴露文字变长的问题，因为多个标签要争用同一横行。原文已经勉强放得下的页头，几乎没有容纳更长措辞的余地。换一种语言后，可能需要更早切换呈现方式，或采用能根据可用空间调整的布局。

检查完整页头，包括品牌、语言切换、账户操作和任何推广链接。只看导航标签，可能漏掉真正的碰撞来源。账户标签只长了一点，也可能成为把其他元素都挤到一起的原因。

不要只为保持等宽，就分别缩短各个标签。译者可能为了保留含义而选用不同词语，最终标签在视觉上未必对称。只要整组导航仍然容易理解和使用，其中一项占用更多空间就是合理的。

对于标签页，要考虑换行是否造成歧义。两行标签页可能让人更难判断哪些内容属于当前选中项。视任务而定，另一种控件，或经过明确设计的滚动方式，可能更合适。关键是一起检查选中状态及其对应内容，而不是只确保每个字都看得见。

卡片：保留辨认内容所需的信息与操作

重复排列的卡片，常常会让设计者希望每一项都严格等高。这可能有助于快速浏览，但实现方法很重要。为了保持网格而截掉有意义的文字，可能让卡片更容易对齐，却更难让用户作出选择。

在活动看板上，假设一个活动名占三行，另一个只占一行。如果卡片能合理分配空间，操作仍然可以位于可预期的位置。标题区域应允许增长，同时保留标题、日期和操作之间的清楚关系。

要决定哪些文字可以缩略，以及用户怎样找到完整版。较长描述的预览，与用来识别活动的标题，并不是同一回事。如果截断后两个活动变得无法区分，组件就丢失了选择所需的信息。一个省略号，并不能解释被省掉的区别是什么。

徽章和状态标签要单独检查。较长的状态不能盖住活动名称，也不能把日期挤出卡片。与缩小字号相比，把徽章移到单独一行可能更合适。改完后，也要查看使用短标签的卡片，避免这次修复让其他地方都出现过多空白。

表单：标签、提示、错误一起测

表单布局对文字长度尤其敏感，因为同一个控件周围会出现多种内容：标签用来识别字段，提示解释期望输入什么，错误消息说明应如何修正。换一种语言后，它们可能全都会变长。

检查每种状态时，也要让其他相关内容同时出现。一个字段只有标签时可能很好，但下方出现译后的提示和错误消息后，关系就可能混乱。读者仍须看得出哪些信息属于哪个字段，以及修正后应该在哪里继续。

标签变长后，原本并排的标签与控件可能需要上下堆叠。这是结构选择，不是译文质量差的标志。如果仍采用横向排列，就要让标签和控件都有足够空间履行各自职责。标签宽裕了，输入框却窄得无法使用，并不算改善。

保留错误消息之间的区别。“必填”“内容过长”和“无法保存”描述的是不同问题。本地化评审不能仅仅因为错误区域高度固定，就把它们都压缩成一条短而笼统的提示。应该让这个区域传达具体问题，并随消息长度增长。

把数字、单位和姓名放在上下文中检查

会变长的不只是句子。日期、货币、姓名和单位，都可能改变组件所需的空间及排列顺序。应把它们作为对应语言和地区需要检查的内容样例，而不是由设计师凭记忆临时编造的值。

一行价格可能同时包含货币金额、计费周期和限定说明。如果限定说明换行了，要检查它是否仍然明显属于这项价格。在活动示例中，日期范围可能比单个日期需要更多空间。让标签和值保持联系，可能比让整张卡片少一行更重要。

使用有代表性的用户姓名，不要假定姓名总由固定数量的短词组成。一个只适合“Alex Lee”的布局，并不能证明长姓名也能读清。要考虑哪些地方必须显示全名，哪些地方根据任务可以采用简短表示。

不要在视觉规格中拼接字符串片段，好像原文的顺序适用于所有语言。一句由数字、名词和简短后缀组装出来的话，在译文中可能需要另一种结构。交接时提供预期含义和上下文，让语言工作能写出连贯的信息，而不是在没有指导的情况下重排零散碎片。

W3C 国际化快速提示介绍了相关基础，包括语言声明、内容与呈现分离，以及组合字符串时需要注意的问题。

不只横向，纵向也留空间

常见修法是加宽，却继续固定所有高度。这可能救下一个标签，但另一个标签行数改变后仍会被裁切。要检查整个章节的纵向内容流：较长标题可能把副标题、操作组以及下一节都向下推。

只要任务允许，就让页面容纳这种增长。卡片变高，通常比关键短语消失造成的伤害更小。如果高度必须受限，就明确规定替代行为，例如把次要细节移到单独视图，同时让识别内容所需的信息保持可见。

检查实际渲染字符的顶部和底部。文字框看起来足够大，也可能裁掉重音符号或字形的一部分。换字体、文字体系或字重，都可能暴露这个问题。使用原文字体制作的截图，不足以证明另一种文字体系也能正常呈现。

不要强迫每种语言都复制原页面的确切行数。设计应保留层级、关系和可用性。用不同文字传达同一含义时，章节高度和换行出现一定差异，是合理的结果。

本地化与宽度检查结合

桌面端可用的译文，到了手机上仍可能失败。对容易受影响的组件，检查窄、中、宽三个视图，再检查布局发生变化的宽度。完整执行一项任务时，保持选用同一种语言，才能发现一组孤立截图容易漏掉的内容关系。

把观察到的问题分为语言问题与布局问题。如果措辞读起来不自然，就需要语言评审；如果标签本身表达正确，却与相邻控件碰撞，就需要调整布局。有时两类问题会同时存在，但先判断问题属于哪一类，可以避免设计师和译者反复把同一个问题推回给对方。

措辞与含义的最终判断，应交给理解该语言的评审者。 不会这种语言的人，可以发现文字裁切、重叠和缺字，却无法可靠地确认：缩短后的标签是否仍然传达正确操作。应在评审记录中注明这个限制，而不是把视觉上放得下，等同于译文已经获批。

从右向左的布局还需要单独检查方向性。只把从左向右的文字加长，并不能证明排列顺序、混合方向内容或带方向含义的控件都能正确工作。要明确保留这项检查，不能把它混进“所有语言均已通过”之类的笼统结论。

用 OpenDesign 检查并修订

OpenDesign 可以通过 HTML 预览、桌面、平板和手机视图，以及有针对性的设计修订，支持这些工作。你可以提供已批准的文字作为上下文、查看结果，再通过评论或聊天描述发生碰撞的位置。受支持的手动文字和样式编辑，也适合尝试局部调整。

例如，明确要求活动标题允许多占几行、日期必须完整可见，以及主要操作必须继续与所在卡片保持关联。测试布局修复时，保持文字不变。这样，比每次出现长字符串就要求整体重新设计，更容易判断修复结果。

判断最终布局时，使用已批准的译文，以免通过改词掩盖仍然需要修复的碰撞。

局部修复后，再比较一次原始内容与加长内容。解决最长样例的规则，可能让短标签变得不必要地别扭。良好的弹性应支持一段内容范围：普通文字保持协调，较长文字仍然可用，任何例外处理都有清楚的理由。

明确什么才算“已准备好交给翻译”

有用的交接应记录容易受影响的组件会如何表现、试过哪些压力样例，以及实际评审过哪些语言。还要列出尚未解决的限制，例如外部小组件的标签宽度固定，或某张含文字图片仍然需要本地化版本。

为有歧义的字符串提供上下文。按钮通向哪里、周围有哪些解释、几个相近操作之间有何区别，都可能影响翻译。如果字符数限制确实无法避免，就说明限制及原因，并指明由谁决定是否可以更改。不要悄悄把每个容器当前的宽度都变成对语言的约束。