C++标准库不支持多语言翻译，std::locale仅处理格式化；实现UI多语言需用GNU gettext：标记字符串、提取.pot、翻译为.po、编译为.mo、运行时绑定路径并设置locale。
直接说结论：C++ 标准库本身不提供开箱即用的多语言翻译能力，std::locale 只能处理格式化（如数字、日期、货币），不能做界面字符串翻译；真要实现 UI 层多语言，得靠外部方案——最常用、最可控的是 GNU gettext + .po 文件，配合 C++ 封装调用。
为什么不能只靠 std::locale 做翻译
std::locale 的设计目标是本地化（localization），不是国际化（internationalization）中的“文本翻译”。它能帮你把 123456.78 格式化成 123.456,78（德语习惯），但没法把 "Save" 变成 "Speichern"。
- 所有
std::locale相关 facet（如std::numpunct、std::time_put）都不接受自定义字符串映射表 - 没有标准接口加载/切换语言包，也没有
gettext那样的上下文（msgctxt）、复数形式（ngettext）支持 - 跨平台时，Windows 的
std::locale("")行为与 Linux 差异大，容易在 CI 上出错
用 gettext 实现 C++ 多语言的实际步骤
核心是把 C++ 字符串标记为可翻译，并由 gettext 运行时按当前 locale 查表。关键不在 C++ 语法，而在构建流程和运行时环境。
- 源码中用宏包裹待翻译字符串，例如：
_("<code>File not found")（注意下划线函数名） - 用
xgettext --c++ -o messages.pot *.cpp提取所有_()调用，生成模板文件 - 为每种语言复制
messages.pot→de.po、zh_CN.po，用 Poedit 或命令行编辑翻译 - 编译
.po为二进制.mo：执行msgfmt de.po -o locale/de/LC_MESSAGES/app.mo - 程序启动时调用
setlocale(LC_ALL, "")和bindtextdomain("app", "locale")，再textdomain("app")
⚠️ 容易漏掉的点：bindtextdomain 的路径必须是绝对路径或相对于可执行文件的相对路径；Linux 下默认找 LC_MESSAGES 子目录，Windows 需手动设 setenv("LANG", "de_DE", 1) 才生效。
立即学习“C++免费学习笔记（深入）”；
C++ 封装 gettext 的常见坑
直接裸调 gettext() 返回 const char*，在 UTF-8 环境下没问题，但遇到宽字符或 Qt/GUI 框架时容易乱码或内存生命周期问题。
- 不要返回
gettext("xxx")的指针给std::wstring——gettext不管理宽字符，且返回内存可能被下次调用覆盖 - 推荐封装一层：用
std::string包装gettext()结果，或用std::u8string（C++20）确保 UTF-8 语义 - 如果用
boost::locale，它底层也调gettext，但自动处理了编码转换和缓存；不过它不默认启用gettext后端，需链接-lboost_locale并显式调用boost::locale::generator::add_messages_path() - 避免在全局变量或静态初始化中调用
gettext—— 此时 locale 尚未设置，返回原字符串，且无法重载
真正麻烦的从来不是“怎么写翻译函数”，而是构建时提取、测试时验证各语言 .mo 是否加载成功、以及 Windows 上 locale 名称（German_Germany.1252）和 GNU 约定（de_DE）之间的映射。建议在 main() 开头加一行日志输出 setlocale(LC_MESSAGES, NULL) 的返回值，确认环境已就位。
