Page MenuHomePhabricator

Verdy_p (Philippe Verdy)
User

Projects (9)

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Sunday

  • Clear sailing ahead.

User Details

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

Recent Activity

Tue, Apr 27

Verdy_p added a comment to T201171: Create a Scribunto interface for the Variables extension.

Having variables kept across Lua invokation is still useful as long as these variables have idempotent values (i.e. values that should be independant of the number of calls, but just depending on the state when starting to parse a wiki page: basically there are things that are constant for all the wiki (like the default language) or depend on properties of the current page (the content language, and the starting time when this page gets parsed and rendered, even if the parsing is incomplete), the user's UI language (not specific to the user but shared and cachable for any usage of the same language).
The frame itself tracks such constants, but the lua calls should not depend on their order of invokation and all calls should work as if they were the first one being evaluated in the same context.
Then initializations can be performed only once, cached, and reused without the associated cost (notably in CPU time, as most often memory space is not the major blocker). This means that lua calls should depend on a small environment (even smaller that what is in the "current frame" which contains the current state of analysis and various synchronisation data for caches and different rendering servers).
If we make these Lua calls more functional, with reduced sets of dependencies (taken from any "current frame" where they should not change over time), it becomes possible to render a page incrementally and update only what is necessary, just by invalidating caches more incrementally, and queuing the rendering and caching of other fragments: we then solve the problem of CPU time, as well as later the resources limits on memory space, because caches will fill the gap). The only price will be the total time to have the page full refreshed, but at least we should be able to have a usable page that can be built incrementally in several steps.
Notably parser hooks (for namespaces, of parser functions) could have their own cache independant of the cache for the fully rendered page: what is needed is to track the dependencies for reused cached fragments that the Mediawiki will use, and purging the Mediawiki page cache no longer need to purge the cache used by each hook.
As well the parser hooks can run on different servers/hosts. The main Mediawiki parser will still be able to compose the elements, but will no longer need to run hooks synchronously in a single pass. We get better scalability, common fragments with the same conditions can be parsed only once and reused (via the cache). It will be up to each cache to detect when it has been specifically flushed or is too old for the new page content changing call parameters and then decide to delegate or not the effective execution of the hook to refresh the cached result that Mediawiki uses

Tue, Apr 27, 2:21 PM · Patch-Needs-Improvement, MediaWiki-extensions-Scribunto, MediaWiki-extensions-Variables

Mon, Apr 26

Verdy_p added a comment to T264413: getCurrentFrame not exist in the table mw in the scribunto library.

Why isn't still there a mw.env property to expose variaous variables of the PHP MediaWiki API (notably the user's UI language, which still requires a (costly) recursive call to Mediawiki parser only to expose a call to {{int:Lang}} (which is not really supported for all languages are requires maintenance, in addition to bind to a parser hook for the int: namespace, which also still does not specialcase the int:Lang to avoid a costly database load from MediaWiki:Lang/code pages, supposed to just contain the code which to just match the subpage name; internally the int: parser hook for this special namespace is supported in PHP and uses the environement variable of the MediaWiki API in PHP, so why not exposing the same integration in the Scribunto hook?).

Mon, Apr 26, 7:26 PM · MediaWiki-extensions-Scribunto
Verdy_p added a comment to T269990: jsonEncode fails when value contains more than 1 reference to the a same table.

That's because the code maintains an internal hashtable for objects that have already been visited. If the intent is to avoid infinite circular loops for objects that have members pointing to some of their parent, then the internal hashtable for that have indexed any node before visiting its members should remove that node from that table: this table would then work more like a stack in that case, where nodes are added and removed from the top of stack (but that stack is actually not looked up sequentially from top to bottom, a node is in the "visiting" state only if it is present and indexed in the hashtable).

Mon, Apr 26, 5:14 PM · MediaWiki-extensions-Scribunto
Verdy_p removed a project from T131025: Adding/modifying namespace translations for an and ast for Gadgets and Scribunto: MW-1.27-release (WMF-deploy-2016-04-05_(1.27.0-wmf.20)).
Mon, Apr 26, 4:46 PM · MW-1.27-release (WMF-deploy-2016-03-29_(1.27.0-wmf.19)), MediaWiki-extensions-Scribunto, MediaWiki-extensions-Gadgets
Verdy_p added a comment to T254670: [EPIC] Update extensions that run hooks to use the new HookContainer/HookRunner system.

