为什么语言环境 es_MX 有效但 es 无效？
GNU gettext 的维基百科条目 显示了一个示例，其中区域设置只是语言，“fr ”。 而i18n gettext()“hello world”示例 具有包含语言和国家/地区的区域设置值“es_MX”。 我已修改“es_MX”示例以仅使用语言“es”，但它会生成英语文本而不是预期的西班牙语。
cat >hellogt.cxx <<EOF
// hellogt.cxx
#include <libintl.h>
#include <locale.h>
#include <iostream>
int main (){
setlocale(LC_ALL, "");
bindtextdomain("hellogt", ".");
textdomain( "hellogt");
std::cout << gettext("hello, world!") << std::endl;
}
EOF
g++ -o hellogt hellogt.cxx
xgettext --package-name hellogt --package-version 1.2 --default-domain hellogt --output hellogt.pot hellogt.cxx
msginit --no-translator --locale es --output-file hellogt_spanish.po --input hellogt.pot
sed --in-place hellogt_spanish.po --expression='/"hello, world!"/,/#: / s/""/"hola mundo"/'
mkdir --parents ./es.utf8/LC_MESSAGES
msgfmt --check --verbose --output-file ./es.utf8/LC_MESSAGES/hellogt.mo hellogt_spanish.po
LANG=es.utf8 ./hellogt
环境变量LANGUAGE，其中 仅由 GNU gettext 使用...如果 已定义，LANGUAGE 优先 通过 LC_ALL、LC_MESSAGES 和 LANG。
LANGUAGE=es.utf8 ./hellogt
生成预期的西班牙语文本而不是英语。
但这并不能解释为什么“LANG=es”不起作用。
Wikipedia entry for GNU gettext shows an example where the locale is just the lanuage, "fr". Whereas the i18n gettext() “hello world” example has the locale value with both the language and country, "es_MX". I have modified the "es_MX" example to use just the lanuage, "es", but it produces the English text rather the expected Spanish.
cat >hellogt.cxx <<EOF
// hellogt.cxx
#include <libintl.h>
#include <locale.h>
#include <iostream>
int main (){
setlocale(LC_ALL, "");
bindtextdomain("hellogt", ".");
textdomain( "hellogt");
std::cout << gettext("hello, world!") << std::endl;
}
EOF
g++ -o hellogt hellogt.cxx
xgettext --package-name hellogt --package-version 1.2 --default-domain hellogt --output hellogt.pot hellogt.cxx
msginit --no-translator --locale es --output-file hellogt_spanish.po --input hellogt.pot
sed --in-place hellogt_spanish.po --expression='/"hello, world!"/,/#: / s/""/"hola mundo"/'
mkdir --parents ./es.utf8/LC_MESSAGES
msgfmt --check --verbose --output-file ./es.utf8/LC_MESSAGES/hellogt.mo hellogt_spanish.po
LANG=es.utf8 ./hellogt
According to Controlling your locale with environment variables:
environment variable, LANGUAGE, which
is used only by GNU gettext ... If
defined, LANGUAGE takes precedence
over LC_ALL, LC_MESSAGES, and LANG.
LANGUAGE=es.utf8 ./hellogt
produces the expected Spanish text rather than English.
But this does not explain why "LANG=es" does not work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯...听起来像是平台问题。 我在 Mac OSX 下做了同样的事情并得到了预期的结果。 我怀疑您的 linux 版本不喜欢
LANG=es.utf8。 检查有关setlocale(3)或xlocale(3)等内容的本地系统文档（如果后者受支持）。IIRC，仅包含主要标识符（ISO-639 语言代码）的区域设置标识符附加了主要语言国家/地区的 ISO-3166 国家/地区代码。 然后通过在
/usr/share/locale中查找来执行结果区域设置查找。 我查看了 MacBook 上的语言环境目录，发现有一个名为es和es_ES的目录。 这可能是一个简单的系统配置问题。如果您是，我强烈建议您使用 ICU 而不是 gettext 和标准库提供的语言环境内容开发商业应用程序。 Gettext 可用于简单的消息查找，但它几乎无法提供真正完成完全国际化的应用程序所需的功能。
Hmmm... it sounds like a platform problem. I did precisely the same thing under Mac OSX and got the expected results. I suspect that your version of linux doesn't like
LANG=es.utf8. Check your local system documentation surrounding things likesetlocale(3)orxlocale(3)if the latter is even supported.IIRC, locale identifiers containing only a primary identifier which was an ISO-639 language code had the ISO-3166 country code of the primary speaking country appended to them. Then the resulting locale lookup was performed by looking in
/usr/share/locale. I looked in the locale directory on my MacBook and there is a directory namedesas well ases_ES. It may be a simple system configuration issue.I would highly recommend using ICU instead of gettext and the locale stuff offered by the Standard Library if you are developing a commercial application. Gettext will work for simple message lookup but it doesn't offer nearly what you need to really do a fully internationalized application.