The SIP unveils its Luxembourgish TTS

At the end of June, we were once again at VoxxedDays in Mondorf-les-Bains to present Mia and Mil, two Luxembourgish speech synthesizers designed for assistive technologies. Watch the video for a look back at this unique technical adventure.

Monday, July 27, 2026


When a project comes to fruition and gives rise to innovation, it’s an opportunity to raise awareness of it and let it evolve in the hands of users. But we also wanted to give you a behind-the-scenes look at an unusual project: the creation of Luxembourgish synthetic voices tailored for digital accessibility. This was the focus of the presentation given at VoxxedDays at the end of June.

Alain Vagner and Dominique Nauroy present the Luxembourgish speech synthesis project
Presentation of the SIP at VoxxedDays on 18 June 2026. Extract from a video recording.

In the absence of a Luxembourgish text-to-speech (TTS) system, the best solution to date has been to use a German synthesis system to read out Luxembourgish text: a makeshift solution which, used as a daily work tool, could lead to an additional cognitive load and, consequently, increased fatigue.

Lire à la volée le luxembourgeois (Dominique Nauroy , Alain Vagner)

Transcript

Bonjour et bienvenue. Merci d’être là. On se présente : Alain Vagner et Dominique Nauroy. On vous présente cet après-midi ce qui a été pour nous une petite aventure technique : la mise au point d’une voix luxembourgeoise qui était adaptée aux technologies d’assistance utilisées par les personnes en situation de handicap. Voilà pourquoi nous avons intitulé notre présentation « Lire à la volée le luxembourgeois : une innovation et un progrès pour l’accessibilité ». Petite question : y a-t-il des luxembourgophones dans la salle ? Oui ? OK, parfait, très bien : vous allez nous aider !

Avant d’aller plus loin, cette présentation, vous pouvez la retrouver en ligne à cette adresse ou en scannant ce QR Code. ET si ça a été trop vite, vous venez nous voir à la fin. On vous redonnera le lien.

Déjà on se présente en deux petits mots. On travaille depuis 2020 au sein du Service information et presse du gouvernement, et plus précisément au sein d’une division qui est très active sur l’accessibilité numérique. Vous pouvez nous retrouver sur les réseaux sociaux sous la dénomination « Accessibility Luxembourg ».

Nous pouvons résumer ainsi nos missions : 

  • On contrôle les sites et apps mobiles publics en fonction de leur accessibilité ;
  • On sensibilise : on donne pas mal de formations sur le sujet, on essaie de vulgariser le sujet par la publication d’articles sur notre portail de l’accessibilité numérique ;
  • On agit comme médiateur entre les utilisateurs qui rencontrent des problèmes, qui sont empêchés dans leur navigation, et les administrations

Donc, on a des profils qui mêlent un peu de développement, un peu d’expertise en accessibilité, un peu de pédagogie, un peu de sens de la communication. En revanche on n’est pas forcément des linguistes, et dans le projet qu’on va détailler maintenant, on a un peu appris sur le tas.

Pour celles et ceux qui ne savent pas ou qui ne n'ont pas une idée très précise de ce qu'est l'accessibilité numérique au quotidien, on vous la présente en deux mots parce que c'est quand même dans ce contexte qu'a démarré le projet. 

L'accessibilité numérique, c'est quoi ? C'est en fait une discipline qui vise à garantir à tous sans discrimination un même accès à l'information et aux services en ligne. Quelle que soit la nature du handicap des personnes et la façon dont chacun consulte l'information. Et donc un handicap peut être multiple, on peut très bien être aveugle, sourd, né avec un handicap physique ou cognitif. Et il existe différentes variantes ou combinaisons de ces de ces handicaps. On peut très bien être malvoyant ou daltonien, mais on peut aussi être aveugle et sourd en même temps. Ça c'est tout à fait envisageable. Et on aime bien cette la manière dont l'OMS définit le handicap. Pour eux, ce n'est pas uniquement une question de santé, c'est aussi un phénomène, une interaction entre les caractéristiques corporelles d'une personne et les caractéristiques de la société où elle vit. Donc grosso modo, ce qu'elle nous dit, c'est que ce n'est pas une question médicale uniquement, c'est une question de société. Donc la société, elle doit être adaptée aux personnes handicapées. C'est à elle aussi de se rapprocher.

Alors ce qui va nous intéresser plus spécifiquement dans cette présentation, c'est de savoir comment aujourd'hui les personnes aveugles notamment naviguent avec un smartphone ou avec un ordinateur desktop. Dans la plupart des cas, elles utilisent ce qu'on appelle un lecteur d'écran, un screen reader, qui va restituer le contenu qui est affiché sur l'écran, qui va le vocaliser, qui va dire la structure d'une page web par exemple et arriver à la zone de contenu, le paragraphe et va le lire. 

C'est ainsi que les personnes aveugles peuvent accéder à l'information et interagir sur des sites web. Ça fonctionne de la même manière pour des applications mobiles et il peut aussi y avoir une restitution via une plage braille pour les utilisateurs qui qui lisent le braille.

Quelques petits exemples de lecteurs d'écran, ça vous dira sans doute quelque chose. Sur macOS ou iOS vous en avez un qui est VoiceOver. Vous avez Talkback sur sur Android. Sur Windows, vous avez plusieurs solutions : NVDA qui est une solution open source gratuite, Narrator qui est le lecteur d'écran qui est proposé par défaut par Microsoft et JAWS qui est une solution payante assez populaire auprès des malvoyants et des personnes aveugles.

Alors cette restitution vocale qu'on a commencé à évoquer, il faut qu'elle soit immédiate en fait. Il faut qu'il n'y ait aucun temps de latence ou qu'il soit très faible. 

Pourquoi est-ce que c'est si important cette réactivité ? Et pourquoi même elle peut primer sur la sur la qualité audio ? Il faut imaginer que quand on est devant un écran et qu'on commence à cliquer quelque part, si à chaque fois on doit attendre 2 secondes entre le clic et la réception de de l'action, c'est très rapidement un calvaire. Il faut imaginer que si votre seul canal d'interaction c'est la voix et que vous devez attendre à chaque fois 2 secondes à chaque action, ça devient pénible. 

Donc voilà, la restitution vocale, comme je vous le dis, elle décrit le contenu et la structure d'une page, par exemple, les titres, les listes à point, dire s'il s'agit d'une image, un paragraphe et cetera. Et elle va décrire la fonction de chaque élément interactif. Elle va vous dire "Vous êtes dans tel champ de formulaire, il s'agit d'un bouton, il s'agit d'un lien et cetera." Et en plus de ça, elle doit fonctionner à très haute vitesse, à des vitesses où nous aurions vraiment les plus grandes difficultés à comprendre, mais ça permet aux personnes qui utilisent les lecteurs d'écran de scanner la page un petit peu comme nous on peut on peut on peut le faire. 

