WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 2 years ago

#23311 new enhancement

Enable internationalization in PHPMailer

Reported by: iandunn Owned by:
Milestone: Future Release Priority: normal
Severity: minor Version: 3.5
Component: I18N Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (4)

23311.diff (2.0 KB) - added by iandunn 3 years ago.
23311.2.diff (2.8 KB) - added by iandunn 3 years ago.
Creates new class extending PHPMailer
23311.2-unit-tests.diff (784 bytes) - added by iandunn 3 years ago.
23311.2.2.diff (2.9 KB) - added by iandunn 2 years ago.
Updated for PHPMailer 5.2.4

Download all attachments as: .zip

Change History (14)

comment:1 @mark-k3 years ago

  • Cc mark@… added

comment:2 @SergeyBiryukov3 years ago

  • Version changed from trunk to 3.5

@iandunn3 years ago

comment:3 @iandunn3 years ago

  • Keywords has-patch needs-codex added

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?

comment:4 follow-ups: @nacin3 years ago

  • Milestone changed from Awaiting Review to 3.6

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.

comment:5 @nacin3 years ago

  • Keywords needs-codex removed

comment:6 in reply to: ↑ 4 ; follow-up: @mark-k3 years ago

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: '),
       ....
    );

comment:7 in reply to: ↑ 6 @nacin3 years ago

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().

@iandunn3 years ago

Creates new class extending PHPMailer

@iandunn3 years ago

comment:8 in reply to: ↑ 4 @iandunn3 years ago

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.

@iandunn2 years ago

Updated for PHPMailer 5.2.4

comment:9 @iandunn2 years ago

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.

comment:10 @ryan2 years ago

  • Milestone changed from 3.6 to Future Release
Note: See TracTickets for help on using tickets.