User Details
- User Since
- Dec 17 2015, 11:46 AM (378 w, 5 d)
- Availability
- Available
- LDAP User
- Iniquity
- MediaWiki User
- Iniquity [ Global Accounts ]
Tue, Mar 14
Wed, Mar 1
I think you are right and we need to remove this link from the menu and move it to the first level of ULS. Smth like that:
Thu, Feb 23
Hello! Maybe you are right and I was just too surprised that some of the messages appeared in English. It's just that most of the sidebar used to be controlled MediaWiki:Sidebar including the headers. Therefore, the first thing I did was get into the MediaWiki:Sidebar, and only then did I start looking through &uselang=qqx. Just in one essentially the menu - two different behaviors. And it's not entirely clear, maybe you just need to get used to it. If you do not see this as a clear problem, then we can return to this later.
Mon, Feb 20
Feb 15 2023
Yes, for Russian we have the same problem:
On Polish Wikipedia we have tools like "Report a bug". This should be visible for all users. And should be easily accessible.
Feb 12 2023
Feb 7 2023
I think I come here with Russian Wikipedia soon.
Feb 5 2023
Feb 2 2023
I have one more question, does it bother you that this text ([hide]) repeats the text in navboxes and other collapsed blocks, but works in a completely different way? It stumped me, for example. Maybe change it to [collapse] or [unpin] or smth else?
Feb 1 2023
Jan 31 2023
I understood why it was added there - to explain the mechanics of adding pseudo-language templates that are not in ISO. For example: hangul, ipa, css, cyr etc. Not all userboxes are pseudo-languages and therefore not all of them should be included in the main block.
Wow, yes, of course it should be removed. Because these extensions are clearly not meant to be a regular userbox. I don't know why it was added, to be honest.
In fact, no, a separate template is created, in the subpages of which their css are published. Or can ask the admins to change the content model.
Yes, exactly creating a ton of separate templates is what results in a mess.
No, I'm not talking about that. You create one template, and create CSS on its substation. For example: https://test.wikipedia.org/wiki/Template:Userbox/iniquity.css
Lastest Chrome, Win 10.
These are not babylon templates, babylon templates only support language and pseudo-language templates. Everything else is regular userboxes that should not be inserted into the Babel.
Jan 30 2023
It shouldn't be manual, it should be semi-automatic: T228598. Moreover, all userboxes in almost all projects have a align setting. Babel creates userboxes. And the problem with the lack of such a setting for Babel userboxes at one time gave me problems.
I'm not sure that we need to support single template parameters, That's something scary. For personal design, you can always use TemplateStyles.
Jan 28 2023
Thanks! @Pppery, can you please check if this overlaps with your patches? :)
I really don't like that our descriptions are built on a CERF scale and don't match to ILR scale. They should be updated.
There is a problem here, to realize that you need a template, it can take a long time. And during this time, a huge number of categories will be created.
@Amire80, @Nikerabbit Hey! Do you think that a separate task is needed to fix work with languages in MediaWiki?
Yes, that's exactly what I'm talking about. Why wrong? If you tell the extension during installation that you need to create a certain template in order for the categories to start being created. I don't really see any other way.
Since the extension uses the ILR scale, it has an extended level, for example, 0+, 1+, 2+, 3+, 4+: https://en.wikipedia.org/wiki/ILR_scale. A complete system adaptation would be helpful.
I fixed it here: T178782. There are only languages with long names left (simple, be-tarask etc), but it seems to me that this is ok.
Given that categories can be renamed in the future, you need to focus on the English language or the Wikimedia Commons category in the element. That is, check when creating in all elements containing Q20010800, the text: User %code%. Or, in general, request separate qualifiers for elements in the wikidata: this will make it much easier to catch the desired element.
The problem still exists: https://en.wiktionary.org/wiki/Special:Contributions/Babel_AutoCreate
@Shizhao Hello! Can you please elaborate on the problem? Now it is not clear what it is.
Yes, as a minimal fix - it's great :) Thank you! And in the future, I thought that we could make a setting in Community Configuratuion: show/hide footer/header T328171.
Created a separate task on how this problem can be solved in the future: T328193.
It's extremely unsafe to let an automated bot overwrite the text of multiple categories.
There are actually two tasks here:
- Document or change how the header and footer are hidden. It's not really obvious, and a separate task is needed.
- Do not display or modify the block if categorization is disabled, all category settings are set to "false". It seems to me that this is a waste of too many resources for a small result (and I'm still not sure if it's the right thing to do).
Jan 27 2023
It looks like there is another setting wgBabelCategorizeNamespaces. I don't know how it works, not documented.
Jan 26 2023
It might be interesting to add the basic category ($wgBabelMainCategory and $wgBabelCategoryNames) settings that are currently in the config file to the community config: T323811.
Jan 25 2023
Jan 24 2023
I understand correctly that this task is not subtask and it is a duplicate of T165118? :)
Jan 17 2023
I think this is a good idea :) Can also make a setting that would show all mentees / only active mentees.