使用或不使用PHP的本地gettext與自建的原因是什麼？

爲了讓我的應用程序使用多種語言，我想知道GNU的gettext是否有很大的優勢，或者是否有構建自己的「庫」的大缺點。使用或不使用PHP的本地gettext與自建的原因是什麼？

此外，如果「建立自己的」更建議，什麼是最好的做法是什麼？顯然他們必須存儲在數據庫中，我懷疑我想用平面文件工作，所以在某些時候我最好緩存它們，我應該如何處理這個問題？

來源

2011-03-25 Gerben Jacobs

你說緩存他們，其中..平面文件也許。 – RobertPitt 2011-03-25 16:06:20

哈哈，觸摸。但我的意思是讓我的目錄在平面文件中。 – 2011-03-25 16:17:42

gettext擴展有一些怪癖。

它將翻譯字符串保留在內存中，因此在更新目錄時可能需要重新啓動（在mod_php運行時下）。
gettext API並非真正爲web應用程序設計。（它會查找環境變量和系統設置，您必須輸入Accept-Language標題。）
許多人遇到問題時都會遇到問題。
另一方面，gettext有更多的工具支持。

你幾乎總是有一個handicrafted解決方案少一些麻煩。但是，據說gettext API在簡潔性上是無與倫比的。 _("orig text")或多或少是翻譯文本的最佳接口。

如果你想自己的東西代碼了，我建議你專注於這一點。

使用簡單的函數名稱。代替_()幾個php應用程序使用雙下劃線__()。不要採用任何使實際使用翻譯後的字符串變得麻煩的庫。（例如，如果使用Zend Framework，請始終編寫包裝函數。）
接受原始英文文本作爲輸入。避免記憶翻譯鍵（例如BTN_SUBMT）
不要在任何情況下使用轉換目錄數據庫。這些文本是運行時數據，而不是應用程序數據。（對於一個壞榜樣看到自從。）

你可以經常逃脫PHP腳本數組包含lang/nl.php不過$text["orig english"] = "dutch here";，這很容易從你使用任何接入方式利用。

也避免將所有內容都按到系統中。有時採用第二種更長的文本機制是不可避免的。例如，我使用template/mail.EN.txt更大的斑點。

來源

2011-03-25 16:09:41 mario

我同意。另一方面，gettext幾乎是關於從中受益的工具的'事實上'的標準：當管理翻譯時，PO編輯器，xgettext和msgmerge確實是非常方便的工具。 – Artefact2 2011-03-25 16:19:36

感謝您的精心解答，但有一個問題。爲什麼像「BTN_SUBMIT」這樣的索引是錯的？ – 2011-03-25 16:20:26

@Gerben Jacobs：他們本身沒有錯。但回過頭來看，我希望我避開了這個計劃。這是一種非常典型的PHP方法，用於定義（「TEXT_BTN_NAME」，「按鈕名稱」）。但是這使得後來轉換到其他系統變得更加困難，並且最終導致源代碼的可讀性降低。使用縮寫通常基於您想要隨時更改文本內容的錯誤假設。實際情況並非如此。編寫你的應用，並在最後翻譯它。一次完成而不是逐步完成這一切更簡單。但除此之外，ABBRV並沒有真正的技術問題。 – mario 2011-03-25 16:44:04

的Gettext是not thread-safe。

在決定實施自己的，我建議你看一看Zend_Translate。它支持gettext適配器，以及TMX，CSV，INI，Array和更多格式。如果您的首選格式不受支持，例如數據庫存儲，那麼編寫自己的適配器也應該很容易。

來源

2011-03-25 16:03:32 Htbaa

僅供參考：因爲環境變量不是線程安全的，所以'setlocale'因此'gettext'不是線程安全的。聽起來像是添加新代理環境API的好主意。 – 2011-05-06 16:16:02

gettext不是線程安全的，但在很多情況下並不重要：http://stackoverflow.com/questions/1646249/php-gettext-problems-like-non-thread-safe/6726570#6726570。 Zend-translate很不錯，但比PHP的內置模塊要胖得多。 – Stann 2011-07-17 20:45:35

使用或不使用PHP的本地gettext與自建的原因是什麼？

回答

相關問題