The Participants Database plugin is set up for internationalization. There are several languages available, although currently many of these translations are incomplete. Which language is used is based on the WordPress language setting or, if a multilingual plugin is used, the setting determined by that plugin.
If you’re looking for information on how different non-English characters are handle in searching and sorting, take a look at this post: Getting Correct Search Results with Non-English Characters
Multilingual or Localized?
There is a big difference between running a WordPress site in a non-English language and running WordPress as a multilingual application.
If you just need the application run in your own language, it is fairly easy to set up: just select that language in the WordPress general settings and the plugin will follow, using the translation files provided with the plugin.
If the translation for for your language is missing or incomplete, you can complete the translation or create a new one using a translation tool such as Poedit. The details on how to get that done are discussed in several places:
- wpmudev.org: How to Translate a WordPress Plugin
- WordPress Localization
- wplang.org: How to translate a WordPress plugin
If you are completing or correcting a translation or creating a new translation, and would like to see it added to the plugin for others to use, please contact me…or just send the files to support@xnau.com. I’ll give you a credit in the plugin readme.
Multilingual Sites
Setting up a multilingual site (that is, a site that can be read in more than one language) is more complex, and usually involves the use of a multilingual plugin. In this case, the plugin must be set up for all the languages you want to support. This usually means using a special format for plugin settings that are printable strings: things such as feedback messages, emails, field titles, etc. The specially-formatted strings are then filtered according to the current language so that only the translation for that language is shown.
Participants Database accommodates this by filtering all it’s settings strings, titles, etc. through a “gettext” statement where the multilingual plugin can filter it. However, since this can slow the plugin down, the strings are not normally passed through this extra function. It is necessary to tell the plugin that you need to translate the strings by setting a constant. You can do that easily in your wp-config.php file with a line like this:
define( 'PDB_MULTILINGUAL', true );
That should allow the multilingual plugin to translate all the plugin’s settings strings.
Plugin Setting Strings
Many of the strings in the plugin’s settings, including field titles, will need to be translated. Since they are user-defined, they can’t be included in translation files. For multilingual sites, the multilingual plugin is expected to provide a way to define plugin settings for multiple languages.
With many multilingual plugins, it is possible to define your settings strings as complex strings that are filtered according to the current language. For example to define the title for the first_name field you would put:
[:en]First Name[:de]Vorname[:fr]Prénom[:nl]Voornaam[:]
That is an example for the Q-Translate-X plugin, other multilingual plugins will have a different syntax for such strings.
Setting Up Selector Fields
With any kind of selector form element, the plugin provides a way to set up a “display” value (which can be translated) that is associated with the “stored” value, which is not.
In a multilingual setup, you are expected to set up your selector fields with display values that have the the languages embedded in the string. For example if the selector values are “blue,red”:
[:en]Blue[:es]Azul[:de]Blau[:fr]Bleu[:nl]Blauw[:]::blue, [:en]Red[:es]Rojo[:de]Rot[:fr]Rouge[:nl]Rood[:]::red
The value saved is “blue” or “red” but the user will see the label in their own language. When they search in their own language, the word they use is indexed to the options and matched to the value in the database. This way, it doesn’t matter what language they are using, it will match the corresponding value that is stored in the database.
Creating a Custom Multilingual Parser
If you are not using a multilingual plugin that provides a parser (such as in the example above) you can set up your own parser (given some coding knowledge). The plugin uses the filter pdb-translate_string for all display strings, so you can set up a parser on that filter.
One way that would work is you could use some kind of notation (such as what Q-Translate-X uses) to embed all the language strings into the setting (for instance, a field title) and then use a handler on that filter to parse out the correct string for the currently selected language.