As long as the multi-language site supports the .po/.mo language packs, multiple languages can be supported with a few caveats. You will need some additional consideration for the following that will not be in the language pack:
- Custom fields
- Dialogs
- Emails
Custom Fields
The plugin is fully localized. However, keep in mind that because the plugin contains a dynamic element (custom fields), any custom fields you add will not be contained in the translation template.
The label for any custom field will be handled through the same processing in the form builder as any other field, so it will pass through WP’s gettext() handler. However, no translation will be found in the plugin’s translation template.
You can handle custom field labels in a multi-language application by one of the following:
- Maintaining a custom translation file for the plugin (see Maintain a Custom Translation File)
- Filtering the output with WP-Members’ filters (use a filter for the custom fields)
- Targeting the specific string/text-domain in your multilanguage application (WP-Members uses “wp-members” as the text domain)
Dialogs
All user-facing dialogs pass through WP’s gettext() handler the same as fields (as noted above). However, keep in mind that some dialogs are editable in the WP-Members admin panel and all others can be changed using custom filter functions. If you change any dialogs from the plugin default, they will no longer match anything in the plugin’s language packs. Any custom dialogs would require custom handling the same as custom fields (as noted above).
Emails
Emails are editable in the plugin’s settings and are not passed through any translation method. The gettext() process is not applied to emails.
For running emails in a mutli-language application, you can either filter your email content using the plugin’s filters, or you can create custom emails for each language needed. Your filter functions can use WP’s `get_locale()` function to determine what language is being served.
.