Et enfin et bien cette voix synthétique doit s'adapter à toutes les langues présentes dans un même document. Il est possible d'avoir régulièrement plusieurs langues sur une même page, surtout ici au Luxembourg et il faut systématiquement que la bonne voix soit utilisée pour chaque langue. Sinon, essayez de lire de l'anglais avec une prononciation française, ça sera compliqué. 

Et enfin cette voix doit fonctionner sans connexion à un serveur distant. C'est un critère qui est critique pour la vie privée.

Alors, maintenant qu'on a présenté le cadre, on vous présente quel a été le problème. Aujourd'hui, on n'a pas de véritable text to speech luxembourgeois. Jusqu'ici, la meilleure solution, ça a consisté à utiliser une synthèse allemande pour lire du luxembourgeois. Dans la plupart des cas, c'était OK, mais c'était quand même très loin d'être optimal.

Donc oui, c'est frustrant, ça peut être une perte de temps et puis surtout ça a un impact au quotidien. Si on travaille 8h par jour avec ça, bah ça peut être la cause d'une charge cognitive accrue et donc d'une fatigue accrue. C'est quand même plus agréable d'avoir une synthèse vocale dans sa propre langue.

Alors la situation jusqu'à cette année, à quoi ça ressemblait ? On a fait lire le même article par trois synthèses vocales et ça va être un petit peu à vous de nous dire laquelle vous semble le plus compréhensible. On va vous lire : c'est un article qui vient de RTL. On va vous lire à chaque fois le titre et l'accroche. Alors attention c'est parti.

Alors on vous montre maintenant qui est derrière chacune de ces voies. Le tout premier extrait, c'était la toute première synthèse luxembourgeoise et ils utilisaient eSpeak. C'était jusqu'ici la seule compatible avec les lecteurs d'écran, mais comme certains d'entre vous ont pu le déceler, la qualité de restitution n’était vraiment pas au niveau. La deuxième, c'est comme on vous l'a un petit peu dévoilé, c'est un TTS allemand sous macOS : un peu plus clair. Troisième extrait : c'est lu grâce à la synthèse vocale qui est développée par le centre pour la langue luxembourgeoise, le ZLS. Donc là, la qualité est nettement meilleure. C'est le moteur qui est aujourd'hui utilisé notamment pour la Sproochmaschinn. Seul bémol, dans notre cas d'usage, elle n’est pas adaptée aux lecteurs d'écrans. Et pourquoi ? Parce qu'elle ne répond pas à plusieurs critères essentiels, notamment la réactivité, l'absence de de latence ou la lecture à très haute vitesse. C'est quand même deux critères essentiels. Donc voilà la définition du problème dans lequel on a commencé à nager. 

Et pourquoi aussi ça s'apparente plutôt un défi ce projet ? Plusieurs questions : il fallait que ce soit interopérable avec la grande majorité des lecteurs d'écran qui existent aujourd'hui sur le marché. Or aujourd'hui, il n’y a pas de standard qui couvre tous les OS et les screen reader pour les synthèses vocales. Par exemple, sous Windows, vous avez un standard SAPI5 qui est largement supporté, mais après il convient de développer des intégrations spécifiques pour chaque lecteur d'écran et chaque OS. 

Autre point qui n'est qui n'est pas des plus légers, le luxembourgeois est considéré comme un low-resource language. Qu'est-ce que ça veut dire ? Ça veut dire que la langue compte un nombre relativement peu élevé de locuteurs comparé à d'autres langues et elle suscite de la même manière relativement peu d'intérêt des grands éditeurs américains. Voilà pourquoi aujourd'hui vous n’avez encore ni Microsoft ni Google et cetera qui ont développé une voix luxembourgeoise. 

Troisième point : le multilinguisme. On est dans un contexte multilingue ici au Grand-Duché. Or, on ne peut pas travailler en silo et produire uniquement une voix purement luxembourgeoise. La voix, elle doit être aussi capable de prononcer des mots de français, d'allemand sans que ce soit un souci. 

Et enfin, l'open source. Les grands acteurs du domaine, Microsoft, Nuance et cetera, produisent des voix mais leur code est majoritairement propriétaire. Donc, il y a quelques moteurs de voix comme eSpeak NG qui sont en open source. La qualité est très limitée. On a vu, c'était l'extrait numéro 1 qu'on a entendu tout à l'heure. La sortie est très peu naturelle. Pour nous, l'open source, c'est un critère majeur parce qu’il s'agit d'argent public et donc ça doit déboucher sur du code public.

Sur quoi cela a débouché ? Sur deux voix qu'on a appelé sobrement Mia et Mil. Voilà, c'est un petit peu les attendus du projet.

Alors, les résultats de la solution développée : on vous propose ici une petite démonstration des voix en utilisation sur une page web. Alors, je vous montre.

Moien. Mäin Numm ass Mil. Ech schwätzen Lëtzebuergesch.

Je parle aussi français. 

Ich kann auch ein bischen Deutsch.

I am the English voice, I am here to assist Mil for the English language.

Hallo, ech sinn d’Mia, ech sinn déi zweet Lëtzebuerger Stëmm vum “Screen Reader LB” Projet.

S04E06: Wéi ee Saumon an der Uelzecht

Heading level three.

An den 1950er gouf hei am Land de leschte Saumon gesinn. Fréier konnt een dëse Wanderfësch tonneweis an der Uelzecht fänken. Kéint e Retour vum Saumon geléngen, wa Lëtzebuerg seng waasserpolitesch Hausaufgaben erleedegt?

Den Transkript vun der Episod fannt Dir hei.

Blank.

Voilà. Donc là, on vous a montré deux extraits. Un sur une page web sur desktop, l'autre directement sur l'app, donc sur téléphone. Il s'agit de voies qui répondent au cahier des charges. Elles sont disponibles via une interface qui s'appelle RH Voice, qu'on va vous détailler dans les prochaines minutes. Et ce qui était intéressant pour nous, c'est qu'elles sont interopérables, disponibles sur cinq environnements : mobiles (iOS et Android) et des environnements desktop (macOS, Windows, Linux).

Alors qui s'est penché sur le berceau ? On n'a pas été seuls au Service information et presse à bosser dessus et sans les trois partenaires, il n’aurait pas davantage pu voir le jour. 

