Maintenir un livret d’accueil multilingue, disponible hors ligne et réellement à jour

Définir une source unique avant de traduire

Chaque rubrique possède une version source, un responsable, une date et un statut. La traduction référence cette version. Si la source change, la langue concernée passe en révision au lieu de continuer à afficher silencieusement une consigne ancienne.

Les champs structurés — adresse, heures, numéros, modèle d’équipement — sont séparés du texte lorsque cela évite les divergences. Leur modification déclenche néanmoins une revue du contexte : une heure de départ peut apparaître dans la page d’accueil, la checklist et la version imprimable.

Les contenus réservés à un séjour ne sont pas copiés dans la base éditoriale publique. Une traduction de code, de nom ou d’identifiant est interdite ; les secrets restent hors du corpus et des outils de traduction.

Prioriser les traductions selon le risque et l’usage

L’ordre de traduction commence par urgence, accès, sécurité, contact, équipements essentiels et départ. Les recommandations touristiques et contenus d’ambiance viennent ensuite. Si l’équipe ne peut pas maintenir une langue complète, elle publie un périmètre explicitement limité et un canal d’aide plutôt qu’une navigation qui bascule sans prévenir vers une consigne non comprise.

Une traduction automatique peut préparer un brouillon. Les expressions de sécurité, unités, heures, négations et instructions séquentielles demandent une relecture humaine. Le relecteur vérifie le sens dans le contexte réel, pas seulement la grammaire.

La langue principale du document et les changements ponctuels sont déclarés pour la synthèse vocale. Les liens, textes alternatifs, titres de formulaire et messages d’erreur sont traduits avec le contenu visible.

• Urgence et sécurité relues en premier.
• Adresse, heures et numéros copiés sans transformation.
• Unités et formats de date rendus sans ambiguïté.
• Navigation, erreurs et alternatives traduites.
• Nom et date du statut de relecture conservés.
• Langue suspendue si une modification critique n’est pas révisée.

Concevoir un hors-ligne utile plutôt qu’une copie indiscriminée

Le hors-ligne priorise l’adresse, le contact, les urgences, l’accès non sensible, le départ et quelques consignes d’équipement. Une version imprimable fournit un repli simple. Les horaires, événements et recommandations à forte volatilité affichent leur date et peuvent exiger une connexion avant d’être présentés comme actuels.

Un service worker met en cache un shell et des ressources publiques versionnées. Il ne place pas par défaut codes, références de réservation ou réponses personnalisées dans un cache partagé. Le nom du cache inclut une version, l’activation remplace l’ensemble de manière cohérente et les anciennes versions sont retirées après bascule réussie.

Le quota est borné. Les images lourdes restent facultatives ; les textes essentiels et icônes utiles sont prioritaires. Une politique LRU peut retirer les ressources les moins récentes, mais ne doit pas supprimer la page d’urgence tout en conservant une galerie décorative.

Tester le cycle complet en ligne, hors ligne puis de nouveau en ligne

Le test charge le livret, ferme l’onglet ou l’application, coupe le réseau, rouvre les pages essentielles puis rétablit la connexion. Il vérifie que la date de synchronisation est perceptible et qu’une nouvelle version remplace l’ancienne sans mélanger navigation récente et consigne périmée.

Un échec hors ligne ne doit pas produire une page blanche. Le repli explique ce qui reste disponible, fournit les contacts enregistrés et distingue clairement une information mémorisée d’une donnée actuelle. Il ne fabrique jamais un horaire ou un état.

Sur appareil partagé, la déconnexion ou l’expiration retire les ressources réservées. L’absence de réseau ne doit pas permettre de contourner une autorisation expirée.

1. Installer ou enregistrer explicitement la version validée.
2. Fermer complètement la surface de lecture.
3. Couper le réseau et rouvrir les pages essentielles.
4. Vérifier textes, liens internes, médias nécessaires et date locale.
5. Rétablir le réseau et publier une révision contrôlée.
6. Confirmer l’activation atomique et le retrait de l’ancien cache.
7. Vérifier qu’aucune donnée réservée ne persiste sur un profil non autorisé.

Gérer les informations qui expirent

Chaque donnée changeante porte une période de validité ou une prochaine révision. Avant l’échéance, le responsable reçoit une tâche. Après l’échéance, la page retire la valeur ou l’étiquette comme non confirmée ; elle ne la recycle pas dans une autre langue pour éviter un trou.

Les horaires de transport, programmes d’événement, tarifs et disponibilités proviennent de la source compétente. Un petit manifeste courant peut avoir une durée courte et pointer vers des ressources versionnées plus durables. ETag et If-None-Match évitent de retélécharger un artefact inchangé sans figer une donnée vivante.

La publication reste humaine : une détection de changement ouvre une file de révision, mais ne remplace pas automatiquement un texte visible. Une correction conserve la source, la décision et le rollback.

Traiter une correction sans créer de doublon

Le signalement identifie la page, la langue, le passage et la source proposée. Il ne demande pas de transmettre un code ou le contenu d’un séjour. Une erreur critique d’accès ou de sécurité entraîne la suspension de la consigne avant la traduction complète.

La correction modifie la page canonique et sa date. Les versions linguistiques concernées passent dans la file de revue. Une ancienne traduction reste disponible seulement comme rollback technique non indexable, pas comme seconde page concurrente.

Le lecteur voit la date de révision et un canal de correction. Le journal public résume les changements importants sans exposer l’identité du voyageur ou le détail d’un incident.

Checklist de maintenance

• Version source, langues dérivées et responsables identifiés.
• Urgence, accès, équipements essentiels et départ entièrement traduits.
• Relecture humaine des consignes critiques et des unités.
• Date de synchronisation et fraîcheur visibles.
• Cache réservé aux ressources autorisées et versionnées.
• Test fermeture, hors ligne, retour en ligne et activation atomique réalisé.
• Péremption des données vivantes gérée sans valeur inventée.
• Correction, retrait, rollback et suppression des anciens caches documentés.

Limites

Le hors-ligne dépend du navigateur, du système, de l’espace disponible et des réglages de l’appareil. Il doit être vérifié sur les environnements annoncés ; une PWA installable ne garantit pas à elle seule la disponibilité de chaque page.

Une traduction relue peut devenir fausse si la source change. Une date visible et une gouvernance réduisent ce risque sans l’annuler. Pour une urgence ou une consigne propre au bâtiment, l’émetteur reste responsable de fournir une information actuelle et un canal humain adapté.