翻译一份几十页的合同或手册时，正文往往已经换好了语言，页脚却先露馅：原来每页递增的「第 3 页 共 36 页」，变成每一页都印着同一个「第 1 页 共 36 页」。
这和正文里的脚注编号不是一回事（脚注见 Word 文档翻译时，脚注和尾注的编号会不会跑位）。这里谈的是页面底部、随翻页变化的页码。
页码不是写在纸上的数字
在 Word 里，「第 3 页」里的 3 通常不是作者敲进去的。它是一个会重算的域：当前页用 PAGE，总页数用 NUMPAGES。Word 更新域时——例如某些重新分页或打印操作中——会按真实页序计算数字。
普通翻译工具看到的却是上次保存时留下的缓存文字——一个普通的「3」。于是它把整句「第 3 页 共 36 页」当散文送去翻译，再把「Page 3 of 36」当作纯文本写回去。域没了，数字冻住了。三十六页文件里，每一页都显示同一个数，比页脚留在中文更难看。
还有一层更容易漏：Word 页码库里有些设计会把数字放在浮动形状的文本框中，而不是页脚段落里，页脚段落本身几乎是空的。只扫普通段落的工具会判定「页脚没有字」，整段页脚连翻译都进不了。
该保护的是计算，不是整段页脚
页脚里并不全是「不能动的域」。PAGE、NUMPAGES 这类会自己更新的内容需要留下来；同一页脚里的 HYPERLINK 显示文字（「返回封面」「公司官网」）却是作者写的，应当照常翻译。一律当成不可碰的结构，链接文字会静默漏翻。
SimplifyAI 处理这类页脚时，大致做三件事：
- 只保护会重算的部分，周围的「第」「共」「页」送去翻译。目标语语序可以变：英语是
Page 3 of 36，日语常见36 頁中の 3 頁，数字仍是活的域。 - 页脚段落和文本框都扫到。Word 读一套较新的文本框写法，WPS 和部分旧阅读器读另一套回退形状——译文两边都写，避免「Word 里对了、别人打开是空的」。
- 宁肯少一个数字，也不把句子填进页码。模型如果漏掉了页码该在的位置，句子会留下、页码空着。系统会记下这次错位，供校对时核对。绝不会把整句译文塞进域的缓存结果——那正是「三十六页同一个数」的来源。
打开 Word 之后，页码仍由 Word 自己按页重算。我们不代替 Word 刷新域。
目前做得到、做不到的
机器会自动处理：识别页眉页脚里的页码域、翻译周围文字、把域按目标语语序放回去，并覆盖文本框里的页码。
仍建议人工看一眼：页脚里若还有公司地址、密级、文件编号，确认语气和术语是否合适；分节后的「目录用罗马数字、正文从 1 重新起」这类设置，翻译不会改你的分节规则。
目前不会替你做的：目录条目旁边的页码（那是另一套 PAGEREF，留给 Word 在更新域时重算，见 Word 翻译后目录怎么还是原文）；把 PDF 上「看起来像页脚」的重复页眉提升成真正的 Word 页脚。
适合什么文件
公司模板里页脚固定、又必须随页数变化的合同；译完还可能微调行距、总页数会变的说明书；需要分发给只用 WPS 或网页预览打开的同事——他们不会、也常常不能按 F9。
结语
长文档翻译的破绽，经常出在正文以外。把带页码页脚的 Word 上传到 SimplifyAI 试一次，看译完后向下翻页，数字是否还在动。