Donc je dirais le premier partenaire, le partenaire le plus important peut-être, ça a été le ZLS, qu'on a déjà évoqué. C'est quand même la référence pour tout ce qui touche à la langue luxembourgeoise. Il gère le LOD, c'est le dictionnaire en ligne, le Spellchecker et la Sproochmaschinn, qu'on a déjà évoquée. 

Par ailleurs, ce sont des champions de l'open data. Toutes leurs données sont disponibles sur le portal Open Data et ce sont parmi les plus réutilisées. Ils ont des données qui nous intéressent : notamment la phonétique de chaque mot – c'était vraiment essentiel – et aussi des enregistrements de chaque mot. 

D'un autre côté, le CDV, donc c'est le centre de développement des compétences liées à la vue. On ne fait pas un produit pour les aveugles sans les impliquer. Donc le CDV, c'est la référence au Luxembourg, ils sont régulièrement impliqués dans des projets d'innovation. 

Évidemment, on peut quand même citer le ministère de la Digitalisation qui a financé le projet. Sans argent, là aussi pas de projet. 

En résumé, le ZLS nous a fourni les données et l'expertise linguistique, ce qui nous a beaucoup aidé. Le CDV nous a fourni l'expertise accessibilité et usage ainsi surtout que le testing. On reviendra un petit peu après. 

Alors à l'issue de l'appel d'offre, c'est donc la solution RH Voice qu'on a retenue. Pourquoi est-ce qu'elle n’a pas de réel challenger ? 

D'abord, elle offre une bonne compatibilité avec les screen readers et les OS existants. Ils étaient en cours de finalisation de portage sur MacOS et iOS. Donc pour nous, c'était déjà un bon critère de choix. Elle est compatible, elle fonctionne avec des low power devices, c'est-à-dire qu'on n’a pas besoin d'un processeur spécifique IA ou d'un gros GPU avec plein de RAM pour qu'elle puisse fonctionner. C'est une solution open source.

Sa conceptrice, Olga Yakovleva, dispose d'une expérience reconnue dans le support des low-resource languages. Donc à ce jour, il y a 22 synthèses vocales qui ont été développées. Donc voilà, le Kirghiz, le Swana etc.

C'est à peu près tout ce que je voulais vous dire. Ah oui, mais en fait pourquoi est-ce que le luxembourgeois ça reste quand même un cas particulier ? Parce que même dans les langues qu'on peut citer, parmi lesquels on peut aussi citer le serbe, le roumain, le slovaque, le turkmène etc, même dans ces cas-là, le nombre de locuteurs est quand même beaucoup plus élevé que le luxembourgeois. Ça se compte en général en millions. 

Voilà, le but de de ce projet pour nous, c'était vraiment de permettre aux aveugles qui parlent cette langue d'avoir accès à une synthèse vocale de qualité, alors que la langue n'est pas supportée par les principaux OS du marché.

Qui a testé la solution ? On a eu deux groupes. Un groupe constitué de personnes voyantes avec des tests en situation réelle et des tests synthétiques. Alors, c'est quoi des tests en situation réelle ? On a en fait généré des sons pour des articles qui sont issus des principaux sites éditoriaux luxembourgeois, RTL, la radio 100.7 notamment. Donc il y a eu une écoute de ces enregistrements et une remontée des mots mal prononcés. Ça nous a déjà pas mal occupés. 

Et puis après : des tests synthétiques, c'est-à-dire qu'on a généré des échantillons de mots sur base de dictionnaires français et luxembourgeois, qui ont été intégrés à la voix. Mais là aussi, on a détecté des motifs de problèmes. Ensuite, évidemment, on a impliqué des personnes aveugles. Il y a eu des tests en situation réelle et une beta test publique qui a eu lieu au début de l'année pendant deux mois et on l'a conclue par l'organisation d'Install parties. Ça a été un nœud essentiel également parce qu'on s'est rendu compte que ça pouvait être une barrière essentielle à l'adoption d'une innovation. C'est-à-dire qu'on a essayé d'amener les gens à installer et configurer ces voix. C'est pas forcément évident comme on vous le disait en introduction. 

Jusqu'alors, ces personnes utilisaient un TTS allemand pour lire du luxembourgeois. Même si ce n'était pas optimal, elles s'étaient habituées à cette version dégradée et c'est, disons, la logique du changement c'est toujours quelque chose qu'il ne faut pas sous-estimer dans le développement d'une innovation.

Maintenant on va s'accrocher et on va ouvrir le capot pour rentrer vraiment dans le détail du projet et on va vous montrer comment est-ce que nous, non linguistes, on a quand même essayé de faire dialoguer technique et linguistique. 

Alors on commence par faire un petit pas de côté et on va vous rappeler les principales familles de synthèse vocale. Elles sont au nombre de trois. On a la concaténative, la paramétrique, la neuronale. 

Alors, grosso modo, la concaténative, elle fonctionne par assemblage d'extraits audio de voix enregistrées. Ça produit des voix assez naturelles parce qu'elles sont basées sur de vrais enregistrements, mais c'est très peu flexible et surtout c'est difficile d'ajuster le ton ou la vitesse. Or, comme je vous l'ai dit régulièrement, les utilisateurs de lecteur d'écran vont lire en x 2, x 3, x 4, parfois même x 5. Donc voilà, c'est une techno qui est ancienne. Les exemples de moteurs qui l'utilisent, Mbrola ou Festival par exemple, sont relativement gourmands en mémoire. 

Après, on a la paramétrique, qui génère de la parole à partir de modèles mathématiques. Alors, des modèles mathématiques formants ou statistiques. C'est plus flexible que les concaténatives parce que notamment on peut régler le débit ou l'intonation. Il y a un inconvénient, les voies sont un peu robotiques. Donc ce sont des voix qui sont les plus frugales en termes de puissance de calcul, de mémoire ou de stockage. Alors des exemples de moteurs open source : eSpeak ou la solution qu’on a choisie, RH Voice. Il y a une différence entre les deux. eSpeak se base sur les formants tandis que RH Voice sur un modèle statistique qu'on appelle le modèle de Markov caché. On y revient dans quelques minutes. RH Voice sonne donc un peu moins robotique.

Enfin neuronale. Les voix neuronales sont les plus naturelles. Le problème – toujours un inconvénient – c'est qu’elles vont demander beaucoup plus de puissance de calcul pour fonctionner et pour certaines, la présence d'un GPU est incontournable. Et enfin, la réactivité n’est pas forcément toujours optimale. Alors voilà, de notre point de vue, les derniers développements de l'IA ne nous aidaient pas forcément parce qu'au vu de nos contraintes, seule la famille paramétrique pouvait coller à nos besoins. C'est-à-dire que c'est la plus frugale, elle est flexible et elle permet de régler la vitesse et l'intonation. 

