我發現這是一個字符串的翻譯(msgid)爲空,所有的gettext工具都會認爲該字符串是未翻譯的。如何標記在po gettext文件中翻譯的空翻譯(msgstr)?
是否有解決方法?我希望有一個空字符串作爲這個項目的翻譯。
我發現這是一個字符串的翻譯(msgid)爲空,所有的gettext工具都會認爲該字符串是未翻譯的。如何標記在po gettext文件中翻譯的空翻譯(msgstr)?
是否有解決方法?我希望有一個空字符串作爲這個項目的翻譯。
我有很長一段時間的同樣的問題,我其實不認爲你可以。我最好的選擇是插入註釋,所以我可能標誌着從那裏它「翻譯」:
# No translation needed/Translated
msgid "This is a string"
msgstr ""
到目前爲止,它已經由最好的解決方法:/如果你最終找到一個辦法,請張貼!
由於這似乎是gettext規範中的一個大設計缺陷,我決定在這些字段中使用: Unicode Character 'ZERO WIDTH SPACE' (U+200B)
。
是的,gettext規範確實存在缺陷。很長時間以來,我一直在尋找這個特殊問題的答案。零寬度空間,這似乎是一個很好的解決方法,可能比評論(它並不能解決空字符串的問題)更好。謝謝你的提示 :) – Dyn
我意識到這是一個老問題,但我想指出的替代方法:
msgid "This is a string"
msgstr "\0"
由於gettext的使用嵌入的空值的信號串的末尾,並且適當地平移C轉義序列,我想這可能會工作,並導致空字符串翻譯?它似乎工作在我的程序(基於GNU libintl),但我不知道這是否實際上標準/系統允許。據我瞭解gettext的PO沒有被正式指定所以有可能會比看源代碼,其他沒有權威的答案...
https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html
這往往不是一個很好的事情做程序員將在東西嵌入的空值但它可能適用於你的情況?可以說它比零寬度空間技巧更沒有惡意,因爲它實際上會產生一個大小爲零的字符串。
編輯:
基本上所有能發生的最糟糕的事情是,你運行msgfmt
時,是否會感到困惑關於字符串的大小,它假設沒有得到段錯誤/不良行爲嵌入null,並在某處溢出緩衝區。
假設msgfmt
雖然可以容忍這一點,libintl
將不得不做正確的事情與它,因爲只有意味着它必須返回字符串是char *
,所以最終的應用程序只能看到到空字符不管什麼。
對於它的價值,我的寶解析庫spirit-po
明確支持這個:)
https://github.com/cbeck88/spirit-po
編輯:gettext的文檔,看來,他們提到了在嵌入的空值的可能性MO文件,並說: 「這是強烈爭議」:
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文件格式是一個好的開始。沒有什麼是具體的,格式可能稍後會演變得相當容易,所以我們應該對目前的方法感到滿意。
所以,至少它不會像他們會說「man,消息字符串中嵌入null」,我們從來沒有想到過!最有可能的是,如果msgfmt
不會崩潰,那麼我會認爲它是猶太教。
這似乎是Gettext文件格式中的一個大設計缺陷。 – sorin