Before we deep-dive into developing the ContentTranslation-TranslationList, we need to decide how will it actually be stored.
Generally, the more it is integrated into the usual way in which MediaWiki works, the better. An important requirement is that it works globally, as most things in CX do. Preferably it should add as few new data structures as possible, and should be editable not only through the CX UI, but through other means—editing a wiki page, editing a category, editing Wikidata, using an API, etc.
If we can simply reuse existing MediaWiki features for storing the actual list, it will be perfect. Here are some possibilities:
- A list of links on a wiki page. T132913 suggests something like this, but it would be even better if the page was not imported into a task list, but fully synchronized with it: when a link is added to the wiki page, the task lists immediately has it. This will allow advanced users to edit the list quickly and easily, and will make it possible to seamlessly reuse existing lists, such as the famous https://meta.wikimedia.org/wiki/List_of_articles_every_Wikipedia_should_have .
- Category. Similarly to the above item, T132912 suggests importing a category, and in fact we can already do this by running a script on the server. But it would be better if the translation task list would be fully synchronized with the category—when a page is added to a category, it appears in the task list. Some issues with this:
- If the category is fully synchronized, then task list probably cannot be edited through the CX UI, but only by adding articles to categories and removing them.
- Another issue is that categories are specific to one project, and while in practice it is often useful to translate a whole category from English, for example, it may not always be great to focus too much on a particular source language.
- Wikidata query. This is T115869. It might be more complicated than the above two points, but it better satisfies the multilingual nature of the project.
- Another Wikidata-based strategy would be simply listing Q numbers instead of synchronizing with a query. This is T112769.
With all the above strategies there is an issue of tracking the progress—can progress be tracked if the list itself changes over time?