Alors, dernière question. Pourquoi est-ce qu'on n’a pas choisi la voie du deep learning ? On voulait quelque chose de vraiment peu gourmand qui fonctionne sur un Android de 10 ans par exemple, avec peu de RAM et qui soit super réactif. Donc on est parvenu à avoir ça avec une techno de génération N-1. Au niveau de la puissance CPU, il faut s'imaginer aussi que votre téléphone ou votre ordi, il exécute d'autres tâches que celle de restituer vocalement un contenu. Donc la voix ne doit jamais saccader. Voilà pourquoi cette famille paramétrique correspondait le mieux à nos besoins spécifiques.

Pour comprendre comment ça marche, on va étudier le processus qui convertit du texte en parole.

Alors, on peut démarrer par la source. Donc, on affiche un texte luxembourgeois dans une page web. Là, vous avez dans le navigateur Moien, mäin Numm ass Mil. Bonjour, mon nom est Mil. Le navigateur, lui, il a une représentation en mémoire que vous connaissez sans doute bien. C'est le DOM. Ce DOM, le document object model, est synchronisé avec une autre représentation en mémoire qu'on appelle l'accessibility tree. Cet arbre, il est indépendant de la techno et il va fonctionner aussi pour les applications, ce n'est pas uniquement pour du HTML. Et ça, c'est l'information qui va être lu par le lecteur d'écran. Le lecteur d'écran ne lit pas le HTML.

Alors, l'accessibility tree est lu par le lecteur d'écran. Ça, on l'a vu. Celui-ci, il va convertir l'information dans un format qui va être compréhensible par la voix, ici à un format qu'on appelle le SSML.

Donc, l'interaction entre le lecteur d'écran et le text to speech se fait via une API standardisée comme SAPI5 sous Windows par exemple. Alors le TTS, il n’a aucun contrôle sur la manière dont le texte est découpé. Par exemple en phrase ou en partie de phrase, voire même en caractères à épeler.

Le moteur de RH Voice convertit le texte en phonèmes, G2P. Alors on va voir dans une seconde ce qu’est un G2P. C'est un moteur qui convertit les graphèmes en phonèmes, qui sont écrits en sons. Et donc ensuite ces phonèmes sont envoyés au modèle statistique qui va convertir les phonèmes en sons. Donc ce qu'on voit en bas de l'écran, ça correspond en fait à la syntaxe RH Voice avec les phonèmes des voix luxembourgeoises. Voilà. 

Et là en fait Alain va vous expliquer plus en détails ce qui se passe entre l'étape une, donc ce qui est affiché à l'écran, et l'étape finale, ce qui est restitué par l'application.

Merci Dominique. Voilà. Donc ensuite on passe au modèle statistique. Donc c'est vraiment l'étape finale. Donc on a une représentation texte des phonèmes. Un phonème, c'est un son. Ça peut être un E, un O, un U ou un M par exemple. Tout ça ce sont des phonèmes. Ces phonèmes-là vont être convertis en son. Donc nous, ce qu'on a fait, c'est qu'on a pris du ZLS des enregistrements, donc, de mots. Donc dans le dictionnaire vous avez toujours un enregistrement de chaque mot. On a pris ça et on a pris la représentation phonétique. Et avec ça, on a entraîné un modèle. Enfin, en tout cas, notre prestataire a entraîné un modèle. Alors, nous, on dit que c'est une boîte noire. Pourquoi c'est une boîte noire ? Tout simplement parce que s'il y a un problème à un endroit dans le modèle, on ne peut pas le corriger, on est obligé de réentraîner. 

Je vous donne un exemple. On prononce mal un mot en particulier, je ne sais pas, le mot Moien. On a un problème à dire Moien. Le « ien », par exemple, la diphtongue « ien » dans le mot est mal prononcée, on ne va pas pouvoir la corriger. On va devoir faire d'autres enregistrements qui contiennent le son « ien » et on va renvoyer ça à l'entraînement, pour avoir une nouvelle version du modèle. 

Donc voilà, le modèle statistique paramétrique, il est basé sur une technologie qui s'appelle HTS.

C'est un projet open source qui se base sur les modèles de Markov cachés. Voilà, on ne va pas plus rentrer dans les détails. Nous, on n’a pas beaucoup travaillé sur cette partie-là. 

Mais l'étape d'avant, le grapheme to phoneme. Donc ça c'est une partie qui est intéressante. Qu'est-ce que c'est ? Donc c'est la partie qui va lire du texte et qui va convertir ça en phonèmes. Donc le phonème, c'est la représentation phonétique en fait de chaque mot. Ici vous avez donc le mot écrit « cat » en anglais, le chat en anglais. On va identifier les graphèmes. Donc ça peut être une lettre à chaque fois ou des groupes de lettres. Par exemple si vous avez chien en français le ch va être un phonème, un seul phonème : le son ch.

Donc, « cat », vous avez trois graphèmes et ces graphèmes sont ensuite convertis en phonèmes. Donc quels sont les trois sons, vous voulez, qui constituent le mot « cat » ? Le k, le a et le t à la fin. Voilà. Donc ça c'est le G2P. On va faire ça pour tout. Donc pour des mots, des phrases, des paragraphes de texte. 

On l'a implémenté sur base du langage FOMA. Alors, le langage FOMA, c'est un langage informatique et un compilateur qui est basé sur le principe des transducteurs.

Les transducteurs, ce sont des automates finis. Donc si vous avez des vieux souvenirs des études supérieures, les automates finis, ça va vous rappeler quelque chose, ils produisent une sortie à partir d'une entrée.

Je ne vais pas trop rentrer dans les détails de la théorie, mais nous on prend ces transducteurs et on va les appliquer au grapheme to phoneme. Enfin, on va prendre des graphèmes et on va les convertir en phonèmes.

Vous avez à cette adresse le code source de notre G2P

Donc toutes les règles en fait qui permettent de convertir du texte luxembourgeois en phonèmes luxembourgeois. Avec FOMA, on décrit toutes les règles. Et quelles sont les règles qui ont été décrites ?

Tout simplement déjà comment est-ce qu'on découpe une phrase en mots ? Comment est-ce qu'on découpe par phrases ? C'est quoi les caractères qui délimitent les phrases ? Comment est-ce qu'on prononce l'alphabet quand on épelle un mot ? Comment est-ce qu'on prononce les nombres ? Alors, des nombres petits, des nombres grands, des adresses, des codes postaux, tout ça, des numéros de téléphone.

