是否有解决此问题的方法?我确实希望将空字符串作为此项的翻译。
由于这似乎是gettext规范中的一个重大设计缺陷,因此我决定在这些字段内使用:Unicode字符“零宽空格”(U+200B)
。
我知道这是一个老问题,但我想指出另一种方法:
msgid "This is a string"
msgstr "\0"
https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html
通常在编程中,将嵌入式的空值放入内容中并不是一件好事,但在您的情况下可能会起作用?可以说,这比零宽度空格技巧更加友好,因为它实际上会导致字符串大小为零。编辑:
基本上,最糟糕的情况是在运行 msgfmt
时,如果它混淆了不带嵌入空值的字符串的大小,并在某个地方溢出缓冲区,则会导致段错误/错误行为。
假设 msgfmt
可以容忍这种情况,libintl
将不得不正确处理它,因为它返回字符串的唯一方式是 char *
,所以无论如何,最终应用程序只能看到空字符。
值得一提的是,我的 po-parser 库 spirit-po
明确支持此功能:)
https://github.com/cbeck88/spirit-po
https://www.gnu.org/software/gettext/manual/html_node/MO-Files.html
没有任何东西阻止 MO 文件在字符串中嵌入 NUL。然而,当前使用的程序界面已经假定字符串以 NUL 结尾,因此嵌入的 NUL 有点无用。但 MO 文件格式足够通用,因此如果我们想要在 MO 文件中实现宽字符,其中 NUL 字节可能会意外出现,那么稍后可能会出现其他接口。(不,我们不想在 MO 文件中使用宽字符。它们会使文件变得不必要地大,并且“wchar_t”类型是平台相关的,MO 文件也将成为平台相关的。)这个问题在 GNU gettext 开发论坛上已经进行了激烈的辩论,可以预见 MO 文件格式将随着时间的推移而发展或改变。甚至可能同时支持许多格式。但是,我们肯定要从某个地方开始,这里描述的 MO 文件格式是一个很好的开始。一切都没有确定下来,格式可能会相对容易地发展,因此我们应该对当前的方法感到舒适。
所以,至少不像他们会说“嵌入空消息字符串?我们从未想过!”最有可能的是它可以工作,如果msgfmt
不会崩溃,那么我会认为它是合法的。
我有同样的问题很长一段时间了,实际上我认为你根本无法解决它。我最好的选择是插入注释,这样我就可以从那里标记它为“已翻译”:
# No translation needed / Translated
msgid "This is a string"
msgstr ""
到目前为止,这是我最好的解决方法 :/ 如果你最终找到了一种方法,请发布!