示例 - #5208 ### 定义 翻译笔记/翻译说明（暂名）是一种记录翻译过程中某条或某类译名的形成过程、参考来源、译员思考的文档。 > 定义/名称可能可以找一个标准翻译/国标里的东西来修正 ### 需要做的工作 - 确定一个或一类翻译笔记的文件名。 - 可能的半结构化文件格式规范方便机器识读。 - 将倡议写入相关贡献指南，
Activity
SlimeSB commentedon Jul 30, 2025
#5208 译后记与最终做出的更改并不完全一致，因此没有在此仓库留档。在写完译后记过了几天重新审查自己的翻译时，又有了一些新的体会。
面对这些“过时”的想法，其实我是有些害羞的，因为当时没完全弄懂就写下来，而且还写得信誓旦旦的。
但是与此同时我认为这些思考过程可以供一些译者参考，犯错并不可怕。
#5208 的译后记已迁移至 https://github.com/SlimeSB/SlimeSB/tree/main/doc
就我在写此译后记的体验，我对未来的相关区域建设建议如下：
其他后续待补，或到此为止。
mamaruo commentedon Jul 31, 2025
谢谢史哥的的建议。回应如下：
总的而言，该建议是我观察到原版翻译长期缺乏翻译解读的境况，看到 #5208 后成文 issue。
我希望能鼓励译者将自己翻译过程中查阅过的资料，形成的思考，作出的判断成文记录下来，起到引导后人的作用。具体来说，有以下作用：
并非，我指倡议译员书写翻译说明。
这个似乎和翻译说明没有什么干系，但可以考虑。大模型里小规模模型有免费端点可以调用，有人写代码都好办。
我想说的是确定一个半结构化的数据格式，类似：
[ { "key": ["item.biomancy.primordial_core", "block.biomancy.primordial_cradle"], "note": "我重新接手时所有 prim- 均被译作“原初”。不能算错，但我本身并不喜欢这种风格。出于对前译者的尊重最终还是决定保留，将 Primordial 定为“原初”。Primal 前后改动了几版，现定为“元始”，也是为了和描述中的 Primitive 进行区分。" }, { "key": [], "note": "模组背景：杀死一只动物之后，你听到其鲜活血肉中的低语，得到启示。之后你发现了这隐秘的学科——生物炼金术。\n模组大概可以分为三个阶段：聆听启示（从生肉到原初摇篮）、掌控原始力量（从原初摇篮到各种生物结构）、生物炼金\n这是一个密契主义的模组，而非邪化宗教、邪神的控制或者什么恐怖血腥。重点在于隐秘的知识。阅读同人文可以更好理解。（有粮吃了ww）" } ]我希望将相关资料文件存储到本库。cfpa.site引用
FelixAgairu commentedon Aug 14, 2025
这不还是，语言是交流用的，翻译主要还是给人看的。
标准这个事，感觉没必要，符合游戏设定和习惯就好。毕竟这确实就是个游戏，外加如果原文就跑偏呢。工作流程越复杂效率越低，新人来协助这个项目还需要熟悉工作流程，理清工作分工，这样会增加工作成本。
记忆和上下文这个更像是词典和关键字自动填充。
参考资料
真不如自动化协作，真需要看的自己也能通过其他方式获取信息，就是需要时间。至于数据格式，JSON 不是万能的容器，用作数据交换没什么问题，但要说 JSON 适合人类我不赞同。SQLite 类似数据库储存更方便，但具体那些 AI 怎么接入没研究过。
=============
对于翻译员来说，为什么要研究代码及数据结构。感觉GUO内主要还是为了减少人员成本，前后端一个人都给干了多好（例如：Vue），或者恨不得一个 Java 把公司拿下。
现在这我的世界的翻译更像是在翻译方言（中文 我的世界），某些翻译确实难以统一：
这还好说，那天看到翻译寿司就不好说了，难度一下从简单变成困难了：
简体中文现状也是很乱，各种类型都叫寿司，欧美也差不多 sushi 或 roll。
=============
可能生产力源于懒惰吧，但实现成本已经成
zh_cn.json大合集，变成了自动化翻译 + 我的世界名词词典 + 专业校对。可能这样对最终用户比较好，但对贡献者还是有影响的。
=============
对于服务器来说，可以使用 Polymer 模组生成资源包，
/polymer generate-pack这样只需要重新加入服务器就可以完成加载资源包，帕秋莉手册没仔细研究过。因为自己搭建的小服务器翻译缺失，自己用资源包补全翻译，基本完成了才发现 Minecraft-Mod-Language-Package。
以上，有感而发
SlimeSB commentedon Aug 15, 2025
reply: #5438 (comment)
在面对“难译项”时，机器翻译或者大语言模型翻译就是完全的废物，或者说只能提供大意参考。难译项是指
https://cfpa.site/TransRules/#难译项
对于这部分翻译，以及其他文化氛围的传达，是有写一大篇笔记的必要的。它们考验译者的跨文化交流和母语写作能力。就像虽然现在大语言模型很发达了，但我宁愿读人写的小说也不愿意读AI生成的。
对于标准有没有必要，其实这里没有说确立一个翻译标准，而是在说存放笔记的地方怎么建设。程序上的事自然得有个标准文档。
关于翻译的“标准”或者“规范”，我会在有空的时候写一篇文章谈谈对译文好坏的评价。我有一个比较新的观点是“套路/思路的可复制性”，这有助于减少翻译的思考量。比如说按照“条件-效果”翻译魔咒描述，无论原文如何，或多或少，都翻译成“xx时，产生xx的效果”。或者对于多项定语状语，要不要加“的”，在何处加“的”，怎么样排布。或者“枪药”、“火药”、“易爆粉末”这样适用面的宽窄。这些想法仍在“实验室阶段”，我需要进一步厘清才能下笔。
还有一些观点从《新英汉翻译教程学生用书》中引用。
FelixAgairu commentedon Aug 15, 2025
对于笔记或参考
如果需要存储笔记供大家参考，相应的笔记应该是简短精炼的，完整的笔记不适宜高效引用参考，因此需要对与之相关的特定内容进行提炼。
源于：对近几年开发软件来说，访问类似 CSND 博客 和 JB51 的网站真的是去看开发历程了吗。
建立参考库（可能类似词典）
类似升级版 Glossary?
译者可根据关键字搜索相关的笔记节选、翻译习惯、风俗、故事等。
并提供相关笔记节选的笔记原文或外部链接。
“对于寻求效率者，可以快速获取所需信息。”
“对于探索语言魅力的来说，得到了前人宝贵的经验。”
提供集成翻译环境？
类似升级版 WebTranslator? 或是缝合的产物 WebTranslator + Glossary。
翻译环境可提供相关条目翻译的：修改建议、候选翻译词频（点赞数）、建议原因、笔记节选（或原文、链接）等。
可通过划词弹出以上实现功能。
至少可用性应比 VS Code 或是什么 Notepad++ 好一些。