Thank you Gilles for your efforts!

@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).

In T181315#3788787, @ema wrote:

We've recently started logging requests taking longer than 60 seconds (from varnish's point of view) and sending the logs to logstash. Here are the logs relevant to load.php.

In T181315#3788779, @Peter wrote:

@Samat Just want to check, FF 57 is mentioned in the description but you got this before on older versions too (just want to make sure it isn't browser related)?

@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 performance-team@wikimedia.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 :)

Thank you for both of your comment!

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 :/

Proposed to Community-Wishlist-Survey-2017

Proposed to Community-Wishlist-Survey-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.

In T153011#3614643, @Trizek-WMF wrote:

Hi @Samat

Concerning your first point, do you use any gadgets or scripts? Have you tried to identify or bypass them?

In T176049#3614294, @Deskana wrote:

I am the product manager of the Editing team now.

@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.

@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?

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.

1. 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.
2. 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.
3. 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.

4. 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.

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"

I am in, too.

In T165872#3321172, @Halfak wrote:

Can you give me some example for good "fart" words in Hungarian?

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'?

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?

ok, thanks :)

@thiemowmde, thank you for your answer. I thought that Wikibase use the month names in English right now, but I was not correct: the names itself are good (for example "12 június 1990").

Can we use the BVDS on a wiki base? List of words per languages or something like that?

Background: word "ha" has the meaning "if" in Hungarian, and widely used in written texts.

Also the Hungarian date format (and name of the months in Hungarian) should be implemented. I think, the proposed patch covers this case, too. Is it correct?

I restored the file now.

I just tried to rename a user with few edits and worked fine: https://meta.wikimedia.org/wiki/Special:GlobalRenameProgress/Moja1868 , and in the last days there were some other successful renames, too: https://meta.wikimedia.org/wiki/Special:Log/gblrename

Dear Erik,

Most of... but not all.
I am really curious about the the answer for question 6 and I am still and patiently waiting for @ezachte on this.

I recorded the video into AVI format (default settings) with CamStudio 2.7.4 and converted to webm using Save as... function (built in converter) of VLC.

And this page on huwiki until (?action=purge) yesterday evening.
In this case only for logged out users, but earlier this happened for logged in users, too (reported by Tacsipacsi here).

Dear Erik,

The first and third form result the same rendered text, while at the second option the ban part will be unlinked.
Usually we used the 3rd form in wiki code: easier to write and it results simpler code.
If an article used the first form, bots (like AWB in the frame of general fixes) change to option 3.

Dear Erik,

Dear Erik,