Closed xinyihl closed 1 week ago
感觉使用模组来实现这个功能更合适,因为汉化资源包不就是汉化模组的吗,再加个模组也无妨
启动器做这个感觉不太行(
而且 CFPAOrg 的 i18nUpdataMod 不就是干这个的吗?
感觉使用模组来实现这个功能更合适,因为汉化资源包不就是汉化模组的吗,再加个模组也无妨
启动器做这个感觉不太行(
而且 CFPAOrg 的 i18nUpdataMod 不就是干这个的吗?
整合包汉化主要汉化任务以及整合包作者自定义的物品,流体,实体等等内容, 现在流行的汉化方式是替换文件,cfpa是针对的mod内容汉化
为什么要这么复杂……安装一个资源包修改 i18n value 就行了
感觉使用模组来实现这个功能更合适,因为汉化资源包不就是汉化模组的吗,再加个模组也无妨 启动器做这个感觉不太行( 而且 CFPAOrg 的 i18nUpdataMod 不就是干这个的吗?
整合包汉化主要汉化任务以及整合包作者自定义的物品,流体,实体等等内容, 现在流行的汉化方式是替换文件,cfpa是针对的mod内容汉化
流行的不是资源包汉化吗,CFPAorg 的 i18nupdatamod 也是资源包汉化啊
资源包可以修改那些非硬编码(应该吧,不知道怎么说)的文本。任务书等需要专门的模组再配合资源包汉化。
我认为启动器做不太行,做一个模组再汉化合适一点,不过感觉也还行(
加油
资源包并不能解决全部问题(现在的汉化包也不只有资源包啊),其次整合包没法识别唯一声名(代表着你怎么知道这是什么整合包,我们不可能去强迫所有整合包让他们按照我们的标准去声明自己的整合包吧),所以mod来搞基本是行不通的
感觉使用模组来实现这个功能更合适,因为汉化资源包不就是汉化模组的吗,再加个模组也无妨 启动器做这个感觉不太行( 而且 CFPAOrg 的 i18nUpdataMod 不就是干这个的吗?
整合包汉化主要汉化任务以及整合包作者自定义的物品,流体,实体等等内容, 现在流行的汉化方式是替换文件,cfpa是针对的mod内容汉化
流行的不是资源包汉化吗,CFPAorg 的 i18nupdatamod 也是资源包汉化啊
资源包可以修改那些非硬编码(应该吧,不知道怎么说)的文本。任务书等需要专门的模组再配合资源包汉化。
我认为启动器做不太行,做一个模组再汉化合适一点,不过感觉也还行(
加油
资源包不能修改和覆盖config文件夹的文件吧,而且如果ftbq使用了提取工具,支持了资源包里放lang文件汉化他们,但这也要使用提取工具。你可以看看宝藏猎人的汉化,汉化包里面一大部分在config里的json文件,资源包覆盖不了那些文件
该功能复杂,需要开发的过程繁多,而且可能包含安全性和合规性风险。 先不谈安全性和合规性风险。
就单独考虑开发过程,各个启动器使用各个平台/各个语言,对于这个功能开发很耗费心力。 而且收益对开发者来讲,是没有的。 而且,有很多开发者本来就忙于工作或其他项目开发,对于启动器本就采用仅维护态度。
要让他们为了一个可以被任意环节任意工具随意替代,还不会对启动器产生任何实质性好处的功能付下那么多的开发心力,那就太难为人了不是吗?
也有人提议 “汉化包推动者方开发一个公用 SDK,就可以免于启动器进行复杂的开发。” 且不谈接入 SDK,依旧需要启动器开发调整很多东西,就单独谈为什么启动器要内置这个 SDK。 启动器需要对用户安全负责,启动器开发者没有精力审查与评估你们的 SDK 是否有不安全代码,恶意行为。 当然,你可能说你不会干这些事,但这不影响我对你们的不信任。 你说你要让 Minecraft 汉化变得更方便,你有无数种方式,没有必要非要来绑架启动器开发者。
最后,我建议你们推出一个独立的应用程序,你们独立引导用户使用。 这最方便,也最舒服。 用户可以在你们的独立程序上通过你们的平台寻找用户需要的内容,并且你们也可以直接帮他安装好。 而不需要启动器做任何事。
该功能复杂,需要开发的过程繁多,而且可能包含安全性和合规性风险。 先不谈安全性和合规性风险。
就单独考虑开发过程,各个启动器使用各个平台/各个语言,对于这个功能开发很耗费心力。 而且收益对开发者来讲,是没有的。 而且,有很多开发者本来就忙于工作或其他项目开发,对于启动器本就采用仅维护态度。
要让他们为了一个可以被任意环节任意工具随意替代,还不会对启动器产生任何实质性好处的功能付下那么多的开发心力,那就太难为人了不是吗?
也有人提议 “汉化包推动者方开发一个公用 SDK,就可以免于启动器进行复杂的开发。” 且不谈接入 SDK,依旧需要启动器开发调整很多东西,就单独谈为什么启动器要内置这个 SDK。 启动器需要对用户安全负责,启动器开发者没有精力审查与评估你们的 SDK 是否有不安全代码,恶意行为。 当然,你可能说你不会干这些事,但这不影响我对你们的不信任。 你说你要让 Minecraft 汉化变得更方便,你有无数种方式,没有必要非要来绑架启动器开发者。
最后,我建议你们推出一个独立的应用程序,你们独立引导用户使用。 这最方便,也最舒服。 用户可以在你们的独立程序上通过你们的平台寻找用户需要的内容,并且你们也可以直接帮他安装好。 而不需要启动器做任何事。
我就提一个问题点,如果搞一个与启动器独立开的软件去安装汉化,首先就是软件不能确定用户要给什么整合包安装什么汉化,且一般启动器安装整合包后也没有留什么特征文件。按这样出的软件,操作流程 可能 就是要用户去搜索整合包名确定有没有汉化,然后下载汉化文件(一般是压缩文件,不会是什么安装包程序),然后通过给软件整合包根目录或手动覆盖来安装汉化,那这样和现在用户上网找汉化包再安装有什么差别呢?
从我个人角度讲,我有非公开的innosetup代码,专门为整合包汉化安装定制的,只需要用户学习如何提供整合包根目录,就可以安装汉化和下载其它所需的文件,但这只省去了汉化安装流程,用户仍需要上网找安装包汉化,然后下载安装汉化,这个和上文的SDK的效果差不多。所以说如果启动器方投入开发,就可以在用户安装整合包时就可快捷方便的知道有没有整合包汉化(接API接口),并选择要不要安装
所以说这个看启动器方,如果想要用户更舒服方便,就需要投入,如果考虑安全性和工程量,就不必投入,但大概是启动器作者的投入会出现费力不讨好的现象
话说这个项目有仓库和网站了吗
话说这个项目有仓库和网站了吗
网站在搞的样子,仓库还没有,他们先把网站搞清楚看看
检查项
您是什么类型的用户
第三方网站管理/负责人(MC相关的)
请简单的说一下您的想法
目前我们整合包汉化收集团队正在进行一个整合包的汉化包的收集网站项目, 该项目未来将提供相关 api 用于获取整合包是否拥有相应汉化包以及提供下载链接。 但当前汉化包的格式混乱难以实现汉化包的自动安装功能, 因此我们希望有一个汉化包的通用规范,用于方便各启动器实现对汉化包的自动安装, 该规范现在正在草案阶段仍需要更多意见对其进行完善。 在规范完善后各启动器也可以先开发本地文件安装汉化包的功能。
它能解决什么样的问题/带来什么样的帮助
解决汉化包安装问题,部分整合包玩家不会安装汉化包,以及寻找汉化包困难, 我们希望的是让安装与寻找汉化包变的和整合包一样简单方便。
期望的结果
实现自动化安装汉化包效果
是否有对这个方案的相关链接?
https://docs.qq.com/doc/DQmx3YlhLSHhxSmJP
附注
该汉化包收集项目由于成员大多为在校学生因此推行进度较为缓慢, 但对于汉化包规范的讨论以及汉化包安装功能则可以先行进行,因此在此单开一个讨论。