Page MenuHomePhabricator

Verdy_p (Philippe Verdy)
User

Projects

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Thursday

  • Clear sailing ahead.

User Details

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

Recent Activity

Sat, Nov 21

Verdy_p added a comment to T264991: Upgrade the MediaWiki servers to ICU 63.

Is it blocking the edition on wikis (i.e. does it force them to be shutdown for extended period, beside the short time to upload the new collation tables in the database and restarting it)?
Or does it only affect how categories will be temporarily listed?
Also I don't understand why upgrading ICU on the host OS affects the ICU version used by the database (or its clients running on separate processes on any host, or the MediaWiki plugins, e.g. for PHP or Lua which may also have their own version of ICU).

Sat, Nov 21, 11:27 AM · Patch-For-Review, Beta-Cluster-Infrastructure, DBA, Operations, serviceops

Thu, Nov 12

Verdy_p added a comment to T262770: Normalize ZObjects.

Does normalisation include the suppression of all unnecessary whitespaces? It does not matter if the underlying storage uses a compact form, not easily readable by a human, given that the wiki editor could as well expand it with proper indendation for easier editing, and recompact it after.

Thu, Nov 12, 2:11 AM · Abstract Wikipedia (Phase δ)
Verdy_p added a comment to T260953: Documentation for ZObjects.

May be related, we have two fully translatable pages on the wiki:

The second item may need significant revision over time but the first one should be almost OK, unless there are drastic changes required, and minor things (like the name of the project and showing the new logo once it will be voted).

Thu, Nov 12, 1:14 AM · Abstract Wikipedia (Phase ι)

Tue, Nov 3

Verdy_p added projects to T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue: Commons, Mobile.
Tue, Nov 3, 5:04 PM · translatewiki.net, I18n
Verdy_p updated the task description for T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue.
Tue, Nov 3, 5:02 PM · translatewiki.net, I18n
Verdy_p updated the task description for T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue.
Tue, Nov 3, 5:02 PM · translatewiki.net, I18n
Verdy_p updated the task description for T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue.
Tue, Nov 3, 5:00 PM · translatewiki.net, I18n
Verdy_p renamed T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue from [[Wikimedia:Commons-android-strings-contributions subtitle/fr]] translation issue to [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue.
Tue, Nov 3, 5:00 PM · translatewiki.net, I18n
Verdy_p created T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue.
Tue, Nov 3, 4:59 PM · translatewiki.net, I18n

Mon, Oct 26

Verdy_p added a comment to T265291: The tool should add a blank line before comment.

Another way could be also to modify the Wiki parser so that if there's a blank line between 2 ":"-indented blocks, that blank line should be interpreted as implicitly *repeating* the same number of ":" of used in the preview line.

Mon, Oct 26, 2:34 AM · DiscussionTools

Oct 25 2020

Verdy_p added a comment to T265291: The tool should add a blank line before comment.

I agree that there should be no blank line at all that breaks the semantic HTML structure. The presentation can be fixed only by customizing the CSS between successive comments at different indentation levels).

Oct 25 2020, 12:53 AM · DiscussionTools

Oct 17 2020

Verdy_p added a watcher for Wikimedia-production-error: Verdy_p.
Oct 17 2020, 11:28 PM
Verdy_p added a comment to T49137: Add ability to generate a list of pages based on prefix to Scribunto/Lua.

Note that as of today (Saturday 2020-10-18), any attempt to sort the native language names returned by fetchLanguageNames() (after copying these names into a new sequenced table using table.insert(t, ...)) fails when calling table.sort(t, compare): this is a new bug of Scribunto that changed the interface of table and no longer accepts in parameter a standard comparison function (taking two native language names which should be strings). Visibly, fetchLanguageNames now no longer return standard strings, they are protected including in their references, and do not match the expected signature for the comparison function (this causes an internal error, inside sort(), where the comparison function is called with the wrong parameters, causing a invalid-type error).

Oct 17 2020, 10:51 PM · MediaWiki-extensions-Scribunto

Oct 16 2020

Verdy_p added a comment to Blog Post: Visual Studio Code + Neovim.

