fix: ASCII-fy domainWord()

[schw4rzlicht]

The en locale includes the word "jalapeño" which is the only one with a special char. Imo this is inconsistent and it leads to other problems as well, see #1105 (comment) for example.

This PR removes the word from the locale.

This PR uses faker.helpers.slugify() to remove non-ASCII characters from domainWord().

[ST-DDT]

AFAICT: jalapeño is a proper English word, isn't it?
For #1105 I think we should rather ansify these characters.

[schw4rzlicht]

AFAICT: jalapeño is a proper English word, isn't it?
For #1105 I think we should rather ansify these characters.

Yes, might make more sense. I altered the Regex that filteres illegal characters in Internet.domainWord(), maybe that's what helps?

[matthewmayer]

if #1554 gets merged then you would be able to use the new version of faker.helpers.slugify to turn jalapeño to jalapeno automatically in domainWord (as domainWord seems to be a slight variant of slugify really).

[codecov]

Codecov Report

Merging #1520 (777ded6) into next (b2a72bc) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #1520      +/-   ##
==========================================
- Coverage   99.64%   99.63%   -0.01%     
==========================================
  Files        2221     2221              
  Lines      240110   240108       -2     
  Branches     1051     1049       -2     
==========================================
- Hits       239248   239236      -12     
- Misses        841      851      +10     
  Partials       21       21              

Impacted Files	Coverage Δ
src/modules/internet/index.ts	100.00% <100.00%> (ø)
src/modules/internet/user-agent.ts	84.05% <0.00%> (-2.71%)	⬇️

[schw4rzlicht]

if #1554 gets merged then you would be able to use the new version of faker.helpers.slugify to turn jalapeño to jalapeno automatically in domainWord (as domainWord seems to be a slight variant of slugify really).

From what I've seen this is right.

But that would mean:

• in order to fix that our team has to change the usage of faker for ~2000 test cases. And I don't think we're alone with this.
• we cannot call faker.internet.domainWord()/faker.internet.domainName()/faker.internet.url() without using slugify() together with it, which imo is counter intuitive, not nice to read and will definitely break in the future again, as at some point someone will forget about it
• it doesn't solve the underlying issue with domainWord()

As I said here:

From what I understand, not all TLDs are even accepting internationalized domain names (wiki), so I think it is out of scope for faker to determine which are and keep track of that. Imo, domain words should just not include non-ASCII chars to keep it simple.

Additionally, internationalized domain names are converted to ASCII compatible encoding on the client when using them. They simply don't exist when building servers.

Btw, I noticed I forgot to re-add jalapeño after refactoring the regex of domainWord(). Will do that once our discussion here moves forward :)

[Shinigami92]

@schw4rzlicht I highly assume he meant using it inside faker in this PR, not in your code to wrap faker calls.

[matthewmayer]

right could you change domainWord to just be something like

domainWord(): string {
    return this.faker.helpers
      .slugify(`${this.faker.word.adjective()}-${this.faker.word.noun()}`)
      .toLowerCase();
  }

[schw4rzlicht]

@schw4rzlicht I highly assume he meant using it inside faker in this PR, not in your code to wrap faker calls.

Ah alright, misunderstood that, sorry 🤦

Thanks @matthewmayer, I will update the PR today or tomorrow :)

EDIT: Wasn't able to do it yet, too much work on other projects. Will do asap though.