On va gérer aussi ben un dictionnaire. Donc, on aura un ou plusieurs dictionnaires, on va voir ça avec la prononciation phonétique. Donc, quand on a la prononciation phonétique d'un mot, on sait parfaitement prononcer le mot, mais on va voir qu'il existe des mots dérivés. On ne gère pas forcément tous les cas. 

On a par exemple aussi les mots composés. Donc en luxembourgeois comme en allemand, c'est assez fréquent. On a des mots qui sont composés. Donc on a un préfixe et un suffixe qui sont collés entre eux. Et souvent dans le dictionnaire, on ne les a pas où on aura juste le suffixe ou voilà. Donc on va être obligé d'essayer de découper le mot pour détecter des préfixes et des suffixes. Voilà. Et après, on gère aussi d'autres cas comme les symboles, les emojis, l'intonation : comment est-ce qu'on fait ? Est-ce qu'on monte à la fin ? On descend à la fin de la phrase en fonction de si c'est une question ou pas, ou d'autres paramètres. Voilà. 

Concrètement, ça ressemble à quoi du code FOMA ? Alors, il faut s'imaginer un peu un système de regex avec une autre syntaxe. Je vais vous montrer ici un peu un exemple. J'ai pris trois mots de français avec leur phonétique. Donc vous avez ici à gauche le mot chat avec sa phonétique, le mot chien avec sa phonétique et le mot crocodile avec sa phonétique. Voilà. Et ce qu'on va faire, c'est décrire des règles qui vont pouvoir convertir ces mots-là et a priori que ces mots-là ou pas beaucoup de mots du même genre parce que mes règles ne sont pas assez grandes. Je n’ai pas assez de règles pour faire tous les mots de l'alphabet. Et bien entendu en plus en français et en luxembourgeois et dans d'autres mots, ce sont des langues qui ne sont pas régulières. Ça veut dire qu'il y a toujours des exceptions et c'est pour ça qu'on travaille avec des dictionnaires. Ça c'est plutôt le mode de fonctionnement quand on ne trouve pas un mot dans le dictionnaire, alors on va faire ça. On va essayer de prononcer avec des règles. Voilà. 

Donc qu'est-ce que je fais ici ? J'ai les lettres. Si j'ai les lettres CH, je vais dire que c'est le symbole. OK ? Ça c'est un opérateur de composition. Donc un peu comme dans d'autres langages, CSS ou autres, on peut composer des règles. Donc ça c'est un opérateur de composition qui dit "OK, si maintenant j'ai le caractère C tout seul, je vais le convertir dans le son K seulement s'il y a une condition qui est remplie et cette condition c'est : la lettre est suivie par A, O, U ou R." Voilà. 

Donc par exemple dans crocodile, on a le symbole C qui est suivi par la lettre R. Donc c'est converti en le phonème K. Voilà. 

Pareil le I il est transformé en J seulement s’il est précédé du son ch. Voilà.

Et à la fin ici vous avez la gestion des lettres muettes. Donc en français on a des

lettres qui ne se prononcent pas à la fin des mots. Donc par exemple le crocodile ici le e on ne va pas le prononcer. Le chat, le t à la fin, on ne le prononce pas non plus. Alors, cette règle-là, elle dit quoi ? Elle dit si on a un e, donc ça c'est la condition fin de mot, le caractère et il y a plus rien après, alors on renvoie zéro. Zéro, c'est rien. Voilà. Donc ça, ce sont des règles FOMA qui vont permettre de faire ces conversions-là. 

Donc c'est vraiment un exemple bidon pour vous montrer le principe. Bien entendu, on ne fonctionne pas comme ça. On va d'abord passer par un dictionnaire et au pire des cas, si on n’a trouvé le mot nulle part, on va appliquer des règles génériques comme ça pour prononcer quand même le mot. Voilà.

Notre processus en cascade, il a cinq étapes. On va déjà lire le dictionnaire de l'utilisateur. L'utilisateur peut définir son propre dictionnaire phonétique. Tout simplement, je ne sais pas, j'ai mon propre prénom ou mon propre nom qui est mal prononcé par la synthèse vocale. Je peux le corriger moi-même. Je crée mon user dictionary et dedans, je vais mettre mon nom, mon prénom, je ne sais pas l'entreprise où je travaille. Voilà, parce que ça risque d'arriver dans des mails et si c'est mal prononcé à chaque fois, ça va être pénible. Ensuite, on regarde dans le dictionnaire de luxembourgeois, dans un dictionnaire de français. On va regarder ensuite les mots composés. Donc, on a des listes de préfixes, des listes de suffixes. On va essayer de découper le mot pour voir si on retrouve sur des choses connues et on

recherche de nouveau dans les dictionnaires. Et enfin, en dernier recours, on a ces fameuses règles de prononciations génériques qui vont lire les mots et voilà, comme si vous et moi, on découvre un mot qu'on n'a jamais entendu, on va le prononcer d'une certaine manière. C'est ce qu'on va faire là. Voilà. 

Donc le G2P, on a cinq étapes pour le luxembourgeois mais seulement deux pour l'espagnol. Pourquoi ? Le luxembourgeois est une langue qui est beaucoup plus complexe. L'espagnol est une langue qui est plus transparente. Ça se lit un petit peu comme ça se prononce à part pour des mots d'origine étrangère, on va dire. Voilà. 

Donc ça c'est quelque chose qu'il faut savoir. Maintenant, on a quand même quelques limites avec notre approche, avec des dictionnaires etc.

Quelles sont ces limites ?

On a par exemple le fait qu’on peut avoir un même mot en luxembourgeois et en français. Donc là, on avait deux étapes avec deux dictionnaires. Bien entendu, si on trouve un mot dans le dictionnaire luxembourgeois, ça passe à la sortie, il est prononcé. Donc là, par exemple, les mots comme an si, alors je vais les dire en français peut-être an, si vu, ville sou, rose, ils existent aussi en luxembourgeois : an, si vu, ville sou, rose. Voilà. Donc on a ces mots qui existent dans les deux langues. Donc ce qui va se passer là, c'est que ces mots vont être prononcés à la luxembourgeoise. Donc si on a du texte en luxembourgeois, ensuite une phrase de français avec un de ces mots là-dedans, et bien on aura potentiellement une mauvaise prononciation. Nous, on a trouvé dans les tests que ce n’était pas si grave. On arrive à comprendre quand même ce que c'est. 

C'est autre chose aussi avec les text to speech de voir un petit peu où est-ce qu'on met la limite en fait dans la qualité de la sortie.

