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
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.
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.
Mar 18 2018
Feb 2 2018
Jan 6 2018
Nov 30 2017
Thank you Gilles for your efforts!
Nov 27 2017
@Tgr I think I experienced this on multiple connections, but I usually use my laptop to edit Wikipedia. The only other place where I edit sometimes is the PC at my working place, but normally I shouldn't do this, therefore doesn't happen often. During these few small edits I don't remember that the problem happened (which doesn't necessary mean that my laptop is the problem).
@Gilles 160 secs was an extreme example, but in the 10-60 second range it happens daily. I have several screenshots, but earlier I didn't know about the har file. I will try to record some other examples later. I use only Firefox, so I cannot say if it is the same for other browsers or not. (I could try it on Chrome maybe.)
Hmm: I received from Google the following message: "Message not delivered: 550 Address firstname.lastname@example.org does not exist"
@Gilles I emailed the file to this address. Thank you in advance!
I re-uploaded the .har file. I will give access to it as soon as I will know who should I share with :)
Nov 22 2017
Thank you for both of your comment!
Nov 21 2017
The behavior just happened again (loading time was around 20 sec). Then I started the Developer tools to record, what happens, and for the second try it loaded after 1,2 sec. I really don't know how can I record and report the problem to you :/
Nov 19 2017
Proposed to Community-Wishlist-Survey-2017
Proposed to Community-Wishlist-Survey-2017
Nov 18 2017
@Trizek-WMF sorry that I didn't show up since your last comment. I did some improvement from my side: removed a virus and more malwares from my computer (:S) , cleaned my registry and generally the whole OS, switched off some scripts and gadgets and updated to FF Quantom etc. Since then I still have problem time to time with the loading time (instead of 1-2 seconds it is 10-20 seconds), but I generally don't use safemode and switched on Developer tools to track my browsers activity, and if I reload the page after the problem with these settings or without, this problem doesn't occur again. I will try to find a way to catch the problem, but it is not easy.
I know this is not very useful now, but I wanted to respond to your ping.
Sep 19 2017
Sep 16 2017
@Aklapper actually no, he didn't. I assigned to James because he is the product manager of the VisualEditor team, and he will know who is the best person to be assigned to this task.
Sep 15 2017
@Catrope I wanted to create a new bug report, but this one is quite close what I wanted to report. Therefore I reopened the task.
Is it possible to implement an (probably optional) preview feature (ideally live, but a manually refreshed would be also helpful), which shows the preview of my text below or above the WikiText part?
Sep 10 2017
I am sorry, I wanted to close and merge the other way. I try to fix it.
After some days of testing, I am more sure that we should provide the "Preview" and "Show changes" buttons the same level where the Publish button is, instead of hiding them at the bottom of the publish popup.
- It is quite confusing. If somebody try to see the preview or what she/he changed, before he/she would like to publish the result, she/he doesn't want to click the Publish button. This happened with me at the first time.
- The workflow is quite complicate now. After I clicked the Publish button, I click on the Preview button, from there on the Resume editing, from there Publish again, then Show changes (this cycle happens several times), then Publish (and don't be surprised that there is no edit summary at the end). If I click on Publish changes, then there shouldn't be other function, then publishing the changes (with optional Edit summary and a Back button), because this is what can be naturally expected.
- I thought I can use the Visual editor for Preview for most of the cases, but
3/A Switching between WikiTextEditor and VisualEditor is very slow for larger pages, many time even stuck. (It was especially inconvenient when I presented a live demo about Wikipedia in front of a larger audience and I couldn't load the page for editing...)
3/B There are many pages outside the main namespace, where VisualEditor isn't activated, so this option doesn't work.
- As Mike mentioned at the beginning, usage of the preview button is higher than the publish button. It is not practical to force the user to click two times (and wait for the popup in between) instead of ones in such a case.
Aug 26 2017
Note: We can get similar result using the VisualEditor view and Preview. VisualEditor doesn't show 100% the final view, but at least similar.
In many cases it is enough, if we switch between VisualEditor and WikiTextEditor, and we don't need the preview button.
I am wondering what is the state of this task. Is there any progress?
I checked the date format in case of Hungarian language, and I saw, that there is a small change since May: There is a dot after the day, for example "12. november 1918"
Jun 29 2017
I am in, too.
Jun 6 2017
Oh thanks, I see :)
It is not clear for me from the code, that is this patch a general solution or works only for the word 'ha'?
May 22 2017
I must argue that it is actually more confusing to show partially localised "dd Mmm yyyy". Most users of the internet understand yyyy-mm-dd regardless of mother language and Wikidata users in particular are used to language fallback chains.
@thiemowmde : Imagine your software displays "2017Jahr5Monat22Tag" (which is the Chinese format string with German words substituted in). This is how users of non-"dd Mmm yyyy" languages currently feel when we use Wikidata. It's worse than defaulting to "2017-05-22" or even "May 22 2017".
May I suggest that we actually display "yyyy-mm-dd" until language-specific date formats are implemented?