Make WordPress Core

Opened 14 years ago

Closed 11 years ago

#22172 closed defect (bug) (fixed)

Localized strings not applied in notification email

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

Description

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
\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 14 years ago.
22172.diff (1.4 KB ) - added by dd32 11 years ago.

Download all attachments as: .zip

Change History (15)

#1 @SergeyBiryukov
14 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
14 years ago

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

#3 @pavelevap
14 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
12 years ago

#28074 was marked as a duplicate.

#5 @SergeyBiryukov
12 years ago

  • Keywords has-patch 4.1-early added
  • Milestone Awaiting ReviewFuture Release

#6 @chriscct7
11 years ago

  • Keywords 4.1-early removed
  • Milestone Future Release4.4
  • Owner set to chriscct7
  • Status newreviewing

#7 @wonderboymusic
11 years ago

  • Owner changed from chriscct7 to SergeyBiryukov

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


11 years ago

#9 @SergeyBiryukov
11 years ago

  • Resolutionfixed
  • Status reviewingclosed

In 35620:

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

Fixes #22172.

#10 @dd32
11 years ago

  • Resolution fixed
  • Status closedreopened

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

@dd32
11 years ago

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


11 years ago

#13 @SergeyBiryukov
11 years ago

  • Resolutionfixed
  • Status reopenedclosed

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.