看完这篇文章，彻底解决底部栏按钮宽度的问题！

设计师和研发人员在按钮尺寸设计中会遇到困惑。按钮为何在Bottom bar出现不同尺寸？按钮何时使用“大按钮”或“小按钮”？如何划定Bottom Bar的结构，研发才能确保在不同屏幕尺寸和分辨率下，按钮都能呈现出良好的视觉效果和用户体验？若你也同样陷入这些思考，本文或将为你拨开迷雾，对你有所帮助。

往期干货：

一、这样的问题

事情的起因是近期在做国际化翻译的时候，对于长文本影响 BottomBar 内容展示产生了头疼的问题，如果一个产品没有做好产品翻译适配，很可能会出现文字溢出或者文字被砍断隐藏。例如：

这是因为做本土化翻译的时候，没有考虑好每种语言翻译后的长度，特别是在字符较少的情况下，译文所会产生的变化越大。

1994年IBM发表的的National Language Design Guide 中，当文本从英语翻译为其他各国欧洲语言时，预期长度的平均变化比率如下表：

于是，我们就带着问题去寻找答案，当然如果想看国际化相关我们遇到了哪些坑，以及如何快速搭建，满足产品/设计 ↔️ 客户端 ↔️ 服务端一体化 Json 工作流，记得多多点赞转发，我们会以最快的速度为您呈现！

二、别人是怎么做的

其他平台Bottom Bar的使用情况

1. 特别是页面只有一个主操作且强引导性的场景通常使用按钮撑满屏宽的bar

2. 在同一个页面中可能存在多个状态/流程会有不同数量的操作按钮时，通常按钮不会直接撑满屏宽，左边会留出固定的位置放置其他的元素（如Text、Button等）

3. 在不同场景下可能根据业务需求，需要弱化的按钮以固定宽度展示在左边

其他设计系统对Button / Bottom bar的支持

1. 归类为特殊按钮：有些设计系统将随宽度自适应撑满的按钮作为特殊类型进行归类，这可能是因为这种按钮在设计上需要更多的考虑和约束，或者它们在某些场景下具有特定的用途。通过特殊归类，可以更方便地在设计系统中管理和使用这类按钮。

2. 未特殊归类，仅做位置/布局的说明：另一些设计系统则没有将这类按钮作为特殊类型进行归类，而是将其视为底部工具栏中按钮布局的一种可能性。这种做法可能更加灵活，允许设计师根据具体需求和场景自由选择合适的布局方式。

三、技术实现考量‍‍

避免局限于设计视角收敛实践设计系统，与研发也进行沟通，收敛了结构，基于 APP 现最复杂的情况

Button bar 结构分 4 层

为了更易懂将使用各级父子关系来说明

总的来说

爷爷分 Left Container 和 Right Container左右各包含 N 个爸爸 Container爸爸里可以随便装任何原子分子组件，包括角标、文字等，比如

‍‍‍

而 Left Container 的 fixed 宽度设置了的 5 个百分比档位满足不同场景下的需求，包括左边容器里放什么，和控制右边容器按钮尺寸

1. Left Container Size = 
2. Large(72%) 
3. Medium(43%)
4. Normal(28%)
5. Small(13%)
6. Mini(0%)

也许有人会问，

为什么要靠左边的Left container占屏幕的百分比来决定右边按钮自适应呢？

布局灵活性和与一致性

左侧 Container（fixed）：

fixed 有助于维持设计的一致性与稳定性，特别是在左侧一般可能包含IconButton、Text 等固定元素时fixed 根据不同屏宽的固定百分比档位也为右侧的 fill 按钮提供了稳定的参照点右侧 Container（fill）：

fill 能够确保在不同屏幕尺寸和分辨率下，Button 都能充分利用可用空间，保持视觉上的统一性和操作的便捷性

fill 使 Button bar 在响应式布局中表现得更加灵活，能够适应各种屏幕尺寸的变化‍‍

四、使用指南

1. Call to action （Left Container Size = 0）通常出现于 Landing页、具有引导性质的页面以及深入到某一个操作/任务处理时

2. 若同一页面因业务逻辑复杂，而产生多种状态，控制 Left Container Size 的档位选择来保证右侧按钮的大小一致性

结语‍

现在回到我们最初的诉求，国际化 i18n 翻译内容时候，到底是以 Button 的宽度为第一准则，还是以翻译的语言为第一准则？

当然，我们现在得到答案是：

1. 若想快速 短频快 完成翻译，先成事儿后完美，在一定的 Bottom Bar 规则下，尽可能缩短内容或使用缩写来完成1:1翻译

比如以上，只保留动词就行

1. 取消发货 = Cancel
2. 物流详情 = Details
3. 申请退款 = Refund
4. 追加评价 = Review
5. 修改地址 = Edit Address

2. 在你的需要翻译的语言中，选择一种最短的和一种最长的语言做适配设计，最终选定一个合适的方案。这个方案比较省事，只适合长段文字，因为单词数量越少，需要的水平空间越无法估算。比如下图，社交产品常用的单词Like的译文空间差距甚大：

3. 当你翻译的是短句或者单词时，可以考虑使用图标替换文字

4.避免在狭小空间放文字

...

若想知道更多「方法」，记得点赞转发哦 ~ 我会有更多动力肝出来！

当然，随着海外需求的快速增长，或许要做更为适应本土化的设计改造，国际化只需做一次，但本地化则要针对不同的区域各做一次。这两者之间是互补的，并且两者合起来才能让一个系统适用于各地。

面对组件的多样性与复杂性，确保它们的合理性与可调整性，需要我们不断探索与思考。当设计师在使用过程中遇到困惑，或是发现既有规则存在支持不足、表述模糊之处，这正是我们迭代升级、精进系统的宝贵契机。每一次的更新迭代，也是对设计理念的深化与学习。希望这篇文章能够给予你一些启发。期待你的收获和反馈。