Donc quand on a travaillé là-dessus, on a travaillé avec des dictionnaires. Donc les dictionnaires, comme on l'a dit, on a fait beaucoup de testing pour voir si c'était prononcé correctement. On est parti du dictionnaire luxembourgeois LOD. Et dans ce dictionnaire luxembourgeois, il y a une limite, c'est qu'en fait vous n’avez de la phonétique que pour ce qu'on appelle la forme canonique, la forme normale d'un mot. Donc pour les adjectifs ou pour les verbes, vous n'avez pas les formes déclinées, les formes conjuguées, les variantes. Donc là-dessus, nous on a dû faire de l'inférence, on a inféré toutes les variantes possibles d'un verbe, toutes les conjugaisons, pareil pour toutes les autres formes de mots. 

Et donc en faisant ça, on a pu introduire des problèmes dans la phonétique et c'est ça qu'on a vérifié. Donc on a pris des échantillons, on les a écoutés comme le disait Dominique et on a corrigé ça.

Par ailleurs, on a aussi écouté en situation réelle des vrais articles sur RTL, sur 100.7, sur le site du gouvernement. Et en faisant ça, on a détecté qu’il y a plein de mots qui ne sont pas dans le dictionnaire tout simplement. Donc vous avez des mots pas dans le dictionnaire. Pourquoi ? Parce que ce sont des noms de marque, des noms de société, des noms de personnes, des prénoms, tous ces choses-là, ce sont des choses qu'on n’avait pas et qui étaient mal prononcées. Donc là-dessus, on a fait un peu des cycles dans lesquels on a fait des corrections, on les a testées, on les a réécoutées, recorrigées jusqu'à ce qu'on ait une version un peu améliorée.

Donc voilà sur la phonétique. Alors vous avez vu déjà quand j'ai écrit en phonétique avant, j'ai utilisé la notation API. Donc en anglais c'est IPA. Donc c'est l'alphabet international pour la phonétique, alphabet phonétique international API.

Mais je ne sais pas si vous avez vu les caractères, ils sont quand même un petit peu compliqués à taper au clavier. Donc là-dessus, on utilise en fait une autre forme qui s'appelle le Xampa. C'est une autre écriture qui fonctionne en ASCII 7 bit. Donc pour les plus vieux d'entre vous, c'est quelque chose qui est connu aussi je pense, pardon. Voilà.

C'est beaucoup plus facile, on peut le taper directement sur un clavier. Donc là par exemple vous avez quatre mots en français : chat, école et thinking, un mot d'anglais. Vous avez leur transcription en alphabet phonétique et là vous avez la transcription en XPA.

Donc on voit un peu des ressemblances mais voilà, c'est un alphabet aussi à apprendre. Vous savez que par exemple le T majuscule, ça va être le son en th anglais, comme dans thinking ; si vous avez un e minuscule, vous savez que c'est le é, le é ouvert et non un e. Euh voilà, donc il faut apprendre un petit peu cet alphabet-là pour être capable de saisir tous ces toutes ces transcriptions phonétiques. Ça, c'est quelque chose qui a été fait dans notre équipe. 

Au niveau du développement des dictionnaires : on a dans notre dictionnaire actuellement du lecteur d'écran de la voix luxembourgeoise, on a 68000 mots de luxembourgeois qui proviennent en grande partie du LOD, plus nos variantes. On a 244000 mots de français qui viennent d'un dictionnaire open source. Donc il y en a peut-être trop mais bon, on a tout pris. 

Et on a développé des vocabulaires spécifiques, par exemple des acronymes.

Quand on est au Luxembourg, quand on parle des pompiers, l'organisme c'est le CGDIS. On ne va pas dire CGDIS. Pour le CTIE, c'est CTIE, c'est pas CTIÉ, par exemple. Donc là, il y a tout un tas d'acronymes où il y a une prononciation spécifique.

Pareil pour les prénoms, les noms de famille. Alors, on a fait des prénoms typiques luxembourgeois, des prénoms français, des prénoms allemands, des prénoms portugais, espagnols, italiens. On a fait des listes, on les a inclus.

Pareil pour les noms de famille. On a essayé de faire des top 100. Top 100 des noms de famille, top 100 des sociétés, top 100 des noms de célébrité. On les a écoutés et à chaque fois qu'il y avait un problème, on a corrigé la phonétique.

Voilà, donc ça c'était un gros boulot. On a développé aussi notre propre clavier phonétique parce que ben le X-SAMPA, c'est bien beau, mais comment on fait pour se rappeler quelle est la lettre à utiliser pour faire le son E ou le son É ? Ce n’était pas évident. Donc voilà, on s'est fait notre propre outil pour taper plus rapidement les transcriptions phonétiques.

Des exemples de mots qu'on a corrigés, ici vous avez les deux premiers : eenzeger et nogelies. Ce sont des variantes de mots et là-dedans, notre logiciel, notre inférence avait créé des erreurs. Donc là-dessus, on a fait des corrections et le premier niveau, c'est de faire une correction phonétique et ensuite on voyait ça avec le prestataire pour généraliser.

Vous avez des mots de français aussi qui n’étaient pas bien prononcés. Voilà, on les a corrigés. des prénoms Jeannot, voilà, si on ne sait pas prononcer Jeannot, c'est quand même un peu dommage.

Le CePAS, voilà les fameux acronymes qui ont une prononciation spécifique qui ne sont pas lus de manière épelée C E P A S, mais CE-PASS. Des corrections comme ça, on en a fait plusieurs milliers, je dirais. 

Donc au niveau des challenges et des leçons, la première chose, c'est l'anglais. Donc on a en fait dans notre contexte quand on utilise un ordinateur par exemple, on a beaucoup de mots d'anglais, ces mots ne sont pas traduits. Donc la synthèse vocale, on ne va pas à chaque fois switcher. On doit être capable de parler aussi l'anglais correctement. Quand on a essayé de faire prendre en compte des mots d'anglais avec notre modèle statistique, les phonèmes qu'on avait réussi à entraîner n'étaient pas suffisants pour parler un anglais suffisamment bon. Surtout qu'en général les Luxembourgeois vont bien prononcer les mots d'anglais, pas comme les francophones. C'est-à-dire voilà, on va essayer de prononcer à l'anglaise les mots. Ce qu'on a fait c'est qu'on s'est dit : là, on ne va pas pouvoir réentraîner le modèle, refaire des enregistrements et cetera, c'est trop de travail pour notre projet. Donc on a choisi un switch automatique. C'est celui que vous avez entendu au début dans la vidéo. Donc il y a une détection automatique de langue parce qu'on ne peut pas toujours se baser sur le contenu pour savoir quelle est la langue d'un texte. 

Donc on a un switch automatique de langue dans le système. On a eu pas mal de travail aussi sur les symboles et les emojis.

