New approach for localizing Apple and Android voice names

[HadrienGardeur]

As initially mentioned in #38 and #29, documenting all possible combinations for localized voices on Apple and Android devices feels like a dead-end.

The more voices that I add to this repo, the longer it takes and JSON files keep on getting larger and larger.

To work around this issue, I'm opening a draft PR while I revisit all languages one by one to:

• identify voices that are localized
• and document localized strings for each language

This will be a massive effort, but feels like the best option to continue extending the scope of this project with more and more languages.

I won't merge this PR until we can offer an open-source JS/TS library to work with these localized strings and offer the feature set initially proposed in #9.

[HadrienGardeur]

I'm moving this one to "Ready for review" and the review itself will be the code implementation.

[HadrienGardeur]

Now that I've worked on how a code based approach could work, I'm tempted to drop languages/regions localization entirely and just focus on how the different voice quality presets are localized on Apple devices.

With such a minimal take on localization, it would make more sense to keep a single localization file that contains all languages.

We would no longer be able to match Android voices though, but since these are not truly voices anyway, I'm not sure we'd really lose anything.

@Falcosc @panaC how do you feel about this idea?

[Falcosc]

I only care about Microsoft voices, azure cloud voices are great.
Not sure how they get exposed to the user via Edge Android, Edge iOS and Edge MacOS.

So, no complaint about unable to match google voices. As long as it is easy to get a list of voices if no matches are found.

[HadrienGardeur]

Not sure how they get exposed to the user via Edge Android, Edge iOS and Edge MacOS.

Edge voices are not affected by localization issues at all, so this doesn't make any difference.

So, no complaint about unable to match google voices. As long as it is easy to get a list of voices if no matches are found.

That's the idea with Readium Speech, other voices would simply be listed lower than recommended ones.

[HadrienGardeur]

Spending time with @panaC yesterday was very helpful to identify various issues with this PR. Hopefully things are in a better state now.

We've also discovered Intl.DisplayNames which makes my previous effort of documenting languages/regions even more redundant. I'm keeping these extended locales in the PR for now but will open an issue to drop them once we've fully evaluated to which extent we can rely on Intl.DisplayNames.