Un centre d’aide multilingue sans pages vides

Un projet Kookee pouvait avoir son centre d’aide en anglais et en allemand, et son portail hébergé affichait quand même toutes les pages en anglais. Les articles allemands existaient, et l’API les aurait renvoyés. Le portail ne les demandait jamais.

Le sélecteur de langue de l’en-tête du portail n’arrangeait rien. C’était le sélecteur d’interface de Kookee, avec les six langues dans lesquelles Kookee affiche ses boutons. Choisir Deutsch traduisait les menus et laissait tous les articles en anglais. Un projet rédigé en italien avait un sélecteur sans italien.

Je suis tombé sur le problème en déplaçant la bannière d’annonces du portail dans @kookee/react, et je l’ai corrigé dans la même version, Kookee 1.29.0.

Chaque langue a sa propre adresse

Un lecteur qui envoie la page allemande à un collègue a besoin d’une adresse allemande à lui envoyer. J’ai mis la langue dans le chemin, sauf pour la langue par défaut. Sur le portail de démo de Lumen, en anglais et en allemand, cela donne :

lumen.kookee.dev/help/getting-started/invite-your-team       anglais, la langue par défaut
lumen.kookee.dev/de/help/erste-schritte/dein-team-einladen   allemand
lumen.kookee.dev/en/help/getting-started/invite-your-team    → /help/getting-started/invite-your-team
lumen.kookee.dev/fr/help/getting-started/invite-your-team    → /help/getting-started/invite-your-team
lumen.kookee.dev/de/help/getting-started/invite-your-team    → /de/help/erste-schritte/dein-team-einladen

La langue par défaut n’a pas de segment parce que tous les liens de portail qui existaient avant désignaient la langue par défaut : liens dans des e-mails, dans d’anciens articles, dans les réponses MCP de Kookee et dans les payloads des webhooks. Ils continuent de fonctionner et de désigner la même chose, et Kookee les construit toujours ainsi.

Les redirections garantissent qu’une page n’a qu’une adresse. /en/ sur un projet dont la langue par défaut est l’anglais redirige vers l’adresse sans segment. De même pour une langue que le projet n’a pas, ou qu’il a retirée plus tard : un lien /fr/ partagé avant le retrait du français mène à la page anglaise au lieu d’une 404. Et un slug anglais sous /de/, l’adresse que vous obtenez en tapant /de devant un lien anglais, redirige vers le slug propre de l’article allemand.

Sans traduction, la langue par défaut prend le relais

Le centre d’aide de Lumen compte 12 articles en anglais. Trois d’entre eux, ceux de la catégorie Getting started, existent aussi en allemand. Un lecteur germanophone ouvre lumen.kookee.dev/de/help.

Le portail pourrait masquer les neuf autres. Le centre d’aide allemand aurait alors l’air complet : trois articles, tous en allemand. Le lecteur qui a besoin de l’article sur la facturation n’apprendrait jamais qu’il existe, et écrirait au support pour une question dont la réponse existait en anglais depuis le début.

Il pourrait les afficher avec une mention « pas encore traduit ». J’y ai pensé, puis j’ai renoncé : le lecteur voit bien que l’article est en anglais.

Ou il pourrait afficher l’article anglais à l’adresse allemande, sans mention, comme le faisaient déjà l’API de Kookee et le widget du site. C’est ce que fait désormais le portail. Les cartes de catégories sur /de/help affichent Erste Schritte, la version allemande de Getting started, à côté de Dashboards, Billing et Guides, qui n’existent qu’en anglais :

Un article qui n’existe qu’en anglais, ouvert depuis cette page, garde son adresse /de/ : le sélecteur indique toujours Deutsch, et le lien suivant que le lecteur ouvre reste sous /de/.

L’article lui-même porte lang="en" : un lecteur d’écran le lit avec une voix anglaise au lieu de prononcer des mots anglais selon les règles de l’allemand. Pour l’arabe et l’hébreu, il fixe aussi le sens de lecture de droite à gauche.

