如何本地化 CPAN 模块和依赖项

Question

在阅读"On the state of I18N in perl" 后，我正在尝试使用Locale::TextDomain 本地化CPAN 模块MooX::Options。

在拉取请求的讨论中，问题出现了如何处理不是源自模块本身，而是源自依赖项的消息。在这种特定情况下，当您在命令行上指定未在代码中任何位置定义的选项时，您将收到警告：

未知选项：xyz

源自模块Getopt::Long，其本身尚未本地化。

问题是如何处理这些问题。我基本上看到了三种策略：

1. 忽略它们，我觉得不满意。
2. 尝试以某种方式捕获我当前正在本地化的模块（在本例中为 MooX::Options）中的所有极端情况和消息，并通过这种方式解决依赖项中缺少的本地化模块。这个选项似乎很脆弱，因为我必须不断适应基本模块的变化。有时，几乎不可能捕获消息，因为它们是由模块直接写入输出流的（本例中就是这种情况）。
3. 尝试本地化依赖模块本身。这个选项似乎很难实现，因为不同的项目本身可能使用不同的 I18N 工具和策略，并且依赖关系图可能很大。

总而言之，我认为这个问题更普遍，而不是特定于 perl 和 cpan 模块。所以，我对你的想法、策略和方法很感兴趣。

Answer 1

我比较 strong opionions 对翻译计算术语的想法，大多数人不同意我的观点，所以请接受我所说的一粒盐。

我不明白国际化库以解析命令行选项的意义，除非您想进一步了解 ghettoize 已经是该库的一小部分用户。

如果将wget 称为wal 或wgetir，它会不会对土耳其用户更有用？或者，土耳其用户应该写getir --ayna，而不是wget --mirror？那w呢？

如果您只是翻译这些消息，那么当土耳其语对应的是 wget -y 时，输出帮助消息以响应 wget -h 的意义何在？

事实上，我看到的几乎所有翻译编程相关术语的尝试都是simply awful。最渴望翻译的人通常不会掌握任何一种人类语言——他们似乎也不明白自己在翻译什么。

但是，由于这些热心的人，我发现至少我接触的几乎所有软件的土耳其语翻译都很糟糕。无论我看到什么丹麦语翻译都好不了多少，但至少，由于丹麦语和英语之间的结构更相似，它们是可以容忍的。

我认为每个人的精力最好花在实际确保他们的程序处理内容，包括外部资源/参考的名称，用不同的语言，而不是给我某些科学怪人语言中的错误消息，或者让我指定其助记符与其描述不匹配的命令行选项等，或者显示包含实际上不传达任何含义的字符串的菜单。

在过去的几十年里，我一直有这种感觉……甚至当我用十六进制编辑器修补 IBM PC 键盘驱动程序时，不同地方的人都可以在 WordStar 中键入报告，并在Harvard Graphics 中创建图表。

所以，我不受欢迎的建议是将你的精力放在其他地方......

例如，使用异常对象，以便库的用户（可能是程序员，并且比“Kütük bulunamadı”更容易理解“找不到目录”）可以以独立于人类语言的方式推断发生了什么，以及向用户显示什么信息。我没有仔细查看MooX::Options，但我注意到至少有一个字符串croak。

这是actual error message from an IBM product：

Belirtilen kütük örüntüsüyle eşleşen hiçbir kütük bulunamadı

你可以问地球上近 2 亿突厥人中的每一个人什么是“kütük örüntüsü”，只有真正想出这个无意义的字符串的人才能告诉你它对应到“文件模式”。那么，使用“kütük örüntüsü”与“文件模式”相比，他们能得到什么？什么都没有。

但是，他们失去了与英语世界中的程序员交流并与之竞争的能力。

PS：对所有土耳其语示例表示歉意，但我觉得最舒服的是根据我的母语绘制可恶的示例。