Houd localisatienavigatie in de URL

Een redacteur filtert Contentful-items op één contenttype, kiest een brontaal, zoekt naar een campagne en opent de pagina die review nodig heeft.

Na het controleren van de vertaling klikken ze op terug en zien ze de standaard contentlijst.

De gegevens zijn er nog steeds. De werkcontext is weg.

Navigatiestatus maakt deel uit van de taak

Lokalisatieschermen hebben vaak meerdere dimensies:

• project
• bron- en doellocale
• contenttype
• vertaalstatus
• zoekopdracht
• sorteervolgorde
• pagina

Deze waarden bepalen aan welk werk de redacteur bezig is. Als je ze behandelt als tijdelijke componentstatus, wordt de workflow kwetsbaar bij navigatie, verversen en gedeelde links.

De URL is de natuurlijke plek voor herstelbare navigatiestatus.

Terug moet ook echt terug betekenen

Redacteuren bewegen herhaaldelijk tussen lijst- en detailweergaven. Ze bekijken een item, reviewen een verzoek, keren terug naar de wachtrij en openen het volgende item.

Wanneer filters en paginering in de querystring staan, bewaart de browsergeschiedenis die lus. De gebruiker keert terug naar hetzelfde deel van het werk in plaats van het na elke detailweergave opnieuw op te bouwen.

Dit is niet alleen gemak. Het verkleint de kans dat een reviewer per ongeluk van locale of batch wisselt na het verliezen van de context.

Deelbare weergaven verbeteren de samenwerking

Een URL met stabiele filters kan worden gedeeld met een teamgenoot:

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

De ontvanger opent dezelfde operationele weergave in plaats van geschreven instructies te volgen om die opnieuw te maken.

Ook support en debuggen worden sneller. Een link kan de relevante zoek- en statuscontext behouden terwijl technische identificatoren beschikbaar blijven op de pagina.

Gevoelige gegevens horen niet in de URL, maar gewone contentfilters zijn precies het soort status waar queryparameters goed mee omgaan.

Maak de query canoniek

Permanente URL's vereisen discipline. Meerdere parametervolgordes, lege waarden, dubbele standaardwaarden en verouderde paginanummers kunnen een verwarrende geschiedenis opleveren.

Een nette implementatie moet:

1. querywaarden op de server valideren
2. standaardwaarden weglaten waar mogelijk
3. paginering resetten wanneer een filter verandert
4. niet-gerelateerde geldige filters behouden
5. geschiedenis vervangen bij snelle zoekwijzigingen en geschiedenis pushen bij doelbewuste navigatie

Het resultaat is een URL die de weergave vertegenwoordigt zonder een append-only verslag van elke UI-interactie te worden.

Houd gedeelde bedieningselementen gesynchroniseerd

Localeselectors verschijnen in contentlijsten, itemdetails, vertaalreview en batchschermen. Elk bedieningselement moet lezen uit en schrijven naar hetzelfde navigatiemodel.

Als de ene selector lokale status verandert terwijl een andere de route bijwerkt, zien gebruikers inconsistente labels en kunnen verzoeken met de verkeerde locale worden aangemaakt.

Door de server gevalideerde URL-status biedt één duidelijke bron voor de huidige browsecontext.

De kern

Filters zijn geen wegwerpinterface-instellingen wanneer ze het werk bepalen dat voor een redacteur ligt.

Bewaar locale, zoeken, contenttype, status en paginering in een canonieke URL. Terugnavigatie wordt betrouwbaar, weergaven worden deelbaar en vertaalwerk overleeft de gewone beweging tussen lijsten en details.