La même règle s’applique au reste du portail. Les listes du blog, du journal des modifications et des pages affichent la langue du lecteur quand une traduction existe, et la langue par défaut sinon. Les catégories d’aide sont mises en correspondance d’une langue à l’autre : un article non traduit s’ouvre dans la version allemande de sa catégorie. La recherche porte d’abord sur la langue de la page, puis sur la langue par défaut.

Pourquoi kookee.dev masque au contraire les articles non traduits

Mon propre blog fait l’inverse. kookee.dev/de/blog ne liste que les articles qui existent en allemand, et un lien allemand vers un article uniquement en anglais redirige vers la page anglaise.

La différence, ce sont les moteurs de recherche. kookee.dev est indexé, et un article anglais servi à une adresse allemande, c’est une deuxième URL pour le même texte. Je préfère donner à Google une seule adresse par texte. Les portails envoient X-Robots-Tag: noindex, les moteurs de recherche laissent donc leurs pages de côté, et pour les lecteurs, le repli sur la langue par défaut l’emporte.

Le sélecteur de langue ne propose que vos langues

Le sélecteur liste désormais les langues du projet, chacune sous son propre nom : Deutsch, Italiano, 日本語. En choisir une ouvre la même page dans cette langue : la traduction de l’article s’il y en a une, sinon le même article sous le nouveau segment.

Un projet avec une seule langue n’affiche aucun sélecteur. Les langues d’un projet se règlent dans Paramètres → Projet, sous Langues prises en charge, et le sélecteur apparaît dans l’en-tête, le menu mobile et le pied de page dès qu’il y en a deux.

J’ai complètement retiré des portails le sélecteur d’interface de Kookee. Un portail appartient au projet, et un lecteur qui y voit six langues s’attend à trouver les articles en six langues. Les boutons et les menus suivent toujours le dernier choix du lecteur ou son navigateur, à défaut l’anglais. Choisir une langue de contenu qui existe aussi dans l’interface de Kookee (anglais, russe, espagnol, français, portugais ou allemand) traduit les boutons du même coup. Choisir l’italien les laisse tels quels.

Il n’y a pas de redirection selon la langue du navigateur. Un lecteur dont le navigateur est réglé en allemand arrive sur lumen.kookee.dev/help et voit la page en anglais, avec le sélecteur dans l’en-tête.

Ce qui a changé d’autre sur le portail

• Le widget du site, sur le portail, affiche l’aide et les réponses dans la langue de la page. Il suivait auparavant la langue de l’interface, et pouvait donc afficher l’aide en allemand à côté d’une page anglaise.

• La bannière d’annonces affiche les annonces dans la langue de la page.

• La page d’accueil du portail compte un article et ses traductions une seule fois. Avant, elle comptait chaque langue séparément.

• Signaler cette page, sur une page traduite, rattache désormais le signalement à l’article. Avant, il retombait sur le projet.

Ce qui n’a pas changé : les tags du blog et hreflang

Le compteur d’un tag sur le blog du portail couvre toujours toutes les langues. Les portails n’ont ni liens hreflang ni sitemaps, puisque les moteurs de recherche ne les indexent pas.

Utiliser le portail public détaille les adresses, le sélecteur et les redirections du portail, et Contenu multilingue et langue de repli le même repli via le SDK, pour un centre d’aide sur votre propre site.

Pour aller plus loin

• Votre widget de support doit lire la langue de la page, pas celle du navigateur — comment le widget du site choisit une langue sur votre propre site, et pourquoi il fait confiance à la page plutôt qu’au navigateur.

• Comment créer un centre d’aide pour votre SaaS — structure, catégories et recherche, avant d’en traduire quoi que ce soit.

• Afficher le widget dans la langue de vos visiteurs — les options de langue du widget, de data-locale à setLocale().