內容簡介
nLingual 系統允許 WordPress 靈活的多語言支援和翻譯管理。該系統以每篇文章為基礎處理翻譯，並可以設置為同步，以便在一個文章上的某些細節發生更改時將其複製到其他文章中。它提供您對可以翻譯的內容和方式的控制，還提供了許多可供第三方主題和外掛使用的實用工具。
nLingual 2 提供了更強大的翻譯管理控制、更好的可擴展性和修復了許多以前版本的核心問題。
幾乎可以翻譯任何內容
在設置時，您可以控制哪些內容支援翻譯。任何 UI 啟用的文章類型或分類法都可以啟用，以及任何注冊的導航選單或側邊欄位置。此外，nLingual 包括一個 LocalizeThis API，可在幾乎任何管理中找到的文本字段上啟用，允許任何選項或元字段支援每種語言的單獨值。
簡單的翻譯創建和管理
在文章編輯器屏幕或文章管理屏幕上通過快速編輯來將語言和翻譯分配給文章，也可以通過快速編輯將語言設定為多個文章。您還可以輕鬆地即時創建現有文章的新翻譯；選擇“新[語言][文章類型]”，如果需要，提供翻譯標題，並創建一篇新的草稿文章，它是原始文章的完全複製品，準備進行翻譯。
翻譯作為獨立文章儲存，通過自定義表格與其對應的文章相關聯。這允許您翻譯與文章相關聯的自定義字段和其他元數據，並在需要時指定它們自己的分類法。然而，由於有許多情況下需要在文章之間使用相同的信息，因此 nLingual 提供了文章同步。
文章同步
每個文章類型都有自己的規則，用於在翻譯之間同步數據。當保存更改到文章時，將在翻譯中更新以在核准字段中具有相同的數據。這包括文章數據（例如日期、狀態和菜單順序）、指定分類法的詞以及您指定的任何元字段（例如使用的縮略圖像或自定義字段值）。
提醒：目前，沒有針對同步規則的每篇文章的基礎覆蓋設置。
自由形式的語言管理
必須承認，這是少數人需要的功能，但對那些需要的人來說是一個福音。在設置 nLingual 將使用的語言時，您可以從頭開始定義自己的語言或基於許多預設值。每種語言都有多個字段：
- 系統名稱：在管理員中引用語言時要使用的名稱。
- 本地名稱：語言在網站上對本地說話者看起來的名稱。
- 簡稱：本地名稱的簡短版本（如果適用）。
- 区域设置：表示此語言的語言/國家代碼，並識別要加载的文本域的 .mo 文件。
- 官方 ISO 639-1 代碼：語言的官方 ISO 639-1 代碼（2 個字母）。
- Slug：本地化 URL 時要使用的值，通常與 ISO 代碼相同。
- 文本方向：應以哪種文本方向呈現該語言（從左到右或從右到左）。將覆蓋在文本域文件中指定的方向。
- 活動狀態：是否允許公開訪問該語言的內容。
靈活的語言檢測/切換
當加載站點的公開面時，nLingual 將嘗試使用以下過程檢測要使用的語言：
- 使用網站 URL 上的控制碼；如果找不到，轉到第 2 步。
- 檢查瀏覽器的語言設置以查找最佳匹配的可用語言；如果找不到，轉到第 3 步。
- 使用您在管理員上選擇的默認語言。
此外，nLingual 還提供了一個語言選擇器部件，可供您插入到任何小工具區域中，使您的用戶更輕鬆地切換語言。
外掛標籤
開發者團隊
📦 歷史版本下載
原文外掛簡介
The nLingual system allows for flexible multilingual support and translation management for WordPress. The system handles translations on a per-post basis, and can be set to be synchronized so changes to certain details on one are copied to the others. It offers you control over what can be translated and how, with a number of utilities available for 3rd party themes and plugins to utilize.
nLingual 2 offers more robust control of translation management, better extensibility, and fixes to numerous core issues with the previous incarnation.
Translation for Almost Anything
When setting up, you have control over what content supports translation. Any UI-enabled post types or taxonomies will be available for enabling, along with any navigation menus or sidebar locations registered. In addition, nLingual includes a LocalizeThis API that can be enabled on nearly any text field found in the admin, allowing just about any option or meta field to support separate values in each language.
Simple Translation Creation and Management
Assigning a language and translations to a post can be done on either the post editor screen or the posts management screen via Quick Edit (language can also be set for multiple post via Bulk Edit). You can also easily create new translations for existing posts on the fly; select “New [language] [post type]”, provide a translated title if you wish, and a new draft post will be created that is an exact copy of the original, ready for translation.
Translations are stored as independent posts, associated with their counterparts via a custom table. This allows you to translate the custom fields and other metadata associated with a post, and can assign them their own separate terms if desired. However, since there are plenty of occasions where you want the same information used between posts, nLingual offers post synchronization.
Post Synchronization
Each post type has it’s own rules for what data is synchronized between translations. When changes are saved to a post, it’s translations will be updated with to have the same data in the approved fields. This covers post data (e.g. date, status, and menu order), terms of specified taxonomies, and any meta fields you specify (e.g. the thumbnail image used, or a custom field value).
Note: Currently, there is no per-post basis override for the synchronization rules
Free-form Language Management
Admittedly, this is a feature few will need, but it’s a godsend to those that do. When setting up the languages nLingual will use, you can define you own languages from scratch or based on numerous presets. Each language has a number of fields:
System Name: the name to use when referring to the language within the admin.
Native Name: the name of the language as it appears to native speakers on the site.
Short Name: a shorthand version of the native name, if applicable.
Locale: the language/country code to represent this language, as well identify the .mo file to load for text domains.
ISO Code: the official ISO 639-1 code for the language (2 letters)
Slug: the value to use when localizing a URL for the language (typically the same as the ISO code).
Text Direction: the text direction the language should be rendered in (Left-to-right or right-to-left). Will override the one specified in the text domain files.
Active State: whether or not to allow public access to content in the language.
Flexible Language Detection/Switching
When the public-facing side of the site is loaded, nLingual will attempt to detect what language to serve the page in, using the following process:
Use the language code in the $_REQUEST array for the specified key, if present.
Use the language code in either the subdomain or directory path, depending on method specified.
Use the browser’s preferred language setting and find the closest match, falling back to the default language.
Once the language is set, it can be overridden by the language belonging to the requested post. This override is an configurable option.
In addition, the language can temporarily be switched to another by 3rd party theme or plugin code, similar to switching blogs in a multisite installation. When the language is switched, all text domain files will be reloaded in the desired language (the originals cached for when it’s restored), so any gettext translations will reflect the current language.
Extensibility and 3rd Party Development
In addition to numerous hooks to modify the functionality of nLingual, this plugin also includes some useful gettext utilities: _f, _ef, _fx, _efx, _a, and _xa, all of which are documented in includes/functions-gettext.php.
Backwards Compatibility
Although nLingual 2 has be rewritten from scratch, most if not all of the functions and filters are still available via the backwards compatibility feature, which is automatically enabled upon upgrading. However, any code that directly queries the database using the old nLingual language and translation tables will need to be updated to reflect the new structure.