There's no problem with VSCode, given that you also have VSCodium which is almost the same without the trademark or branding. Many opensource projects can be rebranded in a proprietary way (except those using the GPL which does not allow restrictions on some parts, but this is common with LGPL, and there's nothing wrong for someone that makes some content online and maintain it online, to also promote their own services).

Oct 16 2020, 8:56 PM · Quality-and-Test-Engineering-Team (QTE)
Verdy_p added a comment to T179659: TCG: product announcements should be published in web, not only in mailing lists.

Also avoid making decisions in "live" sessions. The time scheduling of your community is not the same in other regions or for many people that can be online at the scheduled event. IRC-only is a very bad choice, as it stresses everyone to specific hours. IRC is only useful for temproary help, and nothing is kept. If you take an IRC session to decide something in urgence, please publish an archive of the session minutes, and properly index it in relevant categories.

Oct 16 2020, 8:33 PM · CommRel-Documentation
Verdy_p added a comment to T179659: TCG: product announcements should be published in web, not only in mailing lists.

Note: we should maximize the translatability of all these information:

Oct 16 2020, 8:21 PM · CommRel-Documentation
Verdy_p added a comment to T179659: TCG: product announcements should be published in web, not only in mailing lists.

If you use MassMessage, it should be simple to add a subscription to an on-wiki portal page or subpage, that can be seen by everyone, not required to subscribe the channel.

