Tue, Apr 24
Thanks @matmarex for dealing with this.
If you're referring to the discussion two of us had during recent daily meeting, then I was talking about how these highlights relate to section issue indicator, which is about to be introduced for T189488.
Proposed solution in the description of this ticket says: "Expand the "Add translation" placeholder 4px to align in size with the highlight areas next to it". @Pginer-WMF, did you change your mind about this? Or there is a regression in CX1? Not sure what's wrong here.
This is already pointed out in T190907#4110421. I advise to create new ticket for this, although it looks related to what was the scope of this ticket.
Mon, Apr 23
Thu, Apr 19
Wed, Apr 18
I cannot reproduce this on cx-testing and cx2-testing. @Etonkovidova, does this happen for all language pairs and any edit to target article title? I have tried opening some recommended articles for en->es and sr->en language pairs on cx-testing and cx2-testing. Changing target title works as expected and no errors are logged in console.
Tue, Apr 17
CAPTCHA system is implemented in ConfirmEdit extension and everything in my demo dialog from last comment is coming from that extension, including the messages ("CAPTCHA" message in dialog header and introductory text "To edit this page...") and the content of CAPTCHA (question, image, math equation...). So, the messages are defined in ConfirmEdit extension, but we're controlling what is used in dialog and we can introduce new messages for this use case.
That will also remove the dependency on UI messages which are coming from non-CX extension. You can specify entirely different introductory sentence if you want, but keep in mind that different types of CAPTCHA may require different introductory sentences. You have the list of CAPTCHA types on extension mediawiki page (on the end of this comment, there are messages for these different types). Or, we can try to come up with universal intro sentence.
Here is how CX1 handles QuestyCaptcha:
As you can see, problem from T161333 exists in LTR wikis as well.
Mon, Apr 16
Fri, Apr 13
Related comment - T111094#3586689.
Thu, Apr 12
There actually is a separate ticket for everything listed.
(1) When "[CX] Invalid target title" Console error is shown, there is no indication to a user that the title needs to be corrected. The article will be published with the previous valid title or defaults to the title of the article being translated.
I'm dealing with this in T191349, which is meant to restore what we have in CX1 - when user tries to publish with invalid target title, error is displayed. T190804 is set to indicate which characters are wrong and prohibit publishing if there are invalid characters in target title.
(2) Another case for error handling - when a user session is expired. The Publish icon remains active but no action can be performed:
This patch is restoring what we have in CX1. When user tries to publish with invalid target title, publishing fails and error message is shown. After T190804, publishing the page with invalid character in the title will be impossible.
Wed, Apr 11
This blinking no longer happens, but T156324 is still there.
In latest patch publish settings and section/sentence highlighting are disabled while publishing is in progress.
Another example from VE on enwiki beta.
I think patches linked to this ticket are the reason for these checkmarks on CX "New translation" dialog:
Tue, Apr 10
Fri, Apr 6
Thu, Apr 5
In case it wasn't clear from my above comment, once this ticket goes through QA for "Publish anyway" dialog, it should be moved back to "Priority backlog".
My assignment can be removed, so some other person becomes able to work on rest of the specs.
Wed, Apr 4
Errors are generally caught, but not processed properly. Some parts are set to improve after T162768.
There is one error which is easy to reproduce, just insert invalid character in target title. But, it's not handled yet, and reason I wrote "some parts" in above sentence. It will be handled separately, probably very soon.
Maybe it'd be good to add that as check item in the description.
Patch 424153 only shows the dialog when page with target title already exists, to allow user to publish anyway. Rest of the things this ticket specifies are going to be done separately, because we need more robust warnings and errors system in place.
This should probably be resolved in OOUI. By looking at the code, one can observe that .oo-ui-tagItemWidget is preventing wrapping and its only child, .oo-ui-labelElement-label, is trying to add ellipsis, but that fails.
Tue, Apr 3
In current state, error handling is poor, which is set to improve after T162768. Although not everything will be handled after that ticket is resolved, especially easiest way to cause fail message to be displayed, which is to use invalid characters in target title. When user types invalid character, that is recognized, but variable which stores target title isn't actually changed. That means when you try publishing after that, you will succeed. Some parts of invalid characters in target title are covered by T190804, but that doesn't cover publishing.
If publishing failed or warnings were shown, the publishing button will become enabled, allowing to try to publish again without the need for making further changes.
I think what is meant to be covered by this ticket is captured in first part of the sentence: enable the button when publish fails. Although, @Pginer-WMF maybe had different idea.
In cases like (2) when specific cause of errors is given, there is a little value in 'Publish' button become active immediately after the failure. A user should address the cause and then proceed with publishing.
There are some mocks showing future framework for displaying warnings and errors - T189488. More information should be provided about the specificity of errors and ideally "Fix this" button will resolve the issue, enabling user to publish without errors. It is up to @Pginer-WMF to decide whether publish button should be immediately enabled after failure, but it may be useful to quickly retry publishing. Some errors may be recoverable, and some may be unrecoverable, where publish button would probably be disabled.
In cases like (3) it might be beneficial to work on specifying the cause of error in the message.
Yes, displaying just the word "error" really look useless, and I hope we will dedicate time to improve that end of error handling as well. There is one ticket to explore common errors with abuse filters (T189475) and we should do the same for other errors, providing better info to the users about what went wrong.
@Pginer-WMF Should the above spec be part of this ticket? It has not been implemented.
Since T188733: CX2: Confirm translation was published successfully is only about publishing success, I filed T191349: No error messages for unsuccessful publishing with invalid target title.
Title of that bug is covered in T162768, but actual description mentions errors with invalid characters while publishing, which should be dealt with separately and your ticket can be used for that. So, title of the ticket may need to be changed.
I let @Etonkovidova to check remaining points in the description after QA process.