[1] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/571297
[2] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/581225
[3] https://phabricator.wikimedia.org/T240307
[4] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/323ac073d38ec30a97b73b4a25999079b3a125d3/docs/Hooks.md>

Mon, Apr 26, 9:10 AM · Epic, Platform Engineering, Platform Team Initiatives (New Hook System), MediaWiki-extensions-General

Apr 3 2021

Verdy_p added a comment to T189409: Strong reduction of computing time at Wikivoyage needed.

I can not as well a constant growth of computing time in Lua, especially in

recursiveClone <mwInit.lua:41>

which is now the topmost time-spender in pages using many Lua calls (even without using Wikidata at all).

Apr 3 2021, 7:28 PM · Regression, MW-1.31-release-notes (WMF-deploy-2018-03-13 (1.31.0-wmf.25)), MediaWiki-extensions-Scribunto, Performance Issue, MediaWiki-extensions-WikibaseClient, Wikidata

Mar 22 2021

Verdy_p updated the task description for T278170: In "Query string search", is Query a noun or a verb?.
Mar 22 2021, 7:01 PM · Developer-Advocacy (Jan-Mar 2021), User-bd808, Toolhub, I18n
Verdy_p created T278170: In "Query string search", is Query a noun or a verb?.
Mar 22 2021, 7:00 PM · Developer-Advocacy (Jan-Mar 2021), User-bd808, Toolhub, I18n

Mar 14 2021

Verdy_p added a comment to T275945: Launch Wikifunctions.

This is not about the wiki itself, but other Wikimedia wikis will need a way to reference the new wiki. This requires deciding before the lauch what will be the interwiki prefix used, and prepare the other wikis to make sure they don't use the prefix in some titles of pages in their main namespace.

Mar 14 2021, 2:50 PM · Epic, Abstract Wikipedia team (Phase λ)

Feb 17 2021

Verdy_p created T274961: Public Page Content Service project description links to a private Google Doc.
Feb 17 2021, 12:39 AM · Documentation, Product-Infrastructure-Team-Backlog, Page Content Service
Verdy_p added a watcher for Page Content Service: Verdy_p.
Feb 17 2021, 12:34 AM

Feb 14 2021

Verdy_p created T274743: [[Wikimedia:Wsexport-issues/en]] translation issue.
Feb 14 2021, 11:52 PM · Community-Tech, WS Export, I18n

Feb 10 2021

Verdy_p added a comment to T258914: Reserved ZIDs.

See also Abstract Wikipedia/Reserved ZIDs on Meta-Wiki, which references this task.
And Abstract Wikipedia/Updates/2020-11-25.

Feb 10 2021, 2:24 AM · Abstract Wikipedia team (Phase λ)

Jan 29 2021

Verdy_p added a comment to T271256: A page to collect news reports, papers, etc. on Abstract Wikipedia.

There are three existing pages related to this topic:

  1. Abstract Wikipedia/Related and previous work|Abstract Wikipedia/Related and previous work
  2. Abstract Wikipedia/Ideas
  3. Abstract Wikipedia/User stories
Jan 29 2021, 5:45 PM · Abstract Wikipedia team (Phase ζ), CommRel-Specialists-Support (Jan-Mar-2021)

Jan 27 2021

Verdy_p added a comment to T271241: Conduct community logo vote for Wikifunctions.

Added link from Abstract Wikipedia/Wikifunctions logo concept (in the timeline section) to this Phabricator task

Jan 27 2021, 10:04 AM · Abstract Wikipedia team (Phase γ), CommRel-Specialists-Support (Jan-Mar-2021)

Jan 6 2021

Verdy_p added a comment to T270836: SVG renderer: missing support for font-variant="small-caps" and style="font-variant:small-caps".
Jan 6 2021, 5:42 PM · Thumbor, Upstream, Wikimedia-SVG-rendering, Commons
Verdy_p added a comment to T270836: SVG renderer: missing support for font-variant="small-caps" and style="font-variant:small-caps".

