The "most used" messages collection process could be improved. As far as I can see, the last time the measurement of the most common messages was done was in 2015. There were several adjustments since then by @Raymond and @Nemo_bis, but another thorough pass is needed.
In addition, these things should be done (this is just an initial list of ideas, and it may grow):
- Sort the messages in the same order in which they appear in the original messages files. This will make the translation process more convenient, because messages related to the same functionality will appear nearby. If it's too complicated to order automatically according to the original en.json, then at least do the following:
- Sort the months names in a logical sequence. Currently the months names are sprinkled all over the list. It would be more convenient for a translator to do them in sequence. What makes it even messier is the short and the declined ("genitive") names.
- Audit the current list and remove messages that are not actually used. As I'm writing the first version of this report, I found two (personaltools, jumpto), although removing them is not completely trivial; I'm reporting them as separate subtasks. I will likely find more (help is welcome).
- Consider avoiding some very technical messages, for example about transclusion. I actually had translators for new projects complaining about this—it's an unnecessarily hard blocker for creating new projects.
- Consider some new ways of finding the messages to include. It's good that dry counting of messages' use is data-driven, but it's a bit too data driven, and we may think of something more tailored for the task at hand, which is boot-strapping a new wiki. For example, the most used messages are required for new projects, but the measurement is done in existing major projects and don't necessarily include messages that are needed for ContentTranslation, Incubator, Wikidata, etc. This is a significant thing that deserves its own subtask.
- After re-creating the list, check that all the messages have correct and up-to-date qqq documentation. (Example problem: T190158.)