将本地化导航保留在 URL 中

编辑将 Contentful 条目筛选为某一种内容类型，选择源语言区域，搜索某个活动，并打开需要审查的页面。

检查完翻译后，他们点击返回，却发现回到了默认内容列表。

数据仍然存在，但工作上下文消失了。

导航状态是任务的一部分

本地化界面通常有多个维度：

• 项目
• 源语言区域和目标语言区域
• 内容类型
• 翻译状态
• 搜索查询
• 排序顺序
• 页面

这些值决定了编辑当前在处理哪项工作。把它们当作临时组件状态，会让工作流在导航、刷新和共享链接时变得脆弱。

URL 是保存可恢复导航状态的天然位置。

返回就应该是返回

编辑会在列表视图和详情视图之间反复切换。他们检查一个条目、审查一个请求、回到队列，然后打开下一个项目。

当筛选条件和分页信息存在于查询字符串中时，浏览器历史会保留这个循环。用户会回到同一段工作视图，而不是每次查看详情后都要重新构建它。

这不仅仅是便利。它还能降低审查者在丢失上下文后意外切换语言区域或批次的可能性。

可共享视图提升协作效率

带有稳定筛选条件的 URL 可以分享给队友：

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

接收者打开的是同一个操作视图，而不是根据书面说明去重建它。

支持和调试也会更快。链接可以保留相关的搜索和状态信息，同时页面中仍可提供技术标识符。

敏感数据不应放在 URL 中，但普通内容筛选正是查询参数最擅长处理的状态类型。

规范化查询参数

持久化 URL 需要纪律性。参数顺序不一致、空值、重复的默认值以及过期的页码，都会造成令人困惑的历史记录。

一个干净的实现应该：

1. 在服务器端验证查询值
2. 尽可能省略默认值
3. 当筛选条件变化时重置分页
4. 保留无关但有效的筛选条件
5. 对快速搜索变更使用 replace history，对明确的导航操作使用 push history

结果就是，一个 URL 能表示当前视图，而不会变成记录每次 UI 交互的只增不减日志。

保持共享控件同步

语言区域选择器会出现在内容列表、条目详情、翻译审查和批量处理界面中。每个控件都应从同一个导航模型中读取并写入。

如果一个选择器修改本地状态，而另一个更新路由，用户就会看到不一致的标签，并且请求可能会以错误的语言区域创建。

经过服务器验证的 URL 状态，为当前浏览上下文提供了一个清晰的单一数据源。

要点

当筛选条件定义了编辑眼前的工作时，它们就不是可随意丢弃的界面设置。

将语言区域、搜索、内容类型、状态和分页持久化到规范化 URL 中。返回导航会变得可靠，视图会变得可共享，而翻译工作也能在列表与详情之间的日常切换中得以保留。