According to the Gnome project, this has to go fgurther upstream into a bug of Pango.
See also https://github.com/Automattic/node-canvas/issues/894 (submitted in 2017)
Apparently, Pango does not use these styles, you need to enable the "smcp" OpenType feature (which is disabled by default of course but should be enabled with these CSS styles). Enabling an individual Opentype feature is possible with some SVG rendererers using a "labs" CSS property (still not part of the SVG or HTML5 standard, so with custom prefixes for CSS properties)

Jan 6 2021, 5:36 PM · Thumbor, Upstream, Wikimedia-SVG-rendering, Commons
Verdy_p added a comment to T270836: SVG renderer: missing support for font-variant="small-caps" and style="font-variant:small-caps".
Dans T270836#6715595, @Aklapper a écrit :

@Verdy_p: Are you willing to follow https://www.mediawiki.org/wiki/How_to_report_a_bug and structure your bug reports?

Jan 6 2021, 5:13 PM · Thumbor, Upstream, Wikimedia-SVG-rendering, Commons
Verdy_p added a comment to T270836: SVG renderer: missing support for font-variant="small-caps" and style="font-variant:small-caps".
Dans T270836#6715613, @Aklapper a écrit :

Steps to reproduce:

  1. Look at the SVG file https://upload.wikimedia.org/wikipedia/commons/archive/2/23/20201226141533%21Wikifunctions_wordmark.svg (that's "14:09, 26 December 2020" under "File history" on https://commons.wikimedia.org/wiki/File:Wikifunctions_wordmark.svg )
  2. Look at the corresponding PNG thumbnail for that SVG file.

Expected outcome:
The PNG thumbnail looks like SVG; All letters are upper case; all letters except for first letter have less height than the first letter

Jan 6 2021, 5:10 PM · Thumbor, Upstream, Wikimedia-SVG-rendering, Commons

Dec 28 2020

Verdy_p added a comment to T270836: SVG renderer: missing support for font-variant="small-caps" and style="font-variant:small-caps".

See https://upload.wikimedia.org/wikipedia/commons/archive/2/23/20201226141533%21Wikifunctions_wordmark.svg

Dec 28 2020, 3:51 AM · Thumbor, Upstream, Wikimedia-SVG-rendering, Commons

Dec 26 2020

Verdy_p created T270836: SVG renderer: missing support for font-variant="small-caps" and style="font-variant:small-caps".
Dec 26 2020, 2:33 PM · Thumbor, Upstream, Wikimedia-SVG-rendering, Commons

Dec 20 2020

Verdy_p added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.
Dec 20 2020, 2:17 AM · Patch-For-Review, patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata

Dec 14 2020

Verdy_p added a comment to T54687: Use IEC units (KiB, MiB, etc.) and not SI units (KB, MB).

I agree keeping those unchanged as SI units:

  • MediaWiki:Size-kilobytes
  • MediaWiki:Size-megabytes
  • MediaWiki:Size-gigabytes
  • MediaWiki:Size-terabytes
  • MediaWiki:Size-petabytes
  • MediaWiki:Size-exabytes
  • MediaWiki:Size-zetabytes this should be renamed as MediaWiki:Size-zettabytes
  • MediaWiki:Size-yottabytes
Dec 14 2020, 11:21 PM · Platform Team Workboards (Clinic Duty Team), Patch-For-Review, WorkType-NewFunctionality, MW-1.27-release-notes, Multimedia, MediaWiki-General

Dec 9 2020

Verdy_p added a comment to T261460: Pair a function with its inverse function for testing.

