Conserver la navigation de localisation dans l’URL

Un éditeur filtre les entrées Contentful sur un seul type de contenu, choisit une langue source, recherche une campagne et ouvre la page qui doit être révisée.

Après avoir vérifié la traduction, il clique sur retour et retrouve la liste de contenu par défaut.

Les données sont toujours là. Le contexte de travail a disparu.

L’état de navigation fait partie de la tâche

Les écrans de localisation ont souvent plusieurs dimensions :

• projet
• langue source et langue cible
• type de contenu
• état de la traduction
• requête de recherche
• ordre de tri
• page

Ces valeurs déterminent le travail que l’éditeur est en train d’effectuer. Les traiter comme un état temporaire du composant rend le flux de travail fragile lors de la navigation, du rafraîchissement et du partage de liens.

L’URL est l’endroit naturel pour un état de navigation récupérable.

Retour doit vouloir dire retour

Les éditeurs passent sans cesse entre les vues liste et détail. Ils inspectent une entrée, révisent une demande, reviennent à la file d’attente, puis ouvrent l’élément suivant.

Lorsque les filtres et la pagination vivent dans la chaîne de requête, l’historique du navigateur préserve cette boucle. L’utilisateur revient à la même tranche de travail au lieu de la reconstruire après chaque vue de détail.

Ce n’est pas seulement une question de confort. Cela réduit le risque qu’un réviseur change de langue ou de lot par accident après avoir perdu le contexte.

Des vues partageables améliorent la coordination

Une URL avec des filtres stables peut être partagée avec un coéquipier :

?locale=fr&content_type=landingPage&state=failed

Le destinataire ouvre la même vue opérationnelle au lieu de suivre des instructions écrites pour la recréer.

Le support et le débogage deviennent aussi plus rapides. Un lien peut préserver l’état pertinent de recherche et de statut, tandis que les identifiants techniques restent disponibles sur la page.

Les données sensibles ne doivent pas être placées dans l’URL, mais les filtres de contenu ordinaires sont exactement le type d’état que les paramètres de requête gèrent bien.

Canonicaliser la requête

Les URL persistantes exigent de la rigueur. Des ordres de paramètres multiples, des valeurs vides, des valeurs par défaut dupliquées et des numéros de page obsolètes peuvent créer un historique déroutant.

Une implémentation propre devrait :

1. valider les valeurs de requête côté serveur
2. omettre les valeurs par défaut lorsque c’est possible
3. réinitialiser la pagination lorsqu’un filtre change
4. préserver les filtres valides sans rapport
5. remplacer l’historique lors de changements rapides de recherche et ajouter à l’historique lors d’une navigation délibérée

Le résultat est une URL qui représente la vue sans devenir un enregistrement cumulatif de chaque interaction de l’interface.

Garder les contrôles partagés synchronisés

Les sélecteurs de langue apparaissent dans les listes de contenu, le détail d’entrée, la révision de traduction et les écrans de lots. Chaque contrôle doit lire et écrire dans le même modèle de navigation.

Si un sélecteur modifie l’état local tandis qu’un autre met à jour la route, les utilisateurs voient des libellés incohérents et des demandes peuvent être créées avec la mauvaise langue.

Un état d’URL validé côté serveur fournit une source claire unique pour le contexte de navigation actuel.

À retenir

Les filtres ne sont pas de simples paramètres d’interface jetables lorsqu’ils définissent le travail devant l’éditeur.

Conservez la langue, la recherche, le type de contenu, le statut et la pagination dans une URL canonique. La navigation de retour devient fiable, les vues deviennent partageables et le travail de traduction survit aux déplacements ordinaires entre listes et détails.