Skip to:
Content

Opened 3 years ago

Closed 3 years ago

#3498 closed defect (bug) (fixed)

bug with e-mails sender address in Arabic website

Reported by: cupid4 Owned by:
Milestone: 1.5 Priority: normal
Severity: normal Version:
Component: Members Keywords: has-patch
Cc:

Description

I just started Arabic website using buddypress, and found this problem, the: noreply @ domainname . com is wrong when Arabic language is set as site language in wp-config, the e-mails sender show like this:

???.????@domainname.com ( in hotmail )

. @domainname.com ( in yahoo )

and of course, however you try to add this address to your safe list or contacts it never happen, it can't even be removed from Hotmail spam box for this reason.

  • another side note, is it just my website or you can't choose Arabic letters username in buddypress? :)

Attachments (2)

3498.001.diff (652 bytes) - added by cnorris23 3 years ago.
3498.002.diff (586 bytes) - added by cnorris23 3 years ago.
remove i18n

Download all attachments as: .zip

Change History (17)

comment:1 cupid43 years ago

just to make sure..that bug report is not hidden or anything? :)

comment:2 follow-up: johnjamesjacoby3 years ago

  • Component changed from Core to Members
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 1.5
  • Version 1.5 deleted

Not hidden. Do have any idea if this happens with the 1.2 branch of BuddyPress, or if this is new? Something tells me this is an old bug that we may not have time for in 1.5 unless someone can volunteer time with a fix.

comment:3 in reply to: ↑ 2 cupid43 years ago

well, I never tried Arabic language with 1.2 branch, just when the 1.5 beta stage started, I though of doing that, as 1.5 looked more solid to me to build a community, I wish I can help with the bug, but I can help testing any patch on my website, it's semi-live, I just advertised it for an hour before I discovered this bug so I paused.

ar.cupidcalled.com

Last edited 3 years ago by cupid4 (previous) (diff)

comment:4 follow-up: cnorris233 years ago

  • Keywords has-patch added; needs-patch removed

This is not an issue with BP per se. This is an issue with translating 'noreply' into Arabic. According to RFC 5322 (part of the email standard) only approved ASCII characters may be used in email addresses. Non-latin (which includes Arabic) characters are forbidden. Attached patch adds context to the translation of 'noreply', to give translators some clarity on this matter.

As far as Arabic usernames... again, it's not a BP issue. BP uses WP functions during username creation. You may want to add your voice to #WP5918. The ticket appears to have traction, just no momentum.

I almost think it might be better to remove the i18n from 'noreply'. WP doesn't even have this as translatable.

cnorris233 years ago

comment:5 cnorris233 years ago

I decided to go ahead and add a patch for the alternative solution.

comment:6 cupid43 years ago

Thank you so much Cnorris23 for the patch, I tested it now, it give me that error:

Parse error: syntax error, unexpected T_RETURN in /home/content/.../wp-content/plugins/buddypress/bp-core/bp-core-filters.php on line 56

is this fix for allowing translating "noreply" or for making it not translatable? I think the second option will be the best, as the e-mail address is usually English itself as the domain name, so the translation of "noreply" won't be any useful.

Thanks for the ticket link, I'm amazed it has been there since 4 years without a fix, I added a comment let's hope it will change anything :)

Last edited 3 years ago by cupid4 (previous) (diff)

comment:7 cnorris233 years ago

I made an important comma disappear. For my final act I made it reappear, so everything should work now.

comment:8 cupid43 years ago

sorry, but it give this error now:

Parse error: syntax error, unexpected '.' in /home/content/..../wp-content/plugins/buddypress/bp-core/bp-core-filters.php on line 56

cnorris233 years ago

remove i18n

comment:9 cnorris233 years ago

After reviewing it again, the original patch (3498.002.diff) was correct. I've changed it back. I'm not a my dev computer, so I can't test. How are you applying the patch?

comment:10 cupid43 years ago

I don't know exactly what I was doing wrong, I did the same and now no error, but the activation e-mail still the same:

???.????@domainname.com

Edit: well, I thought of something and wanted to check, I found the problem was that the translation file of BuddyPress that I got from GlotPress have the "noreply" there and translated to Arabic, I changed that to English and everything worked, I think any fix for this should include removing the " noreply" from buddypress POT file and making it fixed term, or include a warning there for translator to not change it from English.
for now, I just submitted a change in GlotPress for 'noreply' reverting back to English.

http://translate.wordpress.org/projects/buddypress/dev/ar/default?filters[status]=either&filters[original_id]=4691&filters[translation_id]=1178166

comment:11 boonebgorges3 years ago

I agree with cupid4 that the best course here is probably to hardcode 'noreply@'. Any objections?

comment:12 cnorris233 years ago

No objections. That's what 3498.002 does, and what WP does also.

comment:13 in reply to: ↑ 4 cupid43 years ago

Yes, just as cnorris23 explained in comment4 ,I should have thought to check the translation file from the point.
For the Arabic usernames, the current ticket seems to be totally ignored as it was reported 4 years ago, You think I should add new ticket about current WordPress version?

comment:14 cnorris233 years ago

No don't start another ticket. It will just get closed as it will be a duplicate. That's why I suggested you comment on the existing ticket. Any help you can add there will help get it added. You can help by testing the existing patch. Update the patch if needed and you're capable.

comment:15 boonebgorges3 years ago

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

(In [5123]) Hardcode default replyto email address in bp_core_email_from_address_filter(), to avoid l18n problems in non-Latin charsets. Fixes #3498. Props cnorris23

Note: See TracTickets for help on using tickets.