在软件本地化方面，需要牢记一些通用原则。 第一个是在任何项目开始时就计划进行本地化。 对于最初生成时没有考虑国际化或本地化的现有语义模型（旧称为数据集）或报表，向它们添加本地化支持的难度更大。

Power BI 报表尤其如此，因为有许多常用的设计技术不支持本地化。 在向现有的 Power BI 报表添加本地化时，大部分工作是撤销不支持本地化的内容。 只有在完成此工作后，才能继续推进支持本地化的设计技术。

在继续之前，需要决定如何打包语义模型定义和报表布局以进行分发。 使用 Power BI Desktop 的内容创建者使用两种常用方法。

若要向 Power BI 解决方案添加多语言支持，请选择以下任一方法。

可以将报表布局及其基础语义模型定义打包在一起。 通过将项目发布到 Power BI 服务工作区，部署如下所示的报告解决方案。 如果需要更新报表布局或语义模型定义，请通过发布 .pbix 项目文件的更新版本进行升级。

“单个项目文件”方法并不总是提供了你需要的灵活性。 也许一个团队负责创建和更新语义模型，而其他团队负责生成报表。 在单独的 .pbix 项目文件中与报表共享语义模型可能是有意义的。

若要使用共享语义模型方法，请创建一个包含语义模型和空报表的 .pbix 项目文件，此报表仍然是未使用的。 将此语义模型部署到 Power BI 服务后，报表生成器可以使用 Power BI Desktop 连接到它，以创建仅限报表的 .pbix 文件。

此方法使生成报表的团队能够生成具有报表布局的 .pbix 项目文件，这些布局可以独立于基础语义模型进行部署和更新。 有关详细信息，请参阅连接到语义模型。

在本地化中，另一个重要概念是为增长做规划。 用英语显示时宽度为 400 像素的标签在翻译成另一种语言时可能需要更大的宽度。 如果针对英文文本优化标签的宽度，你可能会发现其他语言的翻译引入了意外的换行符或被截断。 这些效果会对用户体验造成不利影响。

在开发国际化软件时，向本地化标签添加适当程度的填充是常态。 必须使用计划支持的每种语言来测试报表。 你需要确保报表布局与你选择支持的任何语言的显示效果一样。