Page MenuHomePhabricator

Verdy_p (Philippe Verdy)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Tuesday

  • Clear sailing ahead.

User Details

User Since
Feb 23 2015, 1:39 AM (279 w, 6 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Verdy p [ Global Accounts ]

Recent Activity

Wed, Jul 1

Verdy_p added a comment to T252568: Comma separated lists should always use unicode-bidi: isolate.

The only way to create a valid list of user names (or autonyms for language names, or lists of translated terms), is to "isolate" each displayed name (inside a "bdi" element, or using equivalent Unicode controls in plain text). Then you can use the comma you want and other separators, and keep the list logically ordered.

Wed, Jul 1, 4:49 PM · User-Huji, I18n, MediaWiki-Internationalization
Verdy_p added a comment to T256649: incorrect English names for languages (they display the native names only).

Anyway I don't see the rationale for including a LRM marker (U+200E) in every entry of

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/languages/data/Names.php

whose value is terminated by a closing parenthese.

Wed, Jul 1, 3:47 PM · MediaWiki-Internationalization

Tue, Jun 30

Verdy_p added a comment to T256649: incorrect English names for languages (they display the native names only).

Aren't these supposed to be translated to English from CLDR data (except variants like "formal" and "unformal"), whereas only autonyms are in languages/Name.php?
Or is there another source (in messages imported from translatewiki.net)?

Tue, Jun 30, 3:49 AM · MediaWiki-Internationalization
Verdy_p added a comment to T256647: {{#language:cho}} : missing native name ("Choctaw" is in English).

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/languages/data/Names.php (line 119)

- 		'cho' => 'Choctaw', # Choctaw
+		'cho' => 'Chahta Anumpa', # Choctaw
Tue, Jun 30, 3:04 AM · MediaWiki-Internationalization

Mon, Jun 29

Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Mon, Jun 29, 4:52 PM · MediaWiki-Internationalization
Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Mon, Jun 29, 4:51 PM · MediaWiki-Internationalization
Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Mon, Jun 29, 4:48 PM · MediaWiki-Internationalization
Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Mon, Jun 29, 4:41 PM · MediaWiki-Internationalization
Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Mon, Jun 29, 4:19 PM · MediaWiki-Internationalization
Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Mon, Jun 29, 3:36 PM · MediaWiki-Internationalization
Verdy_p created T256649: incorrect English names for languages (they display the native names only).
Mon, Jun 29, 3:33 PM · MediaWiki-Internationalization
Verdy_p added a comment to T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English).

But the native names for "formal"/"informal" variants are still incorrect with RLM.
A test page is a proof, and helpful to explain what is expected That test page has a full coverage of all locales supported in Mediawiki (at least its version currently deployed in Commons).

Mon, Jun 29, 3:20 PM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface
Verdy_p renamed T256647: {{#language:cho}} : missing native name ("Choctaw" is in English) from {{#language:cho}} : missing native name to {{#language:cho}} : missing native name ("Choctaw" is in English).
Mon, Jun 29, 3:17 PM · MediaWiki-Internationalization
Verdy_p created T256647: {{#language:cho}} : missing native name ("Choctaw" is in English).
Mon, Jun 29, 3:15 PM · MediaWiki-Internationalization
Verdy_p created T256646: {{#language:cho}} : missing native name.
Mon, Jun 29, 3:14 PM
Verdy_p added a comment to T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English).

Because the fix was partial and not reviewed correctly. I had also already indicated the test page (on Commons) where you can see all this (and where the bug was initially detected since the start)

Mon, Jun 29, 2:59 PM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface
Verdy_p renamed T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English) from native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES to native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English).
Mon, Jun 29, 2:22 PM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface
Verdy_p added a comment to T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English).

This is fixed only in the native name; still there's no English name assigned, which is still displayed as "себертатар" instead of "Northern Tatar".

Mon, Jun 29, 2:16 PM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface

Thu, Jun 25

Verdy_p added a comment to T256225: Syntax for explicitly omitting plural forms in CLDR-style plurals.

Is it really a CLDR issue or just an issue of your existing Ruby package, that has no support for selecting the correct plural form to use from language-specific rules?
It would be more convenient if your app was aware and use plural rules to select the appropriate form, instead of relying on a specific order in a fixed-sized indexed array. Ruby has support for associative arrays, or arrays conteinaing text or nil values (remap CLDR form types "default", "one","two","few","many" into an integer constant, and you're done)

Thu, Jun 25, 5:49 PM · MediaWiki-extensions-Translate

Tue, Jun 23

Verdy_p added a comment to T59383: Information template fields can contain lots of complex HTML.

images that are imported by Wikidata infoboxes (on Wikimedia Commons) and that happen to have notes in them, are currently supposed to be rendered as inline spans;
However the rendered "wpImageAnnotatorControl" object is a "div" element inside the span, and it is missing the "display:inline-block" CSS required to isolate it from the layout it generates internally for the annotation control.

Tue, Jun 23, 8:40 PM · Multimedia, CommonsMetadata

May 27 2020

Verdy_p added a comment to T252259: Refine Commons Template:Map with Lua modules to populate the template with Wikidata.

The effect is not the same depending on wikis. I assume they don't have the same version of Scribunto deployed.

May 27 2020, 8:06 PM · Wikidata, Commons, Wikibase-Lua, Wikimedia-Hackathon-2020
Verdy_p added a comment to T252259: Refine Commons Template:Map with Lua modules to populate the template with Wikidata.

@ Jarekt: I use the same method also With Notepad++ (it's strange that the source editor for modules in the wiki does not even show the line numbers!)

May 27 2020, 7:03 PM · Wikidata, Commons, Wikibase-Lua, Wikimedia-Hackathon-2020

May 25 2020

Verdy_p added a comment to T253485: Add a Lua call that returns a list of defined properties without requiring a call to getEntity.

And please add getEntityByLang(lang), which will implement language fallbacks, so that we can load (and cache) entities only using relevant languages; and remove all sitelinks from this call: sitelinks can be loaded selectively on specific entities (and in general it is only the entity related to the current page: these sitelinks are already loaded in the languages side bar, and can have their own separate cache keeping loaded sitelinks for that single entity).

May 25 2020, 9:06 AM · Wikibase-Lua, Wikidata

May 22 2020

Verdy_p added a comment to T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English).

Still not deployed. this native name still sorts incorrectly between "Cymraeg" and "dansk" in Latin-written scripts.
Note that the customized sort order in [https://commons.wikimedia.org/wiki/Module:Multilingual_description/sort] fixes it (but only for Commons): the effect is not visible by humans in the automatic sort order for languages (including languages navboxes that use this module) on Commons, but this bug affects all other templates or other wiki not fixing it and using basic sort (there are countless examples, including the homepage of wikimedia.org).

May 22 2020, 6:57 PM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface

May 5 2020

Verdy_p added a comment to T200206: Omit `<link rel="mw-deduplicated-inline-style">` from page view HTML.

Ideally the style/link tag shouldn't be considered as content, but I doubt this is doable (or even advisable, actually).

May 5 2020, 6:58 PM · Performance-Team (Radar), Parsing-Team, MediaWiki-Parser, TemplateStyles
Verdy_p added a comment to T200206: Omit `<link rel="mw-deduplicated-inline-style">` from page view HTML.

Ideally, this would mean that Mediawiki would not generate only one content, but two in parallel: the content to transclude (and that can be tested with #if:) and separately the metadata which will be inserted elsewhere.

May 5 2020, 6:05 PM · Performance-Team (Radar), Parsing-Team, MediaWiki-Parser, TemplateStyles

Apr 26 2020

Verdy_p added a comment to T33817: The <bdi> tag is sanitized.

Note that even though iOS/MaoOS does not render the "bdi" element properly, it has support for the "isolate" mode since mid-2012.
This support is in the native iOS/MacOS text renderer and accessible with the "-webkit-isolate" value in CSS.
Unfortunately, the "bdi" element (even if it's parsed correctly by Chrome and Safari in the HTML DOM) still has no style associated in the default stylesheet of the user agent.
So we need to set this for iOS/MacOS (works since Safari 6)

bdi, output { unicode-bidi: -webkit-isolate; }
Apr 26 2020, 7:14 AM · RTL, I18n, Verified, MediaWiki-Parser

Apr 20 2020

Verdy_p added a comment to T69196: PAGESINCATEGORY should decode HTML entities of input - if {{PAGENAME}} contains ' or " it will display 0.
Apr 20 2020, 2:26 PM · MediaWiki-Parser
Verdy_p added a comment to T69196: PAGESINCATEGORY should decode HTML entities of input - if {{PAGENAME}} contains ' or " it will display 0.

Using a wiki-dependant Lua module is not a good workaround (also Lua modules are not deployed in all wikis) and slower and more costly than using the builtin parser function {{#titlepart:}} to decode these named or numbered character entities (&amp;, &lt;, &gt;, &quot;, &#32;, &nbsp;, &#xA0;, and so on) when they are valid (so a & alone or without the correct syntax and the required trailing semicolon must remain intact).

Apr 20 2020, 1:50 PM · MediaWiki-Parser

Apr 2 2020

Verdy_p added a comment to T134423: Deprecate nonstandard behavior of self-closed HTML tags in wikitext..
Dans T134423#3578929, @ssastry a écrit :

<span style="white-space:nowrap; display:inline;">'''{{ #if: {{{skóre|}}} | {{{skóre}}} | v }}''' {{#if:{{{prodl|}}}|<span style="font-size: 85%">([[Prodloužení|prodl.]])</span> }}</span>{{ #if: {{{celkově|}}} | <br /> <div style="font-size: 85%">('''{{{celkově}}}''' [[Playoff|celkově]])</div> | }}{{ #if: {{{penaltyskóre|}}} | <br /> <div style="font-size: 85%">('''{{{penaltyskóre}}}''' [[Penaltový rozstřel|pen]])</div> | }}

I think I have to change the whole logic, but I'm not sure how
Apr 2 2020, 4:17 PM · MW-1.35-notes (1.35.0-wmf.37; 2020-06-16), Patch-For-Review, Chinese-Sites, MW-1.28-release-notes, MW-1.28-release (WMF-deploy-2016-07-12_(1.28.0-wmf.10)), User-notice, Parsoid, MediaWiki-Parser

Mar 25 2020

Verdy_p added a comment to T4085: Add a {{USERLANGUAGE}} magic word.

"As mentioned before, wikitext in the user interface language complicates caching."

Mar 25 2020, 11:33 AM · Parsing-Team, Performance-Team (Radar), MediaWiki-Parser, I18n, MediaWiki-Internationalization

Mar 20 2020

Verdy_p added a comment to T4085: Add a {{USERLANGUAGE}} magic word.

There should not be any need to call the wiki parser from Lua just to get an information which is built in the Wikimedia API (in PHP) itself. The best way would be to expose this value directly in the environment offered by Scribunto.

Mar 20 2020, 8:38 AM · Parsing-Team, Performance-Team (Radar), MediaWiki-Parser, I18n, MediaWiki-Internationalization

Mar 8 2020

Verdy_p added a comment to T186359: Add Siberian Tatar (sty) to Names.php.

Note that "Northern Tatar" is an alternate (and probably prefered) name in English for "Siberian Tatar" (which is too restrictive for that language). The native name really means "Northern Tatar" as it refers to a larger region than just the Siberian dialect.

Mar 8 2020, 12:58 AM · MW-1.31-release-notes (WMF-deploy-2018-02-06 (1.31.0-wmf.20)), User-MarcoAurelio, MediaWiki-Internationalization
Verdy_p added a comment to T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English).

And now after a few minutes that this fix is accepted and documented, I see numerous wikis that used the incorrect cyrillic letter, plus a few other sites, correcting it in their lists of language codes. It is clear that their source was Mediawiki and the error in Mediawiki was propagated elsewhere.
Google also has made more extensive searches and finds now many more references to the Cyrrilic-only orthograph) and this is growing, while the number of results with the Latin latter is now shrinking quite rapidly (Google must also have updatred its own indexing thresholds for results significance, their bots are aware of what happens here!)

Mar 8 2020, 12:52 AM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface
Verdy_p added a comment to T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English).

Also If I google it now, I actually see more results with the Cyrillic initial (in serious articles, news, blogs, talks...) than with the Latin initial (where it appears only in technical lists autogenerated from some data that must come initially from Mediawiki, but not within plain sentences !) Serious linguistic data sources all use the Cyrillic initial and don't mixup Latin !

Mar 8 2020, 12:24 AM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface
Verdy_p added a comment to T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English).

There's no reason why only the first letter should be Latin and not the remaining letters "e", "p", "t", "a" of this word (which are actually all Cyrillic like the rest of the language).

Mar 8 2020, 12:20 AM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface

Mar 7 2020

Verdy_p added a project to T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English): MediaWiki-Interface.
Mar 7 2020, 5:36 PM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface
Verdy_p updated the task description for T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English).
Mar 7 2020, 5:33 PM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface
Verdy_p created T247170: native language name for Northern Tatar (code 'sty', written in Cyrillic) uses an incorrect initial Latin small letter C instead of the Cyrillic small letter ES (also check English).
Mar 7 2020, 5:31 PM · MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), MediaWiki-Interface

Jan 10 2020

Verdy_p added a comment to T11996: Multiline tags in lists should be output more intelligently.

Yes, using explicit HTML tags for list containers can be a solution too.... if it works (for now no, because, like you say, the wikisyntax opens a new embedded container)

Jan 10 2020, 11:44 PM · Parsoid, RemexHtml, Tidy, MediaWiki-Parser
Verdy_p added a comment to T11996: Multiline tags in lists should be output more intelligently.

Styling ol, ol ol, ol ol ol, etc. does not work for the general case. It's much preferable to be able to give attributes (notably id and class) for list items and list containers (style can then be made on classes, id's can be used as anchors).

Jan 10 2020, 10:09 PM · Parsoid, RemexHtml, Tidy, MediaWiki-Parser
Verdy_p added a comment to T11996: Multiline tags in lists should be output more intelligently.
<div style="list-type-type: upper-roman">
# roman
# numerals!
</div>
Jan 10 2020, 9:41 PM · Parsoid, RemexHtml, Tidy, MediaWiki-Parser
Verdy_p added a comment to T11996: Multiline tags in lists should be output more intelligently.

Also note the special case for numbered lists; it is frequently needed to split a numbered list in several parts, or showing only an extract, or numbering them differently (e.g. with letters, or with roman digits, or starting at a different value than 1). This cannot be specified on list items, only as attributes of the list container (and MediaWiki provides no syntax for the container of the list itself, only a syntax for individual list items, it infers the presence of containers (ul, ol, dl) from the sequential generation of individual items (li, dt, dd, encoded with the wiki syntax), and then it groups them "magically".

Jan 10 2020, 7:09 PM · Parsoid, RemexHtml, Tidy, MediaWiki-Parser
Verdy_p added a comment to T11996: Multiline tags in lists should be output more intelligently.
:: <<< any
== wiki text ==
markup you like
* including embedded lists
<div style="clear: both; color: red">including html-ish tags</div>
* list continued here
>>>
Jan 10 2020, 7:02 PM · Parsoid, RemexHtml, Tidy, MediaWiki-Parser
Verdy_p added a comment to T11996: Multiline tags in lists should be output more intelligently.

Another possibility would be to define a magic keyword like __TIDY__ that could be used as a "meta-element" inside template to indicate that what is generated by the template will be tidied only in the scope of this template, which would then generate some replaceable hidden element.

Jan 10 2020, 4:42 PM · Parsoid, RemexHtml, Tidy, MediaWiki-Parser
Verdy_p added a comment to T11996: Multiline tags in lists should be output more intelligently.

The clear intent in this example is to insert a floatting element inside a list item, not outside of it.

Jan 10 2020, 4:28 PM · Parsoid, RemexHtml, Tidy, MediaWiki-Parser

Dec 17 2019

Verdy_p added a comment to T240918: [[Wikimedia:Ia-upload-zip-file-too-large/en]]: MB vs MiB.

Even though I translated it in French as "Mio" (which the the approved value for mebibytes, i.e. binary), this was reverted to "Mo" which is decimal in French, then I was blocked for that !
Th reason being that "if MB" is used in English, use "Mo" in French, as they assume that "MB" unambiguously indicates decimal in English, which of course is not.

Dec 17 2019, 12:36 PM · Community-Tech, IA Upload, I18n
Verdy_p added a comment to T54687: Use IEC units (KiB, MiB, etc.) and not SI units (KB, MB).
Dans T54687#574233, @Nikerabbit a écrit :

That may be the ideal, but it is far from true in practice. Most languages using non-latin scripts will at least transliterate the symbols.

Dec 17 2019, 10:10 AM · Core Platform Team Workboards (Clinic Duty Team), Patch-For-Review, WorkType-NewFunctionality, MW-1.27-release-notes, Multimedia, MediaWiki-General
Verdy_p added a comment to T240918: [[Wikimedia:Ia-upload-zip-file-too-large/en]]: MB vs MiB.

IEC units are standard in the UI of file explorers even if they do not always use the correct unit symbol, or use shorter symbols (like M instead of MB or MiB) for more compact presentations in table views (e.g. in MacOS) or on consoles (e.g. in Linux with "df -h", intended to be "human readable").

Dec 17 2019, 9:58 AM · Community-Tech, IA Upload, I18n
Verdy_p updated the task description for T240918: [[Wikimedia:Ia-upload-zip-file-too-large/en]]: MB vs MiB.
Dec 17 2019, 12:53 AM · Community-Tech, IA Upload, I18n
Verdy_p updated the task description for T240918: [[Wikimedia:Ia-upload-zip-file-too-large/en]]: MB vs MiB.
Dec 17 2019, 12:48 AM · Community-Tech, IA Upload, I18n
Verdy_p created T240918: [[Wikimedia:Ia-upload-zip-file-too-large/en]]: MB vs MiB.
Dec 17 2019, 12:47 AM · Community-Tech, IA Upload, I18n

Nov 6 2019

Verdy_p added a comment to T191231: RFC: Abstract schemas and schema changes.

Note that when closing T194125 (charset issue) this new task still does not address the backend conformance or emulation level we'd need to check (possibly with additional extensions to load in the backend SQL server). Each backend must still be able to pass a conformance test and fail, or enable an emulation layer to be used to allow compatibility or background migration of schemas (without causing a server upgrade to be imemdiately shutdown for hours... or days).

Nov 6 2019, 8:21 PM · MW-1.35-notes (1.35.0-wmf.32; 2020-05-12), Core Platform Team Workboards (Initiatives), CPT Initiatives (Abstract Schema), TechCom-RFC (TechCom-RFC-Closed), MediaWiki-Installer, Patch-For-Review, User-Addshore, SQLite, Oracle Database, MSSQL, PostgreSQL, Epic

Oct 22 2019

Verdy_p added a comment to T236011: Some newusers log entries show the IP address of the currently viewing user.

@Nikerabbit I don't know why you affirm in T235188 that I was "spamming" people. As far as as know I post in a thread which is still relevant to an unsolved issue which continues to have effect and whoise origin is still not known. Also that previous bug is still open and people were instructed to signal every quirk they saw that may be related to mysterious caching effects and incorrect displays, and you filed this new bug T236011 only very recently.

Oct 22 2019, 10:10 AM · MediaWiki-extensions-Translate, Regression

Oct 21 2019

Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.
Dans T235188#5590245, @Nikerabbit a écrit :

The last comment has nothing to do with this issue.

Oct 21 2019, 9:52 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p awarded T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache a Burninate token.
Oct 21 2019, 12:09 AM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net

Oct 20 2019

Verdy_p added a comment to T235389: IP Address ranges (CIDR) are stored as strings and cannot be queried.

The decimal form cannot be correct of it's not qualified with the address type (IPv4 or IPv6).

Oct 20 2019, 10:59 PM · Patch-For-Review, Wikidata, MediaWiki-extensions-WikibaseRepository
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

I don't know if this is related, but there's now a very strange behavior with lost sessions somewhere in the wiki.

Oct 20 2019, 9:45 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net

Oct 15 2019

Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Note that despite of the (selective?) cache purge in Translatewiki.net, the incorrect a cached version (including "Le champ est obsolète. $1", but not only this text) is still recurring (Look at some of my edit history on TWN for comments with "T235188").

Oct 15 2019, 11:39 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net

Oct 14 2019

Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

According to:
https://www.php.net/manual/fr/functions.anonymous.php

Oct 14 2019, 5:33 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T231720: Deploy Growth experiments at Ukrainian Wikipedia.

Adding a space at end if the translation unit actually does not work always: yes it will be stripped but if the translation was incorrectly marked fuzzy, this does not work.
You need to add a character that is NOT stipped automatically, forces an update in the SQL database, even if you then remove it in a subsequent change.
And to make sure this effectively works, you need to force refreshing the page.
And this only works if you do that in the wikitext editor on a separate specific page for each message, it does not work in the Translation UI which really seems to have its own caching and to delay pending updates in Memcached. With the Translation UI, there's a strange effect caused by a subsequent automated edit made by Fuzzybot (at unpredictable time, and visibly this job is delayed and can rerun multiple times, by either canceling the pending change(s) and then doing nothing, or incorrectly changing the pending changes when readding the incorrect FUZZY mark to the old message).

Oct 14 2019, 1:51 PM · MW-1.35-notes (1.35.0-wmf.15; 2020-01-14), Growth-Team
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

There's something to search around "TranslationsUpdateJob::getRenderJobs( $page );", probably not selective enough in its query.

Oct 14 2019, 12:07 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

I think that this is caused by very old background jobs being relaunched, using outdated data from its own internal cache and resubmitting the incorrect message with its old incorrect FUZZY mark prepended, and sending that to Memcache, even if no SQL request is performed.
When checking if changes must be made to the database, there's some "break" that blocks the update, but still the update of the key in Memcache is not blocked, and use any message left in some temporary variable which was not cleared after use when processing other messages in a loop.
The bug is to be searched in this background job that continues to corrupt the Memcached data.
For now all that can be done is to force an SQL update (which will also update the Memcached data) by inserting some space (and then removing it), and also changes the version number and timestamp.
some old jobs in job archives are incorrectly reprocessed if this was about a resource previously containing the prepended FUZZY mark (even if that mark was buggy).

Oct 14 2019, 12:03 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net

Oct 13 2019

Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Yes,, the bug is effectively reported also in Russian, Turkish, Arabic, i.e. the languages where there are more active reviewers. Initial translations where there are not very frequent users working on it are less affected.
And clearly there's a bug in the logic for marking updated messages "fuzzy", in Fuzzybot, with different assumptions and checks made by this bot, and those made by the wiki editor, or by the translate UI, each one using its distinct strategies to manage caches.
On servers there's not a single cache but several layers (internal and external), and they are not properly synchronized coherently. This causes havoc in the database and all other dependant services (such as data exports). The bug in Memcached is probably caused by insufficient keys to detect concurrent modifications of pages. And I think there are also various buffer overflow bugs or uncaught exceptions with incorrect/unsafe restart that are also not logged properly. The overall design of TWN architecture is very fragile and depends too much on unchecked assumptions, and it highly depends on external components updated independantly without measuring the impact of the change (notably the order of events because of the existing assumptions)

Oct 13 2019, 12:30 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net

Oct 11 2019

Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Looks OK now, the last glitches (for the remaining fake "FUZZY" marks) can be successfully solved by dummy-editing (and then reverting instantly) the affected messages in the wiki editor, as indicated above.

Oct 11 2019, 9:44 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p awarded T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache a Like token.
Oct 11 2019, 9:41 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Note: I could successfully update and fix some dirty reads, but not when using the Translate UI: instead I select each message and use the wikitext editor, add a dummy space in the middle of the correct string (just removing the leading !!FUZZY!! mark has no effect) then remove it. In which case both actions are now viwible in the history.
To make sure, I click on the "clock" in the top right to see if it makes a dirty read again.
Then I refresh the Translate UI page and this message is gone from the list of fuzzy messages, but on the "all messages" it is now correct.
This is definitely now a bug in the Translate UI interface itself, rather than the wikieditor, because it performs a batch of 100 dirty reads at once and seems to make unsafe async requests when updating anything. It seems to use its own internal cache (in its extension in PHP), independant of Memcached and the SQL backend, to decide what to do.
As well, there are most probably dirty reads and local caching in the client-side javascript that regular users of the Translate UI are working with. There are missing synchronization tokens (at least a version number and timestamp) to assert that what is submitted matches what is on the server-side backend(s).

Oct 11 2019, 7:26 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

@daniel, @aaron: I have a theory as to what's going on here.

The key functionality in getMultiWithUnionSetCallback looks roughly like this:

$id = null; // current entity ID
$func = function ( $oldValue, &$ttl, &$setOpts, $oldAsOf )
    use ( $callback, &$id, $newValsById, $newTTLsById, $newSetOpts )
Oct 11 2019, 7:11 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

I can confirm that this still does not work: submitted modified data are not always visible in the history and when looking at them individually in the wikitext editor (no indication at all that there's a new version). Translations continue to be marked fuzzy (with the older content) when they were already fixed (or even changed by some dummy extra space or punctuation, then modified again to remove this dummy character: nothing appears in the history, the old incorrect value is still there).
I wonder if the logic used for computing storage keys into Memcached is correct, why it does not have any version number or version timestamp?
It seems to be a race issue with reordered requests that are overriding each other or canceling the effect of a prior store by using data from dirty reads.
In Translatewiki.net this may be the effect of concurrent modifications: those made by the actual editor, those made by a SemanticWiki bot, or by FuzzyBot, or which do not have consistant reads, and then rapidly overwrite what was just stored from their older view.

Oct 11 2019, 6:40 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Is there any chance that the Memcache server has incorrect clock setting (or NTP failing its updates) ?

How would that explain the problem? Or have any impact, for that matter?

Oct 11 2019, 12:02 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Is there something (garbage, truncated or unparsable XML, incorrect encoding, incorrect security token, deprecated security algorithm, incorrect data compresssion...) in my own user data (or in user data from other users) on the wiki that could cause this bug ?
Was the Memcached software updated with new dependencies not satistisfed in the current installation (e.g. a security fix or new requirement for some shared ZLib component), cauising its own local storage to be garbled (possible buffer overflow)?

Oct 11 2019, 11:05 AM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Now https://translatewiki.net/w/i.php?title=MediaWiki:Bcmath-payload-counter/fr&diff=next&oldid=9049392

Oct 11 2019, 11:02 AM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

That page still shows the incorrect message "Le champ est obsolète. $1" in a dozen of units:
https://translatewiki.net/w/i.php?title=Special:Translate&group=mwgithub-bcmath&language=fr&filter=translated&action=proofread

Oct 11 2019, 10:56 AM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Is there any chance that the Memcache server has incorrect clock setting (or NTP failing its updates) ?

Oct 11 2019, 10:49 AM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

I still see other occurences of "Le champ est obsolète. $1"
e.g. in "MediaWiki:Logeventslist-tag-log/fr"

Oct 11 2019, 10:33 AM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

I see these duplicates in normal accesses, not if I link to oldversion.

Oct 11 2019, 10:20 AM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Another message duplicated:
"<strong>$1</strong> a été effacé."

Oct 11 2019, 10:01 AM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

There are other mixup with French messages containing
"Lien vers les conditions d’utilisation. Requis si ce partenaire exige que les utilisateurs acceptent les conditions d’utilisation pour recevoir l’accès ; sinon facultatif."
they are also duplicated.
This time I was not among the authors or reviewers

Oct 11 2019, 9:55 AM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

There's somthing strange in your Memcache query; "rev_user_text:" is empty for many ones. Aren't revisions supposed to be associated to a user ?
In that case a SQL join failed to load one user, and some bad outer join made that sort of mixup.
An for those, I think I was the initial author, but then why am I not listed like others ? My own user data failed to load ?

Oct 11 2019, 9:50 AM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net

Oct 10 2019

Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

So this is related to a migration of schema, with some changes in a limited period not correctly migrated (duplicate or missing ids in the database, causing unresolved outer joins or joins with the wrong row of another table or from a previous row in a subselection dataset ?
Then the bug should be isolated within a well defined period: when the migration started (probably the migration was made when the wiki was restarted and already live, but with event handlers still not running, or missing constraints that were delayed during the construction of some index, while data was already being added or updated by the live service).
In that case, an integrity check on changes made 2 days ago should detect the missing data in some helper tables (notably if the schema is partly denormalized for performance reason, with some data times duplicated in different tables).
Was there a migration of collation rules by upgrading the SQL engine for a new version of Unicode and its DUCET, or in CLDR support libraries if collation is performed by computing and storing collation keys in the schema?
Was there a change in the filesystem for the datastore for large blobs (e.g. a modified mounting point, or incorerctly migrated access rights if the datastore was moved, or an incorrect setting for some symbolic links)? I can't tell if this is what happened as I don't see the internal installation (only a site admin can inspect what happened and knows when a new installation was performed, and can inspect the migration logs or the internal filesystems and storage settings)

Oct 10 2019, 11:59 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Could that be caused by the volume of my own contributions on that site (if there's some extension trying to process ALL my history, and there's some internal limit which gets exhausted by some limited buffer sizes?
Anyway, even another user trying to fix the broken messages for me do not succeed to do that (possibly this applies to any resource in which I was a commiter: all past contributers in some period have their history processed?).
I'm convinced now this is a problem of resource limits, causing a silent error (not tested or not logged, causing an exception which is caught but at a higher level where the debugging info has been lost, e.g. an exception caught, not logged but rethrown in a simpler way where they are managed in an oversimplistic way without really identifying the initial cause, possibly silently blocked and filtered by strict privacy rules to avoid exposing private data).

Oct 10 2019, 8:10 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Some problem of cache with the wrong message "Le champ est obsolète. $1" displayed (in French) for a dozen of messages in this recent module (was completed several weeks ago, was correct, no change made since, but now with messages replaced by this one (with leading FUZZY marks).

Oct 10 2019, 6:37 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

And if you look at the recent update in Translatewiki, it uses a new set of messages to translate, with multiple ones displayed corrupted even if they were already translated correctly:
https://translatewiki.net/wiki/Special:Translate/mwgithub-central-check-user?group=mwgithub-central-check-user&language=fr&filter=translated&action=proofread
All these are showing the unexpected message (in French): "Le champ est obsolète. $1" (17 occurences), which does not reflect at all what was really translated (or that I tried to fix again without success).

Oct 10 2019, 5:54 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Bad caching is still an issue, because this is what users will see when reviewing translations, so they will try to fix them multiple times, with multiple variants, and validation becomes futile, progress is impossible, users constantly see the same items coming back again and again corrupted, statistics are not properly handled, and lot of work become far bhind in the trail of their to do list.
And this causes many unnecessary updates, and there are even people revalidating as OK things that were corrected with unexplained reverts to old versions (which are themselves still invisible in the history). When people will finally see that in the histories, it will be late, users will not understand why all was OK at one time and then bad later
And it makes any form of cooperation becoming futile between users trying to find an agreement and to apply it consistantly. It then becomes hard to adopt a consistant terminology and a coherent interface in the target wikis where they are imported. And we cannot discuss issues based on page histories when one sees somethig thaty others don't see at all or see differently.

Oct 10 2019, 5:50 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

One reason this may affect the French translations is its heigh level of messages that are already translated and reviewed: finding the remaining messages that are left to translate or review may require more extensive queries. This may be a problem of schema (missing selective indexes, full scans forced over large counts of blobs that will be parsed massively, even if the parsing is very basic).

Oct 10 2019, 4:30 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

another page affected:
https://translatewiki.net/wiki/MediaWiki:Project-localized-name-klwiktionary/fr
(once again the edit that displayed "Le champ est obsolète. $1" was not what I submitted, it has appeared in multiple unrelated messages)
In the page history, nothing was changed since over 2 weeks. But it still loads a different message and I don't know if what is visible in the basic Wiki editor is really what is used and displayed elsewhere, or if it's the basic Wiki editor that "lies" and the effective data is what we see in the Translate UI).

Oct 10 2019, 4:08 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Note that I signeld this bug in Translatewiki.net support, and on its IRC support channel

Oct 10 2019, 4:04 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

I suggest alerting the admins channels so they investigate seriously and do not trust immediately what they see in simplified reports. In case of problems or doubts, they should come to this bug. If there are too many problems caused by this bug, then we should go to maintenance and revert the new version affected.
I don't know when Tranlatewiki.net was updated with a new version or extension causing this.

Oct 10 2019, 4:00 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

I'm not sure, but the "tone" is getting high in some wikis with people complaining that they did not make what they are accused for

Oct 10 2019, 3:59 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.
Oct 10 2019, 3:57 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

the last edit you see is from me, I made it before you reported that message was reported here
I used the suggestion to make pseudo-dummy edits, just by seeing this message was in the list of messages to review.
But then once I did it, another unrelated message is impacted.
We are seeing now a loop of humane corrections that does not seems to end (and most of them are msising the user's history and the page histories, all is mixed up)

Oct 10 2019, 3:57 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

And may be there's a hidden hack that was introduced in the source code (possibly in a library) which is now exploited to attack wikis and create these conditions

Oct 10 2019, 3:53 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

Anyway on the affected wikis, some users start getting insulted or banned even if they did not make the breaking changes.
Havoc starts spreading to random places, and the user's history is now definitely wrong for what they really did.

Oct 10 2019, 3:51 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net
Verdy_p added a comment to T235188: Preemptive refresh in getMultiWithSetCallback() and getMultiWithUnionSetCallback() pollutes cache.

This is not jsut a problem of display:
in https://translatewiki.net/w/i.php?title=MediaWiki:Cx-notification-deleted-draft/fr&diff=9049005&oldid=9046073
the unexpected text that appeared "Le champ est obsolète. $1" was coming from an unrelated change in another translation unit, and it was propagated to multiple different pages.
And then each time we try to fix it, another translation unit is unexpected impacted as well.
Looks like a loop with multiple retries, reusing the content of some local variables due to improper initialisation or invalidation of internal caches.

Oct 10 2019, 3:49 PM · MediaWiki-Cache, MW-1.35-notes (1.35.0-wmf.18; 2020-02-04), serviceops, Core Platform Team Workboards (Clinic Duty Team), User-ArielGlenn, Patch-For-Review, affects-translatewiki.net

Sep 5 2019

Verdy_p added a comment to T41510: Opening Special:EditWatchlist with a large watchlist hits server timeout (Create watchlist pager).

For now this old bug is still present in various wikis (and more serious on wikis running in smaller servers with more limited CPU/memory resources): the HTTP error 500 occurs even when we ask to purge the list completely (and nothing is purged at all) even those with the most recent versions of Mediawiki.

Sep 5 2019, 8:21 AM · User-kostajh, Core Platform Team, Growth-Team, User-notice, Wikimedia-production-error, MediaWiki-Watchlist

Aug 7 2019

Verdy_p added a comment to T139010: Split Min Dong (cdo) translations.

These two scripts are completely incompatible, so please don't make any fallbacks. If fallback is required according to the MediaWiki rules, then fall back to English.

Aug 7 2019, 10:12 AM · MediaWiki-Internationalization, I18n

Jul 22 2019

Verdy_p added a comment to T184664: Install Noto fonts on scaling servers for SVG rendering.

You affirmed "I don't know why" but I explain you the reason. It's a fact that I got notified by Phabricator just a few minutes ago (may be Phabricator was very late in delivering his notification email; in that case you should know that notifications are not delivered in due time and some can take months before being sent).
and your comment about "how to report abug" is NOT relevant, I'm not submitting a new bug, just commenting about the topic covered by the bug: getting consistant view of all scripts using Noto Fonts. Time has passed and this goal is still valid today, the Unicode coverage has constantly been improved (and it continues: Noto is a very active and well supported open project).

Jul 22 2019, 12:21 AM · Operations, Commons, SRE-swift-storage, Wikimedia-SVG-rendering
Verdy_p added a comment to T184664: Install Noto fonts on scaling servers for SVG rendering.

I got a recent update today from this channel. It was sent by "Maintenance_bot removed a project: Patch-For-Review" (https://phabricator.wikimedia.org/T184664) which just got closed now. And I was notified a few minutes ago about it by Phabricator which jsut sent me an email for it.

Jul 22 2019, 12:11 AM · Operations, Commons, SRE-swift-storage, Wikimedia-SVG-rendering

Jul 21 2019

Verdy_p added a comment to T184664: Install Noto fonts on scaling servers for SVG rendering.

Note that ALL ISO 15924 scripts marked as encoded in Unicode up to version 9.0 (including historic scripts) have a suitable Noto Font (most of them a "Noto Sans <abbreviatedScriptName>", but a few ones are in Serif style only). This includes all script variants and script mixes, provided you select the correct fallback for these scripts (e.g. use the default "Latn" script for "Latf" or "Latg", but for "Aran" there's a Nastaliq variant defined, and as well for the "Zsye" variant).
For CJK Fonts, it's best to use the "script-mixes" codes to map them: "Jpan", "Kore", and for "Hans" and "Hant" you should add the Bopomofo to the list.
In all cases, for CSS "font-family:" styles, the default font "Noto Sans" for Latin must be added at end of lists.
For symbols, there are three fonts to add in that order: "Noto Sans Symbols", "Noto Sans Symbols2", "Noto Sans Mono" (the last one needed for box drawing characters should be listed *after* the default font "Noto Sans" for Latin/Greek/Cyrillic.

Jul 21 2019, 11:52 PM · Operations, Commons, SRE-swift-storage, Wikimedia-SVG-rendering

Jul 20 2019

Verdy_p added a comment to T194125: [RFC] Future of charset and collation for mediawiki on mysql .

There's not just MySQL. Other organization may use MSSQL, Sybase, Oracle, Infomix all of them having their own charset support (and in all of them, installing additional charsets to support the full UTF-8 is costly as it also requires installing (and maintaining) collation data. In frequent cases, collation cannot be updated all the time at each Unicode version, because it requires costly reindexing (but partial UTF-8 is possible, and I think this is the reason why MySQL defined the UTF-8(mb3), even if it also requires updating the collations when there are Unicode or CLDR updates for characters encoded in the BMP).

Jul 20 2019, 9:36 AM · MediaWiki-Installer, MediaWiki-General, Core Platform Team (Needs Cleaning - Security, stability, performance, and scalability (TEC1)), Wikimedia-Rdbms