Il faut savoir qu'il y a un projet qui s'appelle le CLDR, qui est un projet international et qui fournit des traductions en texte, des descriptions en texte de tous les emojis dans à peu près toutes les langues, y compris de luxembourgeois. Maintenant quand on a fait des tests, les gens qui ont testé ça ont trouvé les descriptions de certains emojis un peu trop verbeuses, un peu trop longues. Malheureusement, nous on a pris le parti de ne pas corriger. Pourquoi ? Tout simplement parce que le CLDR fait une mise à jour d'emoji par an et des emojis il y en a à peu près 6000 voire plus. Donc c'est quelque chose qui est énorme et qui est mis à jour constamment. Donc là-dessus nous on a pris le parti de garder la base du CLDR. 

Vous avez aussi les problèmes d'interopérabilité avec les lecteurs d'écran. On a trouvé essentiellement des bugs sur iOS. Donc il faut savoir que iOS, c'est le dernier système qui a permis l'ouverture à des synthèses vocales tierces partie, donc des synthèses vocales qu'on peut installer et il y a encore pas mal de bugs. 

Donc on est en contact avec Apple pour corriger certaines choses. Il y a des corrections qui vont arriver dans iOS 27.

Donc on a vu dans la première beta par exemple, ici vous avez un bug tout bête mais le symbole point est envoyé au text to speech sous le mot dot. Donc non traduit. En luxembourgeois, on dirait Punkt. Et là vous recevez dot. Nous on n'est pas capable de retraduire ça derrière. Donc on a dot. C'est prononcé dot. C'est à eux de corriger. 

Pareil, on n’a pas de contrôle sur les symboles et les emojis. On va voir que c'est le cas avec d'autres lecteurs d'écran, avec d'autres plateformes. On a des boutons qui sont lus en anglais parce que la langue luxembourgeoise n'est pas reconnue par le système. Elle n’existe pas officiellement dans le système. Ça va changer aussi avec iOS 27. Par exemple, on aura le clavier en luxembourgeois.

Et certains textes sont aussi envoyés au text to speech sans majuscule, ce qui peut créer des ambiguïtés entre des acronymes et des mots. Donc là-dessus, on a aussi des petits problèmes. Donc on essaie de voir avec eux ce qu'on peut faire.

On a aussi un autre problème qui est celui du switch de langue. Donc comme vous le savez peut-être en HTML, il est possible de spécifier la langue. Donc cet attribut langue, il est hyper important parce qu'il permet au lecteur d'écran de choisir automatiquement le text to speech qui va être utilisé pour lire le texte. Donc si vous mettez lang=LB, ça va être lu avec une langue luxembourgeoise. Si vous mettez lang=FR, ça va être lu en français avec une voix française. 

Le problème de ça, c'est que sur plusieurs OS, le switch auto n'est pas reconnu parce que la langue luxembourgeoise n'est pas reconnue, ça ne fonctionne pas. Sous Windows, on a un autre problème, c'est que le switch auto, il est limité à un moteur de text to speech. Donc là par exemple, RH Voice supporte le luxembourgeois mais ne supporte ni le français ni l'allemand. Donc vous n’avez pas de switch automatique. Donc là l'utilisateur peut switcher manuellement. 

On a aussi la logique de l'usage. Donc nous ce qu'on s'est dit c'est qu’au début, quand on a démarré le projet, on pensait que les gens allaient s'en servir pour lire des articles de presse sur internet, en luxembourgeois. En fait, c'est pas du tout ça. Les gens utilisent essentiellement la langue luxembourgeoise pour discuter, donc sur WhatsApp, par email etc. 

Et quel est l'impact ? L'impact, il est lié à l'orthographe. Nous, comme on se base essentiellement sur le dictionnaire, il faut écrire un luxembourgeois parfait si on veut une restitution parfaite. À partir du moment où il y a une faute d'orthographe, la prononciation sera moins bonne. Voilà. Donc là-dessus, c'est un truc à voir. Qu'est-ce qu'on fait ? Alors, est-ce qu'on peut essayer d'introduire des fautes d'orthographe dans le dictionnaire via, je ne sais pas, un algorithme ou autre pour gérer aussi ces cas-là ou voilà. Donc ça ce sont des choses à réfléchir.

La difficulté d'obtenir des feedbacks était aussi quelque chose qu'on a rencontré. Donc on a travaillé avec le CDV pour être en lien avec des personnes aveugles qui nous ont fait énormément de retour. C'était super. Et ensuite, on est passé au bêta test en se disant "On va ouvrir à tout le monde, n'importe qui va pouvoir installer et va nous faire des retours." On s'est rendu compte que ce n’était pas si simple. On est dans le cadre d'un processus d'adoption technologique. Qu'est-ce que ça veut dire ? Ça veut dire que les gens, ce n’est pas parce que vous mettez un logiciel en ligne qu'ils vont l'utiliser, tout simplement. 

Donc là-dessus, il fallait faire de la communication, de la gestion du changement, du support, aider les gens. Voilà, ils ont un problème, ils n’arrivent pas à installer. Qu'est-ce qu’ils doivent faire ? Voilà.

Le problème de la rétribution aussi des tests utilisateurs. Il y a des utilisateurs qui nous disent "Moi, je veux bien tester mais il faut payer." Voilà. Donc là, qu'est-ce qu'on fait ?

On ne l’avait pas prévu clairement. Donc ça c'est quelque chose aussi pour nos futurs projets, on pourra y réfléchir.

On a des utilisateurs satisfaits. Alors on vous a traduit la réponse en luxembourgeois ici. Donc les personnes trouvent les voix utiles, elles pensent l'utiliser régulièrement.

Elles voient aussi une amélioration par rapport à la voix allemande. Donc ça, on va quand même dans une bonne direction.

On a des retours positifs aussi sur les réseaux sociaux. On vous en a mis quelques-uns, des gens qui travaillent dans le sujet. Voilà, donc qui nous ont dit qu'ils étaient très intéressés.

Un tout petit peu hors sujet, il me reste encore un tout petit peu de temps. Vous avez ici en fait ce moteur RH Voice, c'est tellement léger, frugal qu'on a réussi à le compiler pour qu'il fonctionne dans une page web. On a utilisé le logiciel le compilateur EmScripten qui va prendre du code CC++ et qui va le convertir en ce qui s'appelle du web assembly. C'est un langage binaire quoi, comme un un jar en Java euh qui tourne directement dans le navigateur. Donc on arrive à avoir une fonctionnalité offline. On peut avoir une page web qui fonctionne ensuite sans accès réseau et qui est capable d'utiliser les voix.

Donc si vous voulez sans installer tester nos voix, vous pouvez juste aller là et puis faire quelques tests.

