Make WordPress Core

Opened 11 years ago

Last modified 4 years ago

#23311 new enhancement

Enable internationalization in PHPMailer

Reported by: iandunn's profile iandunn Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.5
Component: I18N Keywords: has-patch needs-refresh
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 11 years ago.
23311.2.diff (2.8 KB) - added by iandunn 11 years ago.
Creates new class extending PHPMailer
23311.2-unit-tests.diff (784 bytes) - added by iandunn 11 years ago.
23311.2.2.diff (2.9 KB) - added by iandunn 11 years ago.
Updated for PHPMailer 5.2.4

Download all attachments as: .zip

Change History (16)

#1 @mark-k
11 years ago

  • Cc mark@… added

#2 @SergeyBiryukov
11 years ago

  • Version changed from trunk to 3.5

@iandunn
11 years ago

#3 @iandunn
11 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?

#4 follow-ups: @nacin
11 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.

#5 @nacin
11 years ago

  • Keywords needs-codex removed

#6 in reply to: ↑ 4 ; follow-up: @mark-k
11 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: '),
       ....
    );

#7 in reply to: ↑ 6 @nacin
11 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().

@iandunn
11 years ago

Creates new class extending PHPMailer

#8 in reply to: ↑ 4 @iandunn
11 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.

@iandunn
11 years ago

Updated for PHPMailer 5.2.4

#9 @iandunn
11 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.

#10 @ryan
11 years ago

  • Milestone changed from 3.6 to Future Release

#11 @chriscct7
9 years ago

  • Severity changed from minor to normal

#12 @desrosj
4 years ago

  • Keywords needs-refresh added
  • Milestone set to Future Release

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

Note: See TracTickets for help on using tickets.