Oct 16 2020, 7:39 PM · CommRel-Documentation
Verdy_p added a comment to T202929: Assure that documentation about communities and engagement processes is relevant and up to date.
  • I have finished making all existing pages on MetaWiki translatable, including the last weekly updates.
  • I completed the French translation for most of them (there remain a few pages partly translated but without difficulty related to the links or embedded "tvars" so they are not difficult to translate (in some cases I added some hints in the doc part of the translate interface for things that may be added or things that should be kept unchanged and better not translated).
  • I wikified a few pages that were using long boring text: the newsletters are less boring, and they now all feature at top the {{Abstract Wikipedia}} template that link to the existing communication channels (this small bar is now floatting to the correct side at top of pages, just below the languages navbar and included a small link to translate the description of its icons visible when you hover them). Note that this template is in a "noinclude" section, just like the "languages" nav bar and categories, leaving only the main content which is deliverable to other users of they which to subscribe these news with MassMessage for their user pages on other wikis or for other community portals.
  • I completed the test for Bidi support. I also arranged the few templates used so they are all translatable and with a correct layout with Bidi.
  • I completed the categories to avoid mixing all languages, they are still navigatable across languages with an easy return to the English version for missing pages still not translated.
  • All links use the internal "Special:MyLanguage/" prefix for link targets (hidden inside tvars, so translators don't have to bother on them).
  • For existing translations, I made the necessary fixes needed after minor changes.
  • I made sure that all translation units are short (splitting long paragraphs into separate units for long paragraphs, this allows easier work in the translate interface, while still not creating a "patchwork" (where sentences are broken in the middle and would not order correctly in other languages according to their grammatical syntax).
Oct 16 2020, 7:10 PM · Goal, CommRel-Documentation
Verdy_p added a watcher for Abstract Wikipedia: Verdy_p.
Oct 16 2020, 6:54 PM
Verdy_p added a member for Abstract Wikipedia: Verdy_p.
Oct 16 2020, 6:53 PM
Verdy_p added a comment to T193550: [PageAssessments] db/addProjectsTable.sql : Error: 1071 Specified key was too long; max key length is 767 bytes.

767 maps well with "utf8" limited to 255 characters coded on 3 bytes (total is 765, plus 2 additional bytes... for null trailing?), i.e. 256*3-1 (excluding an additional lead byte)
With "utf8mb4", the limit would then be 256*4-1=1023, we don't need 3072, but InnoDB should then be tuned to effectively support "utf8mb4" that Mediawiki chose.

Oct 16 2020, 6:09 PM · MediaWiki-extensions-PageAssessments

Oct 1 2020

Verdy_p added a comment to T63547: Make [[Special:WhatLinksHere]] and [[Special:RecentChangesLinked]] work with links which use [[Special:MyLanguage]].

At least the link with Special:MyLanguage/ should be registered at its base page name (everything after the / in that prefix), because it is the source of translations, which should exist, independently of the number of subpages for language codes (which will vary constantly over time).
As well translated subpages will most often have a navbox linking to all other languages, either from a template (this links are registered), or the list autogenerated by <language/> (these links are also not registered).

Oct 1 2020, 7:44 PM · I18n, MediaWiki-General

Aug 26 2020

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

I also agree that {{int:Lang}} is already widely used. However, the "int:" naamespace by default performs a lookup of pages that must be created in the "Mediawiki:" namespace, named "Lang/*", with one page per language. This is the old method, and in my opinioln Mediawiki does not necessarily needs to loads hundreds of pages for hundreds of languages (plus their variant subcodes): the parser can implement a hook that can directly return the user language from the MediaWiki's API, without loading any page from the "Mediawiki:" namespace (so all pages "MediaWiki:Lang/*" could be simply deleted if they still exist, and protected from being recreated, or this namespace "Mediawiki;" would also have a hook implemented that locks creating/editing any page named "Lang" or its subpages).

Aug 26 2020, 5:24 PM · Parsing-Team--ARCHIVED, Performance-Team (Radar), MediaWiki-Parser, I18n, MediaWiki-Internationalization

Jul 10 2020

Verdy_p added a comment to T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.

test.wikipedia is not a production server, so may be there was a fix on the latest release. This still does not work on Commons where the workaround was and is still needed. It's possible that the trimming is partial (drops only one space, not tabs/newlines possibly found in some (positonal) template parameters, but my test cases was for calls of templates written as a single line without any space given, the only space were as is the exemplar code above, in navboxes for geographic entities).
So for Commons this is still not solved.

Jul 10 2020, 10:27 AM · ParserFunctions

Jul 9 2020

Verdy_p added a comment to T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.

As as I wrote, your comment repeating the statement "there is possible another issue when using template argument" is simply completely false (this is just your untested assumption).
This has absolutely NOTHING to do with template parameters ands can be reproduced outside of any template call.
This is not caused by template expansion, which works normally and expands with spaces as expected. But this bug is only about how PAGESINCATEGORY treats its effective parameter.

Jul 9 2020, 2:47 PM · ParserFunctions
Verdy_p added a comment to T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.

It has been reported multiple times as part of relevant bugs that were partly solved and closed, even when discussing the proposd solutions).

Jul 9 2020, 2:10 PM · ParserFunctions
Verdy_p added a comment to T232897: Thousand separator for large numbers.

The tradition for formatting long numbers has always been to have several grouping lengths, i.e. small groups of 3 digits separated by non-breaking spaces (best if these are narrow, i.e. NNBSP U+202F whose width is about 0.3em, not NBSP U+00A0 whose width is about 0.5em), but still allow larger groups to split on long lines.

Jul 9 2020, 2:39 AM · MediaWiki-Internationalization, ParserFunctions
Verdy_p added a project to T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly: ParserFunctions.
Jul 9 2020, 2:23 AM · ParserFunctions
Verdy_p updated the task description for T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.
Jul 9 2020, 2:09 AM · ParserFunctions
Verdy_p updated the task description for T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.
Jul 9 2020, 2:09 AM · ParserFunctions
Verdy_p updated the task description for T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.
Jul 9 2020, 2:04 AM · ParserFunctions
Verdy_p updated the task description for T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.
Jul 9 2020, 2:04 AM · ParserFunctions
Verdy_p updated the task description for T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.
Jul 9 2020, 2:03 AM · ParserFunctions
Verdy_p updated the task description for T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.
Jul 9 2020, 1:54 AM · ParserFunctions
Verdy_p updated the task description for T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.
Jul 9 2020, 1:47 AM · ParserFunctions
Verdy_p updated the task description for T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.
Jul 9 2020, 1:46 AM · ParserFunctions
Verdy_p updated the task description for T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.
Jul 9 2020, 1:45 AM · ParserFunctions
Verdy_p created T257535: {{PAGESINCATEGORY: Name }} does not trim its Name parameter and returns 0 unexpectedly.
Jul 9 2020, 1:43 AM · ParserFunctions
Verdy_p added a comment to T16237: PAGESINCATEGORY should differentiate between pages and subcategories.

No, PAGESINCATEGORY does NOT (and has NEVER) worked with spaces.

Jul 9 2020, 1:42 AM · MediaWiki-Categories

Jul 8 2020

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

I agree: for Mediawiki the support is accurate. For other projects using other parsers, that don't recognize the MediaWiki "template"-like syntax, such as some Ruby projects that also use poorer libraries (which need all plural forms to be specified in a strict order), the best we can do is to usggest them to integrate a better I18N library that don't have the stupid requirement for ALL plural forms to be specified when they could work with defaults.

Jul 8 2020, 6:07 PM · MediaWiki-extensions-Translate
Verdy_p added a comment to T252568: Comma separated lists should always use unicode-bidi: isolate.

Note that using "bdi" HTML elements is not the only solution.

Jul 8 2020, 10:51 AM · User-Huji, I18n, MediaWiki-Internationalization

Jul 6 2020

Verdy_p added a comment to T16237: PAGESINCATEGORY should differentiate between pages and subcategories.

Also I note that {{PAGESINCATEGORY: name |R}} does not seem to trim whitespaces in the given category names (this is a problem in templates where category names are generated by complex rules where there may be optional parts separated by spaces). So it does not work like [[CATEGORY: name ]] : in such cases, it will return 0 even if the category is not empty and has many members.

Jul 6 2020, 12:07 AM · MediaWiki-Categories
Verdy_p added a comment to T16237: PAGESINCATEGORY should differentiate between pages and subcategories.

I don't know if PAGESINSCATEGORY must be accurate. As it is costly, we probably don't need the exact count if we can just have an exact estimate below a maximum.

Jul 6 2020, 12:07 AM · MediaWiki-Categories

Jul 1 2020

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, and each item can contain arbitrary text (in any script and direction).

Jul 1 2020, 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

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

Jun 30 2020

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

Jun 30 2020, 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
Jun 30 2020, 3:04 AM · MediaWiki-Internationalization

Jun 29 2020

Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Jun 29 2020, 4:52 PM · MediaWiki-Internationalization
Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Jun 29 2020, 4:51 PM · MediaWiki-Internationalization
Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Jun 29 2020, 4:48 PM · MediaWiki-Internationalization
Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Jun 29 2020, 4:41 PM · MediaWiki-Internationalization
Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Jun 29 2020, 4:19 PM · MediaWiki-Internationalization
Verdy_p updated the task description for T256649: incorrect English names for languages (they display the native names only).
Jun 29 2020, 3:36 PM · MediaWiki-Internationalization
Verdy_p created T256649: incorrect English names for languages (they display the native names only).
Jun 29 2020, 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).

Jun 29 2020, 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).
Jun 29 2020, 3:17 PM · MediaWiki-Internationalization
Verdy_p created T256647: {{#language:cho}} : missing native name ("Choctaw" is in English).
Jun 29 2020, 3:15 PM · MediaWiki-Internationalization
Verdy_p created T256646: {{#language:cho}} : missing native name.
Jun 29 2020, 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 (with all the coverage needed). 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)

Jun 29 2020, 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).
Jun 29 2020, 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".

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

Jun 25 2020

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)

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

Jun 23 2020

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.

Jun 23 2020, 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--ARCHIVED, 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--ARCHIVED, 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 · I18n, RTL, 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--ARCHIVED, 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--ARCHIVED, 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 · 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.36-notes (1.36.0-wmf.14; 2020-10-20), Patch-For-Review, MW-1.35-notes (1.35.0-wmf.32; 2020-05-12), Platform Team Workboards (Initiatives), Platform Team Initiatives (Abstract Schema), TechCom-RFC (TechCom-RFC-Closed), MediaWiki-Installer, 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, 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, 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, MediaWiki-extensions-WikibaseRepository, Wikidata