Page MenuHomePhabricator

Allow nesting of AggregateMessageGroups in Special:LanguageStats via Special:AggregateGroups
Open, MediumPublic

Description

Special:LanguageStats is extremely cluttered on Meta-wiki and might become so on other wikis in the future. That page being slow and cluttered, turns unusable for translators (not to mention stats update problem as described in T160565)

Currently there is an aggregate group "Affiliates". And there are aggregate groups like "Wikimedia France", "Wikimedia Chile", "Wikimedia Russia" etc, which should become subgroups of the "Affiliates" parent group. Also all the "Grants:..." aggregate groups should go to a single parent "Grants" aggregate group.

"2015 Community Wishlist Survey" and "2016 Community Wishlist Survey" should go to "Community Wishlist Survey" parent group, and so on.

I think this will solve the cluttering problem, but it would be nice to make Special:AggregateGroups work faster, if it is possible at all.

I'm thinking of a system like on Translatewiki.net – the "MediaWiki" aggregate group has a subgroup of "MediaWiki extensions", which itself contains three more subgroups. But perhaps you might invent something even more convenient.

Event Timeline

Nemo_bis renamed this task from Enable subgroups on Special:LanguageStats to Allow to filter Special:LanguageStats by aggregate group.Mar 20 2017, 12:39 PM
Nemo_bis subscribed.
Nemo_bis renamed this task from Allow to filter Special:LanguageStats by aggregate group to Allow to filter Special:LanguageStats by aggregate group or list of groups.Mar 20 2017, 12:40 PM

@Piramidion Can you clarify what is requested here? It seems you are asking for the possibility of nesting aggregate groups [1], while @Nemo_bis 's change to the title is something different.

[1] This is already possible, but there is no wiki-side configuration for it.

Yes, I'm asking for the possibility of nesting. That would help to make Special:LanguageStats somewhat shorter in size (visually) on Meta-wiki, and would help to eliminate the clutter by clustering the related aggregate groups into larger parent groups.

Nikerabbit renamed this task from Allow to filter Special:LanguageStats by aggregate group or list of groups to Allow nesting of AggregateMessageGroups in Special:LanguageStats via Special:AggregateGroups.Mar 23 2017, 6:54 AM

I'm not sure in what way you expect nesting to reduce clutter, but if you think that the existing aggregate groups are too many/too small you can ask the translation admins to merge them.

TL;DR again or what? Because I don't think that my English is that bad for you to not understand what I write. Besides, I've been talking about working with Special:AggregateGroups and that it works extremely slow on Meta-wiki. How could I possibly know that without being a translation admin myself?

There's an affiliate – Maithili Wikimedians User Group which has a separate aggregate group for a reason: it contains 17 message groups with 674 messages in total. Do you suggest me to flood the "Affiliates" aggregate group with those? Or would it be better if the nesting of such groups was made possible, so that everyone searching for affiliates' message groups would find them all in the "Affiliates" aggregate group containing nicely clustered, not cluttered, message groups relating to relevant affiliates?

(I'll address off-topic comments on the user talk page.)

Or would it be better if the nesting of such groups was made possible

Of course as a category addict I like hierarchical trees, but that doesn't mean they're necessarily helpful or "better".

nicely clustered, not cluttered, message groups

The total amount of stuff would be the same, so I'm not sure "not cluttered" applies. It's not clear why making Special:LanguageStats "somewhat shorter" visually would help anything.

Do you suggest me to [add them to] the "Affiliates" aggregate group [...]?

That would depend on what the translators use most often. I suspect that translators interested in Maithili would like to see the message group listed immediately on Special:LanguageStats so that they can just scan the page (or ctrl-f) to see it. But it's also possible that nobody cares about those pages being in this or other group.

so that everyone searching for affiliates' message groups would find them all in the "Affiliates" aggregate group

I don't know who is "searching for affiliates' message groups". Do you know some such translators? I find it more likely that people searching for this specific group would get lost, since they would never be fully aware of the meaning of the hierarchical tree existing in the translation admins' mind. The nesting is quite good at confusing people even when the classification is rather clear, see e.g. T86004: Weirdly nested aggregate groups within "Extensions used by Wikimedia".

Since nesting is already technically available for other groups, I see no reason not to make available for these groups as well. It isn't really necessary to spend time discussing what kind of structure makes or doesn't make sense, that's something for the users of this feature to decide.

It is true that it would not make the page faster, but that is not what is being asked here.

I don't know who is "searching for affiliates' message groups". Do you know some such translators?

You got me wrong. I meant that the "Affiliates" aggregate group should contain the message groups for all the affiliates, not just some of them (while the others are kept outside as if they're special or smth). Being one of "such translators", when I open the "Affiliates" aggregate group, I expect to find there all the affiliate related message groups, including the one for Maithili Wikimedians User Group, because this is simply obvious.

The fact that you use terms such as "simply obvious" suggests that you're mostly thinking about your own personal workflow, knowledge and ideas, disregarding other translators. Most people I know who are interested in chapters etc. don't even know that they're now called "affiliates". Most people I point to Special:Translate don't even know that nested groups are a thing and that they need to click somewhere to expand.

Obvious is obvious. Your examples are irrelevant.

Obvious is obvious

By the recurse to apodictic statements I consider you forfeit reasoning. Hence it's proven that nested groups are not generally positive. Thanks.

Nemo_bis triaged this task as Lowest priority.Mar 27 2017, 9:30 AM

By the recurse to apodictic statements I consider you forfeit reasoning. Hence it's proven that nested groups are not generally positive. Thanks.

And you call my requests "opinionated"? There's been enough reasoning from my side. The sole problem is that YOU don't understand it. And now you use your advanced rights to gain an advantage to make your personal opinion prevail. Very nice.

@Nikerabbit, can I request @Nemo_bis to be banned from deciding on the tasks I create? There's a long-lasting conflict between us, and I consider that he makes a bad use of his 'powers' just to harm me.

Aklapper raised the priority of this task from Lowest to Needs Triage.Mar 27 2017, 10:50 AM

Nested groups exist already, so it is a reasonable request to allow using them (that's why I reopened the task). Whatever happens here won't resolve this issue until someone comes and actually makes a patch (that's why I discouraged further discussion in my previous comment).

I have marked my own interest on potentially trying to solve this whenever I might have time by adding the User-Nikerabbit tag.

Thank you all. I'll remain silent from now on.