Do we need a separate name for inverse functions?
After all a function is just a relation associating some ordered items from several sets, stating that, when the items are properly ordered, they form a tuple that is part of the set of tuples represented by the relation (independantly of their inner side-effect, but if there are side-effects, they should apply to two other items added to the tuple: the "input" state and the "output" state (including errors of executions or exceptions thrown and their own properties).
So we don't really need to make a distinction between inputs and outputs, they are just items in the ordered tuple; the subset of what is input or what is output does not matter if we want to be purely function. What really matters during the evaluation is to check that the tuple is a member or not of the relation, and an evaluator can as well resolve any function as a relation, i.e. as if it was an enumerator of tuples it contains: so we can bind any value to any input or output, the code of the "function" will see what is bound and will return an enumerator whose result will be either:

  • an empty sequence (this is not a solution, the tuple is not member of the relation)
  • a singleton sequence (this is the unique solution, what was an unbound variable is resolved to a single value; if all variables were bound, the enumerator will return the same tuple in the sequence to assert that the tuple is a valid member, but if it returns an empty sequence, we kwno that the proposed tuple was not a solution); it may also return a singleton containing unbound variables: this is exactly like an object data type, but can be reused later for further inferences.

You could design multiple implementations of the function, actually a relation, they can be tried and run in parallel to see which one reduces the number of unbound variables, so you have several enumerators returned whose state (empty, singleton or sequence, and number of unbound variables) can be used to make inferences even if not all variables are bound (e.g. when we don't care aboutr the value of the unbound variables but just to see if the relations offers solutions or not, and for which bound values of any variable)

Dec 9 2020, 12:51 AM · Abstract Wikipedia team

Dec 8 2020

Verdy_p added a comment to T95553: Full stop in messages such as Wikibase-time-precision-century is incorrect in English.

Note that the presentation "9e siècle" in French is readable but defintely not the prefered one:

  • it should really use roman digits (preferably in small-capitals for centuries, but plain-capitals like for millenia are OK)
  • the ordinal suffix "e" (or "er" only for 1st) is normally in superscript.
Dec 8 2020, 11:33 AM · Patch-For-Review, patch-welcome, MediaWiki-extensions-WikibaseRepository, I18n, Wikidata

Dec 4 2020

Verdy_p added a comment to T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.

There's no reason to close this: the translations in TWN are used as part of the installed data for Phabricator and must then be checked. So it is really a bug of the Phabricator project itself, even if this comes from data imported from TWN, but for a translation package created and submitted to TWN by the Phabricator project itself.

Dec 4 2020, 9:30 PM · Patch-For-Review, Phabricator, I18n
Verdy_p reopened T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years ! as "Open".
Dec 4 2020, 5:55 AM · Patch-For-Review, Phabricator, I18n
Verdy_p added a comment to T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.

Note that it is not correct either in English (see the screenshots!). In fact it is broken in ALL locales preferences, which are mixed incorrectly.
Aklapper: did you only check anything before early deciding this was "invalid" when it is easy to reproduce and see? Did you look at the provided screenshots clearly annotated?
Just look at any bug that lags nbehind since long: the dates indicated are insufficient. The code justr makes assumptions about dates not lagging more than 1 month...
I can set the locale to English and it is still all messed.
I I found no date settings in the preferences that work correctly (not even when selecting ISO 8601 explicitly).
And your comment about translatewiki.net is very unlikely. It is correct as it is, but the code of Phabricator certainly makes false assumptions about date formats.

Dec 4 2020, 5:51 AM · Patch-For-Review, Phabricator, I18n

Dec 3 2020

Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 10:19 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 10:18 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 10:17 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 10:08 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 10:01 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:58 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:56 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:55 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:54 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:50 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:48 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:48 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:44 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:40 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:39 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:38 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:37 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:36 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:35 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:34 AM · Patch-For-Review, Phabricator, I18n
Verdy_p updated the task description for T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:33 AM · Patch-For-Review, Phabricator, I18n
Verdy_p created T269339: incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !.
Dec 3 2020, 9:32 AM · Patch-For-Review, Phabricator, I18n

Nov 21 2020

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

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

Nov 12 2020

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.

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

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

Nov 12 2020, 1:14 AM · WikiLambda, Epic, Abstract Wikipedia team (Phase ι)

Nov 3 2020

Verdy_p added projects to T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue: Commons, Mobile.
Nov 3 2020, 5:04 PM · translatewiki.net, I18n
Verdy_p updated the task description for T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue.
Nov 3 2020, 5:02 PM · translatewiki.net, I18n
Verdy_p updated the task description for T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue.
Nov 3 2020, 5:02 PM · translatewiki.net, I18n
Verdy_p updated the task description for T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue.
Nov 3 2020, 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.
Nov 3 2020, 5:00 PM · translatewiki.net, I18n
Verdy_p created T267142: [[Wikimedia:Commons-android-strings-contributions subtitle]] translation issue.
Nov 3 2020, 4:59 PM · translatewiki.net, I18n

Oct 26 2020

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.

Oct 26 2020, 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 team: Verdy_p.
Oct 16 2020, 6:54 PM
Verdy_p added a member for Abstract Wikipedia team: 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