Can you fix the file permissions please Brian?

Done and learnt something new ;)

Thanks!

How shall we test this? Just see if IDN email addresses still can be entered successfully in email fields in backend? Or roll back the change from #3429 to test also if punycode contains a correction for that?

@infograf768 can you help test this please

Will do tomorrow, Please remind me. :)

Hmm

A valid punycode mail adress would be:
юзер@екзампл.ком (for Ukrainian)
Whether I revert the change done in #3429 it does not validate.

To test, edit a contact mail.

It looks like we have to change the validation regex in validate.js as well as validate-uncompressed.js

setHandler('email', function(value, element) {
            value = punycode.encode(value);  // changed here from value = punycode.toASCII(value);
            var regex = /^[a-zA-Z0-9.!#$%&’*+\/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/;
            return regex.test(value);
        });

See bestiejs/punycode.js@92f8796

So to confirm you are saying that neither the existing code or the new code
in this PR works?

They work if the local part is ascii, not if it is utf8
юзер@екзампл.ком will not validate
info@екзампл.ком will.

This why the regex has to be modified.

Should I add that regex change to this PR?

On 12 May 2016 at 09:53, infograf768 notifications@github.com wrote:

They work if the local part is ascii, not if it is utf8
юзер@екзампл.ком will not validate
info@екзампл.ком will.

This why the regex has to be modified.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#9889 (comment)

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I have not posted the regex change

SO, normally we should revert #3429 to get:
value = punycode.encode(value); instead of value = punycode.toASCII(value);
and then find the correct regex to replace
var regex = /^[a-zA-Z0-9.!#$%&’*+\/=?^_{|}~-]+@[a-zA-Z0-9-]+(?:.[a-zA-Z0-9-]+)*$/;`

Sorry I thought you had - ignore my last commit

please revert your last commit so that we can find and test a new regex

reverted

All depends on the mail servers. If they obey to RFC5322 or more recent RFC6530
Quote from : https://en.wikipedia.org/wiki/Email_address#Internationalization

Internationalization examples

The example addresses below would not be handled by RFC 5322 based servers, but are permitted by RFC 6530. Servers compliant with this will be able to handle these:

Latin Alphabet (with diacritics): Pelé@example.com
Greek Alphabet: δοκιμή@παράδειγμα.δοκιμή
Traditional Chinese Characters: 我買@屋企.香港
Japanese Characters: 甲斐@黒川.日本
Cyrillic Characters: чебурашка@ящик-с-апельсинами.рф

All I really want to do with this PR is to update the library to the current release. If we have an issue with local nonascii email addresses BEFORE and AFTER this PR then there is no change in behaviour caused by this PR and we can merge this one and then look at that as a new issue. If I understand correctly

We have indeed no more issues after this PR, as far as I tested, when the local part is ascii

BTW, Travis error is unrelated to this patch

So we can merge this PR then?

On 12 May 2016 at 10:57, infograf768 notifications@github.com wrote:

BTW, Travis error is unrelated to this patch

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#9889 (comment)

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Would be good to get other tests first using
info@екзампл.ком as test mail in contact for example.

I have tested this item successfully on 84fce68

юзер@екзампл.ком -> not validate
info@екзампл.ком -> validate

I have tested this item successfully on 84fce68

RTC - thanks for testing