Adding 'tracking' keyword.

Adding some blockers. I'm not adding the (dozens) of bugs requesting for errors/confirmation/other messages to be split, added or moved, which probably wouldn't even use a tracking bug as they're very separate issues and there's no need to address them together or consistently (besides, nobody would ever bother).

What's the exact difference of this tracking bug compared to bug 38638?
Specifying in the bug summary very welcome (verbs always welcome in a bug summary)

(In reply to Andre Klapper from comment #3)

What's the exact difference of this tracking bug compared to bug 38638?

Per comment 0 and comment 2, this is about system messages as a whole, while bug 38638 is about individual messages having issues. We could also say this is about what is not called the "messages API", in a way.

(Though in practice this tracking bug doesn't seem to really be used.)

happy.melon.wiki wrote:

(In reply to Andre Klapper from comment #3)

What's the exact difference of this tracking bug compared to bug 38638?
Specifying in the bug summary very welcome (verbs always welcome in a bug
summary)

I haven't seen bug 38638 before, but I'd say probably the most useful distinction to make would be to say that that bug is to track where the *content* of messages needs to be improved (be that by rewording, documenting, adding {{PLURAL:...}} or {{GENDER:...}} support, etc), while this bug tracks the way MW *uses* and *generates* messages. Eg bug 17148, which is essentially "sometimes MW sticks completely the wrong data into a message".

In T20521#225307, @Nemo_bis wrote:

(Though in practice this tracking bug doesn't seem to really be used.)

This 'tracking bug' feels so vague that I propose closing it. We don't need categorizing for the sake of categorizing if it helps basically nobody.