HelloWorld 的富文本翻译在大多数日常场景下能保留原文的结构与常见样式（段落、标题、粗体、斜体、列表、链接与简单表格），但在遇到复杂排版、嵌入对象、动态样式或平台专有格式时，可能出现样式偏差或需要人工微调以恢复精确布局与视觉一致性。

先弄清楚“保留格式”到底指什么

想知道富文本翻译能不能“保留格式”，先别急着看技术细节，先把问题拆成几块：文本内容、文本结构、样式属性、布局与嵌入对象。这四项分别代表不同层面的信息，只有把它们分开来看，答案才不糊涂。

• 文本内容：字面上的文字，这是翻译的核心。
• 文本结构：段落、标题层级、列表项、表格单元格等，决定信息的逻辑和顺序。
• 样式属性：字体、大小、颜色、粗体、斜体、下划线、链接样式等，影响视觉呈现。
• 布局与嵌入对象：复杂表格合并单元格、图表、文本框、脚注、脚注编号、方程式、嵌入媒体或交互组件。

HelloWorld 在各层面上的实际表现

一句话：对文本与基础结构支持很好，对复杂布局或平台专有样式则有限制。下面用表格把常见元素和支持程度列出来，方便参考。

举个常见例子来说明

想象你有一份公司手册，包含标题、两级目录、表格与一些强调文字。把这份文档交给 HelloWorld 翻译后：

• 标题和段落通常能一一对应，结构没问题。
• 粗体和斜体等强调样式往往会被保留。
• 简单的表格行列也许能保存，但如果表格里有合并单元格、图形或嵌入Excel图表，翻译系统可能把这些部分导出为文字或图片，呈现方式有差异。
• 页眉页脚、页码和交互式元素（比如表单字段）通常需要额外处理。

为什么会出现格式偏差？用费曼方法解释一下

把文档想像成“层层叠的透明纸”：最底层是文字，上一层是样式，顶层是布局和互动。翻译系统最擅长拿走最底层的文字内容并替换成另一种语言，但上层的“墨水标记”和“纸张折痕”要完全一模一样地复原，就像想把不同语言的文字塞进原本为另一种语言设计的盒子里——有时候会不太合适，得重新微调。

技术层面的具体原因

• 语序与长度差异：不同语言句子长短不同，原有排版空间可能不足或过剩。
• 样式依赖平台：某些字体或CSS样式是平台特有的，目标环境可能不支持。
• 格式转换损失：从 PDF、DOCX、HTML、Markdown 之间互转，标记可能丢失或被重写。
• 嵌入对象不可解析：图片中的文字可能需要 OCR；图表与表单字段通常无法直接翻译成结构化文本。
• 语言方向与排版规则：从左到右语言变成从右到左或字体属于复杂脚本时，会触发行间距和对齐变化。

实际操作时的分步建议（用户向导）

不想在翻译后又花时间修格式？按这个流程来准备和校对文档，很多问题可以在源头避免。

步骤一：判断原始格式并选择合适的传入格式

• 如果是结构化内容（网页、文档手册），优先使用 HTML 或 DOCX 而不是 PDF。HTML 与 DOCX 更容易保留语义与样式。
• 如果来源是图片或扫描件，先用高质量 OCR 提取文本，再处理样式。

步骤二：简化与标注（预处理）

• 把重要样式如“不要翻译”“保持原样”“品牌名”用标记标注出来。
• 将复杂的表格或图表导出成可编辑的结构（例如表格转换为 Excel，再将文本列导出）。

步骤三：选择合适的翻译输出格式

• 需要对接排版系统时，优先选择 XLIFF 或 DOCX 格式的双语包，方便原样回写。
• 网页内容建议保留 HTML 标签并使用内联样式或样式表说明，减少转换时的样式丢失。

步骤四：校对与微调（人工不可少）

• 注意检查段落换行、表格单元格合并状态和列表嵌套级别。
• 针对长文本，评估翻译后文本长度对版式的影响，必要时调整字体大小或行距。

不同文档类型的具体建议

DOCX / Word

• 优点：结构化良好，样式可保留到较高程度；支持嵌入样式与表格。
• 建议：保留样式名称（Heading1、Normal 等），导出或导入时使用 DOCX 原生 API，避免先转成纯文本再翻译。

HTML / 网页

• 优点：语义化标签（h1、p、ul、table）利于保留结构。
• 建议：把本地样式表（CSS）和脚本分离，翻译时保留标签内容，不要改变 DOM 结构；对内联脚本或动态文本，采用数据层（JSON）翻译。

PDF

• 问题点：PDF 更像“最终输出”，很多是图形化的，文本层可能缺失或被嵌为路径。
• 建议：如果可能，找到源文件（如 Word、InDesign），在源文件层面翻译；若必须在 PDF 上操作，先做高质量 OCR，再尽量将文本映射回原位置。

Markdown / 简单标记语言

• 优点：结构清晰，易于程序化处理。
• 建议：翻译时保留标记，直接替换内容部分，保持代码块与注释不被误译。

面向开发者：如何集成 HelloWorld API 以保留富文本

若你在开发中集成 HelloWorld 服务，以下是几条实战建议：

• 优先使用格式化输入输出接口（如支持 DOCX/HTML 的接口），而不是把内容先剥离为纯文本。
• 使用双语格式（XLIFF 或 Excel 带列的方式）进行批量翻译，翻译后再回写到原始文档结构。
• 处理表格时，把单元格内容抽取为单元格级的翻译单元，保留合并信息作为元数据，翻译后再根据元数据恢复合并。
• 对嵌入对象（图表、图片），保留占位符（如 [[图1]]），在翻译交付清单中同时提供替换文本或翻译后的说明。

常见问答（FAQ）

Q：翻译后字体会完全一样吗？

A：不一定。HelloWorld 会尽量保留字体样式的标记，但目标环境不一定有相同字体，或者翻译后文本长度改变导致视觉效果差异。最佳做法是在交付前确认所需字体并嵌入或替换为通用字体。

Q：表格里合并单元格的问题如何解决？

A：把合并信息作为元数据导出，逐个单元格翻译，然后在回写阶段恢复合并；或在源文件中先拆分为独立单元格、翻译后再合并。

Q：PDF 里的图像文字如何翻译？

A：需要先做 OCR，将图像中的文字提取为文本，再翻译并通过图像编辑或替换生成最终页面。如果图像含有复杂图形，通常把翻译稿作为替换图层交付设计人员处理。

工具和标准：能帮你更好保留格式的那些东西

• XLIFF：一种行业标准，用于在不同本地化工具间交换翻译内容，能保留很多元数据。
• CAT 工具（例如 SDL Trados、MemoQ 概念）：这些工具能处理 DOCX/HTML/XLIFF，保留标签与样式信息。
• 版本控制与术语库（TM）：保持术语一致有助于减少手动修订，且能在回写时提高保留率。

一个小清单：提交文档给翻译前请检查

• 是否有源文件（首选）而不是仅有 PDF？
• 是否标注了不需翻译或需保留的片段？
• 是否导出表格的元数据（合并单元格、列宽）？
• 是否提供目标显示环境（网页、手机、印刷）以便调整版面？

写到这里，顺手给你一句比较生活化的提醒：如果你是做国际化交付的人，把“先把格式想清楚，再交给机器翻”当成习惯，会少很多返工。说不定还有哪儿想起来要改的细节——那就顺手改了。