空の翻訳（msgstr）をpo gettextファイルに翻訳してマークする方法はありますか？

Question

文字列の翻訳（msgid）が空であることがわかりました。すべてのgettextツールは文字列を翻訳されていないものとみなします。

回避策はありますか？私はこの項目の翻訳として空の文字列を持っています。

Answer 1

私は長い間同じ問題を抱えていましたが、私は実際にあなたができるとは思っていません。

# No translation needed/Translated 
msgid "This is a string" 
msgstr "" 

これまでのところ、それが最善の回避策によりをされている：私の最高のオプションは、私はそれをマークすることができ、そこから「翻訳」のコメントを挿入することでしたあなたは方法を見つけることに終わるならば/を投稿してください！

Answer 2

これはgettext仕様の大きな設計上の欠陥と思われるため、これらのフィールドの内側に Unicode Character 'ZERO WIDTH SPACE' (U+200B)を使用することにしました。

Answer 3

が、私はこれが古い質問です実現が、私は別のアプローチを指摘したかった：

msgid "This is a string" 
msgstr "\0" 

gettextのは、文字列の終わりを知らせるために埋め込まれたヌルを使用し、それが適切にCのエスケープシーケンスを変換しているので、私はこれがうまくいくと思って、空の文字列翻訳になるでしょうか？ GNU libintlに基づいて私のプログラムで動作するようにはがと思われましたが、これが実際にシステムによって標準/許可されているかどうかはわかりません。私は

https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html

...ソースコードを見ている以外には公式の答えがないことがあるので、gettextのPOが正式に指定されていない理解として、それは多くの場合、物事に埋め込まれたヌルを置くために、プログラマに行うにはいいことではありませんあなたのケースではうまくいくかもしれませんか？間違いなく、ゼロ幅スペースのトリックよりも悪いことはありません。サイズがゼロの文字列が実際に生成されるからです。

---

編集：それはそれは持っていないと仮定した文字列のサイズについて混乱になるだろう場合は、msgfmtを実行するときには、セグメンテーション違反/悪い行動を得る

基本的に、起こることができる最悪のことがあります埋め込まれたヌル、およびどこかのバッファオーバーフロー。

libintlが唯一それがchar *ある文字列を返すために有することを意味するので、最終的なアプリケーションだけに関係なく、null文字まで見ることができないので、それで正しいことをしなければならないとしている、msgfmtはしかし、これを許容できると仮定すると、何。何が価値があるために

、私のPO-パーサライブラリ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ファイルフォーマットは一般的なので、後で他のインタフェースが可能になります。たとえば、NULバイトが誤って表示される可能性のあるMOファイルでワイド文字を実装したい場合などです。 （いいえ、私たちはMOファイルにワイド文字を入れたくないので、ファイルが不必要に大きくなり、 'wchar_t'タイプがプラットフォームに依存するため、MOファイルもプラットフォームに依存します）

この特定の問題はGNU gettext開発フォーラムで強く議論されており、MOファイルフォーマットは時間の経過とともに進化または変化することが期待されています。後で多くの形式を同時にサポートすることも可能です。しかし確かに、私たちはどこかから始めなければなりません。ここで説明したMOファイル形式は良いスタートです。何も具体的にキャストされていないので、後でフォーマットがかなり容易に進化する可能性があるので、現行のアプローチに慣れていなければなりません。

だから、少なくとも「メッセージ文字列に埋め込まれたnull」と言うつもりはありません。おそらくそれは動作します。もしmsgfmtがクラッシュしなければ、私はそれが正気であると思います。