i18n 多语言化插件测试发布

Cocos Creator 编辑器扩展:实现 Label 和 Sprite 组件的多语言国际化(i18n)。

注意,多语言国际化和本地化的区别是,国际化需要软件里包括多种语言的文本和图片数据,并根据用户所用设备的默认语言或菜单选择来进行实时切换。而本地化是在发布软件时针对某一特定语言的版本定制文本和图片内容。

本插件是多语言支持插件,因此不包括构建项目时去除一部分多语言数据的功能。

版本要求:Cocos Creator v1.3.2 以上

下载地址

使用说明


欢迎大家试用反馈

9赞

收藏了,感谢

如果说有语言的 spriteFrame 都加载进来就会占用过多的内存了

这个插件能不能整到1.4默认工具包中。多谢了

动态控制加载和编辑器里能随时切换预览的需求无法兼得

如果需要大量本地化的图片内容,建议用动态加载自己控制

动态加载的话,现有的文本本地化就可以做到,直接i18n.t取到resource内的地址,然后动态加载

以多年多语言项目经验, 强烈建议能够实现自动生成key文件(类似zh.js), 根据所有编辑器中label以及代码中调用i18n.t的text
翻译的源文字通过人工来保证绝对是不靠谱的, 而且效率低下
另外, 还有个关联功能, 实际上不同语言的label应该要支持不同的font字体才行, 不同的语言一般都不会使用同样的字体, 而且许多字体就只有某种语言特有.

能详细讲一下自动生成 key 如何工作的吗?

实际也不复杂,就是一个脚本能够自动搜索工程里所有相关的文件,
例如找到所有界面的label空间的string字段, 以及代码里用正则匹配搜索到出现的会成为源语言的字符串
将这些东西作为源语言生成key,生成一个包含所有语言字符串的文件
然后翻译人员直接参照这个文件就可以翻译并生成最后的使用的en.js这样的输出(实际过程可能会有转换到excel里和从excel导出成en.js的过程)
如果没有这些自动化的过程, 仅仅靠程序去维护原始的翻译列表,效率是低下并且质量很难保证的
一切自动化之后, 负责本地化的人员很容易就能知道哪些是新增语言, 哪些是删除修改的
不知道这样说, 你们能理解不

多语言最简单的是生成一个本地多语言的表,通过多国语言key来动态取出所有的字符串!这样可以保证质量

可以理解,谢谢!

@jare 目前发现这个插件使用的js文件会与项目脚本编译到一起, 建议是不是可以拆开,这样更新文字的时候不需要热更新项目脚本. 也就是不要把文字文件当脚本而是当资源来管理.

怎么我下载下来的运行不起!

cc-i18n已经解决你的问题,请加载使用 npm install cc-i18n -g