As part of the work to support Custom translation suggestions (T113257), the selection of filters is reflected in the URL (T369012). This is convenient in contexts such as Wikiprojects and events, to direct participants to specific topic areas. However, the current processing of the URL is not accommodating for errors, and any mistake results in filters being broken.
When all parameters are properly set (example) the URL works as expected. Below some examples based on variations of the previous URL to consider:
| Case | Result | Notes |
|---|---|---|
| filter-type is correct, but filter-id is not a valid topic ("invented" is used but it could be a topic that usedd to be valid in the past and was removed from ORES or just a typo, for example) |  | Filter options not shown in UI, error message in JS console. |
| filter-type is correct, but filter-id is missing |  | Filter options not shown in UI, error message in JS console. |
| filter-id is provided, but filter-type is missing |  | Suggestions not loading, filter options not shown in UI, error message in JS console. |
This is problematic because the user gets a broken experience, and without the filtering UI they don't have a clear way to revert the issue.
Proposal
The following improvements are proposed:
- Ignore incorrect parameters. A badly constructed URL such as those in the examples, should lead to the translation dashboard with the default filtering (same as if the filter parameters were not present at all).
- When incorrect parameters are provided, a Mediawiki bubble notification will be shown to indicate the following: "Filters from the link are not valid. Check the options to filter the list of suggestions."
- The "For you" and "Popular" seem to have their own filter-type and filter-id parameters with the same value. We may want to consider "For you", "Popular", and similar to be filter-type "automatic", and consider it as a default type so that a URL with filter-id="previous-edits" and no value for filter-type would still lead to "Popular" topics.