Enable internationalization in PHPMailer

[iandunn]

Per the discussion in #23291, we should enable PHPMailer's internationalization feature so that any error messages returned by it and displayed to the user will be translated.

[iandunn]

I've attached a patch for this. #23291 will need to be committed for this to have any effect, though, since currently wp_mail() ignores any errors that PHPMailer throws.

If this gets committed, we'll need to update the Codex to tell users how to install the PHPMailer localizations that match the version of PHPMailer shipped with Core.

It'd also be good to have the PHPMailer localizations ship with the localized versions of WP (e.g., ​http://fr.wordpress.org/, etc). What would be the best way to approach that? Is there a team that maintains those, or is it just random contributors?

[nacin]

What we can do instead is add every string in PHPMailer::SetLanguage to the WordPress POT file, so it may be translated like any other string in WordPress.

Then, we can set $phpmailer->language directly, with our own strings.

As $phpmailer->language is protected, it would probably make the most sense to actually extend PHPMailer and create a WP_PHPMailer class.

Unit tests should then test that we are not missing any strings in WP_PHPMailer that are present in a potential future version of PHPMailer, by confirming that the keys returned by PHPMailer::GetTranslations() line up.

Or, to involve upstream, we can submit a change upstream to allow for the language strings to be set from an array, rather than from a PHP file. Then implement that change downstream and leverage it here. I would not be surprised, though, if the comment from upstream is to simply extend PHPMailer.

[mark-k]

Replying to nacin:
Can't we do

$phpmailer->SetLanguage( 'wp', ABSPATH . WPINC .'/' ) ); 

and add a file named phpmailer.lang-wp.php to wp-includes which looks like

    $PHPMAILER_LANG = array(
      'provide_address' => __('You must provide at least one recipient email address.'),
      'mailer_not_supported' => __(' mailer is not supported.'),
      'execute' => __('Could not execute: '),
       ....
    );

[nacin]

Replying to mark-k:

Replying to nacin:
Can't we do

$phpmailer->SetLanguage( 'wp', ABSPATH . WPINC .'/' ) ); 

and add a file named phpmailer.lang-wp.php to wp-includes which looks like

    $PHPMAILER_LANG = array(
      'provide_address' => __('You must provide at least one recipient email address.'),
      'mailer_not_supported' => __(' mailer is not supported.'),
      'execute' => __('Could not execute: '),
       ....
    );

Looks like that would work too. It does abuse the $langcode parameter, but that is only used for the include().

[iandunn]

Creates new class extending PHPMailer

[iandunn]

Replying to nacin:

What we can do instead is add every string in PHPMailer::SetLanguage to the WordPress POT file, so it may be translated like any other string in WordPress.

Then, we can set $phpmailer->language directly, with our own strings.

As $phpmailer->language is protected, it would probably make the most sense to actually extend PHPMailer and create a WP_PHPMailer class.

Unit tests should then test that we are not missing any strings in WP_PHPMailer that are present in a potential future version of PHPMailer, by confirming that the keys returned by PHPMailer::GetTranslations() line up.

That's done in 23311.2.diff and 23311.2-unit-tests.diff.

[iandunn]

Updated for PHPMailer 5.2.4

[iandunn]

PHPMailer was updated from 5.2.1 to 5.2.4 in #21074 and the $PHPMAILER_LANG keys changed a bit. 23311.2.2.diff is updated to reflect the changes.

[desrosj]

This ​came up in the comments of a recent call for testing after a recent PHPMailer update.

The patch here will definitely need a refresh