Make WordPress Core

Opened 8 years ago

Closed 5 years ago

#22172 closed defect (bug) (fixed)

Localized strings not applied in notification email

Reported by: pavelevap Owned by: SergeyBiryukov
Milestone: 4.4 Priority: normal
Severity: normal Version: 3.4
Component: I18N Keywords: has-patch
Focuses: Cc:


After user registration and activation (multisite), administrator receive email (function wpmu_signup_user_notification() in wp-includes/ms-functions.php). But content of this email is not translated even if localization file contains translated strings.

New User: %1s\n
Remote IP: %2s\n
Disable these notifications: %3s

Email subject is localized, but content not. I am not sure about the cause of this problem...

Attachments (2)

22172.patch (425 bytes) - added by SergeyBiryukov 8 years ago.
22172.diff (1.4 KB) - added by dd32 5 years ago.

Download all attachments as: .zip

Change History (15)

#1 @SergeyBiryukov
8 years ago

I can only reproduce on a TortoiseSVN checkout under Windows. There's a gettext bug that affects multiple line strings like this one or the one in welcome_user_msg_filter() due to different line endings on Windows and Unix.

Replacing actual line breaks with \n and keeping everything on one line could work, but it would also make the strings harder to read and translate:

"New User: %1s\nRemote IP: %2s\n\nDisable these notifications: %3s"

Related BuddyPress ticket: http://buddypress.trac.wordpress.org/ticket/2703

Could not reproduce on a regular (non-SVN) install.

#2 @SergeyBiryukov
8 years ago

22172.patch is an attempt to solve the line endings issue.

#3 @pavelevap
8 years ago

Thank you, Sergey! You are right, I am using Windows and TortoiseSVN.

I applied your patch and it works now without problem. So, WordPress can handle this problem easily...

I also tried replacing \n in original string, but then there were \n characters also in notification email.

There are many strings with \n and only some with \r\n. Maybe it should be unified? Readability should not be problem, GlotPress and Poedit can handle these situations easily for translators...

#4 @helen
6 years ago

#28074 was marked as a duplicate.

#5 @SergeyBiryukov
6 years ago

  • Keywords has-patch 4.1-early added
  • Milestone changed from Awaiting Review to Future Release

#6 @chriscct7
5 years ago

  • Keywords 4.1-early removed
  • Milestone changed from Future Release to 4.4
  • Owner set to chriscct7
  • Status changed from new to reviewing

#7 @wonderboymusic
5 years ago

  • Owner changed from chriscct7 to SergeyBiryukov

This ticket was mentioned in Slack in #core by wonderboymusic. View the logs.

5 years ago

#9 @SergeyBiryukov
5 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 35620:

I18N: In Translations::translate_entry(), account for multi-line strings in files with Windows line endings.

Fixes #22172.

#10 @dd32
5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

@SergeyBiryukov Wouldn't this be better handled within the Translation_Entry class? Possibly in the key() method?

5 years ago

#11 @dd32
5 years ago

22172.diff Is a diff with it in key() instead (Note, this was created against the GlotPress variant of POMO)

This ticket was mentioned in Slack in #core by wonderboymusic. View the logs.

5 years ago

#13 @SergeyBiryukov
5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 35686:

I18N: After [35620], move the code for standardizing on \n line endings to Translation_Entry::key().

Props dd32.
Fixes #22172.

Note: See TracTickets for help on using tickets.