Converting Apple voices from a list of altNames to a localized string

[HadrienGardeur]

As documented in #23, Apple has an inconsistent approach for voice names, where different string patterns are used, based on:

• the browser
• and the number of variants installed for a given voice

As I continue to add more and more languages to this project, it keeps on taking longer and longer to go back to every single language that I've already documented and add localized voices in altNames.

I'm tempted to move away from this approach and document locales instead. For example the English locale for Apple could look something like that:

{
 "quality": {
  "medium": "Enhanced",
  "high": "Premium"
  },
  "languages": {
    "en": "English"
    "fr": "French"
  },
  "regions": {
    "fr": "France",
    "ch": "Switzerland",
    "be": "Belgium",
    "ca": "Canada"
  }
}

For each Apple voice, I would document a new quality property along with a new localizedVoice property. Here's an example:

{
  "label": "Audrey (France)",
  "name": "Audrey",
  "note": "Audrey can be installed on all Apple devices and offers three variants. Like all voices that can be installed on Apple devices, it suffers from inconsistent naming due to localization.",
  "altNames": [
    "Audrey (de qualité)",
    "Audrey (premium)",
    "Audrey (français (France))"
  ],
  "language": "fr-FR",
  "quality": [
    "low",
    "medium",
    "high"
  ],
  "localizedVoice": "apple",
  "gender": "female",
  "rate": 1,
  "pitch": 1,
  "os": [
    "macOS",
    "iOS",
    "iPadOS"
  ]
}

In contrast, here's the current approach where everything is listed in altNames:

web-speech-recommended-voices/json/fr.json

Lines 183 to 226 in cecfa69

	{
	"label": "Audrey (France)",
	"name": "Audrey",
	"note": "Audrey can be installed on all Apple devices and offers three variants. Like all voices that can be installed on Apple devices, it suffers from inconsistent naming due to localization.",
	"altNames": [
	"Audrey (de qualité)",
	"Audrey (Premium)",
	"Audrey (premium)",
	"Audrey (prèmium)",
	"Audrey (korkealaatuinen)",
	"Audrey (høj kvalitet)",
	"Audrey (Enhanced)",
	"Audrey (mejorada)",
	"Audrey (ottimizzata)",
	"Audrey (melhorada)",
	"Audrey (erweitert)",
	"Audrey (verbeterd)",
	"Audrey (millorada)",
	"Audrey (parannettu)",
	"Audrey (förbättrad)",
	"Audrey (forbedret)",
	"Audrey (French (France))",
	"Audrey (français (France))",
	"Audrey (francés (Francia))",
	"Audrey (francese (Francia))",
	"Audrey (francês (França))",
	"Audrey (Französisch (Frankreich))",
	"Audrey (Frans (Frankrijk))",
	"Audrey (francès (França))",
	"Audrey (ranska (Ranska))",
	"Audrey (franska (Frankrike))",
	"Audrey (fransk (Frankrig))",
	"Audrey (fransk (Frankrike))"
	],
	"language": "fr-FR",
	"gender": "female",
	"rate": 1,
	"pitch": 1,
	"os": [
	"macOS",
	"iOS",
	"iPadOS"
	]
	},

Overall:

• altNames would continue to provide all possible variants for that voice's language, which would be a decent fallback for those who don't want to use code to generate the full list of voice names
• the list of recommended voices for each language would be smaller overall with fewer strings in altNames
• thanks to localizedVoice, language, quality and navigator.language I could easily generate additional voice names
• for example, if my browser returns en-us for navigator.language, it would generate the following voice names using the localization file: "Audrey (Enhanced)", "Audrey (Premium)" and "Audrey (French (France))"
• with this approach, it would be easier to order voices based on quality as well

The main downsides to this approach that I can currently identify:

• it would either require to turn this repo into a full JS/TS library first (Transforming this repo from a documentation to a code repo #9) or implementers would need to be aware of locales and string patterns for Apple voices as well
• it's possible to use a different language as the default language in your browser than your system language
• documenting locales for each language would still be quite a bit of work

The second one is fairly easy to work around (we could generate voice names for every single language supported), but less optimal than simply generating voice names for the user's locale.

[HadrienGardeur]

• This strategy could also be applied to Android voice names: Is it really useful to document Android voices? #29

[HadrienGardeur]

I'm closing that discussion since this is now a work in progress: #40