Keep Localization Navigation in the URL

An editor filters Contentful entries to one content type, chooses a source locale, searches for a campaign, and opens the page that needs review.

After checking the translation, they click back and find the default content list.

The data is still there. The work context is gone.

Navigation state is part of the task

Localization screens often have several dimensions:

• project
• source and target locale
• content type
• translation state
• search query
• sort order
• page

These values determine which work the editor is doing. Treating them as temporary component state makes the workflow fragile across navigation, refresh, and shared links.

The URL is the natural place for recoverable navigation state.

Back should mean back

Editors move repeatedly between list and detail views. They inspect an entry, review a request, return to the queue, and open the next item.

When filters and pagination live in the query string, browser history preserves that loop. The user returns to the same slice of work instead of rebuilding it after every detail view.

This is not only convenience. It reduces the chance that a reviewer switches locales or batches accidentally after losing context.

Shareable views improve coordination

A URL with stable filters can be shared with a teammate:

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

The recipient opens the same operational view instead of following written instructions to recreate it.

Support and debugging also become faster. A link can preserve the relevant search and status state while technical identifiers remain available in the page.

Sensitive data should not be placed in the URL, but ordinary content filters are exactly the kind of state query parameters handle well.

Canonicalize the query

Persistent URLs need discipline. Multiple parameter orders, empty values, duplicate defaults, and stale page numbers can create confusing history.

A clean implementation should:

1. validate query values on the server
2. omit defaults where possible
3. reset pagination when a filter changes
4. preserve unrelated valid filters
5. replace history for rapid search changes and push history for deliberate navigation

The result is a URL that represents the view without becoming an append-only record of every UI interaction.

Keep shared controls in sync

Locale selectors appear across content lists, entry detail, translation review, and batch screens. Each control should read from and write to the same navigation model.

If one selector changes local state while another updates the route, users see inconsistent labels and requests may be created with the wrong locale.

Server-validated URL state provides one clear source for the current browsing context.

The takeaway

Filters are not disposable interface settings when they define the work in front of an editor.

Persist locale, search, content type, status, and pagination in a canonical URL. Back navigation becomes reliable, views become shareable, and translation work survives the ordinary movement between lists and details.