V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  eyelly  ›  全部回复第 1 页 / 共 3 页
回复总数  45
1  2  3  
11 天前
回复了 yuuko 创建的主题 macOS M2 Pro 系统 14.4 鼠标偶尔会变慢
不知道是不是跟你的情况一样,我的鼠标是会休眠个几秒钟,这几秒中内鼠标会卡住不动,过会儿才好。我一开始以为是鼠标坏了,后面键盘也是这样的。鼠标和键盘都是外置蓝牙链接的,卡住的时候操作触控板和本身的键盘都是 OK 的,所以我怀疑是蓝牙有问题。我的系统也是 14.4.1 的,M1 芯片
225 天前
回复了 EatMi 创建的主题 程序员 大家项目的 README 习惯放中文还是英文?
个人看法也是看当前库的受众,如果仅限国内用户,只需中文文档即可;否则的话,默认语言应该还是以国际通用语言英语为主,然后可以加上中文文档链接。



哈哈哈,打个广告,后续皆为广告😊

之前我也为如何同时维护多个语言的 README 文档而发愁,因为文档的内容或者结构发生变化,然后又需要调整多个语言的文档还是挺繁琐的。然后采用了一个策略,将 Markdown 文件当做是产出的资源,通过 js 代码来动态生成,这样不同语言就可以抽取出独立的语言包,整个文档结构是在代码中固定的,后续调整只改 js 代码的结构而不用每个语言都改,这样就看似很像日常前端开发中给前端页面添加多语言功能。

然后,上述的这套逻辑,已装了一个工具 https://github.com/eyelly-wu/jsx-to-md ,它可以像平常写 React 一样来编写 Markdown ,举个例子

// 这里文案的内容通过 t 函数标记了,是需要多语言处理的内容
export function Temp(){
return (
<>
t('这是一段中文描述,这是后续的描述内容')
</>
)
}

然后再配上另一个国际化的工具 https://github.com/i18n-pro/core ,它可以识别出需要翻译的内容(例如上述代码示例中的“这是一段中文描述,这是后续的描述内容”),并调用第三方翻译平台的接口(例如 谷歌和 OpenAI 等,还不止这些)对内容进行翻译并生成生成各自语言的语言包(当然翻译的内容效果不保证一定很理想,但是调整语言包也很方便)

有了语言包,以及固定的文档结构,就能生成不同语言但结构相同的 Markdown 文档了。后续无论是文档内容的变化或者是新增语言的支持,都将变更轻松很多。


最后,上面提到的两个工具的中英文文档都是这样生成的,热烈欢迎各位开发者朋友的尝试😊
怒之铁拳 4 ( Streets of Rage 4 ),生存模式,随开随玩
296 天前
回复了 magic3584 创建的主题 游戏 求推荐手机上的游戏
@ewiglicht +1 ,国内版本是叫《原界之罪》
@Ansen 我的通知也关的差不多了,好多应用的推送都很烦人,例如美团啊,滴滴啊,简直服了
@kid1412621 大佬说话就是硬气,我是本着能省则省的原则
@omerg 哈哈哈,立马切换成了辅助模式(长辈版),清爽多了
@xRayyyy 是可以用啊,就是没有折扣呢,就等着天府通在 ApplePay 上推出 [天府通] 卡,但凡其他城市推出了卡,天府通都会被拉出来挨骂
@Ansen 这个也不错,不过云闪付的消息推送比天府通还可怕
@xwayway callkit 这个我是一只都没有,表示项目啊;不过成都地铁好像只能用来坐地铁,不能坐公交,把通知权限关了,也还可以将就用
@lvcnsc 哈哈哈,还挺会安慰自己。最后彻底支持 ApplePay 才顺我心啊
哈哈哈,感觉我就是需要这样的工具,试用了下,感觉挺不错的
@K120 如果觉得翻译不到位话,还是可以人工在调整语言包的啊(源语言与目标语言是一对一的,很方便调整),就像你程序代码写好了,就不管改 bug 了吗?
@lvcnsc 的确是可以通过 ApplePay 来刷其他城市的卡,但是没有 9 折的折扣,这对于日常坐地铁的人来说,没有折扣是很大一笔损失。表示对哥们的早于表示同情,要是推出成都的 ApplePay 公交卡估计就遇不到这样的问题了,那你是后续通过扫二维码,还是实体卡呢?
@awesomes 谢谢,希望可以真正帮助到广大开发者朋友们

我们的愿景是:为了让接入国际化成为轻松且愉快的事😄💪🏻
@lisxour #5
感谢大佬耐心且详细的回复

针对上述的的问题:
3.1 如果语言包中已经存在该文案的翻译,就不会再次翻译该文案了,只要文案本身不变,就不用担心翻译好的内容(不管是机翻的,还是人工手动的)丢失

3.2 如果文案发生了变化
例如:`欢迎` -> `你好,欢迎!`,那么以前针对 `欢迎` 翻译内容是会被移除掉,又会基于 `你好,欢迎!` 重新翻译。

因为 文案即 key ,代码中改了文案,语言包中的文案也会被同步改掉,当然人工手动翻译的是会丢失。虽然可以做到在语言包中保留不再使用的文案,但是这样没有意义。

针对上述场景可以有这样的解决方案:

例如:针对 `欢迎` 文案,对于机翻的 `Welcome` 不满意,然后人工维护成了 `Welcomeeeee`,但是后续文案显示上要变成 `你好,欢迎!`

如果要保留人工维护的翻译内容,新的文案写法这样调整可以满足需求:
以前:t('欢迎')
现在:t('你好,{0}!', t('欢迎'))

相当于某些文案已经有固定的翻译内容了,可以理解为抽成一个变量,在文案中基于`变量插值`的特性与其他文案进行组合来生成新的文案
@lisxour #2 比较好奇是什么样的维护问题?可以展开说说吗
@lisxour 对于第二点表示认同,机器翻译肯定不能做到 100%满意的,但是对于绝大部分(不是所有哟)开发人员的话,外语水平可能都不太好,但这样至少可以应对,如果翻译不佳,后期在语言包中调整也不是什么大问题

基于第一点的文案生成的语言包是这样的
{
"你好,${0},欢迎登陆后台": "假如这里是翻译后的内容"
}
如果文案调整了第 3 点的,会重新生成下面的语音包:
{
"你好,${0},欢迎使用后台": "这里会是新翻译的内容"
}
哈哈哈,希望你能实现自由
@eyelly 倒是不着急,你慢慢来
1  2  3  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3760 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 00:15 · PVG 08:15 · LAX 17:15 · JFK 20:15
Developed with CodeLauncher
♥ Do have faith in what you're doing.