做SAP项目的朋友应该都遇到过这种场景系统要支持多语言程序里的按钮、消息、表字段标签几百上千条文本靠SE63一条条手工翻译能翻到怀疑人生。Maintain Translations事务代码SLL2就是专门干这个活的——它把翻译对象集中管理支持导出/导入XLIFF文件可以让外部翻译公司或CAT工具协同完成本地化工作。这篇内容就是围绕SLL2中上传已翻译的XLIFF文件 → 发布 → 生效这条完整链路把每个环节的实操细节和坑都交代清楚。无论你是刚接手翻译任务的初级顾问还是被多语言上线折磨过的项目经理照着做都能少走弯路。1. 认识Maintain TranslationsSLL2与XLIFF工作流1.1 SLL2在SAP翻译链路中的位置SAP系统的多语言机制值得先捋一捋。系统里每个文本对象程序文本符号、消息文本、数据元素标签、屏幕元素等在初始状态下只有源语言通常是英文文本。当用户用其他语言登录时系统会根据当前登录语言去查找对应语言的翻译文本找不到就显示源语言。SE63能做手工翻译但它的定位是一个对象一个对象地去翻处理几十条可以面对上千条文本效率太低了。SLL2Maintain Translations则是从对象集合的维度来管理翻译。你可以按对象类型、名称、语言等条件批量筛选出所有待翻译文本然后集中导出、打包、交给外部翻译资源处理完成后批量导回、逐条审核、发布。这套流程在企业级项目中几乎是标准做法。SLL2在SAP菜单里的路径是Tools → Translation → Maintain Translations不过绝大多数人直接在GUI里输Tcode SLL2进方便得很。在翻译链路里SLL2的位置是调度中心和审核仓。它负责翻译对象的选择与分发也负责翻译文本的入库审核。它并不替代SE63去编辑具体翻译内容而是把SE63能做的批量操作统一收纳进来。可以说懂SLL2是做好SAP翻译项目的基本功。1.2 为什么用XLIFF而不是SE63手工翻XLIFFXML Localization Interchange File Format是OASIS定义的一种开放标准格式专门用于本地化工具的翻译数据交换。SAP从较新的版本开始支持XLIFF的导出与导入使得SAP翻译可以跟外部主流翻译工具Trados、memoQ、Passolo等无缝衔接。选择XLIFF而不是手工编辑对项目的影响是实实在在的。第一外包翻译场景下你不可能把SAP GUI的账号开通给翻译公司的译员把翻译任务打包成XLIFF文件发出去是最安全的协作模式。第二XLIFF文件是纯文本格式带完整的原文上下文和翻译占位符定义CAT工具可以借助它做翻译记忆匹配、术语一致性检查和批量质量校验这比人工肉眼校对靠谱得多。第三XLIFF文件本身可以纳入版本管理追溯每一次翻译变更这对多轮迭代和事后审计非常重要。1.3 环境准备权限与语言配置动手之前先确认三件事缺一不可。第一是SAP账号权限SLL2涉及翻译写入需要S_TRANSPRT授权对象以及对应语言的S_LANGU权限。如果没有权限打开后一片空白或者提示没有执行此功能的授权这在项目初期的常见卡点是权限角色还没配好找权限顾问加一个就完事。第二是目标语言是否在系统中激活。进入事务代码SCC4或SMLI里可以看到已安装的语言版本。如果目标语言连语言包都没装翻译文本导进去也没地方存SLL2操作界面里甚至可能选不到该语言。第三是传输请求设置。SLL2中的发布操作在开发系统上往往要挂在传输请求下才能把翻译带回测试/生产系统所以需要确认当前客户端允许创建请求或者你已经分配了一个有效请求。这三点是基础任何一项不到位后面的操作都会卡脖子。2. 从SLL2导出翻译对象为XLIFF2.1 选择翻译对象的维度与范围进入SLL2后界面上方是查询条件区关键维度有三个对象类型、对象名称、源/目标语言。对象类型决定你筛出来的文本长什么样比如PROG是程序文本元素、CLAS是类、DTEL是数据元素、MSG是消息、SCRN是屏幕。对象名称支持通配符比如要处理所有以ZPP开头的程序就填ZPP*。选择对象范围时有个经验之谈不要一次性把所有对象类型都选上更不要选全系统范围。一方面不同对象类型的文本特点不同混在一起导出的XLIFF文件会很庞大后续审核和回传容易混乱另一方面SAP系统的标准文本如SAP自带程序的文本一般已经在语言包中提供自己翻译反而会覆盖官方翻译得不偿失。建议以项目自开发对象为主体按程序前缀或功能域分组分批次处理。语言维度的设定也很关键。源语言通常选英文E目标语言选你要翻译的语言如中文1H。在界面上选择好这三个维度后回车下方列表会列出符合条件的全部翻译条目每条显示文本键、源文本、现有目标文本和翻译状态。对于还没翻译的条目状态是红色或空白已有翻译但未发布的显示黄色已发布的是绿色。导出前先浏览一遍列表确认筛选结果的集合是符合预期的再执行导出。2.2 导出XLIFF的操作步骤选中需要的条目可以多选点击工具栏或菜单中的导出XLIFFExtras → Export XLIFF。系统弹出对话框需要配置几个参数。XLIFF版本建议选1.2兼容性最好。SAP支持1.2和2.0两种规范但CAT工具对2.0的支持成熟度参差不齐除非工具明确支持2.0否则用1.2更稳。导出范围一般选全部已修改和未翻译的文本这样文件里是真正需要翻译的内容不会混入大量已经发布过的历史文本。文件编码必须选UTF-8这是后续能正确导回的重要前提。确认参数后指定本地保存路径点击继续SAP会生成XLIFF文件。生成速度取决于文本量几百条是秒级几千条也就十几秒。导出后我建议用记事本或VS Code打开文件抽查一下确认里面包含的trans-unit数量与SLL2列表中选中的条目数量一致再做分发。这一步看起来多余但能及时发现选错了对象范围或语言方向的问题比文件发给翻译公司之后再返工成本低得多。2.3 看懂XLIFF文件结构XLIFF文件的理解难度不大核心就几个元素。以一个SAP导出的典型文件为例?xml version1.0 encodingUTF-8? xliff version1.2 xmlnsurn:oasis:names:tc:xliff:document:1.2 file originalZPP_MATERIAL_LIST source-languageen target-languagezh datatypeplaintext body trans-unit id001 resnameTXT001 sourceMaterial Number/source target物料编号/target /trans-unit trans-unit id002 resnameBTN001 sourceDisplay amp;1/source target显示 amp;1/target /trans-unit /body /file /xliff这里的file标签的original属性对应SAP对象名source-language和target-language用ISO语言代码en、de、zh等。每条翻译在body下的trans-unit中id或resname对应SAP侧的文本键source是原文target是要填写的译文。注意source中的变量占位符如1、%2在翻译时必须原样保留在target中对应位置这在CAT工具里一般是作为占位符锁定的但人工翻译Word版时经常被误改我在后面会专门强调。理解这个结构对排查问题的帮助非常大。凡是上传失败的情况十有八九都能从文件结构上找到原因要么是file的original名字不对要么是trans-unit的id被人为改动要么是target-language和SLL2里选的目标语言不一致。3. 上传已翻译的XLIFF文件3.1 上传前的检查清单翻译公司把文件回传后别急着点上传按照下面这张清单过一遍能省很多麻烦第一编码检查。用VS Code或记事本打开文件确认是UTF-8编码、没有BOM头。如果文件被某些Windows工具保存成ANSI或GBK直接上传必然乱码。第二结构检查。打开文件确认xmlns命名空间还在、xliff根标签完整、所有trans-unit都有source和target。部分工具会把已经翻译过的target节点替换为空这种文件上传后SAP会认为该条目仍然未翻译白白浪费一轮。第三占位符检查。把每个trans-unit的source和target里的1、%1、#等占位符逐一比对数量不一致的要退回重新处理。第四对象与语言比对。确认file节点里的original与从SLL2导出时选的对象一致source-language和target-language与SLL2中设置的一致。第五去掉多余内容。有些翻译公司的工具会在XLIFF里追加备注、批注、自定义属性这些在SAP导入时可能触发解析告警建议用格式化工具清理后再上传。这张检查清单看起来繁琐但每一步都是实际项目的血泪教训换来的。我在一个项目里因为没检查占位符导致发布后程序运行时报参数数量不足的错误线上用户直接看到中文界面崩溃教训相当深刻。3.2 文件上传操作与系统校验上传入口和导出在同一个位置SLL2中菜单 Extras → Import XLIFF或者对应工具栏按钮。选择本地XLIFF文件后SAP先做文件解析然后执行批量导入。系统解析过程中会做几件事校验XLIFF文件格式是否符合标准校验file节点的original对象与当前选择的翻译对象范围是否匹配校验语言代码与SLL2当前筛选条件是否一致校验每条trans-unit的id在对象中是否存在。一旦发现不匹配项SAP会在日志中记录详细信息并跳过对应条目。导入完成后SLL2会在状态栏给出成功导入N条已跳过M条之类的汇总信息。我的建议是不要只相信汇总数字要在列表里抽查几条导入的翻译确认状态已经发生变化从红色变为黄色或绿色。如果发现跳过条目较多打开SLL2的日志菜单中显示日志或转到日志看具体原因大多数情况下是id不匹配或语言方向错误修正后重新导出、翻译、导入即可。一个常见操作误区是在SLL2中把筛选条件设成了已发布文本导致导入的翻译没有落到当前列表里。解决方法是把筛选条件放开一些或直接在全部文本视图下观察变化。3.3 上传后的状态与数据校验上传成功后翻译条目在SLL2中的状态会从未翻译变为已翻译待发布这是预期中的正常现象。此时如果去SE63查看也能看到这些翻译文本但它们尚未真正生效用户登录系统看到的还是旧文本或源语言文本。在发布之前建议先做一轮独立的数据校验而不只是依赖文件导入成功的提示。最好的校验方式是回到SLL2的列表界面按对象类型和文本键将源文本与译文对照浏览。重点检查三类问题译文是否完整有没有空target译文是否包含品牌相关的不规范翻译特殊字符有没有被错误转换比如句点变全角、引号变中文引号导致程序消息格式异常。如果项目里有测试顾问或业务关键用户也可以安排他们在测试系统里通过SE63的预览功能核对翻译效果。不过SE63的预览只能看到文本本身看不到程序运行时的上下文。更稳妥的做法是让业务用户在沙箱系统中用目标语言登录实际执行相关功能观察UI上的译文是否符合文案规范。这一步做完再发布效果会好很多。4. 发布翻译并确认生效4.1 单条发布与批量发布的执行方式发布操作在SLL2中非常直接。单条发布选中目标语言文本已经正确的条目点击工具栏上的发布按钮一般是一个带对勾的图标系统弹出确认提示说明发布后现有翻译将被覆盖点击确认即可。批量发布按住Ctrl或使用CtrlY的矩形多选模式选中多条符合要求的条目再点击发布按钮SAP会逐条执行发布并显示成功/失败计数。这个功能在处理数千条文本时价值很大不用一条条点。但这里有一个重要的经验批量发布前一定要确认所有选中条目都是已翻译待发布状态且译文质量没有问题。SAP在批量发布时不会对译文内容做语义审查只做格式和长度校验一旦你误把不合格的译文发布出去回滚的成本远高于逐条核对的成本。我在项目上一般是先批量发布一部分比如一个程序对象让开发或测试验证样式无误后再推进剩余部分。4.2 发布背后的机制与影响范围发布的本质是把目标语言文本写入SAP的语言存储表。不同类型对象的文本存储位置不同比如程序文本符号存在TEXT/TEXTS类表中消息文本存在对应消息类的T100表中数据元素标签存在对应数据元素的文本表中。写入后文本对象的翻译版本被标记为已发布运行时语言解析会直接拾取该版本。发布后翻译的生效范围要分两种情况看待。对于程序、类、消息这类在ABAP运行时编码中解析的文本发布后不需要重新生成新会话中切换到目标语言登录时即可看到新翻译。但对于一些涉及UI渲染缓存的对象比如屏幕元素标签、GUI标题可能需要重新激活相关程序或刷新SAP GUI本地缓存后才生效。另外如果用户当前已经打开了会话里面的文本缓存不会自动刷新重新登录或切换语言后才会看到变化。另一个容易被忽略的影响是传输请求。在开发系统中发布翻译时如果系统配置要求翻译对象纳入传输管理一般是的开发/测试/生产三系统架构下SAP会让你指定或创建一个传输请求翻译内容会作为一个任务记录在该请求下。发布本身不负责传输它只是把数据写到开发系统的语言表里你还需要通过传输请求把翻译带到下游系统。如果忘了这个环节开发系统上翻译好好的测试/生产系统切换目标语言后还是老文本这是项目中最常见的翻译不生效类问题之一。4.3 发布后的多维度验证发布完成后验证工作不能省。最直接的验证在SAP GUI中复制一个新会话用目标语言登录通过GUI状态栏的语言切换或重新登录运行相关对象比如执行被翻译的程序、调用包含翻译消息的场景观察界面上的文本。对SAP自身标准界面语言包一般已经包含翻译看到的大多数是官方翻译对自开发的程序这就是验证我们翻译成果的关键场景。二次验证建议放在数据层面查询语言存储表确认对应的目标语言条目已经写入。查询方式取决于对象类型比如要验证程序ZPP_MATERIAL_LIST中的文本符号翻译可以用事务代码SE63打开该程序的语言页签查看也可以看SLL2中条目的状态图标是否为绿色。部分老顾问会直接看表数据例如消息文本查T100表字段标签查DD03M相关文本表。对于代码相关的对象我更推荐SE63和SLL2的组合验证操作可视化程度高几乎不会误判。验证完成后还有一项收尾工作记录发布日志。SAP本身会记录翻译变更但如果项目有外审或客户验收要求建议在项目交付文档中整理一份翻译发布清单列明对象类型、对象名、文本键、译文、发布日期和传输请求号。这样万一后期某个翻译需要回退或排查能快速定位到发布版本。5. 常见问题与实战排查5.1 上传失败类问题速查上传XLIFF报错是大家遇到最多的场景我把常见的几类错误和解决办法整理一下。错误现象常见原因处理办法文件解析失败文件编码错误或XML结构被破坏用文本编辑器重新保存为UTF-8检查XML标签闭合导入日志提示未找到匹配对象file节点的original与SLL2选定对象不一致回SLL2确认对象类型与名称重新导出再翻译所有条目被跳过target-language与SLL2目标语言不一致检查ISO语言代码映射zh vs 1H等导入成功但列表无变化当前筛选条件排除了相关条目放开筛选条件在全部文本视图下查看部分trans-unit报id异常翻译工具改写id属性重新导出原始XLIFF用差异对比工具合并译文这里要特别强调id异常的问题。少数CAT工具在导出时会把trans-unit的id当作自定义字段重新生成SAP导入时按id匹配原文一旦id变了就找不到对应文本整条被跳过。排查方法是用文本对比工具我用的是Beyond Compare对比原始XLIFF和回传文件凡是id、resname被改动的trans-unit手改回原始值就行。5.2 翻译状态异常处理SLL2中常见的状态异常包括上传后条目显示黄色已修改待发布但发布时报错提示对象已被修改或者发布后条目依然是黄色状态一直跳不过去。对象已被修改的根源通常是导出XLIFF之后开发人员又修改了该对象的源文本比如程序文本符号的原文变了导致上传时SAP发现文本版本与导出时的基线不一致。处理方式不是硬发布而是重新导出最新版本然后借助翻译记忆或差异对比把之前已经翻好的译文合并到新版本中。说白了就是做一次版本间的人工合并。状态异常还有一种情况是源语言和目标语言在系统中配置的双语代码方向与XLIFF中的声明不一致。比如SLL2里源语言选了英文但XLIFF文件里source-language被工具改写成了zh上传时SAP会认为语言方向错误目标语言文本被写入错误缓冲区。优先检查XLIFF头部的语言声明与SLL2界面条件保持一致。另外发布后状态依然黄色还有一个常见但容易被忽略的原因该文本被纳入了翻译工作包Translation Package只能在拥有包处理权限的请求下发布。这种场景多见于较大的项目启用集中式翻译管理找包负责人确认权限或调整包归属即可解决。5.3 项目中容易踩的坑第一个坑是占位符错位。SAP文本里的1、%1、%_等占位符对应程序运行时的动态参数翻译时位置可以调整但数量不能变。比如原文Material 1 not found in plant 2中文译成在工厂2中未找到物料1是没问题的但如果翻译漏掉其中一个占位符程序运行时就会抛异常。这个坑最容易发生在人工翻译或机器翻译后人工校对时因为译员不理解占位符的含义。建议在上传前用脚本自动比对每个trans-unit中source和target的占位符数量。第二个坑是文本长度。SAP的文本元素和消息文本都有长度限制程序文本符号通常有20/40/60等字符档位消息文本最长72个字符中文译文比英文一般短但偶尔会遇到译文超长。SLL2导入时对长度校验是宽松的有可能显示出导入成功但发布后运行时报文本长度超出目标字段。处理方法是发布前在列表中检查译文长度超长的提前压缩或请求开发调整文本长度定义。第三个坑是多人协作时的重复发布。项目中如果有多个顾问在翻译不同对象发布前没有沟通好对象范围很容易出现A发布了B正在翻译的对象导致B的译文被覆盖或版本冲突。建议项目里用一张翻译对象分配表管理每个人的工作范围发布前核对分配表中是否标记为已发布。5.4 批量场景下的优化技巧文本量大到几千上万条时有没有办法提升效率有几个实战技巧可以分享。第一利用XLIFF导出时的对象分片。把程序按前缀分组、把数据元素按逻辑模块分组每组导出一个小文件。这样翻译公司可以多人并行处理不同文件且每个文件的翻译风格更容易保持一致。第二建立术语表。在翻译前维护一份项目术语清单比如物料这个词在全系统统一翻译为物料而不是材料翻译公司依据术语表进行翻译可以减少后期大量返工。术语表可以直接附在XLIFF文件的备注中或者单独文档随文件一起发送。第三善用批量发布与分段验证的组合。不要等到所有文本一次导入完再统一发布而是按对象或按批次每完成一批就发布一批、验证一批问题早暴露、早解决。第四脚本化质量检查。对于几千条文本人工逐条核对占位符和长度不现实。可以写一段Python脚本读取XLIFF文件自动检查占位符数量一致性、target是否为空、译文长度是否超限。我把自己常用的检查脚本贴在下面各位根据项目情况调整即可。import xml.etree.ElementTree as ET ns {xliff: urn:oasis:names:tc:xliff:document:1.2} tree ET.parse(translation.xlf) for trans_unit in tree.findall(.//xliff:trans-unit, ns): source trans_unit.find(xliff:source, ns).text or target trans_unit.find(xliff:target, ns).text or src_phs set(source.replace(%_, ).split()[1::2]) tgt_phs set(target.replace(%_, ).split()[1::2]) if src_phs ! tgt_phs: print(f[占位符不一致] {trans_unit.get(id)}: {source} - {target}) if not target.strip(): print(f[空译文] {trans_unit.get(id)}) if len(target) 72: print(f[超长] {trans_unit.get(id)}: {len(target)} chars)这段脚本的逻辑很简单提取source和target中所有以开头的占位符集合比对两组是否相等同时检查空译和长度。我在实际项目里跑一遍几千条文本几秒钟就能定位所有问题。要注意的是占位符除了1、2这类还有%1这种ABAP格式占位符示例代码里做了简单归一化项目里如果占位符形态更复杂正则写法需要对应调整。写在最后最后再分享一点个人体会。SLL2这套流程技术上并不复杂真正的门槛在于流程纪律。导出、翻译、导入、发布每一步都有看似不起眼的检查项省掉哪一步后面都可能以翻倍的成本补回来。尤其是占位符、编码和传输请求这三个点我在不同项目里反复踩过每次都是线上用户反馈问题之后才追根溯源发现是翻译流程的细节没盯住。建议各位把文中的检查清单和脚本保存下来作为项目交付物的一部分每次执行翻译任务时按清单走一遍。熟练之后一次几千条文本的发布也就半小时的事但能保证全程不出差错。如果你在项目中遇到了别的SAP翻译问题也欢迎留言交流一起把这个流程打磨得更稳。