From 8931ab9c494139ec68bbd095d73c6140b989d4dd Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Wed, 5 Feb 2025 10:58:01 +0800 Subject: [PATCH 01/13] =?UTF-8?q?+=E6=9C=BA=E7=BF=BB=E9=A2=84=E5=AE=A1?= =?UTF-8?q?=E6=9F=A5=20+=E8=B4=A8=E9=87=8F=E8=A6=81=E6=B1=82?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CONTRIBUTING.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e9d8b6104b8f..ba46338bf503 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -74,8 +74,8 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 1. 模组活跃更新的 Minecraft 版本优先。 2. 若所有小版本都活跃更新，则 Minecraft 版本高者优先。 +- 例：Minecraft 版本 1.19.2 与 1.19.4 均属同一大版本号 1.19 下的子版本。 -* 例：Minecraft 版本 1.19.2 与 1.19.4 均属同一大版本号 1.19 下的子版本。 若某一模组在两个版本上的开发均活跃，由于 1.19.4 的版本号更高，因此优先考虑该模组在 1.19.4 下的译名标准化情况与适配情况。 这一优先级不会影响到模组在其他大版本下（如 1.18、1.12 等）的分支。 @@ -84,7 +84,6 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 1. “材料 + 质/制 + 中心词”的翻译，如“铁质涡轮”或“铁制涡轮”，二者皆合理。只需单模组内统一。 2. 关于“木制品名称”的翻译，可参考 [#4525](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package/issues/4525) 的解决方法。 - ## 翻译贡献方针 以下内容只针对 [projects](./projects) 文件夹下的贡献。 @@ -93,9 +92,10 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 - 翻译**必须**符合 [Minecraft 模组简体中文翻译规范与指南](https://cfpa.site/TransRules/)的规定。 - **拒绝**接收机器翻译（含生成式 AI）、生硬翻译。 + - 提交的机器翻译需事先经过人工审查，且满足[审查规则](#审查规则)要求的品质。 - 若直接提交此类翻译，该 PR 将被打上“生硬翻译”标签。 - 若作者不及时进行有效修改，PR 可能会依照本仓库的[搁置规则](#搁置规则)处理。 -- 翻译**必须**在审校后才能进入仓库。 +- 翻译**必须**在审查后才能进入仓库。 ### Pull Request 相关规定 @@ -136,15 +136,16 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 #### 审查规则 -- 审查的基本依据**是**[翻译贡献方针](#翻译贡献方针)。 -- 审查流程**必须**满足本文档[翻译审查](#翻译审查)内容所述。 -- 审查过程中各方**应**遵守[礼仪](https://zh.wikipedia.org/wiki/Wikipedia:%E7%A4%BC%E4%BB%AA)（[备用](https://share.weiyun.com/LRvx1omf)）。 +- 翻译审查的基本依据**是**[翻译贡献方针](#翻译贡献方针)。 +- 翻译审查的目的是使译文满足 `GBT 19682-2005 翻译服务译文质量要求` 和 `ZYF 001-2016 本地化翻译质量和排版质量评估规范` 文件的要求 +- 翻译审查的流程**必须**满足本文档[翻译审查](#翻译审查)内容所述。 +- 翻译审查过程中各方**应**遵守[礼仪](https://zh.wikipedia.org/wiki/Wikipedia:%E7%A4%BC%E4%BB%AA)（[备用](https://share.weiyun.com/LRvx1omf)）。 #### 审查人 - 任何人都能利用 GitHub 提供的[相关功能](https://docs.github.com/zh/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request)来审查 PR 中翻译。所有参与审查的用户即为审查人。 -- [CFPA团队](https://github.com/CFPAOrg) 的成员（Member）和[仓库](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package)的协作者（Collaborator）是具有团队官方性质的审查人。 -- 至少一位具有官方身份的审查人对 PR 给出批准（Approval）审查后，PR 才能合并。 +- [CFPA团队](https://github.com/CFPAOrg) 的成员（Member）和[本仓库](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package)的协作者（Collaborator）是具有团队官方性质的审查人。 +- 至少一位具有官方身份的审查人对 PR 给出批准（Approval）意见后，PR 才能合并。 - 审查人在给出批准审查后**应**给 PR 加上“即将合并”标签，此后需至少等待 24 小时，若等待期间没有新动态则可以合并 PR。 - “动态”包括但不限于 PR 作者发送提交（Commit）、审查人提出意见。 @@ -154,7 +155,7 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 - 在接受审查人的建议后，PR 作者**应**解决（Revolve）相应的对话（Conversation）。 - 若拒绝审查人的建议，或和审查人的观点相左，PR 作者**不应**急于解决（Revolve）对话（Conversation） - PR 作者**应**及时做出回应，否则 PR 可能会按[搁置规则](#搁置规则)关闭。 -- PR 作者如遇到 Git/GitHub 操作上的困难，**应**先询问后操作，避免造成混乱。 +- PR 作者如遇到 Git/GitHub 操作上的困难，请先询问后操作，避免造成混乱。 ### 搁置规则 From 8253f395a2b12e48de8ffe91429f3321f0802cf8 Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Wed, 5 Feb 2025 11:00:05 +0800 Subject: [PATCH 02/13] =?UTF-8?q?=E6=A0=BC=E5=BC=8F=E6=94=B9=E5=8A=A8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CONTRIBUTING.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ba46338bf503..0c2ea613ab3b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -75,9 +75,8 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 2. 若所有小版本都活跃更新，则 Minecraft 版本高者优先。 - 例：Minecraft 版本 1.19.2 与 1.19.4 均属同一大版本号 1.19 下的子版本。 - -若某一模组在两个版本上的开发均活跃，由于 1.19.4 的版本号更高，因此优先考虑该模组在 1.19.4 下的译名标准化情况与适配情况。 -这一优先级不会影响到模组在其他大版本下（如 1.18、1.12 等）的分支。 + 若某一模组在两个版本上的开发均活跃，由于 1.19.4 的版本号更高，因此优先考虑该模组在 1.19.4 下的译名标准化情况与适配情况。 + 这一优先级不会影响到模组在其他大版本下（如 1.18、1.12 等）的分支。 ## 翻译用语共识 From 188debdd8ca912adbf609f40bb23f3e8db81aeb9 Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Fri, 7 Feb 2025 21:17:16 +0800 Subject: [PATCH 03/13] =?UTF-8?q?=E6=B7=BB=E5=8A=A0=E8=B6=85=E9=93=BE?= =?UTF-8?q?=E6=8E=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0c2ea613ab3b..e69058eaf00d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -136,7 +136,7 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 #### 审查规则 - 翻译审查的基本依据**是**[翻译贡献方针](#翻译贡献方针)。 -- 翻译审查的目的是使译文满足 `GBT 19682-2005 翻译服务译文质量要求` 和 `ZYF 001-2016 本地化翻译质量和排版质量评估规范` 文件的要求 +- 翻译审查的目的是使译文满足 [`GB/T 19682-2005 翻译服务译文质量要求`](https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=4F2D9ACF302B1EAE813590EF8DB2A101) 和 [`ZYF 001-2016 本地化翻译质量和排版质量评估规范`](https://plaintalks.com/uploads/short-url/pWGGqRcUcO1pgrfm2iIlBjFS8zX.pdf) 文件的要求 - 翻译审查的流程**必须**满足本文档[翻译审查](#翻译审查)内容所述。 - 翻译审查过程中各方**应**遵守[礼仪](https://zh.wikipedia.org/wiki/Wikipedia:%E7%A4%BC%E4%BB%AA)（[备用](https://share.weiyun.com/LRvx1omf)）。 @@ -166,7 +166,7 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 - 2.2 若审查意见都无需 PR 作者参与，PR 将被加上“即将拒收”标签。1 天缓冲期内官方审查人**可以**直接采纳审查意见，并终止计时，转入合并流程。 3. 在 1、2 所述过程中，若 PR 作者做出了回应，标签将被清除，计时重新从 1 开始。 -因搁置而关闭的 PR，PR 作者若想继续更新，可重新打开（Reopen）PR。 +因搁置而关闭的 PR，PR 作者若想继续更新，可联系管理员重新打开（Reopen）PR。 ### 公示规则 From 0f8589c053969aef056a152d6a1303d8dfe16f81 Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Mon, 17 Feb 2025 17:13:20 +0800 Subject: [PATCH 04/13] =?UTF-8?q?=E5=B0=86=E4=B8=A4=E4=BB=BD=E6=A0=87?= =?UTF-8?q?=E5=87=86=E7=A7=BB=E5=8A=A8=E5=88=B0=E6=9C=BA=E7=BF=BB=E5=AE=A1?= =?UTF-8?q?=E6=9F=A5=E5=8F=82=E8=80=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CONTRIBUTING.md | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e69058eaf00d..fe28f5638152 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -6,7 +6,6 @@ - [贡献方针](#贡献方针) - [仓库结构](#仓库结构) - - [翻译用语共识](#翻译用语共识) - [翻译贡献方针](#翻译贡献方针) - [总则](#总则) - [Pull Request 相关规定](#pull-request-相关规定) @@ -78,11 +77,6 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 若某一模组在两个版本上的开发均活跃，由于 1.19.4 的版本号更高，因此优先考虑该模组在 1.19.4 下的译名标准化情况与适配情况。 这一优先级不会影响到模组在其他大版本下（如 1.18、1.12 等）的分支。 -## 翻译用语共识 - -1. “材料 + 质/制 + 中心词”的翻译，如“铁质涡轮”或“铁制涡轮”，二者皆合理。只需单模组内统一。 -2. 关于“木制品名称”的翻译，可参考 [#4525](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package/issues/4525) 的解决方法。 - ## 翻译贡献方针 以下内容只针对 [projects](./projects) 文件夹下的贡献。 @@ -91,7 +85,7 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 - 翻译**必须**符合 [Minecraft 模组简体中文翻译规范与指南](https://cfpa.site/TransRules/)的规定。 - **拒绝**接收机器翻译（含生成式 AI）、生硬翻译。 - - 提交的机器翻译需事先经过人工审查，且满足[审查规则](#审查规则)要求的品质。 + - 提交的机器翻译需事先经过人工审查，且满足上述指南的规定。可参考[`GB/T 19682-2005 翻译服务译文质量要求`](https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=4F2D9ACF302B1EAE813590EF8DB2A101) 和 [`ZYF 001-2016 本地化翻译质量和排版质量评估规范`](https://plaintalks.com/uploads/short-url/pWGGqRcUcO1pgrfm2iIlBjFS8zX.pdf) 文件的要求。 - 若直接提交此类翻译，该 PR 将被打上“生硬翻译”标签。 - 若作者不及时进行有效修改，PR 可能会依照本仓库的[搁置规则](#搁置规则)处理。 - 翻译**必须**在审查后才能进入仓库。 @@ -136,7 +130,6 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 #### 审查规则 - 翻译审查的基本依据**是**[翻译贡献方针](#翻译贡献方针)。 -- 翻译审查的目的是使译文满足 [`GB/T 19682-2005 翻译服务译文质量要求`](https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=4F2D9ACF302B1EAE813590EF8DB2A101) 和 [`ZYF 001-2016 本地化翻译质量和排版质量评估规范`](https://plaintalks.com/uploads/short-url/pWGGqRcUcO1pgrfm2iIlBjFS8zX.pdf) 文件的要求 - 翻译审查的流程**必须**满足本文档[翻译审查](#翻译审查)内容所述。 - 翻译审查过程中各方**应**遵守[礼仪](https://zh.wikipedia.org/wiki/Wikipedia:%E7%A4%BC%E4%BB%AA)（[备用](https://share.weiyun.com/LRvx1omf)）。 From c5ebe26b816cb2e6fd3f020c3eded1ca027195d3 Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Wed, 11 Jun 2025 19:23:22 +0800 Subject: [PATCH 05/13] Update CONTRIBUTING.md --- CONTRIBUTING.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index fe28f5638152..72638e5fc7bd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -83,12 +83,12 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 ### 总则 -- 翻译**必须**符合 [Minecraft 模组简体中文翻译规范与指南](https://cfpa.site/TransRules/)的规定。 +- 翻译**必须**符合 [Minecraft 模组简体中文翻译规范与指南](https://cfpa.site/TransRules/) 的规定。 - **拒绝**接收机器翻译（含生成式 AI）、生硬翻译。 - - 提交的机器翻译需事先经过人工审查，且满足上述指南的规定。可参考[`GB/T 19682-2005 翻译服务译文质量要求`](https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=4F2D9ACF302B1EAE813590EF8DB2A101) 和 [`ZYF 001-2016 本地化翻译质量和排版质量评估规范`](https://plaintalks.com/uploads/short-url/pWGGqRcUcO1pgrfm2iIlBjFS8zX.pdf) 文件的要求。 + - 提交的机器翻译需事先经过人工审查，且满足上述指南的规定。 - 若直接提交此类翻译，该 PR 将被打上“生硬翻译”标签。 - - 若作者不及时进行有效修改，PR 可能会依照本仓库的[搁置规则](#搁置规则)处理。 -- 翻译**必须**在审查后才能进入仓库。 + - 若提交者未及时进行有效修改，可依照本仓库的[搁置规则](#搁置规则)处理。 +- 提交的翻译**必须**在审查后才能进入仓库。 ### Pull Request 相关规定 @@ -136,10 +136,11 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 #### 审查人 - 任何人都能利用 GitHub 提供的[相关功能](https://docs.github.com/zh/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request)来审查 PR 中翻译。所有参与审查的用户即为审查人。 -- [CFPA团队](https://github.com/CFPAOrg) 的成员（Member）和[本仓库](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package)的协作者（Collaborator）是具有团队官方性质的审查人。 -- 至少一位具有官方身份的审查人对 PR 给出批准（Approval）意见后，PR 才能合并。 -- 审查人在给出批准审查后**应**给 PR 加上“即将合并”标签，此后需至少等待 24 小时，若等待期间没有新动态则可以合并 PR。 +- [CFPA团队](https://github.com/CFPAOrg) 的成员（Member）和[本仓库](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package)的协作者（Collaborator）是具有团队官方性质的审查人，统称为管理员。 +- 至少一位管理员对 PR 给出批准（Approval）意见后，PR 才能合并。 +- 管理员在给出批准意见后**应**给 PR 加上“即将合并”标签，此后需至少等待 24 小时，若等待期间没有新动态则可以合并 PR。 - “动态”包括但不限于 PR 作者发送提交（Commit）、审查人提出意见。 +- 管理员有处置包含敏感内容 PR 的权力，处置包括但不限于：要求使用中立表述、删减、关闭 PR、Block User。 #### PR 作者 From 61b0b2f699405768f7d997be20141835dcf29bb8 Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Sun, 22 Jun 2025 14:43:01 +0800 Subject: [PATCH 06/13] =?UTF-8?q?=E5=88=A4=E6=96=AD=E5=92=8C=E5=A4=84?= =?UTF-8?q?=E7=BD=AE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 72638e5fc7bd..dc13b07a1d14 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -140,7 +140,7 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 - 至少一位管理员对 PR 给出批准（Approval）意见后，PR 才能合并。 - 管理员在给出批准意见后**应**给 PR 加上“即将合并”标签，此后需至少等待 24 小时，若等待期间没有新动态则可以合并 PR。 - “动态”包括但不限于 PR 作者发送提交（Commit）、审查人提出意见。 -- 管理员有处置包含敏感内容 PR 的权力，处置包括但不限于：要求使用中立表述、删减、关闭 PR、Block User。 +- 管理员有判断和处置包含敏感内容 PR 的权力，处置包括但不限于：要求使用中立表述、删减、关闭 PR、限制提交。 #### PR 作者 From 8e80f68fdd415ee7867ca45ae013464d2986b69a Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Sun, 22 Jun 2025 19:49:43 +0800 Subject: [PATCH 07/13] Squashed commit of the following: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit commit e8cefb4d2eea829df0906bc3108125005c271e33 Author: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Sun Jun 22 19:48:49 2025 +0800 迁移 commit 66b98b05b89cff0e14d98d94b1d7d055bba17909 Author: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Sun Jun 22 14:57:23 2025 +0800 之后重写翻译理论哲学 commit 2eaf58d8c3b33a499e95a8ee47ff95cef127ca76 Author: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Sun Jun 22 14:54:00 2025 +0800 删去过时文件 commit 79ef54a2a06a1837154b648cd556a5686ab08c64 Author: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Fri Jun 20 16:03:44 2025 +0800 Update 翻译用语共识.md commit 764c86a9ade954b7c37e4d0f6249edeb3d3a6c6e Author: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Sat May 24 13:23:59 2025 +0800 Update 我的翻译哲学.md commit 995b8bfb23791608b02304299168928f62ae4a98 Author: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Tue May 20 22:38:20 2025 +0800 Create 我的翻译哲学.md Update 我的翻译哲学.md Update 我的翻译哲学.md commit 93ca411e968bfe917be332e0635c0f0bd3c1eba3 Author: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Mon Feb 17 17:05:26 2025 +0800 共识修改 标点 对砖与砖块的翻译 修改 修订 矿石翻译 commit e48f398f3b4181d39ea109693210740cb17528dd Author: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Mon Feb 17 14:13:02 2025 +0800 检查单草稿 commit b6e33900834b0c4014fa32ee6d80400e24f06d0a Author: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Mon Feb 17 14:12:08 2025 +0800 添加文档 --- Packer-Doc.md => docs/Packer-Doc.md | 0 ...47\224\250\350\257\255\345\205\261\350\257\206.md" | 11 +++++++++++ 2 files changed, 11 insertions(+) rename Packer-Doc.md => docs/Packer-Doc.md (100%) create mode 100644 "docs/\347\277\273\350\257\221\347\224\250\350\257\255\345\205\261\350\257\206.md" diff --git a/Packer-Doc.md b/docs/Packer-Doc.md similarity index 100% rename from Packer-Doc.md rename to docs/Packer-Doc.md diff --git "a/docs/\347\277\273\350\257\221\347\224\250\350\257\255\345\205\261\350\257\206.md" "b/docs/\347\277\273\350\257\221\347\224\250\350\257\255\345\205\261\350\257\206.md" new file mode 100644 index 000000000000..fc4621b37289 --- /dev/null +++ "b/docs/\347\277\273\350\257\221\347\224\250\350\257\255\345\205\261\350\257\206.md" @@ -0,0 +1,11 @@ +# 翻译用语共识 + +1. “材料 + 质/制 + 中心词”的翻译，如“铁质涡轮”或“铁制涡轮”，二者皆合理。只需单模组内（包括其附属与联动）统一。 +2. 对砖与砖块的翻译： + - 由物品 brick 合成的 bricks，译作某砖块。brick 译作某砖 + - 不通过 brick 合成的 bricks，且纹理与原版石砖（大砖砖块）相似的，译作某砖。 + - 不通过 brick 合成的 bricks，且纹理与原版石砖（大砖砖块）不相似的，建议译作某砖块，译作某砖也可。 +3. 对菜品的翻译： + - 菜品名的翻译相对自由，有较大发挥余地。但经验不足的译者不要发挥太过。 + - 关于食品等在不同规范下的不同翻译，如“冰激凌”（《现代汉语词典》推荐）或“冰淇淋”（《食品科学技术名词》），二者皆合理。只需单模组内（包括其附属与联动）统一。 + - 有其他常用称呼的，若模组作者或审查人无异议，可以使用该称呼。 From 6fac519c99b9600007ebb3cea3ce82ac3a87bf6f Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Mon, 23 Jun 2025 22:59:01 +0800 Subject: [PATCH 08/13] =?UTF-8?q?=E8=AF=91=E5=90=8E=E7=BC=96=E8=BE=91?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CONTRIBUTING.md | 59 +++++++++++++++++++++++++------------------------ 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index dc13b07a1d14..ec52cf2e944e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -29,29 +29,30 @@ Minecraft-Mod-Language-Package ├─.github --------------- // GitHub 相关配置文件 ├─config ---------------- // 配置文件 - │ └─packer -------------- // 打包器配置文件 + │ └─packer ------------- // 打包器配置文件 + ├─docs ------------------ // 各类文档 ├─projects -------------- // 翻译文件 - │ └─(Minecraft 版本) ---- // 不带 fabric 字样的是用于 Forge 和 NeoForge 模组的 - │  └─assets - │  ├─(CurseForge 项目名称) ---- // 见下 - │  │ └─(命名空间) ------------- // 见下 - │  │ └─lang ----------------- // 语言文件文件夹 - │  │ ├─en_us.json --------- // English (United States) 语言文件 - │  │ └─zh_cn.json --------- // 中文 (简体) 语言文件 - │ ├─(Modrinth 项目名称)------- // 见下 - │  │ └─(命名空间) ------------- // 见下 - │  │ └─lang ----------------- // 语言文件文件夹 - │  │ ├─en_us.json --------- // English (United States) 语言文件 - │  │ └─zh_cn.json --------- // 中文 (简体) 语言文件 - │  ├─minecraft - │  │ └─minecraft -------------- // Minecraft 原版使用的命名空间 - │  │ ├─font - │  │ │ └─glyph_sizes.bin ---- // 全角标点修复文件 - │  │ └─textures - │  │ └─font --------------- // 全角标点修复文件 - │  └─1UNKNOWN ----------------- // 存放不在 CurseForge 和 Modrinth 上发布的模组 - │  └─(命名空间) - │  └─lang + │ └─(Minecraft 版本) --- // 不带 fabric 字样的是用于 Forge 和 NeoForge 模组的 + │ └─assets + │ ├─(CurseForge 项目名称) ---- // 见下 + │ │ └─(命名空间) ------------- // 见下 + │ │ └─lang ----------------- // 语言文件文件夹 + │ │ ├─en_us.json --------- // English (United States) 语言文件 + │ │ └─zh_cn.json --------- // 中文 (简体) 语言文件 + │ ├─(Modrinth 项目名称)------- // 见下 + │ │ └─(命名空间) ------------- // 见下 + │ │ └─lang ----------------- // 语言文件文件夹 + │ │ ├─en_us.json --------- // English (United States) 语言文件 + │ │ └─zh_cn.json --------- // 中文 (简体) 语言文件 + │ ├─minecraft + │ │ └─minecraft -------------- // Minecraft 原版使用的命名空间 + │ │ ├─font + │ │ │ └─glyph_sizes.bin ---- // 全角标点修复文件 + │ │ └─textures + │ │ └─font --------------- // 全角标点修复文件 + │ └─1UNKNOWN ----------------- // 存放不在 CurseForge 和 Modrinth 上发布的模组 + │ └─(命名空间) + │ └─lang └─src --------------- // 各种自动化工具的源码 ├─Formatter ------- // 格式化工具，曾用于统一翻译文件格式 ├─Language.Core @@ -62,7 +63,7 @@ Minecraft-Mod-Language-Package **CurseForge 项目名称**：以匠魂为例，它的 CurseForge 页面地址是 `https://www.curseforge.com/minecraft/mc-mods/tinkers-construct`，则 `CurseForge 项目名称` 为 `tinkers-construct`。因为它是唯一的，被用来追溯模组来源。 -**命名空间（Namespace）**：以匠魂为例，用压缩软件打开模组文件（JAR 格式），它的 en_us.json 的路径为 `assets/tconstruct/lang/en_us.json`，则 `{命名空间}` 为 `assets/` 和 `/lang` 之间的内容，即 `tconstruct`。一个模组可能有多个命名空间。命名空间介绍见 [Minecraft Wiki](https://zh.minecraft.wiki/w/%E5%91%BD%E5%90%8D%E7%A9%BA%E9%97%B4ID?variant=zh-cn#%E5%91%BD%E5%90%8D%E7%A9%BA%E9%97%B4)。 +**命名空间（Namespace）**：以匠魂为例，用压缩软件打开模组文件（JAR 格式），它的 en_us.json 的路径为 `assets/tconstruct/lang/en_us.json`，则 `{命名空间}` 为 `assets/` 和 `/lang` 之间的内容，即 `tconstruct`。一个模组可能有多个命名空间。命名空间介绍见 [Minecraft Wiki：命名空间](https://zh.minecraft.wiki/w/%E5%91%BD%E5%90%8D%E7%A9%BA%E9%97%B4ID?variant=zh-cn#%E5%91%BD%E5%90%8D%E7%A9%BA%E9%97%B4)。 **Modrinth 项目名称**：以 Modrinth 独占模组 Clean F3 为例，它的 Modrinth 页面地址是 `https://modrinth.com/mod/clean-f3`，则在 `mod/` 后的内容 `clean-f3` 为 `{Modrinth 项目名称}` 的**主体**部分，而为了与 Curseforge 上发布的模组作以区分，所有仅在 Modrinth 上发布的模组，在其之前需要添加 `modrinth-` 作为区分。综上，它的 `{Modrinth 项目名称}` 为 `modrinth-clean-f3`。 @@ -83,11 +84,11 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 ### 总则 -- 翻译**必须**符合 [Minecraft 模组简体中文翻译规范与指南](https://cfpa.site/TransRules/) 的规定。 -- **拒绝**接收机器翻译（含生成式 AI）、生硬翻译。 - - 提交的机器翻译需事先经过人工审查，且满足上述指南的规定。 +- 翻译**必须**遵守 [Minecraft 模组简体中文翻译规范与指南](https://cfpa.site/TransRules/)。 +- **拒绝**接收机器翻译（含生成式 AI）、生硬翻译（不符合中文表达习惯的）。 - 若直接提交此类翻译，该 PR 将被打上“生硬翻译”标签。 - - 若提交者未及时进行有效修改，可依照本仓库的[搁置规则](#搁置规则)处理。 + - 若提交者未及时进行有效修改，依照本仓库的[搁置规则](#搁置规则)处理。 + - 已经过译后编辑，且**满足指南要求**的翻译可以接收。 - 提交的翻译**必须**在审查后才能进入仓库。 ### Pull Request 相关规定 @@ -139,7 +140,7 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 - [CFPA团队](https://github.com/CFPAOrg) 的成员（Member）和[本仓库](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package)的协作者（Collaborator）是具有团队官方性质的审查人，统称为管理员。 - 至少一位管理员对 PR 给出批准（Approval）意见后，PR 才能合并。 - 管理员在给出批准意见后**应**给 PR 加上“即将合并”标签，此后需至少等待 24 小时，若等待期间没有新动态则可以合并 PR。 - - “动态”包括但不限于 PR 作者发送提交（Commit）、审查人提出意见。 + - “动态”包括但不限于 PR 作者提交（Commit）、审查人评论。 - 管理员有判断和处置包含敏感内容 PR 的权力，处置包括但不限于：要求使用中立表述、删减、关闭 PR、限制提交。 #### PR 作者 @@ -155,7 +156,7 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 搁置规则用于解决由于 PR 作者迟迟不出面响应审查要求而导致的 PR 积压问题。 1. 若 PR 中存在未作者未响应的审查超过 7 天，审查人有权提及（@）PR 作者，提醒其相应审查意见，然后加上“即将被搁置”标签。 -2. 若“即将被搁置”标签存在超过 7 天，PR 作者将被视为无法回应。此时 +2. 若“即将被搁置”标签存在超过 7 天，PR 作者将被视为无法回应。此时： - 2.1 若存在要求 PR 作者参与的审查意见，PR 将被加上“即将拒收”标签。1 天后 PR 将被关闭。 - 2.2 若审查意见都无需 PR 作者参与，PR 将被加上“即将拒收”标签。1 天缓冲期内官方审查人**可以**直接采纳审查意见，并终止计时，转入合并流程。 3. 在 1、2 所述过程中，若 PR 作者做出了回应，标签将被清除，计时重新从 1 开始。 From a7776fac75bb5a7a4001da3dbea2a11df3391e55 Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Mon, 23 Jun 2025 23:01:58 +0800 Subject: [PATCH 09/13] =?UTF-8?q?Create=20=E4=BB=93=E5=BA=93Wiki.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- "docs/\344\273\223\345\272\223Wiki.md" | 474 +++++++++++++++++++++++++ 1 file changed, 474 insertions(+) create mode 100644 "docs/\344\273\223\345\272\223Wiki.md" diff --git "a/docs/\344\273\223\345\272\223Wiki.md" "b/docs/\344\273\223\345\272\223Wiki.md" new file mode 100644 index 000000000000..1eafd9beda59 --- /dev/null +++ "b/docs/\344\273\223\345\272\223Wiki.md" @@ -0,0 +1,474 @@ +# 第一章 了解语言文件 + +## 1. 语言文件发展历史 + +语言文件（这里特指模组相关语言文件）的发展是一个极为曲折的过程。 + +### ① Minecraft 1.6.1 之前 + +在 Minecraft 1.6.1 之前官方还没有指定相关规范，模组本身缺乏对多语言的支持。诸如工业、建筑这样的模组，可能还给提供语言文件，但其他大部分模组直接都是硬编码语言文件。 + +> 硬编码：将可变变量用一个固定数值表示。由于可变变量是固定不变的，一旦编译后很难修改。 +> +> 软编码：和硬编码相对，将可变变量用特殊标记来表示。这样在编译后，只需要修改这个特殊标记即可。 + +为了能够翻译相关模组，当时的翻译者往往需要 jd-gui 这样的反编译工具来反编译模组，而后修改模组的常量池来参与翻译。这样翻译不但效率低下，一旦翻译错误，整个模组文件就报废了。 + +> 关于早期模组翻译，可以参见： + +### ② Minecraft 1.6.1 ~ Minecraft 1.10.2 之间 + +1.6.1 之后官方相关规范的出现，大大简化了翻译的难度。官方采用了简单的语言文件格式来加载本地化，语言文件甚至可以被资源包所替换。大致规则如下： + +- 语言文件都位于 `assets/modid/lang/` 下，其中 modid 是随意的，依据具体的模组不同，名字可能不同。比如林业模组的语言文件都位于 `assets/forestry/lang` 文件夹下。 +- 可以通过资源包覆盖语言文件，覆盖机理和材质一致。 + + +- 语言文件命名参照了 [ISO639](https://www.iso.org/iso-639-language-codes.html) 标准：英文（美国）就是 `en_US.lang`，中文（中国大陆）就是 `zh_CN.lang` + +- 语言文件格式是简单的 `key=value` 方式书写： + + ```properties + item.apple.name=苹果 + tile.stone.name=石头 + ``` + + + > 在上述案例中 `item.apple.name` 就是 `key`，而 `苹果` 就是 `value`。 + +- 以 `#` 开头的段落识别为注释： + + ```properties + # 注释 + # 注释中可以随便书写文字，均不会加载 + item.apple.name=苹果 + tile.stone.name=石头 + ``` + +- 语言文件编码为 `utf-8 无 BOM 编码` + + > [BOM](https://en.wikipedia.org/wiki/Byte_order_mark) + > + > **字节顺序标记**（byte-order mark，**BOM**），即放置在文件开头的字符 `\uFEFF`，它常被用来当做标示文件是以 UTF-8、UTF-16 或 UTF-32 编码的记号。 + +### ③ Minecraft 1.11 以后 + +1.11 版本更新后，官方对部分文件大小写做了严格规范，资源相关的文件名需要通过资源包的 `pack.mcmeta` 中的 `pack_format` 参数来决定。 + +> 一个只包含 `pack_format` 和 `description` 参数的 `pack.mcmeta` 文件，可以看到书写格式和 JSON 一致。 +> +> ```json +> { +> "pack": { +> "pack_format": 3, +> "description": "模组资源文件" +> } +> } +> ``` + +- 当设定为 `2` 时，语言文件名采用旧版本书写方式，英文（美国）就是 `en_US.lang`，中文（中国大陆）就是 `zh_CN.lang`。 + + +- 当设定为 `3` 时，语言文件名需要全小写。比如英文（美国）就是 `en_us.lang`，中文（中国大陆）就是`zh_cn.lang`。 + +除此之外其他规则一致。 + + +## 2. 模组语言文件加载机理 + +### ① 普通语言文件加载 + +> 这一块参考 Minecraft 1.12.x 版本的 Forge 代码。 +> 源代码：[【1】](https://github.com/MinecraftForge/MinecraftForge/blob/1.12.x/src/main/java/net/minecraftforge/fml/common/FMLCommonHandler.java#L707-L747) [【2】](https://github.com/MinecraftForge/MinecraftForge/blob/1.12.x/patches/minecraft/net/minecraft/util/text/translation/LanguageMap.java.patch) + +Minecraft 加载语言文件的机理很简单： + +1. 游戏读取所有模组的 `assets/modid/lang/` 下的语言文件； + +2. 将语言文件处理成映射表； + + 我们刚刚在[第一章](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package/wiki/%E5%86%85%E5%AE%B9#%E7%AC%AC%E4%B8%80%E7%AB%A0-%E4%BA%86%E8%A7%A3%E8%AF%AD%E8%A8%80%E6%96%87%E4%BB%B6)中有简单说过 Minecraft 的语言文件，游戏将会按照条目中的**第一个等号**来拆分成映射表。 + + > 比如 `a=b=c` 在游戏中会拆分成 `a` 和 `b=c` 两个条目，形成一对映射； + +4. 游戏中依据映射表、具体选择的语言来加载翻译条目； + +4. 如果指定语言找不到映射，则开始在 `en_us.lang` 中寻找映射； + +5. 如果在 `en_us.lang` 中还是找不到对应的映射，直接显示`key`； + + > **映射** + > + > 两个非空集合 A 与 B 间存在着对应关系，而且对于 A 中的每一个元素，B 中总有有唯一的一个元素与它对应，就这种对应称为从 A 到 B 的映射。 + +### ② 带有 `#PARSE_ESCAPE` 注释语言文件加载 + +Forge 新增了一个特殊读取：如果注释中存在 `#PARSE_ESCAPE` 注释，那么处理将会严格按照 Java Properties 格式来读取，并处理成映射表； + +Properties 格式很像 Minecraft 语言文件格式，但是要更加灵活强大： + +- Properties 采用 `:` 或 `=` 来书写映射，也是按照第一个 `:` 或 `=` 来拆分成映射表。下面两种书写方式均是正确的： + + ```properties + #PARSE_ESCAPE + item.apple.name:苹果 + item.apple.name=苹果 + ``` + +- Properties 可以采用转义字符来转义 `:` 或者 `=`，转义过的字符不会被识别。 + + ```properties + #PARSE_ESCAPE + item.apple\:name:苹果 + item.apple\=name=苹果 + ``` + +- Properties 可以写成多行的，通过每行行尾的 `\` 符号来识别： + + ```properties + #PARSE_ESCAPE + item.apple.name:苹果\ + 挺好吃的 + item.apple.name=苹果\ + 不咋好吃\ + 真的\ + 确实不好吃 + ``` + +- Properties 采用 `#` 或者 `!` 来书写注释： + + ```properties + #PARSE_ESCAPE + ! 这是一条注释 + item.apple.name:苹果 + # 这也是一条注释 + item.apple.name=苹果 + ``` + +### ③ 映射重名问题 + +由于游戏是将所有模组的语言文件放在一起处理，一些粗心大意的模组作者在书写语言文件方面如果考虑不周，就会罕见的存在映射重名问题。 + +比如经典的 [ShetiPhianCore](https://minecraft.curseforge.com/projects/shetiphiancore) 译名冲突，在 ShetiPhianCore 模组中存在着这几个翻译条目： + +```properties +item.dyePowder.green.name=绿色染料 +item.dyePowder.red.name=红色染料 +item.dyePowder.yellow.name=黄色染料 +``` + +而类似的条目在 Minecraft 原版中恰好也存在，它们的 key 完全相同： + +```properties +item.dyePowder.green.name=仙人掌绿 +item.dyePowder.red.name=玫瑰红 +item.dyePowder.yellow.name=蒲公英黄 +``` + +结果导致 [ShetiPhianCore](https://minecraft.curseforge.com/projects/shetiphiancore) 模组的这几个条目直接覆盖了原版的语言文件，导致玩家在游戏中获取了错误的翻译。 + +除此之外诸如更多武器模组的 `武士刀 `与 PlusTiC 模组的 `李奥纳多的武士刀` 名称相互冲突的等等问题，不一而具。 + +所幸的是这些问题很少见，而且出现后仅仅是对游戏内翻译有所影响，不会带来任何其他方面的崩溃或者冲突。如果你在翻译过程中发现了这些问题，请及时向模组的原作者反馈。 + +# 第二章 基础知识 + +## 1. 字符编码 + +计算机只能识别二进制代码，如果想要让计算机存储或者识别字符，就需要将字符转变为二进制代码。随着时代、用途等诸多因素的影响，字符编码的标准也各不相同。 + +这部分东西会非常多而乱，初学者可能会各种懵逼。没办法……谁让这是计算机呢…… + +### ① ASCII 码 + +1967 年美国国家标准学会制定了第一个字符编码规范，这就是赫赫有名的 ASCII 码。 + +ASCII 码使用 7 位二进制数（剩下的1位二进制为0）来表示所有的大写和小写字母、数字 0 到 9、标点符号， 以及在美式英语中使用的特殊控制字符。 + +然而 ASCII 码支持的字符太少，而后世界各国又独自演化出了适应本国使用的各种编码。诸如中国大陆的 GB2312 编码，日本的 Shift-JIS 编码。 + +![USASCII_code_chart.png](https://i.loli.net/2018/03/25/5ab795ee2c1af.png) + +### ② ISO-8859-1 编码 + +也常被称为 `Latin-1` 编码，在 ASCII 的基础上额外加入 96 个字母及符号，使其能够广泛支持西欧各国语言。 + +特意提一下这个编码，部分欧美作者在书写语言文件时会偶然忘记改变文件编码，系统便自动使用 ISO-8859-1 编码书写语言文件。如果不慎语言文件中出现了非 ASCII 字符，那么这部分字符就会乱码。更有甚者强制使用 ISO-8859-1 编码中文文件，导致翻译者提交的正确翻译，在编译后乱码。 + +典型代表： + +- [Dungeon Tactics](https://minecraft.curseforge.com/projects/dungeon-tactics) 模组，`en_US.lang` 采用 ISO-8859-1 编码。读取其 1.12.2 版本模组 `en_US.lang` 第 245 行字符 `ü`，存在乱码： + + ```properties + item.dungeontactics:terrible_feather.name=Hühnerfeder + ``` + +- [SuperMiner](https://minecraft.curseforge.com/projects/superminer-unified) 模组，`en_US.lang` 采用 ISO-8859-1 编码。读取其 1.12.2 版本模组 `en_US.lang` 第 46 行字符 `§`，存在乱码： + + + ```properties + superminer.excavator.goditems=§aCONGRATULATIONS: §7You've Unlocked the §6God Items§7! + ``` + +### ③ GB 编码 + +- 中国国家标准总局 1980 发布的适合中文的编码，第一版为 GB2312 编码，共收入 6763个汉字、682 个非汉字图形字符。由于中文字符的庞杂性，所以采用了两个字节来表示，向下兼容 ASCII 编码。 + + 值得特殊说明的是，在 ASCII 里本来就有的数字、标点、字母，在 GB 编码中又重编了两个字节长的编码，这就是全角字符。 + + ```properties + # 半角数字、标点、字母 + 1234567890,.abcdefg + + # 全角数字、标点、字母 + １２３４５６７８９０，．ａｂｃｄｅｆｇ + ``` + +- 1995 年又制定了 GBK 编码，GBK 共收入 21886 个汉字和图形符号，兼容 GB2312 编码。 + +- 2000 年又制定了 GB18030 编码，这次收录了 70244 个中文字符，兼容 GBK 编码。GB18030 编采用一二四字节的变长编码。 + +值得一提的是，Windows 操作系统默认的文件编码方式是 ANSI 编码，在简体中文系统就指的 GB 编码。在日文系统上就指的是 Shift-JIS 编码。至于你问为什么非要用这个名字……去问微软爸爸啊。 + +### ④ Unicode 编码 + +世界各国的编码太多太乱了，我们来指定一个全新的通用标准吧，于是 Unicode 编码应运而生。Unicode 编码支持全世界各国文字，采用统一的编码，兼容 ISO 8859-1 编码。~~Unicode 编码依据不同的长度，具体实现方面又分为 UTF-8、UTF-16、UTF-32。（不考）~~最常用的就是 UTF-8 编码。 + +MacOS 和 Linux 都还不错，操作系统默认都是 UTF-8 无 BOM 编码； + +Windows 系统则不然，采用 ANSI 编码，依据不同国家采用不同国家的国标码。但对 UTF-8 编码也有支持，我们在存储文件的时候还是可以将编码选择为 UTF-8 编码。 + +![weiruanbaba.png](https://i.loli.net/2018/03/25/5ab7b1d01cd64.png) + +**但是！**Windows 下存储的 UTF-8 编码文件，其开头加入了字节顺序标记（byte-order mark，简称 BOM，即放置在文件开头的字符 `\uFEFF`），用来当做标示文件是以 UTF-8、UTF-16 或 UTF-32 编码的记号。部分程序并不支持 BOM，导致处理该字符时候会报错。 + +我们日常使用的 Java 7/8 以及 Python 3 这些计算机语言，内部实现默认都使用无 BOM 的 UTF-8 编码。但是在没有指定语言编码的情况下读取系统文件，仍旧是沿用系统编码。这在下一章的存储格式中会有详细的说明，这也是很多令人头疼问题的导火索。 + +## 2. 文件格式 + +这一章我们将介绍模组翻译中会遇见的各种文件格式，以及各种形形色色的问题。 + +### ① 原版语言文件 + +幸运的是，原版语言文件制定了较为严格的规定，同时也提供了方便易用的 I18n 方法。除了极少数模组，大部分模组都较好的遵循了原版语言文件。对几个特立独行的模组简单介绍下： + +- 工业模组：至今仍然采用 `Java Properties ` 格式书写语言文件。 +- 格雷科技：采用程序生成的配置文件来书写语言文件，启动时需要将语言文件放置在游戏主文件夹下。 +- McJty：一个模组作者，写过很多知名的模组，比如 RFTools 三件套，The One Probe 等。除了官方强制要求添加本地化的部分（方块、物品、成就、标签页），其他部分全部采用硬编码。不过所幸他认识到了这个问题，在比较新的 [MeeCreeps](https://minecraft.curseforge.com/projects/meecreeps) 模组中已经开始书写较为全面的语言文件了。本人也表示会在之后逐步在其他模组中添加更多语言文件。 +- [Extreme Reactors](https://minecraft.curseforge.com/projects/extreme-reactors)：属于旧版本遗留问题，所有的 GUI 目前仍旧采用硬编码。 + +原版语言文件的书写与格式在第一章中都详细叙述了，此处不再过多介绍。 + +### ② JSON 语言文件 + +#### （1）JSON 基本介绍 + +全称 JavaScript 对象表示法（JavaScript Object Notation），是一种轻量级的数据交换格式，完全独立于编程语言的文本格式来存储和表示数据。**JSON 不允许写入注释**，整体规则很简单，总结如下： + +- 数据由逗号分隔； +- 花括号保存映射； +- 方括号保存数组； + +下面我们先书写一个最简单的 JSON 文件，包含一对映射，一个存有两个数据的数组： + +```json +{ + "item.apple.name": "苹果", + "item.list.name": [ + "苹果", + "香蕉" + ] +} +``` + +JSON 有很多在线的格式化工具，能够检查我们书写的语法是否有错误，以及对数据进行重新排版。 + +- [JSON.cn](http://www.json.cn/) +- [BeJSON](https://www.bejson.com/) + +#### （2）编码问题 + +按照标准，JSON 文件应当使用 UTF-8 无 BOM 编码，但是部分作者未强制指定编码，导致游戏中中文翻译乱码，或者更甚者无法启动游戏。 + +经典代表就是 [FTB Achievements](https://minecraft.curseforge.com/projects/ftb-achievements) 模组，它在很多 FTB 整合包中均有使用。在 [FTB Skyfactory Challenges](https://www.feed-the-beast.com/projects/ftb-skyfactory-challenges) 整合包中，其所有的挑战任务均使用 [FTB Achievements](https://minecraft.curseforge.com/projects/ftb-achievements) 书写，任务文件在游戏主目录下的 config 文件夹中，采用 JSON 格式书写。其所有的任务描述由配置中的 `tagCompound` 标签书写，但是作者似乎并没有限定编码，导致其强制以 ASCII 编码进行解析，如果不慎写入中文字符，启动过程中游戏会直接崩溃。 + +所幸还是有办法解决，通过转义字符书写 Unicode 编码，即可正常加载。但是转义字符书写的 Unicode 编码毕竟不适合阅读，在翻译过程中检查排错都很困难，如果出现了这些编码问题，请及时向原作者反馈问题。 + +> **转义书写的 Unicode 编码字符** +> +> 采用四位 16 进制，开头辅以 `\u` 字符来转义；比如正常的 `中文` 二字，Unicode 编码为 `\u4e2d\u6587` 。当程序读取到这些转义字符时，便会以 Unicode 编码来进行解析，从而在其他编码环境的文件中愉快的插入 Unicode 字符。 +> +> 网络上有很多相关工具可以将普通字符转换为 Unicode 转义字符，比如[站长工具](http://tool.chinaz.com/tools/unicode.aspx)。 + +#### （3）传参崩溃问题 + +一般 JSON 书写的文件除了语言文件之后，还有许多功能性参数。如果我们在错误的地方进行了翻译，而作者代码又不够健壮，就会导致游戏崩溃。这种崩溃可能是启动中崩溃，也可能是游戏中触发某个事件后崩溃。 + +举个例子，匠魂模组 2.5 版本手册中曾经存在一个翻译错误，翻译者~酒石酸~错误的翻译了 `shulking.json` 文件的`modifier` 字段，此处字段应当为工具强化的 id，不能够翻译。该错误导致匠魂手册在长达半年的时间，中文玩家一打开就会游戏崩溃。 + +![捕获.PNG](https://i.loli.net/2018/03/27/5aba1a06e4372.png) + +> :arrow_up: 上图中 `modifier` 字段不应当翻译。 + +如何判定当前字段是否应当被翻译，需要翻译者查看具体源码，或者多次试错才能够发现，难度较大。 + +### ③ XML 语言文件 + +可扩展标记语言（**EXtensible Markup Language**，简称 XML）是一种标记语言，很像 HTML 语言，不过所有的标签均可自定义。XML 可读性较 JSON 稍差，除了早期模组，现在极少有模组使用这种语言。 + +XML 语言大致结构如下，整个文件主体部分必须要被标签所囊括，可以添加注释： + +```xml + + + George + John + Reminder + Don't forget the meeting! + +``` + +关于更多 XML 知识，可以查看 [W3school 中文教程](http://www.w3school.com.cn/xml/index.asp)。 + +目前所知还在使用 XML 语言的模组仅有 [InGame Info XML](https://minecraft.curseforge.com/projects/ingame-info-xml) 模组。如同 JSON 语言一样，XML 也可能包含很多功能性参数，如果书写位置错误，也可能会导致游戏崩溃。好在 [InGame Info XML](https://minecraft.curseforge.com/projects/ingame-info-xml) 作者代码健壮性还不错，只会导致无法加载，游戏并不会崩溃。 + +这里截取了部分 [InGame Info XML 配置文件源码](https://github.com/Lunatrius/InGame-Info-XML/blob/master/src/main/resources/assets/ingameinfo/ingameinfo.xml)。 + +```xml + + Day {day}, {mctime} ( + + daytime + $eDay + $8Night + + time$f) + +``` + +图中只有 `` 便签围起来的部分可以被翻译。 + +### ④ YAML 语言文件 + +YAML 英文原名为 YAML Ain't Markup Language，YAML 可以方便的表达映射、数组之类的数据，而且采用缩进表示层级关系，阅读性极高。 + +YAML 格式一般如下： + +```yaml +house: + family: + name: Doe + parents: + - John + - Jane # 可以随意插入注释 + address: + number: 34 + street: Main Street + "city": "Nowheretown" + zipcode: 12345 +``` + +- 缩进并没有强制要求，只需要保证同级数据缩进相等即可，不过不可以使用 tab 缩进； +- 数据可以依据个人习惯选择是否用引号圈住； +- `#` 后插入注释； +- 数组内元素采用 `-` 符号，相同缩进来表示； + +采用 YAML 书写配置或者语言文件的模组极为罕见，但在插件的配置、语言文件中几乎全部采用此语言书写。 + +### ⑤ 其他格式 + +然而总是会有模组作者另辟蹊径，选择自定义的格式来书写语言文件或者配置，典型代表就是格雷科技和 [Simple Achievements](https://minecraft.curseforge.com/projects/simple-achievements) 模组。 + +格雷科技采用了原版配置文件格式来加载语言文件，且加载位置放置在游戏主目录下。下图为部分语言文件截取： + +``` +languagefile { + S:"Dirty Water.name"=脏水 + S:bc.trigger.gregapi.energy.air.capacity.empty=空的 (ENERGY.AIR) + S:bc.trigger.gregapi.energy.air.capacity.full=满的 (ENERGY.AIR) +} +``` + +其次是 [Simple Achievements](https://minecraft.curseforge.com/projects/simple-achievements) 模组书写的任务书，这部分配置同样没有限定编码，需要转换成 Unicode 字符，或者采用 GB 编码书写才可以正常使用。 + +下图为其部分截取，作者并未为此添加 `try catch` 结构，如果书写错误，游戏会启动崩溃。 + +``` +--== 神秘农业 ==--| |资源始终是有限的，作物才能满足你的需求::1 +合成一个铁种子::0 +合成一个钻石种子::0 +使用离魂块获得一个怪物灵魂碎片::0 +使用生长水晶和生长加速器::0 +合成一个大师级的注魔水晶::0 +合成一个终极苹果::0 +合成一个终极防具::0 +::1 +::1 +::1 +``` + +## 3. Git 与 GitHub + +### ① Git 基本介绍 + +小明在写一个程序，万恶的产品经理不停地在改需求，小明只好把写好的代码改了删，删了改。一来二去，小明电脑上的文件越来越乱，小明急切的需要一套特殊的工具，能够完美的管控文件，快捷的撤销、重复之前的步骤。我们把这种工具叫版本控制系统（**Version Control System**，简称 VCS）。 + +而 Git 就是其中出色的一款系统，由 Linux 的创始人林纳斯·本纳第克特·托瓦兹创建，Git 监控文件变化的机理很简单——只记录文件的改变。 + +现在有个文件，内容如下： + +``` +Hello World！ +``` + +我么对其进行修改： + +``` +Hello MC！ +你好世界！ +``` + +对于 Git 来说，就记录了这样的变化： + +```diff +- Hello World！ ++ Hello MC！ ++ 你好世界！ +``` + +这样的方式给多人协作带来了极大的方便，因为只记录变化的部分，只要两个人修改的不是同一处文件，简单的把两人的变化记录在一起，即可完美实现协作功能。 + +### ② GitHub 是什么？ + +我们书写了代码，如果想要给其他人观看，就必然要把代码放置在网络上。好在如今有很多网站提供了免费的代码托管。国外的有 GitHub，Gitlab，Bitbucket，国内的有 Coding，而 GitHub 则是其中用户量最大的一家。GitHub 上面的代码全部采用 Git 进行管理，同时支持多人协作，对于公开项目完全免费。 + +**网址：** + +![QQ截图20180328120221.png](https://i.loli.net/2018/03/28/5abb13dba03a9.png) + +### ③ Git 与 GitHub 的使用 + +GitHub 虽然能够支持网页上直接进行操作，但是功能非常少，使用起来也不方便。更多的时候是直接通过 Git 的命令行或者图形化程序来进行代码的下载、本地修改、上传等操作。 + +如果是 Windows 系统，用户需要去 [Git 官网](https://git-scm.com/)下载安装包，安装后即提供了命令行工具。 + +![QQ截图20180328120716.png](https://i.loli.net/2018/03/28/5abb14fa2e8b1.png) + +## 4. 文本编辑器 Atom 的介绍 + +## 5. 正则表达式 + +# 第三章 翻译规范 + +## 1. 翻译指南 + +## 2. 词库 + +# 第四章 自动化翻译 + +## 1. 爬虫系统 + +## 2. Weblate 翻译平台 + +## 3. 持续化集成系统 + From 015f6181cccfc8c832cdbdf6b90f7007ee561cad Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Sun, 20 Jul 2025 17:26:01 +0800 Subject: [PATCH 10/13] =?UTF-8?q?=E8=BF=81=E7=A7=BB=E8=87=B3=20#5008?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/Packer-Doc.md | 410 --------------- "docs/\344\273\223\345\272\223Wiki.md" | 474 ------------------ ...50\350\257\255\345\205\261\350\257\206.md" | 11 - 3 files changed, 895 deletions(-) delete mode 100644 docs/Packer-Doc.md delete mode 100644 "docs/\344\273\223\345\272\223Wiki.md" delete mode 100644 "docs/\347\277\273\350\257\221\347\224\250\350\257\255\345\205\261\350\257\206.md" diff --git a/docs/Packer-Doc.md b/docs/Packer-Doc.md deleted file mode 100644 index 3554b07cc641..000000000000 --- a/docs/Packer-Doc.md +++ /dev/null @@ -1,410 +0,0 @@ -# 打包机制文档 - -**跳转：[快速参考](#快速参考)** - -## 注意事项 - -- 文件地址中，目录分隔符**一律使用正斜杠（`/`）**！ -- 地址相关 - - 下述说明中，**完整地址**永远指从**仓库根目录**算起的地址，例如对根目录下的 `CONTRIBUTING.md`，应为 `CONTRIBUTING.md`；对1.12版本资源包的 `pack.png`，应为 `projects/1.12.2/pack.png`。 - - 下述说明中，**相对地址**永远指从**特定命名空间的文件夹**算起的地址，例如对仓库中的 `projects/1.18/assets/minecraft/minecraft/font/default.json`，应为 `font/default.json`。 - - 下述说明中，**目标地址**永远指**分发的资源包中**，该文件应当被放置的位置，例如对上一条中提及的文件，应为 `assets/minecraft/font/default.json`。 -- 文件相关 - - 下述说明中，**语言文件**永远指可以被打包器解读为**映射表**的文件。这包括了所有 **`lang/` 下的 `.lang` 和 `.json` 文件**。 - - 下述说明中，**文本文件**永远指含有**文本内容**，但**不属于语言文件**的文件。这包括了非语言文件的 `.txt`、`.md`、`.json` 文件。 - - 下述说明中，**非文本文件**永远指**不属于以上两类**的文件，如图片或其他二进制文件。 -- 本次打包器更新以后，对于**非文本文件**无需特殊处理：打包器会按照文件拓展名自动识别文件类型。 - - - -## 配置文件 - -配置文件分为两类： - -- 放置在 `config/packer` 下的**全局**配置文件，用作整个打包流程的基础配置； -- 放置在各命名空间下的**局域**配置文件，用于对特定命名空间（以及模组）提供特殊的配置项。 - -### 文件格式 - -目前而言，所有配置文件都需要填写全部项——无关项可以填写空集合，但不能不填，更不能写 null。有计划在将来优化这一行为。 - -#### 全局配置文件 - -**全局**配置文件 `config/packer/.json` 的格式如下： - -- 根标签 object - - `base` object - 打包流程中的*不变配置*，不能被文件结构中的**局域配置文件**改写。包含的内容都是**不低于**命名空间层级的，因为局域配置文件就是放在命名空间一级中的。 - - `version` string - 该配置文件指向的版本，以 `projects/` 中的文件夹名称为准。原则上*应当*与文件名中的 [version] 一致。 - - `targetLanguages` list - 打包的目标语言，即最终在资源包中存在的语言。 - - string - 目标语言，即该版本使用的语言标识符。 - 以在 `lang` 下的语言文件的文件名，以及其他文件的路径中，标明语言的部分为准。目前而言，使用的是 `zh_cn`，尽管有消息称将要改用 `zho_Hans-CN`。 - - `exclusionMods` list - 被打包器排除的模组文件夹。 - 如果因为某些原因需要移除某个模组的翻译（如移交官方/其他团体等），但意图保留原有翻译，可能需要这一项。 - - string - 排除的模组。 - - `exclusionNamespaces` list - 被打包器排除的 **[namespace]** | **(命名空间)**。 - 暂时闲置，以待后续需求。 - - string - 排除的命名空间。 - - `floating` object - 打包流程中的*可变配置*，可能被文件结构中的**局域配置文件**改写。包含的内容都是**低于**命名空间层级的，因为局域配置文件就是放在命名空间一级中的。 - - `inclusionDomains` list - 强制包含的 **[domain]**。 - 一般而言，用于通常不会包含**语言标识符**的 `domain`。 - 一般而言会包含 `font` 与 `textures`，因为这两处往往不带语言标识符，且字体修复已经需要用到这两个domain；其他内容多半会出现在*局域配置*中。 - - string - 强制包含的domain名称。 - - `exclusionDomains` list - 强制排除的 **[domain]**。 - 暂时闲置，或可用于排除一些策略相关的零散文件。 - - string - 强制排除的domain名称。 - - `exclusionPaths` list - 强制排除的 **[相对地址]**。 - - string - 强制排除的文件的**相对地址**。 - 一般而言，在主配置中只会放置通用的忽略对象，例如 `packer-policy.json` 和 `local-config.json`；其余条目最好放在*局域配置*中。 - - `inclusionPaths` list - 强制包含的 **[相对地址]**。 - 暂时闲置，可以用于添加零散的无语言标记文件。 - - string - 强制包含的文件的**相对地址**。 - - `characterReplacement` object - 打包时采用的字符替换表。用于将部分字符替换至特殊位点，也可单纯用于简化输入。目前而言，包含了字体修复的有关内容。 - - `<查询语句>` string - 用以替换**正则表达式**`<查询语句>`匹配对象的内容，可以是一个或多个字符，甚至可以在这里用**正则替换语句**。 - 主要用于*字体修复包*所需的**符号替换**，此时，查询语句通常是字面量，替换内容一般而言总是以四位 *Unicode 转义码*填写；对于**基础多语种平面（BMP）**以外的字符，最好用 **UTF-16 代理对**书写。 - - `destinationReplacement` object - 打包时采用的目标地址替换。 - 可以用于移动文件，但暂时闲置；使用**检索策略**中的`singleton`也可以实现地址替换，但需要在每个模组下配置。 - - `<查询语句>` string - 用以替换**正则表达式**`<查询语句>`匹配对象的内容，可以是一个或多个字符，甚至可以在这里用**正则替换语句**。 - -#### 局域配置文件 - -**局域**配置文件 `projects//assets///local-config.json` 的格式与全局配置文件中，`floating` 标签下的内容（*可变配置*）一致。 - -### 文件容斥顺序 - -介于在配置文件中出现了多种包含/排除文件的配置项，有必要说明以下这些项生效的顺序： - -1. `exclusionMods` 和 `exclusionNamespaces` 在进入命名空间前即会排除相应的文件夹——甚至不会加载其中的 `local-config.json`。 -当然，如果是通过*检索策略*访问的，则这一项不会生效。 -2. 在剩下的命名空间中，检索文件。下面的配置项可能会被当地的*局域配置*修改，除了 `targetLanguages` 以外。 -3. 在所有检索到的文件中，排除掉 `exclusionPaths` 指定的文件，即便是通过*检索策略*访问的。 -4. 在剩下的文件中，直接包含 `inclusionPaths` 和 `inclusionDomains` 指定的文件。 -5. 在剩下的文件中，排除掉 `exclusionDomains` 指定的文件。 -6. 在剩下的文件中，仅包含由 `targetLanguages` 指定的，在路径中任意位置包含有*简体中文语言标记*的文件，其他文件不予包含。 - -### 局域配置文件的重写规则 - -- 如果在某个命名空间内检测到存在 `local-config.json`，打包器将会在全局配置的基础上，在其*可变配置*中**添加**该文件中的内容，并用这一修改后的配置执行**该命名空间下的**检索工作。 -- 最好不要与全局配置中的内容重复。尽管理论上这样子可以运行，但是重复项保留哪一个或许不容易断定。 -- 需要注意的是，如果通过*检索策略*来**引用其他命名空间**，打包器**只**会加载目标命名空间的局域配置，而**不会**加载原空间的局域配置；不过，在原位进行的检索工作不受影响。 - -## 检索策略 - -对于每个**命名空间文件夹**，打包器除了可以原位检索文件以外，还可以**使用不同的检索方式**。目前，可用的检索方式有四种： - -1. **原位**检索文件。 -2. **引用**给定的命名空间。 -3. 从给定的**组合**文件，直接生成语言文件（或部分）。 -4. 引用**单个**文件。 - -> 计划中，将对*非语言文件的文本文件*添加一个**修改包**策略，但是这个策略暂时还没实现，部分原因是在上一版打包器中，这个策略还没被用过。 - -单独看起来，这或许没什么用（打包器的上一版中，功能还要多些）；但有一点很重要：这些加载策略是可以**串联**、**递归**的！于是，通过这些策略，应该可以满足许多需求。 - -- **串联**：在一个策略文件中，可以放置**多条策略**。策略将会从前往后执行，**前者**优先——和*Minecraft资源包*顺序差不多。不过，在文件冲突时，也提供了一些特殊的冲突解决选项。 -- **递归**：如果**引用**了其他命名空间文件夹，那里的策略文件**也会生效**。这意味着可以实现*连续引用*——尽管前提是不出现**循环引用**。 - -部分案例被放在了 `projects/packer-example/` 这一虚拟的“版本”下。很明显，我们**并不会**分发这一版本，但如果有条件，可以在本地构造打包器，并用这一版本做试验。 - -### 策略相关文件的格式 - -#### packer-policy.json - -对于每个**命名空间文件夹**，策略文件为 `projects//assets///packer-policy.json`。 -若找不到该文件，默认策略内容为 `[{"type": "direct"}]`，也就是**原位**加载，没有特殊配置。 - -- 根标签 list -打包器需要执行的策略，**从前往后执行**。如果有冲突内容，默认以**前者**优先——当然这是可以配置的。 - - object - 单项策略。部分参数可变。 - - `modifyOnly` bool - 默认为 `false`。 - 对于**语言文件**，若本项为 `true`，对于已有的键，若在该步中提供了新的值，则将会用新值替换旧值；**不会**包含本步中新出现的键。 - 对于其他文件，本项无效。 - - `append` bool - 默认为 `false`。 - 对于**文本文件**，将会在已有的文本内容之后**换行**，然后连接本步的内容。 - 对于其他文件，本项无效。 - - `type` strin - 策略的类型。 - - **若 `type` 的值为 `direct`：** 不进行特殊处理，直接按照此处的文件结构打包。 - - **若 `type` 的值为 `indirect`：** 引用给定的命名空间。对于这些文件，其*目标地址*中的*命名空间*将会自动替换为本策略所在的命名空间。（[示例](projects/1.20/assets/minecraft/minecraft/packer-policy.json)的第二条） - - `source` string - 引用命名空间所在文件夹的**完整地址**。 - - **若 `type` 的值为 `composition`：** 从给定的*组合文件*，直接生成语言文件（或部分）。这些组合文件可能不会被自动排除；可以考虑使用*局域配置*处理。（[示例](projects/1.16/assets/macaws-bridges/mcwbridges/packer-policy.json)的第二条；[组合文件示例](projects/1.16/assets/macaws-bridges/mcwbridges/lang/zh_cn-composition.json)） - - `source` string - 引用组合文件的**完整地址**。 - - `destType` string - 需要生成的语言文件的类型。可以为`json`或`lang`。 - - **若 `type` 的值为 `singleton`：** 引用给定的单个文件。理论上该操作可以选取任何位置的文件，只要目标位置填写正确；不过，一般建议放在*合理的位置*。（[示例](projects/1.19/assets/isometric-renders/isometric-renders/packer-policy.json)的第一条） - - `source` string - 引用文件所在的**完整地址**。 - - `relativePath` - 文件需要被放置的**相对地址**。考虑到连续引用，这里不宜使用**目标地址**。 - -#### [组合文件].json - - -- 根标签 object - - `target` string - 生成的语言文件的**目标地址**。 - - `entries` list - 需要生成的组合项。这些项将会分别执行组合以后，连接起来。 - **如果存在键冲突，打包器会在此崩溃！** 有计划在后期更改这一行为；目前而言，可以使用多个组合文件绕过这个限制。 - - object - 单项策略。 - - `templates` object - 组合所用的模板。所有内容采用**C#格式化模式**填写。 - 粗略地说，其中的格式符有形式 `{0}, {1}, {2},...`，字面量花括号需要用 `{{` 和 `}}` 转义；完整的定义可见 *[.net文档/Composite Formatting](https://learn.microsoft.com/en-us/dotnet/standard/base-types/composite-formatting)*。 - - `<键模板>` string - `<键模板>`对应的值模板。 - - `parameters` list - 组合所用的参数表。参数按照模板中的**索引**顺序排列。不支持嵌套，必须用字面量。 - - object - 每个索引位置上可用的参数。 - - `<键参数>` string - `<键参数>`对应的值参数。 - -### 组合文件 - -组合文件用来生成“组合型”的**语言文件/语言文件片段**，也就是那些有大量重复文本、有明显的格式的语言文件片段。 - -组合文件的工作原理如下： - -- 获取 `entries` 中的全部条目，每个条目代表一种组合模式。 -- 每个条目中，由 `templates` 中的所有条目充当模板，`parameters` 中的所有条目充当参数，生成若干组合后的条目。 - - 在 `parameter` 中，有时会出现多于一组参数；这种情况下，每组参数都会自由组合。 - - 同样的，`templates` 也会和每一套参数自由组合。 -- 将所有组合后的条目汇总，生成语言文件。 - - 在这一过程中，如果出现了**键冲突**，目前而言，**打包器会在此崩溃！** 不过，如果后续观察表明确实存在此种需要，也会考虑修改这一行为。 - -组合文件可以和其他打包策略混合使用，以修改组合中效果不好的部分，或者添加非组合的内容。 - -组合文件理论上可以放在任何位置，使用任何名称；因此，打包器的*基础配置*没有办法排除掉这些文件。不过，为了方便，最好将其汇总在一个位置，采用明确的名称，以便在*局域配置*中排除。 - -## 配置注解 - -上述配置全部采用 `json` 格式书写；这导致的一个问题就是，`json` 格式严格意义上是**不支持注释**的！为了解决这一问题，在使用这些内容时，最好在对应的命名空间内附上**注解文件**。当然，这不是必须的，但最好这么做。同时，也可以在此写下对该目录内容和功能的特殊注释。 - -原则上注解文件可以采用任何形式，但建议写到*命名空间目录下的 `README.md` 文件*中——打包的全局配置默认会排除这一文件。同样的，注解文件的形式也没有特殊限定，但尽量统一为佳。 - -一些注解文件的例子为[这个](projects/1.16/assets/minecraft/minecraft/README.md)、[这个](projects/1.18/assets/minecraft/minecraft/README.md)和[这个](projects/1.18/assets/macaws-furniture/mcwfurnitures/README.md)。 - -> 原则上，这些注解甚至可以自动生成。 - -## 快速参考 - -以下列出了一些与打包流程相关的常见文件配置。如果遇到以下情况，可以直接使用下面的方案。 - -### 版本增添 - -> 该项**需要**预先进行讨论，指定合适的版本支持计划！ - -- 制定版本支持计划。 - 这条一般是由管理层指定的。**有时**，支持计划会在 *Issues* 界面中展示——1.19 与 1.20 的支持计划即这么做了。 -- 判定是否需要工具链更新。 - - 无需更新： - - 创建 `config/packer/[version].json`，并按照本文的指导填写，或参照相近版本的配置文件。 - - 在 `.github/workflows/pr-packer.json` 与 `.github/workflows/packer.json` 中，一处形如 `version: [ "1.12.2", ... ]` 的列表中（如[此处](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package/blob/c1d6b114fba63e86b5df682ec01fc30b818ee5e0/.github/workflows/packer.yml#L102)），加入需增添的版本。 - - 创建 `projects/[version]`，并按照其他版本的格式填写 `pack.png`，`pack.mcmeta`，`LICENSE`，`README.txt` 等内容。 - - 注意 `pack.mcmeta` 需要把花括号转义；可以参照其他版本的文件。 - - 注意 `.../minecraft/minecraft` 下的**字体修复文件**，需要按该版本的字体支持情况考虑填写。通常可以引用旧版本的资源，以减少重复工作。 - - 需要更新： - - 更新工具链。这可能需要很长的时间，取决于更新操作的复杂程度。例如，我们对 **1.20** 的支持稍晚，部分原因就是工作人员 ~我~ 全面更新了一次打包器。 - - 按照“无需更新”的内容执行。 - -### 复用语言文件 - -如果你在维护多版本的模组，有可能会遇到相近或相同的多份语言文件。此时，**复用**语言文件，可以减轻维护负担。 - -#### 完全复用 - -这适用于语言文件完全一致的情况，如不同平台的同一模组。 - -- 确定可用的文件来源。 -- 在目标模组的**命名空间**文件夹下，创建 `packer-policy.json`，填写如下内容，其中 `source` 字段按照前一步找到的来源填写。（[示例](projects/1.18-fabric/assets/iron-furnaces/ironfurnaces/packer-policy.json)） - -```json -[ - { - "type": "indirect", - "source": "projects/[version]/assets/[mod-identifier]/[namespace]" - } -] -``` - -- 尽管理论上不会加载，但仍应删除已有的 `lang/zh_cn.json`，以免误会。`lang/en_us.json` 无需移除。 -- （可选）创建**注解文件**。 - -#### 复用+修改 - -这适用于语言文件大部一致，小部有改动的情况。 - -- 确定可用的文件来源，以及需要做出的修改。多余的字段无需删去（也暂时无法删去；如有需要，会考虑增加此功能）；缺少或不同的字段则需要修改。 -- **方案一**：适用于有多个文件需要修改的情况。（[示例](projects/1.20/assets/minecraft/minecraft/packer-policy.json)） - - 在 `lang/zh_cn.json`（或其他需更改的文件）中，保留与来源文本不一致，需要修改的文本，其余内容删去。 - - 在目标模组的**命名空间**文件夹下，创建 `packer-policy.json`，填写如下内容，其中 `source` 字段按照前一步找到的来源填写。 - -```json -[ - { - "type": "direct" - }, - { - "type": "indirect", - "source": "projects/[version]/assets/[mod-identifier]/[namespace]" - } -] -``` - -- **方案二**：（[示例](projects/1.19/assets/isometric-renders/isometric-renders/packer-policy.json)） - - 以合适名称创造新文件（“修改文件”），仅包含与来源文本不一致，需要修改的文本，其余内容删去。 - - 在目标模组的**命名空间**文件夹下，创建 `packer-policy.json`，填写如下内容，其中两个 `source` 字段依次填写修改文件、来源命名空间的**完整地址**，`destination` 字段填写目标文件的**相对地址**。 - -```json -[ - { - "type": "singleton", - "source": "projects/[version]/assets/[mod-identifier]/[namespace]/[file-path]", - "relativePath": "[file-path]" - }, - { - "type": "indirect", - "source": "projects/[version]/assets/[mod-identifier]/[namespace]" - } -] -``` - -- （可选）创建**注解文件**。 - -#### 选取单文件 - -若来源有多个文件，但只需要其中某个文件，可以将上述方案中，`indirect` 策略替换为以下文本： - -```json -{ - "type": "singleton", - "source": "projects/[version]/assets/[mod-identifier]/[namespace]/[file-path]", - "relativePath": "[domain]/[file-path]" -} -``` - -其中 `source` 为**完整地址**，`relativePath` 为在最终资源包中，需要放置的**相对地址**。 - -### 添加无语言标识的文件 - -无其他配置时，打包器只会打包**含有简体中文语言标识**的文件，以及 **domain** 为 `font`、`textures` 的文件。如果需要添加不满足此要求的文件，需要适当修改配置文件。 - -#### 按domain集中添加文件 - -这适用于集中在一个或几个 **domain** 下的文件。 - -- 确定该模组需要加入的 **domain**。 -- 在目标模组的**命名空间**文件夹下，创建 `local-config.json`，填写如下内容：（[示例](projects/1.20/assets/applied-energistics-2/ae2/local-config.json)） - -```json -{ - "inclusionDomains": [], - "exclusionDomains": [], - "exclusionPaths": [], - "inclusionPaths": [], - "characterReplacement": {}, - "destinationReplacement": {} -} -``` - -- 在上述文件中，`inclusionDomains` 处，按照 `Json` 格式填写所需的 **domain**。 - -此外，若可以确定该**domain**在该版本普遍需要添加，可以转而在全局配置 `config/packer/[version].json` 中进行相应修改。 - -#### 添加零散文件 - -这适用于文件没有特殊集中位置的情况。 - -- 确定该模组需要加入的文件。 -- 在目标模组的**命名空间**文件夹下，创建 `local-config.json`，填写如下内容： - -```json -{ - "inclusionDomains": [], - "exclusionDomains": [], - "exclusionPaths": [], - "inclusionPaths": [], - "characterReplacement": {}, - "destinationReplacement": {} -} -``` - -- 在上述文件中，`inclusionPaths` 处，按照 `Json` 格式填写所需文件的**相对路径**。 - -通常不应将这种配置写入全局配置。 - -### 常用组合文件参数 - -原版 16 色 - -```json -{ - "black": "黑色", - "blue": "蓝色", - "brown": "棕色", - "cyan": "青色", - "gray": "灰色", - "green": "绿色", - "light_blue": "淡蓝色", - "light_gray": "淡灰色", - "lime": "黄绿色", - "magenta": "品红色", - "orange": "橙色", - "pink": "粉红色", - "purple": "紫色", - "red": "红色", - "white": "白色", - "yellow": "黄色" -} -``` - -机械动力岩石 - -```json -{ - "andesite": "安山岩", - "asurine": "皓蓝石", - "calcite": "方解石", - "crimsite": "绯红岩", - "deepslate": "深板岩", - "diorite": "闪长岩", - "dripstone": "滴水石", - "granite": "花岗岩", - "limestone": "石灰岩", - "ochrum": "赭金砂", - "scorchia": "焦黑熔渣", - "scoria": "熔渣", - "tuff": "凝灰岩", - "veridium": "辉绿岩" -} -``` diff --git "a/docs/\344\273\223\345\272\223Wiki.md" "b/docs/\344\273\223\345\272\223Wiki.md" deleted file mode 100644 index 1eafd9beda59..000000000000 --- "a/docs/\344\273\223\345\272\223Wiki.md" +++ /dev/null @@ -1,474 +0,0 @@ -# 第一章 了解语言文件 - -## 1. 语言文件发展历史 - -语言文件（这里特指模组相关语言文件）的发展是一个极为曲折的过程。 - -### ① Minecraft 1.6.1 之前 - -在 Minecraft 1.6.1 之前官方还没有指定相关规范，模组本身缺乏对多语言的支持。诸如工业、建筑这样的模组，可能还给提供语言文件，但其他大部分模组直接都是硬编码语言文件。 - -> 硬编码：将可变变量用一个固定数值表示。由于可变变量是固定不变的，一旦编译后很难修改。 -> -> 软编码：和硬编码相对，将可变变量用特殊标记来表示。这样在编译后，只需要修改这个特殊标记即可。 - -为了能够翻译相关模组，当时的翻译者往往需要 jd-gui 这样的反编译工具来反编译模组，而后修改模组的常量池来参与翻译。这样翻译不但效率低下，一旦翻译错误，整个模组文件就报废了。 - -> 关于早期模组翻译，可以参见： - -### ② Minecraft 1.6.1 ~ Minecraft 1.10.2 之间 - -1.6.1 之后官方相关规范的出现，大大简化了翻译的难度。官方采用了简单的语言文件格式来加载本地化，语言文件甚至可以被资源包所替换。大致规则如下： - -- 语言文件都位于 `assets/modid/lang/` 下，其中 modid 是随意的，依据具体的模组不同，名字可能不同。比如林业模组的语言文件都位于 `assets/forestry/lang` 文件夹下。 -- 可以通过资源包覆盖语言文件，覆盖机理和材质一致。 - - -- 语言文件命名参照了 [ISO639](https://www.iso.org/iso-639-language-codes.html) 标准：英文（美国）就是 `en_US.lang`，中文（中国大陆）就是 `zh_CN.lang` - -- 语言文件格式是简单的 `key=value` 方式书写： - - ```properties - item.apple.name=苹果 - tile.stone.name=石头 - ``` - - - > 在上述案例中 `item.apple.name` 就是 `key`，而 `苹果` 就是 `value`。 - -- 以 `#` 开头的段落识别为注释： - - ```properties - # 注释 - # 注释中可以随便书写文字，均不会加载 - item.apple.name=苹果 - tile.stone.name=石头 - ``` - -- 语言文件编码为 `utf-8 无 BOM 编码` - - > [BOM](https://en.wikipedia.org/wiki/Byte_order_mark) - > - > **字节顺序标记**（byte-order mark，**BOM**），即放置在文件开头的字符 `\uFEFF`，它常被用来当做标示文件是以 UTF-8、UTF-16 或 UTF-32 编码的记号。 - -### ③ Minecraft 1.11 以后 - -1.11 版本更新后，官方对部分文件大小写做了严格规范，资源相关的文件名需要通过资源包的 `pack.mcmeta` 中的 `pack_format` 参数来决定。 - -> 一个只包含 `pack_format` 和 `description` 参数的 `pack.mcmeta` 文件，可以看到书写格式和 JSON 一致。 -> -> ```json -> { -> "pack": { -> "pack_format": 3, -> "description": "模组资源文件" -> } -> } -> ``` - -- 当设定为 `2` 时，语言文件名采用旧版本书写方式，英文（美国）就是 `en_US.lang`，中文（中国大陆）就是 `zh_CN.lang`。 - - -- 当设定为 `3` 时，语言文件名需要全小写。比如英文（美国）就是 `en_us.lang`，中文（中国大陆）就是`zh_cn.lang`。 - -除此之外其他规则一致。 - - -## 2. 模组语言文件加载机理 - -### ① 普通语言文件加载 - -> 这一块参考 Minecraft 1.12.x 版本的 Forge 代码。 -> 源代码：[【1】](https://github.com/MinecraftForge/MinecraftForge/blob/1.12.x/src/main/java/net/minecraftforge/fml/common/FMLCommonHandler.java#L707-L747) [【2】](https://github.com/MinecraftForge/MinecraftForge/blob/1.12.x/patches/minecraft/net/minecraft/util/text/translation/LanguageMap.java.patch) - -Minecraft 加载语言文件的机理很简单： - -1. 游戏读取所有模组的 `assets/modid/lang/` 下的语言文件； - -2. 将语言文件处理成映射表； - - 我们刚刚在[第一章](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package/wiki/%E5%86%85%E5%AE%B9#%E7%AC%AC%E4%B8%80%E7%AB%A0-%E4%BA%86%E8%A7%A3%E8%AF%AD%E8%A8%80%E6%96%87%E4%BB%B6)中有简单说过 Minecraft 的语言文件，游戏将会按照条目中的**第一个等号**来拆分成映射表。 - - > 比如 `a=b=c` 在游戏中会拆分成 `a` 和 `b=c` 两个条目，形成一对映射； - -4. 游戏中依据映射表、具体选择的语言来加载翻译条目； - -4. 如果指定语言找不到映射，则开始在 `en_us.lang` 中寻找映射； - -5. 如果在 `en_us.lang` 中还是找不到对应的映射，直接显示`key`； - - > **映射** - > - > 两个非空集合 A 与 B 间存在着对应关系，而且对于 A 中的每一个元素，B 中总有有唯一的一个元素与它对应，就这种对应称为从 A 到 B 的映射。 - -### ② 带有 `#PARSE_ESCAPE` 注释语言文件加载 - -Forge 新增了一个特殊读取：如果注释中存在 `#PARSE_ESCAPE` 注释，那么处理将会严格按照 Java Properties 格式来读取，并处理成映射表； - -Properties 格式很像 Minecraft 语言文件格式，但是要更加灵活强大： - -- Properties 采用 `:` 或 `=` 来书写映射，也是按照第一个 `:` 或 `=` 来拆分成映射表。下面两种书写方式均是正确的： - - ```properties - #PARSE_ESCAPE - item.apple.name:苹果 - item.apple.name=苹果 - ``` - -- Properties 可以采用转义字符来转义 `:` 或者 `=`，转义过的字符不会被识别。 - - ```properties - #PARSE_ESCAPE - item.apple\:name:苹果 - item.apple\=name=苹果 - ``` - -- Properties 可以写成多行的，通过每行行尾的 `\` 符号来识别： - - ```properties - #PARSE_ESCAPE - item.apple.name:苹果\ - 挺好吃的 - item.apple.name=苹果\ - 不咋好吃\ - 真的\ - 确实不好吃 - ``` - -- Properties 采用 `#` 或者 `!` 来书写注释： - - ```properties - #PARSE_ESCAPE - ! 这是一条注释 - item.apple.name:苹果 - # 这也是一条注释 - item.apple.name=苹果 - ``` - -### ③ 映射重名问题 - -由于游戏是将所有模组的语言文件放在一起处理，一些粗心大意的模组作者在书写语言文件方面如果考虑不周，就会罕见的存在映射重名问题。 - -比如经典的 [ShetiPhianCore](https://minecraft.curseforge.com/projects/shetiphiancore) 译名冲突，在 ShetiPhianCore 模组中存在着这几个翻译条目： - -```properties -item.dyePowder.green.name=绿色染料 -item.dyePowder.red.name=红色染料 -item.dyePowder.yellow.name=黄色染料 -``` - -而类似的条目在 Minecraft 原版中恰好也存在，它们的 key 完全相同： - -```properties -item.dyePowder.green.name=仙人掌绿 -item.dyePowder.red.name=玫瑰红 -item.dyePowder.yellow.name=蒲公英黄 -``` - -结果导致 [ShetiPhianCore](https://minecraft.curseforge.com/projects/shetiphiancore) 模组的这几个条目直接覆盖了原版的语言文件，导致玩家在游戏中获取了错误的翻译。 - -除此之外诸如更多武器模组的 `武士刀 `与 PlusTiC 模组的 `李奥纳多的武士刀` 名称相互冲突的等等问题，不一而具。 - -所幸的是这些问题很少见，而且出现后仅仅是对游戏内翻译有所影响，不会带来任何其他方面的崩溃或者冲突。如果你在翻译过程中发现了这些问题，请及时向模组的原作者反馈。 - -# 第二章 基础知识 - -## 1. 字符编码 - -计算机只能识别二进制代码，如果想要让计算机存储或者识别字符，就需要将字符转变为二进制代码。随着时代、用途等诸多因素的影响，字符编码的标准也各不相同。 - -这部分东西会非常多而乱，初学者可能会各种懵逼。没办法……谁让这是计算机呢…… - -### ① ASCII 码 - -1967 年美国国家标准学会制定了第一个字符编码规范，这就是赫赫有名的 ASCII 码。 - -ASCII 码使用 7 位二进制数（剩下的1位二进制为0）来表示所有的大写和小写字母、数字 0 到 9、标点符号， 以及在美式英语中使用的特殊控制字符。 - -然而 ASCII 码支持的字符太少，而后世界各国又独自演化出了适应本国使用的各种编码。诸如中国大陆的 GB2312 编码，日本的 Shift-JIS 编码。 - -![USASCII_code_chart.png](https://i.loli.net/2018/03/25/5ab795ee2c1af.png) - -### ② ISO-8859-1 编码 - -也常被称为 `Latin-1` 编码，在 ASCII 的基础上额外加入 96 个字母及符号，使其能够广泛支持西欧各国语言。 - -特意提一下这个编码，部分欧美作者在书写语言文件时会偶然忘记改变文件编码，系统便自动使用 ISO-8859-1 编码书写语言文件。如果不慎语言文件中出现了非 ASCII 字符，那么这部分字符就会乱码。更有甚者强制使用 ISO-8859-1 编码中文文件，导致翻译者提交的正确翻译，在编译后乱码。 - -典型代表： - -- [Dungeon Tactics](https://minecraft.curseforge.com/projects/dungeon-tactics) 模组，`en_US.lang` 采用 ISO-8859-1 编码。读取其 1.12.2 版本模组 `en_US.lang` 第 245 行字符 `ü`，存在乱码： - - ```properties - item.dungeontactics:terrible_feather.name=Hühnerfeder - ``` - -- [SuperMiner](https://minecraft.curseforge.com/projects/superminer-unified) 模组，`en_US.lang` 采用 ISO-8859-1 编码。读取其 1.12.2 版本模组 `en_US.lang` 第 46 行字符 `§`，存在乱码： - - - ```properties - superminer.excavator.goditems=§aCONGRATULATIONS: §7You've Unlocked the §6God Items§7! - ``` - -### ③ GB 编码 - -- 中国国家标准总局 1980 发布的适合中文的编码，第一版为 GB2312 编码，共收入 6763个汉字、682 个非汉字图形字符。由于中文字符的庞杂性，所以采用了两个字节来表示，向下兼容 ASCII 编码。 - - 值得特殊说明的是，在 ASCII 里本来就有的数字、标点、字母，在 GB 编码中又重编了两个字节长的编码，这就是全角字符。 - - ```properties - # 半角数字、标点、字母 - 1234567890,.abcdefg - - # 全角数字、标点、字母 - １２３４５６７８９０，．ａｂｃｄｅｆｇ - ``` - -- 1995 年又制定了 GBK 编码，GBK 共收入 21886 个汉字和图形符号，兼容 GB2312 编码。 - -- 2000 年又制定了 GB18030 编码，这次收录了 70244 个中文字符，兼容 GBK 编码。GB18030 编采用一二四字节的变长编码。 - -值得一提的是，Windows 操作系统默认的文件编码方式是 ANSI 编码，在简体中文系统就指的 GB 编码。在日文系统上就指的是 Shift-JIS 编码。至于你问为什么非要用这个名字……去问微软爸爸啊。 - -### ④ Unicode 编码 - -世界各国的编码太多太乱了，我们来指定一个全新的通用标准吧，于是 Unicode 编码应运而生。Unicode 编码支持全世界各国文字，采用统一的编码，兼容 ISO 8859-1 编码。~~Unicode 编码依据不同的长度，具体实现方面又分为 UTF-8、UTF-16、UTF-32。（不考）~~最常用的就是 UTF-8 编码。 - -MacOS 和 Linux 都还不错，操作系统默认都是 UTF-8 无 BOM 编码； - -Windows 系统则不然，采用 ANSI 编码，依据不同国家采用不同国家的国标码。但对 UTF-8 编码也有支持，我们在存储文件的时候还是可以将编码选择为 UTF-8 编码。 - -![weiruanbaba.png](https://i.loli.net/2018/03/25/5ab7b1d01cd64.png) - -**但是！**Windows 下存储的 UTF-8 编码文件，其开头加入了字节顺序标记（byte-order mark，简称 BOM，即放置在文件开头的字符 `\uFEFF`），用来当做标示文件是以 UTF-8、UTF-16 或 UTF-32 编码的记号。部分程序并不支持 BOM，导致处理该字符时候会报错。 - -我们日常使用的 Java 7/8 以及 Python 3 这些计算机语言，内部实现默认都使用无 BOM 的 UTF-8 编码。但是在没有指定语言编码的情况下读取系统文件，仍旧是沿用系统编码。这在下一章的存储格式中会有详细的说明，这也是很多令人头疼问题的导火索。 - -## 2. 文件格式 - -这一章我们将介绍模组翻译中会遇见的各种文件格式，以及各种形形色色的问题。 - -### ① 原版语言文件 - -幸运的是，原版语言文件制定了较为严格的规定，同时也提供了方便易用的 I18n 方法。除了极少数模组，大部分模组都较好的遵循了原版语言文件。对几个特立独行的模组简单介绍下： - -- 工业模组：至今仍然采用 `Java Properties ` 格式书写语言文件。 -- 格雷科技：采用程序生成的配置文件来书写语言文件，启动时需要将语言文件放置在游戏主文件夹下。 -- McJty：一个模组作者，写过很多知名的模组，比如 RFTools 三件套，The One Probe 等。除了官方强制要求添加本地化的部分（方块、物品、成就、标签页），其他部分全部采用硬编码。不过所幸他认识到了这个问题，在比较新的 [MeeCreeps](https://minecraft.curseforge.com/projects/meecreeps) 模组中已经开始书写较为全面的语言文件了。本人也表示会在之后逐步在其他模组中添加更多语言文件。 -- [Extreme Reactors](https://minecraft.curseforge.com/projects/extreme-reactors)：属于旧版本遗留问题，所有的 GUI 目前仍旧采用硬编码。 - -原版语言文件的书写与格式在第一章中都详细叙述了，此处不再过多介绍。 - -### ② JSON 语言文件 - -#### （1）JSON 基本介绍 - -全称 JavaScript 对象表示法（JavaScript Object Notation），是一种轻量级的数据交换格式，完全独立于编程语言的文本格式来存储和表示数据。**JSON 不允许写入注释**，整体规则很简单，总结如下： - -- 数据由逗号分隔； -- 花括号保存映射； -- 方括号保存数组； - -下面我们先书写一个最简单的 JSON 文件，包含一对映射，一个存有两个数据的数组： - -```json -{ - "item.apple.name": "苹果", - "item.list.name": [ - "苹果", - "香蕉" - ] -} -``` - -JSON 有很多在线的格式化工具，能够检查我们书写的语法是否有错误，以及对数据进行重新排版。 - -- [JSON.cn](http://www.json.cn/) -- [BeJSON](https://www.bejson.com/) - -#### （2）编码问题 - -按照标准，JSON 文件应当使用 UTF-8 无 BOM 编码，但是部分作者未强制指定编码，导致游戏中中文翻译乱码，或者更甚者无法启动游戏。 - -经典代表就是 [FTB Achievements](https://minecraft.curseforge.com/projects/ftb-achievements) 模组，它在很多 FTB 整合包中均有使用。在 [FTB Skyfactory Challenges](https://www.feed-the-beast.com/projects/ftb-skyfactory-challenges) 整合包中，其所有的挑战任务均使用 [FTB Achievements](https://minecraft.curseforge.com/projects/ftb-achievements) 书写，任务文件在游戏主目录下的 config 文件夹中，采用 JSON 格式书写。其所有的任务描述由配置中的 `tagCompound` 标签书写，但是作者似乎并没有限定编码，导致其强制以 ASCII 编码进行解析，如果不慎写入中文字符，启动过程中游戏会直接崩溃。 - -所幸还是有办法解决，通过转义字符书写 Unicode 编码，即可正常加载。但是转义字符书写的 Unicode 编码毕竟不适合阅读，在翻译过程中检查排错都很困难，如果出现了这些编码问题，请及时向原作者反馈问题。 - -> **转义书写的 Unicode 编码字符** -> -> 采用四位 16 进制，开头辅以 `\u` 字符来转义；比如正常的 `中文` 二字，Unicode 编码为 `\u4e2d\u6587` 。当程序读取到这些转义字符时，便会以 Unicode 编码来进行解析，从而在其他编码环境的文件中愉快的插入 Unicode 字符。 -> -> 网络上有很多相关工具可以将普通字符转换为 Unicode 转义字符，比如[站长工具](http://tool.chinaz.com/tools/unicode.aspx)。 - -#### （3）传参崩溃问题 - -一般 JSON 书写的文件除了语言文件之后，还有许多功能性参数。如果我们在错误的地方进行了翻译，而作者代码又不够健壮，就会导致游戏崩溃。这种崩溃可能是启动中崩溃，也可能是游戏中触发某个事件后崩溃。 - -举个例子，匠魂模组 2.5 版本手册中曾经存在一个翻译错误，翻译者~酒石酸~错误的翻译了 `shulking.json` 文件的`modifier` 字段，此处字段应当为工具强化的 id，不能够翻译。该错误导致匠魂手册在长达半年的时间，中文玩家一打开就会游戏崩溃。 - -![捕获.PNG](https://i.loli.net/2018/03/27/5aba1a06e4372.png) - -> :arrow_up: 上图中 `modifier` 字段不应当翻译。 - -如何判定当前字段是否应当被翻译，需要翻译者查看具体源码，或者多次试错才能够发现，难度较大。 - -### ③ XML 语言文件 - -可扩展标记语言（**EXtensible Markup Language**，简称 XML）是一种标记语言，很像 HTML 语言，不过所有的标签均可自定义。XML 可读性较 JSON 稍差，除了早期模组，现在极少有模组使用这种语言。 - -XML 语言大致结构如下，整个文件主体部分必须要被标签所囊括，可以添加注释： - -```xml - - - George - John - Reminder - Don't forget the meeting! - -``` - -关于更多 XML 知识，可以查看 [W3school 中文教程](http://www.w3school.com.cn/xml/index.asp)。 - -目前所知还在使用 XML 语言的模组仅有 [InGame Info XML](https://minecraft.curseforge.com/projects/ingame-info-xml) 模组。如同 JSON 语言一样，XML 也可能包含很多功能性参数，如果书写位置错误，也可能会导致游戏崩溃。好在 [InGame Info XML](https://minecraft.curseforge.com/projects/ingame-info-xml) 作者代码健壮性还不错，只会导致无法加载，游戏并不会崩溃。 - -这里截取了部分 [InGame Info XML 配置文件源码](https://github.com/Lunatrius/InGame-Info-XML/blob/master/src/main/resources/assets/ingameinfo/ingameinfo.xml)。 - -```xml - - Day {day}, {mctime} ( - - daytime - $eDay - $8Night - - time$f) - -``` - -图中只有 `` 便签围起来的部分可以被翻译。 - -### ④ YAML 语言文件 - -YAML 英文原名为 YAML Ain't Markup Language，YAML 可以方便的表达映射、数组之类的数据，而且采用缩进表示层级关系，阅读性极高。 - -YAML 格式一般如下： - -```yaml -house: - family: - name: Doe - parents: - - John - - Jane # 可以随意插入注释 - address: - number: 34 - street: Main Street - "city": "Nowheretown" - zipcode: 12345 -``` - -- 缩进并没有强制要求，只需要保证同级数据缩进相等即可，不过不可以使用 tab 缩进； -- 数据可以依据个人习惯选择是否用引号圈住； -- `#` 后插入注释； -- 数组内元素采用 `-` 符号，相同缩进来表示； - -采用 YAML 书写配置或者语言文件的模组极为罕见，但在插件的配置、语言文件中几乎全部采用此语言书写。 - -### ⑤ 其他格式 - -然而总是会有模组作者另辟蹊径，选择自定义的格式来书写语言文件或者配置，典型代表就是格雷科技和 [Simple Achievements](https://minecraft.curseforge.com/projects/simple-achievements) 模组。 - -格雷科技采用了原版配置文件格式来加载语言文件，且加载位置放置在游戏主目录下。下图为部分语言文件截取： - -``` -languagefile { - S:"Dirty Water.name"=脏水 - S:bc.trigger.gregapi.energy.air.capacity.empty=空的 (ENERGY.AIR) - S:bc.trigger.gregapi.energy.air.capacity.full=满的 (ENERGY.AIR) -} -``` - -其次是 [Simple Achievements](https://minecraft.curseforge.com/projects/simple-achievements) 模组书写的任务书，这部分配置同样没有限定编码，需要转换成 Unicode 字符，或者采用 GB 编码书写才可以正常使用。 - -下图为其部分截取，作者并未为此添加 `try catch` 结构，如果书写错误，游戏会启动崩溃。 - -``` ---== 神秘农业 ==--| |资源始终是有限的，作物才能满足你的需求::1 -合成一个铁种子::0 -合成一个钻石种子::0 -使用离魂块获得一个怪物灵魂碎片::0 -使用生长水晶和生长加速器::0 -合成一个大师级的注魔水晶::0 -合成一个终极苹果::0 -合成一个终极防具::0 -::1 -::1 -::1 -``` - -## 3. Git 与 GitHub - -### ① Git 基本介绍 - -小明在写一个程序，万恶的产品经理不停地在改需求，小明只好把写好的代码改了删，删了改。一来二去，小明电脑上的文件越来越乱，小明急切的需要一套特殊的工具，能够完美的管控文件，快捷的撤销、重复之前的步骤。我们把这种工具叫版本控制系统（**Version Control System**，简称 VCS）。 - -而 Git 就是其中出色的一款系统，由 Linux 的创始人林纳斯·本纳第克特·托瓦兹创建，Git 监控文件变化的机理很简单——只记录文件的改变。 - -现在有个文件，内容如下： - -``` -Hello World！ -``` - -我么对其进行修改： - -``` -Hello MC！ -你好世界！ -``` - -对于 Git 来说，就记录了这样的变化： - -```diff -- Hello World！ -+ Hello MC！ -+ 你好世界！ -``` - -这样的方式给多人协作带来了极大的方便，因为只记录变化的部分，只要两个人修改的不是同一处文件，简单的把两人的变化记录在一起，即可完美实现协作功能。 - -### ② GitHub 是什么？ - -我们书写了代码，如果想要给其他人观看，就必然要把代码放置在网络上。好在如今有很多网站提供了免费的代码托管。国外的有 GitHub，Gitlab，Bitbucket，国内的有 Coding，而 GitHub 则是其中用户量最大的一家。GitHub 上面的代码全部采用 Git 进行管理，同时支持多人协作，对于公开项目完全免费。 - -**网址：** - -![QQ截图20180328120221.png](https://i.loli.net/2018/03/28/5abb13dba03a9.png) - -### ③ Git 与 GitHub 的使用 - -GitHub 虽然能够支持网页上直接进行操作，但是功能非常少，使用起来也不方便。更多的时候是直接通过 Git 的命令行或者图形化程序来进行代码的下载、本地修改、上传等操作。 - -如果是 Windows 系统，用户需要去 [Git 官网](https://git-scm.com/)下载安装包，安装后即提供了命令行工具。 - -![QQ截图20180328120716.png](https://i.loli.net/2018/03/28/5abb14fa2e8b1.png) - -## 4. 文本编辑器 Atom 的介绍 - -## 5. 正则表达式 - -# 第三章 翻译规范 - -## 1. 翻译指南 - -## 2. 词库 - -# 第四章 自动化翻译 - -## 1. 爬虫系统 - -## 2. Weblate 翻译平台 - -## 3. 持续化集成系统 - diff --git "a/docs/\347\277\273\350\257\221\347\224\250\350\257\255\345\205\261\350\257\206.md" "b/docs/\347\277\273\350\257\221\347\224\250\350\257\255\345\205\261\350\257\206.md" deleted file mode 100644 index fc4621b37289..000000000000 --- "a/docs/\347\277\273\350\257\221\347\224\250\350\257\255\345\205\261\350\257\206.md" +++ /dev/null @@ -1,11 +0,0 @@ -# 翻译用语共识 - -1. “材料 + 质/制 + 中心词”的翻译，如“铁质涡轮”或“铁制涡轮”，二者皆合理。只需单模组内（包括其附属与联动）统一。 -2. 对砖与砖块的翻译： - - 由物品 brick 合成的 bricks，译作某砖块。brick 译作某砖 - - 不通过 brick 合成的 bricks，且纹理与原版石砖（大砖砖块）相似的，译作某砖。 - - 不通过 brick 合成的 bricks，且纹理与原版石砖（大砖砖块）不相似的，建议译作某砖块，译作某砖也可。 -3. 对菜品的翻译： - - 菜品名的翻译相对自由，有较大发挥余地。但经验不足的译者不要发挥太过。 - - 关于食品等在不同规范下的不同翻译，如“冰激凌”（《现代汉语词典》推荐）或“冰淇淋”（《食品科学技术名词》），二者皆合理。只需单模组内（包括其附属与联动）统一。 - - 有其他常用称呼的，若模组作者或审查人无异议，可以使用该称呼。 From 9128dffb8274ee2c3caf98889742aa305be0d58d Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Sun, 20 Jul 2025 17:27:36 +0800 Subject: [PATCH 11/13] =?UTF-8?q?packer=20doc=E5=BF=98=E6=94=B9=E5=9B=9E?= =?UTF-8?q?=E6=9D=A5=E4=BA=86?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Packer-Doc.md | 410 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 410 insertions(+) create mode 100644 Packer-Doc.md diff --git a/Packer-Doc.md b/Packer-Doc.md new file mode 100644 index 000000000000..3554b07cc641 --- /dev/null +++ b/Packer-Doc.md @@ -0,0 +1,410 @@ +# 打包机制文档 + +**跳转：[快速参考](#快速参考)** + +## 注意事项 + +- 文件地址中，目录分隔符**一律使用正斜杠（`/`）**！ +- 地址相关 + - 下述说明中，**完整地址**永远指从**仓库根目录**算起的地址，例如对根目录下的 `CONTRIBUTING.md`，应为 `CONTRIBUTING.md`；对1.12版本资源包的 `pack.png`，应为 `projects/1.12.2/pack.png`。 + - 下述说明中，**相对地址**永远指从**特定命名空间的文件夹**算起的地址，例如对仓库中的 `projects/1.18/assets/minecraft/minecraft/font/default.json`，应为 `font/default.json`。 + - 下述说明中，**目标地址**永远指**分发的资源包中**，该文件应当被放置的位置，例如对上一条中提及的文件，应为 `assets/minecraft/font/default.json`。 +- 文件相关 + - 下述说明中，**语言文件**永远指可以被打包器解读为**映射表**的文件。这包括了所有 **`lang/` 下的 `.lang` 和 `.json` 文件**。 + - 下述说明中，**文本文件**永远指含有**文本内容**，但**不属于语言文件**的文件。这包括了非语言文件的 `.txt`、`.md`、`.json` 文件。 + - 下述说明中，**非文本文件**永远指**不属于以上两类**的文件，如图片或其他二进制文件。 +- 本次打包器更新以后，对于**非文本文件**无需特殊处理：打包器会按照文件拓展名自动识别文件类型。 + + + +## 配置文件 + +配置文件分为两类： + +- 放置在 `config/packer` 下的**全局**配置文件，用作整个打包流程的基础配置； +- 放置在各命名空间下的**局域**配置文件，用于对特定命名空间（以及模组）提供特殊的配置项。 + +### 文件格式 + +目前而言，所有配置文件都需要填写全部项——无关项可以填写空集合，但不能不填，更不能写 null。有计划在将来优化这一行为。 + +#### 全局配置文件 + +**全局**配置文件 `config/packer/.json` 的格式如下： + +- 根标签 object + - `base` object + 打包流程中的*不变配置*，不能被文件结构中的**局域配置文件**改写。包含的内容都是**不低于**命名空间层级的，因为局域配置文件就是放在命名空间一级中的。 + - `version` string + 该配置文件指向的版本，以 `projects/` 中的文件夹名称为准。原则上*应当*与文件名中的 [version] 一致。 + - `targetLanguages` list + 打包的目标语言，即最终在资源包中存在的语言。 + - string + 目标语言，即该版本使用的语言标识符。 + 以在 `lang` 下的语言文件的文件名，以及其他文件的路径中，标明语言的部分为准。目前而言，使用的是 `zh_cn`，尽管有消息称将要改用 `zho_Hans-CN`。 + - `exclusionMods` list + 被打包器排除的模组文件夹。 + 如果因为某些原因需要移除某个模组的翻译（如移交官方/其他团体等），但意图保留原有翻译，可能需要这一项。 + - string + 排除的模组。 + - `exclusionNamespaces` list + 被打包器排除的 **[namespace]** | **(命名空间)**。 + 暂时闲置，以待后续需求。 + - string + 排除的命名空间。 + - `floating` object + 打包流程中的*可变配置*，可能被文件结构中的**局域配置文件**改写。包含的内容都是**低于**命名空间层级的，因为局域配置文件就是放在命名空间一级中的。 + - `inclusionDomains` list + 强制包含的 **[domain]**。 + 一般而言，用于通常不会包含**语言标识符**的 `domain`。 + 一般而言会包含 `font` 与 `textures`，因为这两处往往不带语言标识符，且字体修复已经需要用到这两个domain；其他内容多半会出现在*局域配置*中。 + - string + 强制包含的domain名称。 + - `exclusionDomains` list + 强制排除的 **[domain]**。 + 暂时闲置，或可用于排除一些策略相关的零散文件。 + - string + 强制排除的domain名称。 + - `exclusionPaths` list + 强制排除的 **[相对地址]**。 + - string + 强制排除的文件的**相对地址**。 + 一般而言，在主配置中只会放置通用的忽略对象，例如 `packer-policy.json` 和 `local-config.json`；其余条目最好放在*局域配置*中。 + - `inclusionPaths` list + 强制包含的 **[相对地址]**。 + 暂时闲置，可以用于添加零散的无语言标记文件。 + - string + 强制包含的文件的**相对地址**。 + - `characterReplacement` object + 打包时采用的字符替换表。用于将部分字符替换至特殊位点，也可单纯用于简化输入。目前而言，包含了字体修复的有关内容。 + - `<查询语句>` string + 用以替换**正则表达式**`<查询语句>`匹配对象的内容，可以是一个或多个字符，甚至可以在这里用**正则替换语句**。 + 主要用于*字体修复包*所需的**符号替换**，此时，查询语句通常是字面量，替换内容一般而言总是以四位 *Unicode 转义码*填写；对于**基础多语种平面（BMP）**以外的字符，最好用 **UTF-16 代理对**书写。 + - `destinationReplacement` object + 打包时采用的目标地址替换。 + 可以用于移动文件，但暂时闲置；使用**检索策略**中的`singleton`也可以实现地址替换，但需要在每个模组下配置。 + - `<查询语句>` string + 用以替换**正则表达式**`<查询语句>`匹配对象的内容，可以是一个或多个字符，甚至可以在这里用**正则替换语句**。 + +#### 局域配置文件 + +**局域**配置文件 `projects//assets///local-config.json` 的格式与全局配置文件中，`floating` 标签下的内容（*可变配置*）一致。 + +### 文件容斥顺序 + +介于在配置文件中出现了多种包含/排除文件的配置项，有必要说明以下这些项生效的顺序： + +1. `exclusionMods` 和 `exclusionNamespaces` 在进入命名空间前即会排除相应的文件夹——甚至不会加载其中的 `local-config.json`。 +当然，如果是通过*检索策略*访问的，则这一项不会生效。 +2. 在剩下的命名空间中，检索文件。下面的配置项可能会被当地的*局域配置*修改，除了 `targetLanguages` 以外。 +3. 在所有检索到的文件中，排除掉 `exclusionPaths` 指定的文件，即便是通过*检索策略*访问的。 +4. 在剩下的文件中，直接包含 `inclusionPaths` 和 `inclusionDomains` 指定的文件。 +5. 在剩下的文件中，排除掉 `exclusionDomains` 指定的文件。 +6. 在剩下的文件中，仅包含由 `targetLanguages` 指定的，在路径中任意位置包含有*简体中文语言标记*的文件，其他文件不予包含。 + +### 局域配置文件的重写规则 + +- 如果在某个命名空间内检测到存在 `local-config.json`，打包器将会在全局配置的基础上，在其*可变配置*中**添加**该文件中的内容，并用这一修改后的配置执行**该命名空间下的**检索工作。 +- 最好不要与全局配置中的内容重复。尽管理论上这样子可以运行，但是重复项保留哪一个或许不容易断定。 +- 需要注意的是，如果通过*检索策略*来**引用其他命名空间**，打包器**只**会加载目标命名空间的局域配置，而**不会**加载原空间的局域配置；不过，在原位进行的检索工作不受影响。 + +## 检索策略 + +对于每个**命名空间文件夹**，打包器除了可以原位检索文件以外，还可以**使用不同的检索方式**。目前，可用的检索方式有四种： + +1. **原位**检索文件。 +2. **引用**给定的命名空间。 +3. 从给定的**组合**文件，直接生成语言文件（或部分）。 +4. 引用**单个**文件。 + +> 计划中，将对*非语言文件的文本文件*添加一个**修改包**策略，但是这个策略暂时还没实现，部分原因是在上一版打包器中，这个策略还没被用过。 + +单独看起来，这或许没什么用（打包器的上一版中，功能还要多些）；但有一点很重要：这些加载策略是可以**串联**、**递归**的！于是，通过这些策略，应该可以满足许多需求。 + +- **串联**：在一个策略文件中，可以放置**多条策略**。策略将会从前往后执行，**前者**优先——和*Minecraft资源包*顺序差不多。不过，在文件冲突时，也提供了一些特殊的冲突解决选项。 +- **递归**：如果**引用**了其他命名空间文件夹，那里的策略文件**也会生效**。这意味着可以实现*连续引用*——尽管前提是不出现**循环引用**。 + +部分案例被放在了 `projects/packer-example/` 这一虚拟的“版本”下。很明显，我们**并不会**分发这一版本，但如果有条件，可以在本地构造打包器，并用这一版本做试验。 + +### 策略相关文件的格式 + +#### packer-policy.json + +对于每个**命名空间文件夹**，策略文件为 `projects//assets///packer-policy.json`。 +若找不到该文件，默认策略内容为 `[{"type": "direct"}]`，也就是**原位**加载，没有特殊配置。 + +- 根标签 list +打包器需要执行的策略，**从前往后执行**。如果有冲突内容，默认以**前者**优先——当然这是可以配置的。 + - object + 单项策略。部分参数可变。 + - `modifyOnly` bool + 默认为 `false`。 + 对于**语言文件**，若本项为 `true`，对于已有的键，若在该步中提供了新的值，则将会用新值替换旧值；**不会**包含本步中新出现的键。 + 对于其他文件，本项无效。 + - `append` bool + 默认为 `false`。 + 对于**文本文件**，将会在已有的文本内容之后**换行**，然后连接本步的内容。 + 对于其他文件，本项无效。 + - `type` strin + 策略的类型。 + + **若 `type` 的值为 `direct`：** 不进行特殊处理，直接按照此处的文件结构打包。 + + **若 `type` 的值为 `indirect`：** 引用给定的命名空间。对于这些文件，其*目标地址*中的*命名空间*将会自动替换为本策略所在的命名空间。（[示例](projects/1.20/assets/minecraft/minecraft/packer-policy.json)的第二条） + - `source` string + 引用命名空间所在文件夹的**完整地址**。 + + **若 `type` 的值为 `composition`：** 从给定的*组合文件*，直接生成语言文件（或部分）。这些组合文件可能不会被自动排除；可以考虑使用*局域配置*处理。（[示例](projects/1.16/assets/macaws-bridges/mcwbridges/packer-policy.json)的第二条；[组合文件示例](projects/1.16/assets/macaws-bridges/mcwbridges/lang/zh_cn-composition.json)） + - `source` string + 引用组合文件的**完整地址**。 + - `destType` string + 需要生成的语言文件的类型。可以为`json`或`lang`。 + + **若 `type` 的值为 `singleton`：** 引用给定的单个文件。理论上该操作可以选取任何位置的文件，只要目标位置填写正确；不过，一般建议放在*合理的位置*。（[示例](projects/1.19/assets/isometric-renders/isometric-renders/packer-policy.json)的第一条） + - `source` string + 引用文件所在的**完整地址**。 + - `relativePath` + 文件需要被放置的**相对地址**。考虑到连续引用，这里不宜使用**目标地址**。 + +#### [组合文件].json + + +- 根标签 object + - `target` string + 生成的语言文件的**目标地址**。 + - `entries` list + 需要生成的组合项。这些项将会分别执行组合以后，连接起来。 + **如果存在键冲突，打包器会在此崩溃！** 有计划在后期更改这一行为；目前而言，可以使用多个组合文件绕过这个限制。 + - object + 单项策略。 + - `templates` object + 组合所用的模板。所有内容采用**C#格式化模式**填写。 + 粗略地说，其中的格式符有形式 `{0}, {1}, {2},...`，字面量花括号需要用 `{{` 和 `}}` 转义；完整的定义可见 *[.net文档/Composite Formatting](https://learn.microsoft.com/en-us/dotnet/standard/base-types/composite-formatting)*。 + - `<键模板>` string + `<键模板>`对应的值模板。 + - `parameters` list + 组合所用的参数表。参数按照模板中的**索引**顺序排列。不支持嵌套，必须用字面量。 + - object + 每个索引位置上可用的参数。 + - `<键参数>` string + `<键参数>`对应的值参数。 + +### 组合文件 + +组合文件用来生成“组合型”的**语言文件/语言文件片段**，也就是那些有大量重复文本、有明显的格式的语言文件片段。 + +组合文件的工作原理如下： + +- 获取 `entries` 中的全部条目，每个条目代表一种组合模式。 +- 每个条目中，由 `templates` 中的所有条目充当模板，`parameters` 中的所有条目充当参数，生成若干组合后的条目。 + - 在 `parameter` 中，有时会出现多于一组参数；这种情况下，每组参数都会自由组合。 + - 同样的，`templates` 也会和每一套参数自由组合。 +- 将所有组合后的条目汇总，生成语言文件。 + - 在这一过程中，如果出现了**键冲突**，目前而言，**打包器会在此崩溃！** 不过，如果后续观察表明确实存在此种需要，也会考虑修改这一行为。 + +组合文件可以和其他打包策略混合使用，以修改组合中效果不好的部分，或者添加非组合的内容。 + +组合文件理论上可以放在任何位置，使用任何名称；因此，打包器的*基础配置*没有办法排除掉这些文件。不过，为了方便，最好将其汇总在一个位置，采用明确的名称，以便在*局域配置*中排除。 + +## 配置注解 + +上述配置全部采用 `json` 格式书写；这导致的一个问题就是，`json` 格式严格意义上是**不支持注释**的！为了解决这一问题，在使用这些内容时，最好在对应的命名空间内附上**注解文件**。当然，这不是必须的，但最好这么做。同时，也可以在此写下对该目录内容和功能的特殊注释。 + +原则上注解文件可以采用任何形式，但建议写到*命名空间目录下的 `README.md` 文件*中——打包的全局配置默认会排除这一文件。同样的，注解文件的形式也没有特殊限定，但尽量统一为佳。 + +一些注解文件的例子为[这个](projects/1.16/assets/minecraft/minecraft/README.md)、[这个](projects/1.18/assets/minecraft/minecraft/README.md)和[这个](projects/1.18/assets/macaws-furniture/mcwfurnitures/README.md)。 + +> 原则上，这些注解甚至可以自动生成。 + +## 快速参考 + +以下列出了一些与打包流程相关的常见文件配置。如果遇到以下情况，可以直接使用下面的方案。 + +### 版本增添 + +> 该项**需要**预先进行讨论，指定合适的版本支持计划！ + +- 制定版本支持计划。 + 这条一般是由管理层指定的。**有时**，支持计划会在 *Issues* 界面中展示——1.19 与 1.20 的支持计划即这么做了。 +- 判定是否需要工具链更新。 + - 无需更新： + - 创建 `config/packer/[version].json`，并按照本文的指导填写，或参照相近版本的配置文件。 + - 在 `.github/workflows/pr-packer.json` 与 `.github/workflows/packer.json` 中，一处形如 `version: [ "1.12.2", ... ]` 的列表中（如[此处](https://github.com/CFPAOrg/Minecraft-Mod-Language-Package/blob/c1d6b114fba63e86b5df682ec01fc30b818ee5e0/.github/workflows/packer.yml#L102)），加入需增添的版本。 + - 创建 `projects/[version]`，并按照其他版本的格式填写 `pack.png`，`pack.mcmeta`，`LICENSE`，`README.txt` 等内容。 + - 注意 `pack.mcmeta` 需要把花括号转义；可以参照其他版本的文件。 + - 注意 `.../minecraft/minecraft` 下的**字体修复文件**，需要按该版本的字体支持情况考虑填写。通常可以引用旧版本的资源，以减少重复工作。 + - 需要更新： + - 更新工具链。这可能需要很长的时间，取决于更新操作的复杂程度。例如，我们对 **1.20** 的支持稍晚，部分原因就是工作人员 ~我~ 全面更新了一次打包器。 + - 按照“无需更新”的内容执行。 + +### 复用语言文件 + +如果你在维护多版本的模组，有可能会遇到相近或相同的多份语言文件。此时，**复用**语言文件，可以减轻维护负担。 + +#### 完全复用 + +这适用于语言文件完全一致的情况，如不同平台的同一模组。 + +- 确定可用的文件来源。 +- 在目标模组的**命名空间**文件夹下，创建 `packer-policy.json`，填写如下内容，其中 `source` 字段按照前一步找到的来源填写。（[示例](projects/1.18-fabric/assets/iron-furnaces/ironfurnaces/packer-policy.json)） + +```json +[ + { + "type": "indirect", + "source": "projects/[version]/assets/[mod-identifier]/[namespace]" + } +] +``` + +- 尽管理论上不会加载，但仍应删除已有的 `lang/zh_cn.json`，以免误会。`lang/en_us.json` 无需移除。 +- （可选）创建**注解文件**。 + +#### 复用+修改 + +这适用于语言文件大部一致，小部有改动的情况。 + +- 确定可用的文件来源，以及需要做出的修改。多余的字段无需删去（也暂时无法删去；如有需要，会考虑增加此功能）；缺少或不同的字段则需要修改。 +- **方案一**：适用于有多个文件需要修改的情况。（[示例](projects/1.20/assets/minecraft/minecraft/packer-policy.json)） + - 在 `lang/zh_cn.json`（或其他需更改的文件）中，保留与来源文本不一致，需要修改的文本，其余内容删去。 + - 在目标模组的**命名空间**文件夹下，创建 `packer-policy.json`，填写如下内容，其中 `source` 字段按照前一步找到的来源填写。 + +```json +[ + { + "type": "direct" + }, + { + "type": "indirect", + "source": "projects/[version]/assets/[mod-identifier]/[namespace]" + } +] +``` + +- **方案二**：（[示例](projects/1.19/assets/isometric-renders/isometric-renders/packer-policy.json)） + - 以合适名称创造新文件（“修改文件”），仅包含与来源文本不一致，需要修改的文本，其余内容删去。 + - 在目标模组的**命名空间**文件夹下，创建 `packer-policy.json`，填写如下内容，其中两个 `source` 字段依次填写修改文件、来源命名空间的**完整地址**，`destination` 字段填写目标文件的**相对地址**。 + +```json +[ + { + "type": "singleton", + "source": "projects/[version]/assets/[mod-identifier]/[namespace]/[file-path]", + "relativePath": "[file-path]" + }, + { + "type": "indirect", + "source": "projects/[version]/assets/[mod-identifier]/[namespace]" + } +] +``` + +- （可选）创建**注解文件**。 + +#### 选取单文件 + +若来源有多个文件，但只需要其中某个文件，可以将上述方案中，`indirect` 策略替换为以下文本： + +```json +{ + "type": "singleton", + "source": "projects/[version]/assets/[mod-identifier]/[namespace]/[file-path]", + "relativePath": "[domain]/[file-path]" +} +``` + +其中 `source` 为**完整地址**，`relativePath` 为在最终资源包中，需要放置的**相对地址**。 + +### 添加无语言标识的文件 + +无其他配置时，打包器只会打包**含有简体中文语言标识**的文件，以及 **domain** 为 `font`、`textures` 的文件。如果需要添加不满足此要求的文件，需要适当修改配置文件。 + +#### 按domain集中添加文件 + +这适用于集中在一个或几个 **domain** 下的文件。 + +- 确定该模组需要加入的 **domain**。 +- 在目标模组的**命名空间**文件夹下，创建 `local-config.json`，填写如下内容：（[示例](projects/1.20/assets/applied-energistics-2/ae2/local-config.json)） + +```json +{ + "inclusionDomains": [], + "exclusionDomains": [], + "exclusionPaths": [], + "inclusionPaths": [], + "characterReplacement": {}, + "destinationReplacement": {} +} +``` + +- 在上述文件中，`inclusionDomains` 处，按照 `Json` 格式填写所需的 **domain**。 + +此外，若可以确定该**domain**在该版本普遍需要添加，可以转而在全局配置 `config/packer/[version].json` 中进行相应修改。 + +#### 添加零散文件 + +这适用于文件没有特殊集中位置的情况。 + +- 确定该模组需要加入的文件。 +- 在目标模组的**命名空间**文件夹下，创建 `local-config.json`，填写如下内容： + +```json +{ + "inclusionDomains": [], + "exclusionDomains": [], + "exclusionPaths": [], + "inclusionPaths": [], + "characterReplacement": {}, + "destinationReplacement": {} +} +``` + +- 在上述文件中，`inclusionPaths` 处，按照 `Json` 格式填写所需文件的**相对路径**。 + +通常不应将这种配置写入全局配置。 + +### 常用组合文件参数 + +原版 16 色 + +```json +{ + "black": "黑色", + "blue": "蓝色", + "brown": "棕色", + "cyan": "青色", + "gray": "灰色", + "green": "绿色", + "light_blue": "淡蓝色", + "light_gray": "淡灰色", + "lime": "黄绿色", + "magenta": "品红色", + "orange": "橙色", + "pink": "粉红色", + "purple": "紫色", + "red": "红色", + "white": "白色", + "yellow": "黄色" +} +``` + +机械动力岩石 + +```json +{ + "andesite": "安山岩", + "asurine": "皓蓝石", + "calcite": "方解石", + "crimsite": "绯红岩", + "deepslate": "深板岩", + "diorite": "闪长岩", + "dripstone": "滴水石", + "granite": "花岗岩", + "limestone": "石灰岩", + "ochrum": "赭金砂", + "scorchia": "焦黑熔渣", + "scoria": "熔渣", + "tuff": "凝灰岩", + "veridium": "辉绿岩" +} +``` From d991ce5cfeacd43f91af39ed00ea06b699028844 Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Mon, 28 Jul 2025 19:07:04 +0800 Subject: [PATCH 12/13] =?UTF-8?q?-=20docs=20-=20=E8=A7=84=E8=8C=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CONTRIBUTING.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ec52cf2e944e..4032c1b1922b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,7 +30,6 @@ Minecraft-Mod-Language-Package ├─.github --------------- // GitHub 相关配置文件 ├─config ---------------- // 配置文件 │ └─packer ------------- // 打包器配置文件 - ├─docs ------------------ // 各类文档 ├─projects -------------- // 翻译文件 │ └─(Minecraft 版本) --- // 不带 fabric 字样的是用于 Forge 和 NeoForge 模组的 │ └─assets @@ -84,7 +83,7 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 ### 总则 -- 翻译**必须**遵守 [Minecraft 模组简体中文翻译规范与指南](https://cfpa.site/TransRules/)。 +- 翻译**必须**遵守 [Minecraft 模组简体中文翻译指南](https://cfpa.site/TransRules/)。 - **拒绝**接收机器翻译（含生成式 AI）、生硬翻译（不符合中文表达习惯的）。 - 若直接提交此类翻译，该 PR 将被打上“生硬翻译”标签。 - 若提交者未及时进行有效修改，依照本仓库的[搁置规则](#搁置规则)处理。 From 8446dec63991814bbd65b6aca496a4ea19c21a69 Mon Sep 17 00:00:00 2001 From: SlimeSB <86453765+SlimeSB@users.noreply.github.com> Date: Thu, 27 Nov 2025 12:18:21 +0800 Subject: [PATCH 13/13] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4032c1b1922b..601e45219161 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -140,7 +140,7 @@ projects 文件夹下只标出模组所属的大版本号，其中的模组翻 - 至少一位管理员对 PR 给出批准（Approval）意见后，PR 才能合并。 - 管理员在给出批准意见后**应**给 PR 加上“即将合并”标签，此后需至少等待 24 小时，若等待期间没有新动态则可以合并 PR。 - “动态”包括但不限于 PR 作者提交（Commit）、审查人评论。 -- 管理员有判断和处置包含敏感内容 PR 的权力，处置包括但不限于：要求使用中立表述、删减、关闭 PR、限制提交。 +- 管理员有根据常识判断和处置包含不适宜内容 PR 的权力。处置措施包括但不限于：要求使用中立表述、删减、关闭 PR、限制用户提交。 #### PR 作者