en_IND should be an alias for en_IN in v8

[matthewmayer]

Pre-Checks

• Follow our Code of Conduct.
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Faker issue and not related to a combination with another package.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.
• I am willing to provide a PR.

Describe the bug

#1354 was fixed in #1448 where the en_IND locale was renamed to en_IN

However to avoid an unnecessary breaking change, in v8 en_IND should be kept as an alias for en_IN, emitting a warning if used, and only completely removed in v9

Minimal reproduction code

No response

Additional Context

No response

Environment Info

System:
    OS: macOS 12.6
    CPU: (8) x64 Apple M1
    Memory: 43.42 MB / 8.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 14.20.0 - /usr/local/bin/node
    npm: 8.19.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 106.0.5249.119
    Firefox: 91.0.2
    Safari: 16.0

Which module system do you use?

• CJS
• ESM

Used Package Manager

npm

[wael-fadlallah]

@matthewmayer Do you have any insight about how to accomplish this?

[Shinigami92]

I think we can just add an if->rewrite here:

faker/src/faker.ts

Lines 53 to 60 in 0f9b0c6

	set locale(locale: UsableLocale) {
	if (!this.locales[locale]) {
	throw new FakerError(
	`Locale ${locale} is not supported. You might want to add the requested locale first to \`faker.locales\`.`
	);
	}
	this._locale = locale;
	}

But to be fully backward compatible, we also need to allow the old locale in the UsableLocale TypeScript type 🤔

[ST-DDT]

@Shinigami92 We cannot do that there, because the import has changed. And in v8 we will stop changing/addressing locales via their names/keys.

[xDivisionByZerox]

We could "add" the en_IND back into our system. But instead of actually implementing it could behave like a proxy to en_IN:

1. Import en_IN locale
2. call our deprecated function
3. Export en_IN as en_IND

Since JS files are simply executed on import, the deprecared function will be called whenever we explicitly import en_IND.