Funnel view (as first module) of the statistical toolset is realized and available for huwiki:
Adding other wikis and/or configure different funnels is possible on request.
Dec 28 2020
Funnel view (as first module) of the statistical toolset is realized and available for huwiki:
Nov 29 2020
Use case: Wikiprojects, where there is a list of member on the main page, often with full signatures, but without the need for discussion (example).
Aug 10 2020
Thanks for fixing this issue.
Is there a way that the Discussions Tool will use the signature setting set up in the user preferences?
Jun 22 2020
Ok, thank you for your reply!
Jun 21 2020
Jun 10 2020
It would be nice to display multi-level OSM relations on wikipedia / wikivoyage. For example this hiking path: https://www.openstreetmap.org/relation/2110963 - note that this is a relation of relations, not a relation of ways. The wikidata element is here: https://www.wikidata.org/wiki/Q95735225. As far as I can see, the mapshapes template support only relations that have ways as members.
May 27 2020
May 25 2020
Re-opening this as hu.wiki's Reply tag is not currently linked. @Whatamidoing-WMF is reaching out to hu.wiki to have this corrected.
May 18 2020
(This is mostly for Peter:) I think that access to special characters should be prioritized because it's consistent with the 2030 Strategy and the movement values about inclusivity and accessibility. People may not have a keyboard that matches their language(s), or they may not be "tech-y" enough to know how to make their computer produce those characters.
Also, editors have been identifying this as something they need, whereas I don't think anyone's mentioned that they really need bold and italics. I think this should happen, and I think it should happen soon – maybe even before 2.0 is folded into the existing Beta Feature.
It is useful especially on discussion pages with larger traffic: it is very easy to find out the connection between a text on the page and the item in the page history. Many times it needs some time to find the right diff in the history if I would like to link a specific edit later (even if I know the time stamp: click on the history, next page, next page, not here, next page, looking up which one...). In case they are linked, I need only click on it, or right click + copy link location.
May 17 2020
I didn't forget, but I understood by reading other tickets that it will be implemented differently now, and we will come back to this topic in the future, maybe with different conception and content. I am planning to create the local page soon, but please let me know if this task should be prioritized.
Are these pages marked in anyway that would let us know they are archived?
There are various templates, but all of them use both __NOEDITSECTION__ and __NONEWSECTIONLINK__ to prevent thread editing by accident.
- 1. Are templates typically added to unsigned comments?
It is quite typical, yes. (In many cases with negative tone and comments, that why did not you signed. This makes me often sad especially in case of applied with newcomers. One reason I was waiting for the improvements for talk and discussion pages, is to avoid this behavior.)
- 2. If so, which unsigned templates are added?
https://hu.wikipedia.org/wiki/Sablon:Al%C3%A1%C3%ADratlan is the main template (or at least I use the most), but there are alternatives, like
- 3. What are the ways (e.g. en masse via script(s)/bot(s), manually, etc) in which these unsigned templates are added?
We do not use script/bot for it, so they are only manually inserted. (There are frequent requests for a singing bot, but nobody did it until now. I hope that MediaWiki will solve this issue globally and there will be no need of local bots on each project for this purpose.)
- 4. If unsigned templates are added en masse, what scripts and bots are used on your wiki?
They are added manually.
May 4 2020
May 2 2020
That will be part of our new discussion tool which we have started work on: https://www.mediawiki.org/wiki/Talk_pages_project/New_discussion
@PerfektesChaos: good example. The Hungarian Wikipedia uses the same practice.
And just to be sure, by saying, "I haven't seen any problem with it until now." are you saying you have not observed any issues so far?
May 1 2020
Another use case, when somebody should write text on a language which keyboard is not installed on the used computer. For example I write text sometimes in German, but I cannot type German special characters (ß, ä, Ä, „“). Or I sometimes use computers of my company, where there is only German keyboard installed on the PCs, and I cannot type the Hungarian special characters.
Apr 30 2020
The font (sans / serif / monospace) used in the editor depends on the user preference "Edit area font style".
Thank you for making the tool available on the community pages, that is great! I posted on huwiki.
Apr 29 2020
I like that the tool does not appear on pages with NEWSECTIONLINK where there is no discussion. I haven't seen any problem with it until now.
Apr 28 2020
@Demian thanks for the corrections :)
I would add, that part of the problem (too wide indentation) could be solved by https://en.wikipedia.org/wiki/Template:Outdent or similar, but that creates other problems (it is not clear which replies connected to each others).
Apr 26 2020
Same problem here (only with last two pages of the document):
Apr 25 2020
@Samat & @Dyolf77_WMF, what do you both think of the effectiveness of the approach above? I ask considering there seems to be a relatively small number of pages on ar.wiki and hu.wiki using NEWSECTIONLINK.
Apr 8 2020
@ppelberg I use the toolbar and some of these characters very often (several times on a day) both for articles and discussions, and also for non-wiki activities (such as emails or texts for my professional work etc.).
Apr 5 2020
I propose to change the task description from diacritical marks to special characters.
Apr 1 2020
A note on priority: considering our focus right now is making sure the Replying feature is appearing and working well on existing wikitext talk pages, it is not likely we will begin work on the task above in the next few months.
Mar 31 2020
After I found T245890, I think we could merge these two tickets into one, and keep the T245890 at the end: I like that solution more flexible than enable the tool generally in the Project (and/or in the Help) namespace.
Not all pages in the Project namespace are discussion pages. I would propose a magic word (like __NOTOC__ and others), which tells the software if it is a discussion type of page.
the new Replying feature , and DiscussionTools  as a whole, does not conflict with LiquidThreads or Flow in so far as they only work on existing, wikitext-based talk pages
Mar 30 2020
Just a question came into my mind: might be any conflict with the old LiquidThreads extension (or the remained pages of it)?
Feb 26 2020
Dec 17 2019
Dec 16 2019
I just wanted to report, that
Dec 15 2019
@elappen-WMF I tried it out and it worked well for me as well.
Dec 5 2019
I decompressed the files using Total Commander's own bzip2 plugin, without any problem.
The only issue I experienced, that in case of the multistream file, it cannot show the progress of the process, so I need to wait and believe it is working and will be ready...
Nov 14 2019
I checked the task, everything seems to be okay.
Some translations are missing, or not up to date concerning the interface, but that's not important since we always have to update the interface for the prototypes.
Nov 2 2019
@Trizek-WMF I believe, we finished all mandatory and optional tasks for this ticket. Could or should we do anything else to resolve it?
Is there any category that regroups all the help pages? Or some, even if not perfect?
Do you have any idea, why the Hungarian translation does not work here?
It is 100% translated, but the tool shows it is 51% ready, and the translated messages don't appear on the localized page.
(This is not a temporary issue, we finished the translation weeks ago.)
Nov 1 2019
Oct 23 2019
Oct 22 2019
Oct 16 2019
Oct 15 2019
Oct 14 2019
- There was a specific request during the community discussion, that we should not deploy a new feature where the interface is not yet translated.
- "only ask for the "optional" translations after all the non-optional things are complete" sounds reasonable for me.
@Samat, good job concerning the preparation of the features. Only a few elements are missing, and I need to know when you plan to finish it. It is to define a schedule for the deployments, since all interested wiki are finishing these initial steps at the same time.
Oct 6 2019
(I am following the topic very carefully, however, I don't think I can contribute anyhow now.)
Sep 3 2019
Is it in impossible, that discourse uses a user ID as a unique identifier, and our case it is the same as it is in the Wikimedia database? That would solve most of the the problems above (username and email address changes, non-uniqueness).
an error message would be displayed to the user, like: "There is already an account using this email address. If you want to use more than one account in $SITENAME, then you need to use unique email addresses for each Wikimedia account."
There is the possibility that the username exists but the email address has changed. What should we do in these situations?
Aug 31 2019
@Trizek-WMF we are very much aware of this task, and I wish to make it with top priority (I really believe this will be one of the most important parts of our project, and one of the most important tools to reach our goals), but right now we have less than two weeks to prepare a report for the WMF about the stage of the project, and we try to fulfill all other (docents of) promises (researches, statistics, surveys and interviews, events and their reports, etc.) before that deadline we made in the project application. I hope it will be satisfying for everybody, but it is a lot of work currently.
Aug 28 2019
Aug 14 2019
Aug 7 2019
Aug 5 2019
@Zache not really yet...
Aug 2 2019
Jul 30 2019
I can confirm the bug. One of the huwiki admins tested the function here:
Jul 15 2019
I started to prepare a page with a statistical analysis here (in Hungarian only, yet, but mainly with easy to understand figures):
I will fill up with the main conclusions in the following days (most of them are obvious from the graphs anyway).
Jun 25 2019
Jun 24 2019
I know that the numbers are recalculated, and small difference (few editors) would not be a surprise. But the old and new curves are around parallel with 5-10% difference. I believe that there is a methodological change behind this.
Jun 23 2019
Jun 12 2019
May 12 2019
I am currently working on T209224. I would recommend to wait until the analysis is ready, the community can evaluate the results and make the decision about the future settings.
Apr 11 2019
Dear Hsync7, thank you for your application and for expressing your interest in helping us out in the project.
I received your email as well, sorry that I have not answered until now.
Apr 10 2019
Mar 18 2019
Thank you for your explanation, apparently this is the case. :)
Mar 16 2019
I checked, and I have the </mediawiki> at the end as well.
I downloaded the same file for srwiki (srwiki-20190301-stub-meta-history.xml.gz), and I have the same problem with it, but not in the 41th, but in the 37th line, according to the error message.
I can manually extract the gz file, and the size of huwiki-20190301-stub-meta-history.xml is 9 435 661 537 bytes by me. But the tool accept only .gz files...
@Aklapper the size of huwiki-20190301-stub-meta-history.xml.gz file is 1 434 668 795 bytes. (The tool uses the .gz file, so I do not need to extract it before use.)
I had the same problem with huwiki-20190201-stub-meta-history.xml.gz, the size of the latter is 1 427 856 252 bytes.
Are these sizes are incorrect?
Jun 5 2018
@Tgr already set up the https protocol for the website: https://wikimedia.hu/
We already had a discussion that this should be default for the website, but we postponed it because we wanted to be sure that no service will be broken. Tgr knows the technical details better than me.