SAP 里的翻译管理，看起来是个小众活儿，可一旦遇到客户上线 S/4HANA 云或本地部署版，需要把十几个自定义字段的标签从中文翻成英德日，外部翻译公司交回来一堆 XLIFF 文件，而你在 Maintain Translations 里点了半天，翻译就是"不生效"——这时候你才会意识到，搞定 XLIFF 上传和发布，是整个翻译流程里最容易被低估的一环。
这篇内容就围绕 SAP Maintain Translations 这个 Fiori 应用，把"拿到已翻译 XLIFF 文件之后该做什么"这件事讲透：文件该怎么准备、上传时每个字段有什么讲究、发布到底发到了哪里，以及我在这条路上踩过的那些坑。不管你是刚接触 SAP 翻译顾问工作的小白，还是被客户追问"为什么翻译没出来"的项目顾问，照着这套流程走，至少能少折腾半天。
1. SAP 的翻译工作流里，Maintain Translations 到底扮演什么角色
先说清楚背景。SAP 系统里需要翻译的文本分为两大类：一类是 SAP 标准交付的文本，比如标准 TCode、字段标签、菜单描述，这类文本的翻译由 SAP 官方在语言包升级时统一处理，你基本不用碰；另一类是客户自开发的文本，包括自定义表字段的 data element 描述、自开发程序的文本元素、增强里的标签、甚至你自定义的枚举值描述，这些内容 SAP 语言包里不可能有，只能由项目组自己组织翻译。
Maintain Translations 这个应用（企业内通过 Fiori 启动台访问，对应底层基于 ABAP 的翻译工具链）负责的就是第二类里最常规的流程：把需要翻译的文本对象导出成 XLIFF 格式交给翻译人员，再把翻译公司交回的 XLIFF 文件导回系统，检查无误后发布，让这些翻译在运行时生效。
这里有个核心概念必须理清："上传"和"发布"是两件事。上传只是把 XLIFF 里的译文写入翻译存储区，相当于草稿入库；发布才是把译文标记为"已释放"，让它真正参与运行时文本解析。很多人在上传后打开界面发现还是原文，八成就是漏掉了发布这一步，或者发布时选的传输请求不对，译文根本没进入目标系统。
另外要说清 Maintan Translations 的适用范围。它处理的是"文本对象级"翻译（Text Object 级别），即一条条独立的、带对象类型的翻译单元，比如一个数据元素的描述、一个程序的文本元素。它不负责 BSP/Web Dynpro 那种页面级多语言资源文件的批量导入，那些内容通常有自己的传输通道。搞清楚边界，才不会拿错工具做错事。
2. 上传前必须想明白的准备工作：对象、语言和 XLIFF 规范
很多人在第一步就栽了：从翻译公司拿回的 XLIFF 文件，导入时报"Object not found"或者"Language not allowed"，然后一脸懵。这不是系统抽风，而是因为你没理解 Maintain Translations 对 XLIFF 文件的约束。
2.1 对象类型（Object Type）决定文件填在哪
Maintain Translations 界面里第一件事就是选对象类型和套件（Package），这个选择对应到 XLIFF 文件内部，是通过 XLIFF 的<file>标签的original属性或自定义扩展字段来标识的。SAP 的 XLIFF 导出工具会给每个文本对象编一个类似/SCMT/MSG_/BAL/MESSAGE、TEXT/DDIC/这样的类型前缀，导入时系统按这个前缀把译文对号入座到对应文本池。
所以准备工作第一步是：拿到翻译公司返回的文件前，先和你自己的导出记录对照一遍，确认对象类型、对象名和语言代码没被改动。翻译公司只是给你发回翻译内容，结构应该是原封不动的。
2.2 语言范围：为什么"目标语言"经常报错
XLIFF 文件里<file>标签的target-language属性，或者 ref 属性里的语言代码，必须严格使用 SAP 内部语言代码（如 zh、en、de、ja、pt）。此外 Maintain Translations 只接受"已经在系统语言配置里激活"的目标语言。如果你在 S/4HANA 里没维护某种语言的安装语言或者没有激活语言支持，即使 XLIFF 结构完全正确，导入界面也会用红字提示"Language does not exist"或类似信息。
我个人的习惯是：上传前先到 SPAD/SMLI 之类的语言配置里核对目标语言是否激活，不要等导入报错再回头查，来回折腾费时间。
2.3 XLIFF 版本选择：1.2 vs 2.0
SAP Maintain Translations 官方支持 XLIFF 1.2 格式，2.0 在部分组件上并不兼容。外部翻译公司如果交回了 2.0 版本文件，通常需要你在导出工具里调整模板或要求对方另存为 1.2。这个坑我实际踩过：有次客户从线上供应商拿到一批 XLIFF 2.0 文件，导入时界面直接提示格式错误，后来让翻译公司用 memoQ 重新导出为 1.2 版本就好了。
3. XLIFF 文件内容自查：结构、命名和常见报错
别以为翻译公司给的文件就"肯定没问题"。他们改的往往只是 target 节点的文本，但文件经过各种工具链转手，命名、状态属性和转义字符都可能被改动。上传前花十分钟自查，能省下导入校验反复报错的半小时。
3.1 一个合法的 SAP XLIFF 文件该长什么样
拿一个我实际处理过的数据元素描述来举例：
<?xml version="1.0" encoding="UTF-8"?> <xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2"> <file original="TEXT/DDIC/DATATYPE" source-language="en" target-language="zh" datatype="plaintext"> <body> <trans-unit id="ZFI_ACC_DOC_NO"> <source>Account Document Number</source> <target>会计凭证编号</target> <state>final</state> </trans-unit> </body> </file> </xliff>几个关键点：
<xliff>根节点版本必须是 1.2，命名空间尽量保持标准 OASIS 命名空间；<file>节点的original属性值就是对象类型标识，source-language 和 target-language 必须与导出时的原始语言、目标语言一致；- 每个
<trans-unit>的 id 对应具体文本对象名或键值，这个千万不能改，改了就等于把译文贴到另外一张脸上了； <state>节点虽然不是 SAP 校验的硬性字段，但建议保留，它表示翻译状态，final 或 signed-off 都比 translated 更稳妥；- target 节点为空时，系统认为该文本"未翻译"，不会覆盖原有内容。
3.2 转义与非法字符，最容易忽视的隐形杀手
翻译文本中经常出现引号、尖括号、和符号，如果翻译公司在导出时没有正确转义，XML 解析就会失败。比如目标文本里写了一个裸的&，没转成&，导入时必然报"XML parse error"。
我的经验是：拿到文件后用任意 XML 校验工具先过一遍语法，再进 SAP 上传。这一步成本极低，却能避开莫名其妙的数据丢失——系统有时不会拒绝整个文件，而是静默跳过有问题的 trans-unit，结果某些行没翻译成功，你还找不到原因。
3.3 文件命名不是随便起个名就行
虽然 SAP 上传界面允许你选任意本地文件，但文件名里的前缀和项目符号确实会被部分系统版本用于路径映射和包归属判断。稳妥做法是：以导出时的原文件名回传，只在文件名尾部追加语言代号，例如ZCUSTOMER_FIELDS_ZH.xlf对应中文、_DE.xlf对应德文，但不要改动其余部分。
4. 从上传到发布的标准操作流程与界面细节
准备工作做完了，下面走一遍我在项目中反复执行的标准流程。这套流程在 S/4HANA 2021 及更高版本的 Fiori 界面里都适用，本地部署和云环境差异不大。
4.1 进入应用并选择翻译对象范围
打开 Fiori 启动台，搜索 Maintain Translations 应用（应用 ID 通常是F3544或类似企业内部配置的别名）。进入后第一屏会让选择参数：
- 翻译对象类型（Text Object Type）
- 文本对象名称范围（支持通配符）
- 原始语言（Source Language）
- 目标语言（Target Language）
这里有个效率技巧：如果只是补充更新少量字段，尽量把范围缩窄，只选具体对象类型和对象名段，因为范围越宽，上传时系统匹配的候选翻译单元越多，校验耗时越长，还容易把无关文本的旧译文状态刷掉。
4.2 上传 XLIFF 文件的实际操作
在应用顶部操作栏选择 Upl/Import（不同版本叫法略不同，通常是一个向上的箭头图标，或者"Import XLIFF"），点击后上传本地文件。
文件上传后系统进入"导入预览/校验"阶段，等它跑完会展示校验结果：
- 可上传的翻译单元数量（Matched）
- 因错误被拒绝的数量（Rejected）
- 未匹配到任何对象而忽略的数量（Ignored）
先别急着点最终确认。我强烈建议此刻展开明细，逐项看 Rejected 和 Ignored 这两类。用"状态+原因"两张维度快速判断：Rejected 大概率来自语言代码不匹配或 trans-unit id 找不到对象；Ignored 则可能是原文件中 source 与系统原文不一致（比如你在导出后又改了字段描述），系统拒绝用这个译文覆盖。
这时需要回到 SE80/SE11 核对当前系统里那几行文本是否正确。如果是系统原文真的改了，那就让翻译公司按新原文重新翻译，这个旧文件里的对应行只能放弃。
4.3 上传成功之后：进入"翻译传输列表"准备发布
确认无异议后，提交上传。此时译文进入"草稿"状态，你可以在 Maintain Translations 的"维护翻译"列表里查询到这些文本，但运行时并不会使用新译文。
下一步是创建传输请求（Transport Request），把翻译内容纳入变更传输。在 Fiori 界面中，对应操作叫"发布"或"Add to Transport"：
- 点击发布/传输按钮，系统弹窗让你指定请求类型（Customizing Request 或 Workbench Request）；
- 选择请求号，可以新建一个，也可以塞进已有请求里；
- 确认发布范围，通常和你上传的文本对象范围一致；
- 保存并传输。
这一步是"从草稿变成已发布"的分水岭。发布完成后，翻译才写入对应表的激活状态，运行界面才会取到新语言文本。
4.4 翻译对象与传输的绑定逻辑
需要特别理解的是：SAP 的翻译发布并不是"全库更新"，而是针对特定文本对象创建翻译存储对象（Object Directory Entry），翻译内容随传输请求移动到目标系统。打个比方，XLIFF 上传到开发系统只是把译文放在"开发区的翻译库"里，发布到请求后，译文才和普通 ABAP 对象一样，经过传输链送到测试、生产。
所以，你在生产系统用 STMS 导完请求之后，记得要执行一次"同步翻译激活"或让 Basis 做翻译对象导入后处理，否则在某些版本里，译文对象导入到了目标系统但尚未激活，界面上还是显示原文。
5. 踩坑实录：我在生产环境里遇到的六个高发问题
光讲标准流程是不够的，实践里总会碰到标准文档没写的情况。下面这些坑我都在真实项目中遇到并解决过，几乎每个都能消耗半天以上工时。
5.1 上传后发布按钮是灰的
这次问题出在对象类型选错。客户同时有 S/4HANA 和 BTP 扩展系统，用户把对象类型选成 BTP 扩展的翻译对象（例如YPRD/EXT），但实际 XLIFF 文件是从 ABAP 系统导出的标准文本对象（TEXT/DDIC），系统认为"没有可发布的文本"，按钮自然不可用。
解决方式：回到查询界面上重新按导出文件里的original属性定位对象类型，再重新导入。教训是：导入什么类型的文件，查询和发布也必须在同一类型下。
5.2 发布完成，但 Fiori 界面还是显示原文
这是最经典的一个：传输请求成功、发布成功、目标系统也导入成功，界面依然是原文。查半天发现，Fiori 应用本身对文本做了缓存，翻译更新后需要清浏览器缓存或刷新 Fiori 用户资源（Catalog/Site）才能拉到新语言文本。用旧标签页反复刷新没用，必须硬刷新（Ctrl+F5）或重新登录启动台。
另外 VIP/角色缓存也会导致文本服务不定期失效，通常隔 10-20 分钟自动刷新。所以遇到这类问题，先深呼吸，排除缓存再做其他排查。
5.3 原文长度变短，译文被系统截断
文本对象在数据字典里有长度约束（比如数据元素的 Data Element 描述最大长度 60 字符）。如果目标语言翻译长度超标，上传校验阶段会报"Value too long"或直接截断。翻译公司不会管你的字段长度上限，所以发布前要留意这类风险。
尤其中文确实容易踩：中文字符在 SAP 内部按字符长度计，一个"会计凭证编号"只有 6 个字符，没问题，但"供应商主数据会计凭证编号的参考信息"就可能超 60 字符限制。处理办法只有两个：要求缩翻，或者考虑修改文本对象长度（一般不建议，波及面大）。
5.4 XLIFF 文件乱码与编码不一致
翻译公司返回的文件，如果头部的 encoding 声明是UTF-8，但实际文件内部夹杂了UTF-8 BOM，甚至某些字符用 ANSI 编码存储，导入后会在界面看到奇怪的问号或方块。解决方式：用 Notepad++ 或 VS Code 把文件转换为 UTF-8 无 BOM 格式，再重新上传。
5.5 语言代码的大小写敏感性
有次客户上传EN而不是en，系统秒拒。SAP 语言代码内部存储基本都是小写两字母（中文是zh，不是ZH），外部翻译公司有时会习惯性写成大写，导入前批量替换即好。
5.6 校验时大量对象 Ignored，原因是源文本已更改
一种特别隐蔽的场景：导出 XLIFF 后，业务顾问因为调整描述文案，又改了一次系统里的源语言文本。等翻译完成回传，XLIFF 的 source 节点和系统当前原文不一致，被系统标记为 Ignored。
这时候千万不要强行改 XLIFF 的 source 去骗过校验——那会造成译文和系统文本错位，运行时可能出现"旧译文挂新文本"的怪现象。正确做法是通知业务方确认以哪版为准，如果是新文本，必须重新给翻译公司提供最新 XLIFF 文件。
6. 一次完整的端到端操作复盘（从导出到发布验证）
为了让上面的流程更落地，我把上周刚做的一个小任务完整复盘一遍，案例是给 ZFI001 识别的 5 个自定义字段增加德语描述。
6.1 第一步：导出未翻译的 XLIFF
打开 Maintain Translations，选择对象类型为TEXT/DDIC，对象名前缀ZFI*，源语言en，目标语言de。查询结果里列出系统里已有的英文描述文本和德语空值文本。点击 Export，系统生成一个ZFI001_TEXT_EN_DE.xlf文件，结构包括全部 5 个字段对应的 trans-unit。
这里要注意，对象类型TEXT/DDIC是数据元素文本对象，字段里还有TEXT/DDIC/STXT等更细的类型，导出时选择错误会导致查询为空。
6.2 第二步：外部翻译并回流
我把文件发给翻译人员，约定了字段术语表：Account Document Number固定译为Kontonummer Beleg，Clearing Document译为Ausgleichsbeleg。翻译人员回传文件后，我先在本地用 VS Code 打开，确认：
- XML 语法通过；
- 5 个 trans-unit 的 id 没变；
- target 节点全部有值；
- 文件尾部没有多余的空行或 BOM。
6.3 第三步：校验并上传
回到 Maintain Translations，范围仍选ZFI*，导入文件。校验结果为 4 个 matched、1 个 rejected。明细一看，rejected 那行的语言代码被翻译工具写成了de-DE，带地区后缀，SAP 内部标准语言代码不接受。我直接在本地文件里把de-DE改成de，重新上传，这次 5 个全部 matched。
6.4 第四步：发布到传输请求并验证
上传后，在维护翻译列表里查询到 5 条德语记录，状态为"草稿"。点击发布，新建一个 Workbench 请求ZDEVK900123，把 5 条文本绑进去。保存后到 SE03 确认请求内确实包含 5 个翻译对象，然后释放请求。在测试系统，用 STMS 导入该请求。
导入完成后，到 SE11 打开其中一个数据元素，勾选 Display in Other Languages 或者直接在登录语言为德语时查看 F1/字段描述，确认德语文本已显示。这一步下次记得做，不然你根本不知道目标系统到底有没有激活。
7. 关于发布策略和后续维护的几句实在话
翻译和普通 ABAP 开发对象不同，它不会触发语法检查，也不容易在传输前发现错误。所以基于我的经验，最后分享三条工作习惯，也许能帮你少被领导半夜电话叫醒：
第一，翻译一定要跟着版本走，不要跨版本乱发。比如 7 月刚发布过一版德语翻译，9 月又改了几处原文，那就只追加改动部分的译文，别把整个文件重新传一遍覆盖旧版本，否则容易把之前已经确认过的术语给冲掉。
第二，务必保留 XLIFF 文件的版本历史。哪怕只是改了一个词，也要和翻译公司走一遍文件版本确认流程。我在项目中用命名后缀区分生效版本（比如_v2.xlf），配合翻译术语表，基本杜绝了"改错地方"的问题。
第三，把"发布"操作和 Basis 的传输时间窗对齐。我遇到过一次很尴尬的场景：周五晚上发布了一批翻译并释放请求，但 Basis 计划在下周一统一搬测试，偏偏中间有人改了源文本，导致翻译对象到测试系统后处于"Inconsistent"状态。如果当时我能和 Basis 确认好传输时间，就不会出现这种夹生状态。
翻译上传发布这件事，做的次数多了之后你会发现，它本质上是一个"格式纪律 + 流程纪律"的问题：XLIFF 格式控制好，语言代码不出错，发布后记得验证缓存和传输，大部分问题都能提前规避。希望这篇指南能让你在接到翻译文件时，不再把一下午耗在那个"绿色按钮点了没反应"的界面上。
