有没有发现新wget 会提示讨厌的"英国中部时间"??

yafeng

命令英文，帮助等中文很好啊，楼上偏激了，你喜欢纯英文终端自己设LOCALE去，我想大部分XD还是喜欢中文帮助中文MAN的，看看MS的CMD，汉化的多好。现在KMS成主流了，打个豹哥的UTF8补丁，纯CONSOLE下也能完美显示中文。即使不打，也可以CONSOLE下用英文LOCALE，XTERM下用中文LOCALE嘛

poet

Post by yafeng;2040773
命令英文，帮助等中文很好啊，楼上偏激了，你喜欢纯英文终端自己设LOCALE去，我想大部分XD还是喜欢中文帮助中文MAN的，看看MS的CMD，汉化的多好。现在KMS成主流了，打个豹哥的UTF8补丁，纯CONSOLE下也能完美显示中文。即使不打，也可以CONSOLE下用英文LOCALE，XTERM下用中文LOCALE嘛

英文终端并不需要设置LOCALE，设LANG就可以了。至于中文man，我只在redhat系里面见过，其它的大多数发行版不论你怎么设都是英文man。

CLI不应当翻译，还有一个非常重要的原因，它来源于Unix本原特征：所有命令的输出不但是给人类看的，还是给程序看的。让你的程序去解析完全不同的输出会成为极端头痛的事情，天知道你准备解析的另外一个程序的输出在下一个版本又会被翻译成什么！而统一语言的输出就相对稳定得多。比较经典的例子是gcc输出，gcc输出中可以分错误和警告（Error和Warning字样），有的编辑器可以正常识别gcc输出的错误定位并且区分错误和警告。但当错误与警告的文本被翻译时，就只能检测到阿拉伯数字行号，而不能识别错误和警告的区别。因为编辑器不是gcc，也不是跟gcc一起编译的，它不会知道gcc在某个语言版本中的输出被翻译成了什么文本。不可能去取gcc的po，所以不可能根据语言环境去改变自己要解析的内容。


不过，不论怎么说，这种明显的错误翻译出现在发行版中，又算是什么原因呢？——注意首贴中这个错误并不是“该不该翻译”的问题，而是翻译者完全错误的解析了这个缩写词的意思。

luyaotang

Post by 沙漠之子;2033444
附件解压缩 安装到/usr/share/locale/zh_CN/LC_MESSAGES/wget.mo

Thanks..

ashunter

rm /usr/share/locale/zh_CN/LC_MESSAGES/wget.mo
更彻底...

yqh1203

没人提交bug吗？
还有一个bug，就是makepkg --help的中文输出信息有错误。就是参数 --skipinteg 翻译错误

athurg

@poet
真是无语了。
本来这种争论是没必要参与，但是话说到这份上，就不得不说一说了。
首先，按照你的感觉，国家语言文字工作委员会应该立即停止工作，什么保护少数民族语言文化的工作就是扯淡。全世界应当立即实行全英文教育，法律规定，人一生下来就必须接受英文环境及其教育是人的基本人权……

你的理解我真觉得蹊跷，如果你不知道如何在CLI中看到非英文字母、如果你不知道man是如何用中文说话的，那是可以理解的，因为不知道这些的人很多，原因也很多。可是不能因为你不知道，就说明这个不可能或者不应该。

话说回来，敢问，有多少程序准备识别其他程序的输出作为参数处理的？别告诉我说是Google，Google上你搜不到“错我……”只找到“ERROR……”不证明Google不能搜索中文，只代表这世界上用中文报错的报告公开不多。也别告诉我说什么cat some_program | other_program，那个不是识别、不是参数，而是转移、是数据！

我就不明白了，人家从PHP编译器到GNU，很多类型很多程序作者都在拼命的考虑如何能支持多国语言，人家都这样了，到底是哪党哪国的政治教育，把您教育成了这样。

contrl

很多发行版都有，至今还没解决……。无语啊。

张长弓

不管怎样，先谢谢再说

poet

Post by athurg;2049229

话说回来，敢问，有多少程序准备识别其他程序的输出作为参数处理的？
我就不明白了，人家从PHP编译器到GNU，很多类型很多程序作者都在拼命的考虑如何能支持多国语言，人家都这样了，到底是哪党哪国的政治教育，把您教育成了这样。

简单的一个问题非要提到政治高度，有必要么？一个技术上清晰的论点论据，不会需要拿政治当挡箭牌。

支持多国语言跟翻译界面输出是两回事。一个即时通讯软件，能调出输入法，支持中文输入，能显示中文，能传中文文件名的文件，这就是支持中文。一个MP3播放器，能识别ID3TAG中的中文编码，就是支持中文的最重要部分。一个更加复杂的软件，至少保证热键不跟中文输入法冲突，不吃掉Ctrl-空格，这也很重要。——这些，都是“拼命考虑如何支持多国语言”需要做的事情，而翻译界面，在这个环节上，我不说它是重要还是次要，至少，不应当把软件输出搞出问题吧？

一个 CLI 程序可以根据 LANG 或者 LANGUAGE 环境变量来判断自己的输出语言，而自己的不同语言的字符串是用 .po 那些文件编译到自身的。例如，如果 gcc 输出需要输出 Error 为 错误，那么只有 gcc 自己知道，中文的时候输出错误，英文输出 Error，别的程序是不知道你 gcc 的一个特定字符串在某个特定语言中被翻译成什么的。

现在换到 vim ，我们使用 quickfix 模式编译，gcc 的输出是可以进入 vim 的 quickfix 列表。OK，你现在来看，假如 gcc 真的翻译了输出的错误信息标识，那么 vim 如何把错误和警告区别开？——首先，一个子shell进程可以以任何一个环境启动，甚至可能使用了缺省的 LOCALE=C，所以我们无法判断子进程gcc的 locale，其次，即使我们清楚的知道子进程gcc使用的是跟我们完全相同的 locale，由于 gcc 相关的 po 并没有编译到 vim 中，vim 也绝无可能知道 gcc 的某个版本翻译特定字符串是什么。

所以，现状就是：如果翻译了输出，就可能无法识别警告和错误的区别。——因为你在编译 gnu gettext 相关信息的时候根本不会知道可能有哪些程序去阅读它。不可能把相关的信息编译到所有可能阅读你程序输出的程序中去。

奉劝各位一句：即使你每天把gnu/linux的全部源代码编译一遍，也还不如写一个内核模块／写一个应用程序对Linux的体会来得深。

没本

支持提示信息的本地化工作。poet你是典型的程序员思维模式，总想怎么方便你的程序。不过程序是给人使用的，wget这类程序的提示信息本地化我认为没什么不对。就算gcc的编译信息，不也有本地化的么，程序要处理错误，读行首的错误代号就行了，后面的错误信息是哪国语言，都是给程序员看的而不是程序。命令行和man手册的本地化是大势所趋。