WordPress Plugin: Codestyling Localization (en)
|WordPress Version:||WordPress 2.5 or later|
|PHP Version:||PHP 4.4.2 or later|
|tested Browser:||IE | FireFox | Opera | Safari | Google Chrome|
|not supported Browser:||currently not known|
While get in touch with WordPress you will find out, that the initial delivery package comes only with english localization. If you want WordPress to show your native language, you have to provide the appropriated language file at languages folder. This files will be used to replace the english text phrases during the process of page generation.
This translation capability has the origin at the gettext functionality which currently been used across a wide range of open source projects. The basics of this system are documented Free Software Foundation (FSF) - GNU Project - gettext and can be read there.
The basis for translations are language files defined as *.po format (portable) or *.mo format (machine object), which helps software to get translated on the fly.
The *.po files are pure text format and must meet a dedicated specification to be analyzable by software programs. Normally you would take a texteditor for translation or a specific editor like PoEdit, which have to be installed on your PC first. Using such an editor you can translate *.po files and generate the resulting *.mo files out of. All software products based on gettext are only able to deal with *.mo files at production level (live mode).
In my opinion the effort to localize as example a plugin is too high, because you need the plugin at your local PC and a PoEdit installed. You will translate some phrases, generate a *.mo file and finally upload it. But after inspectation in real live you will encounter such things like to big label texts or small mistakes. And you will repeat this always including that file upload again.
This recurring process is counterproductive and time wasting. So i tried to create a solution which integrates into administration GUI of WordPress, can simply manage and translate any component. The translation results can be controlled immediately using a second browser tab containing the target page.
The Plugin Mainpage - The Beginning
If you have plugin installed and activated, you will get a new menu entry inside “Manage” which is named “Localization“. If you choose the entry, you will get the complete overview about all components of your WordPress installation, that are gettext ready or having already language files on board.
This plugin inspects WordPress itself, all plugins out of plugins folder and also all themes out of theme folder. Only those components will be listed that are really gettext ready and can handle translation files.
You can perform several actions per component (WP | Plugin | Theme) and language. If your choosen component already have had translation files, they will be listed with informations about. Files marked with white indicates, that those are not existing.
A red marked file indicates, that it permits readonly access and thatswhy it can’t be written.
Files marked with green color will show you, that you can read and write it.
All read-only files can be turned into read-write access, if you click at the red symbol. This will be done at several internal steps. First the plugin tries to set the permissions to rw-/r–/r– at this file. If this is not enough to be able to write onto, it tries next to set the permissions to rw-/rw-/r– and if this also fails, finally the permissions rw-/rw-/rw- will be tried. If all that fails totally, you will get an error message box and you have to adjust it using your FTP account. At success case the color of file changes to green and you can use it. This permission change feature is only provided for read-only files.
The Plugin Mainpage - Add New Language
If your prefered language doesn’t exist, you can simply add it. The occuring dialog lets you choose your new language but will skip those already existing for the target component. After you have filled the last translator field (defaults to current logged on WordPress user) and made your choise, the related *.po file will be creates at the target components folder. The new language immediately shows up at language list and can be handled now by further actions. The new file doesn’t contain any catalog entry except the correct file header nessessary for translations.
The Plugin Mainpage - Rescan PHP Source Files
After you have added your new language you will need the text phrases to be able to translate something. Rescanning the PHP source files extracts this text phrases and saves them at *.po file (quite similar to PoEdit). But the plugin performs an intelligent search / analysis process and scans only component related files.
If you want as example rescan the WordPress itself using PoEdit you will get a mixed translation file, containing also any custom plugin or theme phrases.
But this plugin performs intelligent: in case of WordPress itself the scan process skips the complete plugin and theme folder and only explicite adds Akismet and the themes provided at WordPress install package. This ensures that only WordPress related phrases will be attached to that language file and never attach the phrases of plugin XY too.
This process can take some seconds upto minutes, depending on your connection speed and the count of files to be processed. The progress will be shown until all has been scanned. After successful rescan the *.po file will contain all found phrases based at gettext functionality. If you run the scan process at an already existing *.po file, the file gets updated.
No worry about maximum execution time setting of PHP. This process is ajax driven, so you will not have problems related to runtime restrictions.
The Plugin Mainpage - Delete Language
Deleting a language really implies physical erase! Thatswhy you will get a dialog and must confirm this action. After confirmation both files *.po and *.mo will be erased from harddisk. You can abort the confirmation dialog and avoid erase by clicking upper right corner close button.
The Plugin Mainpage - Launch Translation Editor
If you hit the “Edit” action, the view switches into language editor mode. This build-in editor allows the translation of any contained catalog phrase and also produces the *.mo file on your needs.
The Translation Editor
The editor has been designed as comfortable as possible and permits the complete language file catalog editing. After launch it displays the first 100 entries as default out of the *.po file. You can choose the count of entries per page and also the page itself by your needs.
Every entry at the language file will be shown at it’s own row. The left column shows upto 2 possible items:
- PHP symbol - shows the source files containing the text and opens a preview dialog at source file and line
- comment symbol - if the file contains a comment, it will be displayed here
The next 2 columns containing the original text and the translation target text. The last column provides some actions, currently only the action: edit entry.
If you edit an entry, you will get one out of 2 possible edit dialogs. The gettext functionality supports on the one hand side simple text phrases with 1:1 relationship. On the other hand side it supports also plural forms but they have 2:n relationship. The english language knows singular and plural. But several target languages have more or less differences, some support only 1 form (2:1) but other may support upto 4 different pluralizations (2:4). Thatswhy a special dialog will be shown, that handles this fact and shows the formula behind the plural index calculation too.
As can be seen at the screenshots, the dialog supports also translations assisted by Google Translate API. But it will be available only, if the target language is supported by Google. Clicking this link translates the original text by Google Translate API and writes the result into the translation target field. You should handle this as suggestion because in most cases you have to rework it.
Event though Google Translate keeps the HTML markup unchanged, it may often happen, that formatter like %s gets exploded and filled by space character. This is dangerous at formatting functions inside PHP, because the values to be later inserted won’t show up or you script may crash. This also happens if you have backslashed text. The backslashes gets multiplied. You have always to check those translation results carefully.
Both search fields at table head can be used to find matches at the choosen column. This is an exact match search, keep in mind. During typing the seach phrase the number of shown target rows will be reduced on the fly. This search runs always over all language file entries and shows all matches.
Pressing the button “generate mo-file” converts the edited *.po file and saves it additional as new binary *.mo file. An existing *.mo file will be overwritten. In success case the change date beside the button will be refreshed and highlighted.
If you open an additional browser tab with your page subject of your translation, you can check instantly if your changes looks as expected. This online control is useful because sometimes the provided space for labels is not wide enough and you have to find an shorter translation phrase.
All entered translations will be saved during pressing the “Save” button at dialog. Your changed phrases will always made persistent at the *.po file. So you can continue your translation later on too without loosing anything.
This plugin currently only supports languages, that have been stored at internal definition sets. This has been done to ensure the correct usage of plural form definitions automatically. Secondly it supports only languages having the country specifier included such xx_XX. Thatsways following language examples won’t be detected nor supported:
This will be part of later versions and gets a complete extension than.
Plugins that are gettext ready but having no language file contained yet may store the new created languages files at the main folder of plugin instead of its dedicated language folder. This will happen if the language path can’t be detected qualified from source code. If you provide at least an emtpy language file at the target plugins language folder, the correct path will be extracted from this existing file and new languages will now be created a the right sub folder. Upcomming versions will introduce this as choise inside the creation dialog for such cases.
At some plugins the text domain can’t be detected. This happens if the plugin writer did not use text or constants for the textdomain. In such cases the name of the plugin file (without the .php extension) will be used. For this issue i have currently no solution.
Decompress the plugin and upload the complete folder csp-po-edit with all content as sub folder at /wp-content/plugins/. Now you will find the plugin at the menu “Plugins” named Codestyling Localization and can be activated.
During activation the plugin checks the required WordPress and PHP version. If at least one of this tests fails, the plugin can not be activated and reports the issue as can be seen at screenshot.
The plugin does not require any configuration and does not change your database nor content. It works “out of the box” if you meet the above named requirements.
|2008-06-21||0.10||start of coding|
|2008-08-25||0.95||Beta Release (1st closed test)|
|2008-08-26||0.96||Beta Release (2nd closed test)
|2008-08-27||0.97||Beta Release (3rd closed test)
|2008-09-02||1.0||1st public release
Plugin Version: codestyling-localization-v1.99.25.zip (67710 downloads)
It’s planned to lauch a Bug-Trac and user forum. But currently i have no time to setup both. Thatswhy please contact me by email, but keep in mind, that response may take some time. Any mail related to this plugin will be answered.
Hint: Because sometimes the question appears, that plugins or themes doesn’t get detected as translatable, this often caused be the fact, that they use variables as textdomain specifier. If the author would have been using constants, the parser would be able to find them. Example: