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.0SAP 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 version1.0 encodingUTF-8? xliff version1.2 xmlnsurn:oasis:names:tc:xliff:document:1.2 file originalTEXT/DDIC/DATATYPE source-languageen target-languagezh datatypeplaintext body trans-unit idZFI_ACC_DOC_NO sourceAccount Document Number/source target会计凭证编号/target statefinal/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 解析就会失败。比如目标文本里写了一个裸的没转成amp;导入时必然报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才能拉到新语言文本。用旧标签页反复刷新没用必须硬刷新CtrlF5或重新登录启动台。另外 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 BelegClearing 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 格式控制好语言代码不出错发布后记得验证缓存和传输大部分问题都能提前规避。希望这篇指南能让你在接到翻译文件时不再把一下午耗在那个绿色按钮点了没反应的界面上。