The fix that I'm talking about has not reached production yet. Given the current status, earliest time the fix will reach production is late next week.
Sat, Jun 22
Fri, Jun 21
Thu, Jun 20
Currently, configuration works so that user needs to be member of all groups listed. If we add "sysop", basically no one would be able to publish on enwiki, since it will require user to be part of both "extendedconfirmed" and "sysop" groups, which I suspect no one is.
Are you a sysop on enwiki? According to this rule, account needs not be in "sysop" or "bot" groups, to be added to "extendedconfirmed".
Tue, Jun 18
I don't know exact reason behind your title ending up with two ‌ substrings. That is the likely cause behind having your publishing being unsuccessful.
How different is this ticket from what was reported in T203160#5215204?
@Etonkovidova, alongside with the question (that @Pginer-WMF has already answered), you moved the task back to priority backlog.
Now that it is clarified that behavior is expected, can the task be resolved or there is some pending QA work left?
Mon, Jun 17
Sun, Jun 16
I cannot reproduce, because my gray interlanguage link dialog is misplaced - T224880.
Fri, Jun 14
@Etonkovidova I instructed you to cover cases laid out in T221359 and try having some sections with high MT warnings marked as resolved, because that is when MT limits change. In the end, that is what this ticket was about.
Thu, Jun 13
I have uploaded the patch that should show missing template warning only when template is really missing. Previously it could also be shown when no params are adapted.
Yes, I think that line is the culprit for this error. There is similar query and error being caught in another API as well.
If I setup new wiki sometimes, I'll try remembering to fix this.
Wed, Jun 12
There are indeed some differences in how MT percentages are calculated for whole translation (when checking whether to prevent user from publishing) and on paragraph level.
This error happens when user adds completely new reference (not with editing adapted reference).
Tue, Jun 11
Mon, Jun 10
@Etonkovidova, do you need any additional info to continue QA on this ticket?
The root of the problem is that Simple Wikipedia defines content language as English (with 'en' language code) and we use content language code for from parameter when starting translation using CX. So, all translations from Simple Wikipedia through gray interlanguage links are actually started from English Wikipedia. Furthermore, 'en' being used for language code is the likely cause behind showing "Translate from English" instead of "Translate from Simple English" when you click on Simple English gray interlanguage link. Also, sometimes article exists on Simple Wikipedia, but not on English Wikipedia, which causes errors when starting translations.
Solved in CX2 by 97229398b7519fb65c3bcd0770c7be873574d715
Sun, Jun 9
This was resolved with 859c12d8b12f38db411b4a21228863261a7d3fa3.
Fri, Jun 7
Thu, Jun 6
Wed, Jun 5
In 16c7f13cadb246c1e5ff2dd2467c3b057d8ff0ac, I have added math formulas to the list of nodes excluded from MT validation. However, math formulas are wrapped in additional <p>, therefore not excluded right now, but should be excluded once additional wrapper is removed.
Tue, Jun 4
Mon, Jun 3
Sun, Jun 2
Fri, May 31
Thu, May 30
That error is not coming from Content Translation code, but from code in MinervaNeue skin. The error does not prevent page from loading, not sure if there are some implications in other places and if bug should be reported.
I got some questions for @Pginer-WMF:
- Do you plan to use pulsating dot in other places as well? Does it need to be a generic element? I have seen us creating generic solutions for which the full potential was never fully utilized. If this is one-off element, we can remove some of the code shipped on every page view.
- Can the size of the SVG be reduced? It's 18.5KB, while most OOUI SVGs are in hundreds of bytes.
- You say "Once the user clicks on the contributions invite, the pulsing dot will disappear and won't be shown for the user again". Current behavior is that pulsating dot is shown once regardless of user clicking on it or not. I think you expected the dot to be shown until the invite is seen by the used. Also, local storage is used to remember that dot was shown once, which means the dot can appear if using other browsers. Do we need to use global preferences or local storage is fine? New article invite (T216032) uses global preferences.
- When dot is shown, contributions menu isn't. Clicking on dot opens invite from this ticket. Clicking on link opens Special:Contributions. Is this acceptable?
Wed, May 29
Tue, May 28
Like @santhosh said, 512633 fixes header for Minerva.
However, fixing header only means we fixed the problem when Minerva is used on desktop, not on mobile. On mobile, lots of required CX modules are not loaded and we get blank page.
Mon, May 27
May 24 2019
May 23 2019
Per T224120#5206460, errors inside issue card should use 'error' icon (with 'error' flag).