Voilà, c'était à peu près tout. Pour conclure, pour nous c'était, en tout cas pour notre petite équipe, on est quatre. C'était un projet ambitieux euh qui a débouché sur des résultats concrets avec deux voix : une voix masculine, une voix féminine qui fonctionnent en offline, en cross platform, open source qui sont réactives et qui fonctionnent à haute vitesse. Donc le cahier des charges est rempli.

Si vous voulez regarder tout ça un petit peu plus en détail, vous avez un article sur notre site qui vous donne tous les liens de téléchargement, comment est-ce que vous configurez ça

sur votre ordinateur et tout est open source. Donc les contributions sont les bienvenues. Donc si le langage FOMA ou la phonétique vous botte, n'hésitez pas. Voilà, c'est à peu près tout. 

Alors merci pour votre attention et je vais laisser la parole à Mil. Merci fir Är Opmierksamkeet. Merci pour votre attention. Ciao. Bye bye.

Merci beaucoup. On a peut-être le temps pour une ou deux questions s'il y en a. Oui.

Merci. Merci. Merci infiniment. En fait, c'est toujours agréable de votre rencontre. J'ai seulement une question par rapport à la liaison. Est-ce qu'il y la notion de liaison entre les mots ? Parce que j'ai l'impression que ça se base pour chaque mot mais s'il y a un mot qui entre mot, est-ce que c'est traité aussi ou pas ? 

Alors la liaison, on n’a pas eu à le gérer. En Luxembourgeois, la façon dont c'est écrit, on n’avait pas besoin de gérer la liaison. Si on implémentait par exemple une synthèse vocale française, il faudrait implémenter la règle de liaison, d'ailleurs qui est relativement complexe. Donc là nos lois nos voix quand elles lisent le français, elles le lisent malheureusement sans liaison. Mais étant donné que c'était une voix luxembourgeoise, le français c'est juste un backup. Voilà. 

Alors moi ma question c'est sur l'intégration. Je pensais bêtement que le TTS c'était juste un fichier à installer sur son OS. Je ne comprends pas trop quelle est la partie de l'OS, la partie RH Voice et la partie de votre travail à vous. 

D’accord, ça on peut vous expliquer en deux mots. Donc c'est-à-dire dans chaque OS le text to speech c'est un composant logiciel. Donc sous Windows, c'est un genre de DLL, c'est quelque chose comme ça qui va s'insérer dans le système, qui va être enregistré et ensuite le système a à disposition un ensemble de voix. Il peut énumérer les voix et il peut les activer en fonction de la langue dont il a besoin. Ensuite, vous avez le lecteur d'écran qui est aussi un composant de l'OS ou qui peut être un logiciel installé qui va se baser sur les voix disponibles du système. Et RH Voice, c'est ce qu'on appelle un moteur de text to speech. Donc il s'intègre avec le système, donc il va être compatible avec les différentes API de chacun des systèmes. Et derrière, il va avoir à la fois la partie G2P qu'on a vu là, les règles de synthèse des phonèmes statistiques pour être capable de générer la voix.

Dernière question.

Est-ce que vous avez tenu compte des différences régionales dans la prononciation du luxembourgeois parce que malheureusement il y en a.

C'est une très bonne question. On s'est basé uniquement sur les données fournies par le dictionnaire LOD qui est le luxembourgeois normalisé par eux. Donc malheureusement il n’y a pas les variantes mais vous nous donnez une idée pour une version 2. On cherchait un échantillon plus petit encore.

Merci beaucoup. Merci. Merci.

We were therefore keen to offer Luxembourgish voices that work on most platforms (Windows, macOS, iOS, Android), are open source and capable of operating offline, to safeguard users’ privacy.

High-quality data

But the real challenge of a Luxembourgish TTS system is that it is based on a ‘low-resource language’ – in other words, a language with relatively few speakers and fewer resources (such as texts available online) than French, English or German. This is where the ZLS and its LOD dictionary come into play; the data from this dictionary has been invaluable to us: each entry generally includes its phonetic transcription, an audio recording of the word’s pronunciation as well as its pronunciation within a sentence. Reusing this little treasure was a prerequisite for the project.

Another key player was the selected technical service provider, RHVoice, which has extensive experience with ‘low-resource languages’ and develops text-to-speech systems that are light on computing power – an essential criterion for ensuring output with very low latency as well as high speed, two qualities that are indispensable for TTS systems dedicated to accessibility.

Multilingualism presented another challenge: our voices had to be able to pronounce words in both French and German, which is by no means straightforward when two words are identical in Luxembourgish and French, such as: an, si, vu, ville, sou, rose.

Automatic language detection within a sentence allows, for example, the system to switch to an English voice once a certain threshold is reached. Besides, on a web page, the ‘lang’ attribute allows you to manually specify the language in which a sentence fragment is encoded, which theoretically ensures that the pronunciation is always understandable. However, on Windows this only works between languages supported by the text-to-speech engine, and on other operating systems, this switch does not work because the Luxembourgish language is not (yet) recognised.

Fine-tuning: we know where it all begins…

During the project, we gained some basic knowledge of linguistics, particularly to enhance the dictionary following the tests carried out at the CDV, which collected data from real-life situations. Based on this feedback, we converted the graphemes (written words) into phonemes in order to improve their voice synthesis. There were many different scenarios here: conjugated verbs (the LOD does not provide audio recordings for every conjugation); acronyms (C-G-DIS); surnames or company names, etc.

Furthermore, the project involved enabling different systems to communicate with one another, particularly between the TTS and the screen reader (JAWS, NVDA, VoiceOver or TalkBack). Here too, there were a few pitfalls: certain bugs in iOS, beyond our control, can be problematic (for example, the full stop is systematically read as ‘dot’ in English, despite the document or paragraph being in Luxembourgish). Another scenario: symbols and emojis are managed by an international organisation, the CLDR, and a specific interface needs to be established to propose corrections to certain Luxembourgish translations that we sometimes find convoluted.

Adoption and repurposing

We had originally thought that this TTS would help to render articles on web pages in Luxembourgish. However, its main use is primarily active, in discussions via email or WhatsApp. In these exchanges, spelling standards are lower, which has an impact on pronunciation.

Above all, simply releasing an innovation is not enough for people to adopt it straight away. We need to communicate, manage the change, help people install it and provide support. All of this takes time – more than we had anticipated.

The project spanned a year: a bit short for such clearly ambitious objectives and for our involvement in a project whose scale we hadn’t fully appreciated. Nevertheless, Mia and Mil are up and running, and have been very well received. They will continue to grow, and the SIP is proud to have brought them online. You too are invited to make them your own, starting by listening to them on this page.