Verdy_p (Philippe Verdy)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Sunday

  • Clear sailing ahead.

User Details

User Since
Feb 23 2015, 1:39 AM (169 w, 4 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Verdy p

Recent Activity

Sun, May 6

Verdy_p added a comment to T176370: Migrate to PHP 7 in WMF production.

What was off-topic was the sentence I commented: "proposals seen as an attack". Which is completely wrong. Thaere's nothing bad in making proposals and this is not attacking any one or any existing project. It's just about reevaluating the choices that were made years ago under assumptions which may no longer be true. Yes we have put Mediawiki into creating its own isolated ecosystem with just smaller support, and most people in wikis do not how to use this old Lua specification (and its many limitations). Now Lua in Wikimedia servers is draining too much resources and we all want to have wikis that are faster (and it's not just about choosiung between HHMV or PHP7, when there's only a very minor or in fact no measurable or significant performance improvement)
What makes a real performance differnece is the way the frameworks deloped on top of HHVM or PHP are written and if they can benefit of newer versions, optimisations and securisation efforts. Mediawiki tends to be more and more isolated from the worldwide developments. We should not isolate ourself from this trend, as the gaps of technologies is now dangerously increasing, we'll get less users, less developers and this will finally affect also Wikimedia sites if only a few highly specialized users can use it and finally control all the content and bloc kits evolutions. We should be more open.

Sun, May 6, 12:11 PM · TechCom-RFC (TechCom-Approved), User-ArielGlenn, HHVM, MediaWiki-Platform-Team, Operations
Verdy_p added a comment to T176370: Migrate to PHP 7 in WMF production.

"proposals as an attack" ? Strange attitude. I's easy to see that Lua is in fact very slow compared to modern JS engines. And it is damn more complex to program than JS. It also drains more resources (CPU and memory). There used to be some good use cases for LUA in the past that JS did not support but since JS version ES5 and even more since ES6, there's no real difference in use cases; And JS now benefits from a lot more developers for their engines and for securing the exposed APIs or checking and enforcing the conformance requirements.
I'm sure that many admins choosing Mediawiki would like to integrate JS scripting. Many wikis (notably those runnign on small servers, not like those large farms used by Wikimedia) have banned using Scribunto/Lua.. And too many mediawiki users do not want to learn another scripting language and would prefer using JS because it has many more training resources available for them (Lua looks so much "exotic" with its "metatables" and compelx handling of datatypes, default values).

Sun, May 6, 11:45 AM · TechCom-RFC (TechCom-Approved), User-ArielGlenn, HHVM, MediaWiki-Platform-Team, Operations

Sat, May 5

Verdy_p added a comment to T176370: Migrate to PHP 7 in WMF production.

Note that PHP is still only marginally faster than HHVM, only starting since PHP 7.2. HHVM is still faster than PHP 7.1 and PHP 7.0 in terms of requests/second (this was measured for Wordpress, another text templating and CMS system similar to Mediawiki in many use cases).
Some tests reveal that PHP 7.0+ will be faster than HHVM when there are some plugins, because integration of plugins within PHP is probaly easier and faster than in HHVM: this could be the case here to allow Mediawiki coexist with other server-side extensions used by Wikimedia (notably Scribunto for Lua, where the coexistence of the HHVM and Lua VMs may compete for the same system resources, notably for managing memory). However most Mediawiki-based wikis do not even use or want Scribunto and Lua.
The main reason for getting back to PHP is probably based on long term evolution (but I don't tthnk that HHVM itself is suddenly terminated, and that Facebook will stop supporting it, unless Facebook considers that HHVM development is no longer needed as all it wanted in PHP is now integrated in the main branch of PHP (and PHP itself is continuing to improve the speed ot its own VM and JIT compiler, notably with contributions made and sold by Zend and): PHP will probably include new features that may take time or would be complex to port back in HHVM, if this requires them to rewrite significant part of the JIT, and secure the code (think about the nightmare caused by Spectre/Meltdown: there are probably many more developers tracking the issue of resistance to time-attacks in PHP, than in HHVM, simply because many more sites use PHP, and HHVM is rarely proposed and supported by hosting providers which still love PHP they don't have to support directly as it has a larger community of fans and developers finding tricks, workarounds when something has to be replaced or removed: PHP is much easier to maintain and tweak to these needs, and is also vastly more portable on different architectures of CPUs/networks/storages/OSes and PHP is reailly easy to deploy in virtual or distributed cloud environments, with less restrictions than HHVM, and PHP can run on smaller systems, which is also a goal for MediaWiki to be usable on small sites...).

Sat, May 5, 11:07 PM · TechCom-RFC (TechCom-Approved), User-ArielGlenn, HHVM, MediaWiki-Platform-Team, Operations
Verdy_p added a comment to T184664: Install Noto fonts on scaling servers for SVG rendering.

So you just installed only a subset of Noto fonts for just a few *scripts* but not even all the scripts already used in Wikimedia projects...
Why are most "minor" scripts from Asia and Africa ignored?
How do you plan to update these fonts when the Noto package continues evolving and being refined (updates to newer Unicode versions, new supported clusters and dependant forms, updates to OpenType specs, improved hinting, introduction of "variable" styles which allow tuning the blackness of fonts to the size and device color/diffusion profiles better than what hinting alone could produce, better adaptability to 3D rendering, support for more than 1 implicit foreground color, support for variable alpha-transparency in glyphs and various effects that come from OpenGL and SVG, new table lookup formats for large fonts, font linking, new data compression schemes, and special properties for accessibility and device-dependant rendering, plus many fixes needed for better legibility and distinction or better placement of diacritics, improved kerning table, and also faster processing on common OSes like Windows, MacOS, Linux, Android, iOS, improved font properties for easier selection of fonts, inclusion of sample texts for languages where the font was tested.).
Unlike most free fonts and most commercial fonts, these Noto fonts are in constant evolution, it is a very active project with lots of participants, and still they are extremely stable.
These fonts form a single unified set, they are maintained in sync and are interdependant as they share some identical basic subsets and are tweaked so their mutual metrics are compatible (it is especially important to support multilingual texts.

Sat, May 5, 8:44 PM · Patch-For-Review, Operations, Commons, media-storage, Wikimedia-SVG-rendering

Apr 17 2018

Verdy_p added a comment to T55130: Categories should be displayed in a responsive table and be mobile friendly..

If using CSS multicoluln layout, prefer using column-width rather than column-count (even if the specified value 3 is small). And please avoid specifying the width in absolute units, use font-size relative units according t othe text content (this is also needed for accesbility, as users may want to have larger font sizes).

Apr 17 2018, 6:35 PM · Patch-For-Review, MediaWiki-Categories
Verdy_p added a comment to T55130: Categories should be displayed in a responsive table and be mobile friendly..

Rather than CSS multi-column blocks, may be we should use CSS flex layout (which can still have a fallback to multicolumn), to give consistant presentation of cells without undesired column-breaks (flex layout is on a grid but with implicit rows which can be vertical or horizontal, and where full cells can be wrapped and still maintain their alignment.
The fFlex layout is very used on mobile sites (and implemented in all mobile browsers) as it allows a great flexibility of formats, and better accessibility for touch. They have the clean layout of tables, but without forcing a static number of columns or rows, and allow designing the UI so it will get only one scrollbar (horizontal or vertical), never two and it is well suited for mobile phones which can be easily rotated between paysage and portrait. They work magically for all the builtin UI of the OS (e.g. in config menus) and for most apps.
The only problem is flex layout is still new on desktop browsers and some old desktop browsers (and some old browsers for smartTVs that don't rotate and frequently have antique renderers) don't have it (but the same devices also have problems for multicolumn and support of tables is frequently full of bugs/caveats or require device-specific developments and severe degradation of UI features, so I doubt Wikis are even usable on these devices; I think that users that have these device don't use it really to browse the net, and will still have more recent and decent smartphones or tablets; given the lifetime of mobile devices which is roughly 3 years, and flex design and modern browsers implementing it on these mobiel devices have been on market since more than 5 years, I don't think the flex layout will cause compatibility problems; in fact there's probably now a better support for flex layout than multicolumn which was intended for paged devices, i.e. printing, or desktop on large screens in landscape mode).

Apr 17 2018, 6:33 PM · Patch-For-Review, MediaWiki-Categories

Mar 7 2018

Verdy_p added a comment to T187181: [[MediaWiki:Babel/am]] i18n issue.

May be closed now, the bug is solved for this string, but may a a TODO task can be made to check similar problems and prevent them to occur later at any time in any language (double vertical bars should not exist within square brackets).

Mar 7 2018, 11:47 PM · MediaWiki-extensions-Babel

Mar 6 2018

Verdy_p added a comment to T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end.

How users without Javascript upload files ? There's a special page for that and it should still continue to offer the legacy upload form not requiring any javascript, but using form submissions to the server and input fields for the file, the description, and a way to select the licence. All wikis have this form (or should continue to have it). The javascripted version is just an helper which can be lauched to automate various thinkgs or update the form dynamically.

Mar 6 2018, 9:30 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard
Verdy_p added a comment to T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end.

Note also that this new UploadWizard requires Javascript.

Mar 6 2018, 8:11 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard
Verdy_p added a comment to T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end.

Thanks now, at least the problem the recognized and correctly solved. (Of course you'll need to maintain the code so the generated localized URLs will be correct for the languages displayed.

Mar 6 2018, 8:09 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard
Verdy_p added a comment to T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end.

Then you should remove completely this now misleading alert in the "/qqq" documentation:

Mar 6 2018, 5:26 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard

Mar 5 2018

Verdy_p added a comment to T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end.

Initially I thought that the code was running on the server, but I see here that this code is implemented on the client side by loaded javascript, and it does not have any MediaWiki parser builtin.
From what I see, the generation of the content in Javascript is using jQuery to generate HTML tags, and all other text elements are "HTMLized" by the javascript msg() method (which seems then to take the message from the server by querying it for the content of "Mediawiki:message/*".

Mar 5 2018, 3:04 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard
Verdy_p added a comment to T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end.

It seems that what changed was in the .msg() method used in that code, which enforced the HTML-ization of the message (possibly because of security against malicious injection of malicious active HTML, including javascripts and events running in the user agent). Here the parameter of msg is directly the message coming from Translatewiki.net.

Mar 5 2018, 2:49 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard

Mar 3 2018

Verdy_p added a comment to T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end.

This has never been a critic against people, but statements only about the code itself (there's no assumption at all with the addition of the adjective "your", this is not personal offense but means what it means: what "you" support)

Mar 3 2018, 6:55 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard
Verdy_p added a comment to T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end.

"Your" code is the code that "you" want to support, even if it was written initally by someone else. It does not mean it belongs only to you or the initial author of course.
We must find a way to solve this recurring problem. There's an unseen bug, and it's definitely not in TranslateWiki.net but on incorrect assumptions about what Translatewiki.net does or does not perform or how it works. The initial developer was not aware of such caveat. This code was never tested correctly before it was deployed in January on Commons.
(and the initial solution that worked on Commons before January used HTML comments without problems).
It's not something new because the problem was already signaled multiple times last year: the project was incorrectly prepared for translatability on Translatewiki.net and it broke Commons only when the new UploadWizard was deployed there without proper tests with translations (it was visibly tested only in English).

Mar 3 2018, 6:12 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard
Verdy_p added a comment to T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end.

You necessarily use some forme of parsing of the string to change the wiki notation of external links (between [] brackets) into plain HTML links.

Mar 3 2018, 5:37 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard
Verdy_p reopened T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end as "Open".
Mar 3 2018, 4:29 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard
Verdy_p added a comment to T188818: German translation of CC radio button texts in UploadWizard display "<!--$2-->" at the end.

This is definitely a bug of the beta upload wizard which does not parse the basic wiki syntax correctly (including core HTML for comments).
For some unknown reasons, it parses it incompletely (to find links between [bracket]) then HTMLizes everything else (meaning that basic HTML needed for some translations will never render correctly.
This resource is to be valid Wikitext and usable on all wikis (not jsut this beta version of the Upload tool currently now deployed only in Commons)

Mar 3 2018, 4:29 PM · MW-1.31-release-notes (WMF-deploy-2018-03-06 (1.31.0-wmf.24)), Multimedia, UploadWizard
Verdy_p added a comment to T132307: [[MediaWiki:And/fr]] uses encoded leading space (wrong for some East Asian languages).

I don't know why I am assigned this task as I cannot resolve it myself in Mediawiki ! I just want to be notified (i.e. only a subscriber)...

Mar 3 2018, 11:02 AM · Chinese-Sites, MediaWiki-Special-pages, MediaWiki-General-or-Unknown, I18n
Verdy_p placed T132307: [[MediaWiki:And/fr]] uses encoded leading space (wrong for some East Asian languages) up for grabs.
Mar 3 2018, 11:02 AM · Chinese-Sites, MediaWiki-Special-pages, MediaWiki-General-or-Unknown, I18n
Verdy_p added a comment to T183465: Make Extension:ParserFunctions convert localized digits to arabic numerals in #(if)expr and #time.

I think it would be ok to support all digits in any known scripts that have decimal digits (i.e. the "Nd" generic property in Unicode).

Mar 3 2018, 10:35 AM · I18n, MediaWiki-extensions-ParserFunctions
Verdy_p updated the task description for T188790: {{#ifexist:{{FULLPAGENAME}}|...|...}} incorrectly counted as costly.
Mar 3 2018, 10:15 AM · MediaWiki-extensions-ParserFunctions

Mar 2 2018

Verdy_p created T188790: {{#ifexist:{{FULLPAGENAME}}|...|...}} incorrectly counted as costly.
Mar 2 2018, 10:57 PM · MediaWiki-extensions-ParserFunctions

Feb 23 2018

Verdy_p added a comment to T172035: Blockers for Wikimedia wiki domain renaming.

Note that renaming a wiki or changing its internal database or domain name is not mandatory. All we need is to support the correct interwikis, and stop polluting Wikidata with fake language codes for its translations (Wikidata should use "en-simple" even for linking to Wikipedia, and it's perfectly possible to alias the domain name). Only a minor modification of known interwiki codes is needed so that it points to the correct domain name even if it's not changed.
Renaming databases is not absolutely necessary. Some pywiki bots will need to be upated to know also the new interwiki alias.
After years, and with other pending renames or creations, we should know now exactly where and how to centralize such maintenance for lists of language codes supported, fallbacks, updates to Translatewiki.net and its import bot.
And so we should also deprecate legacy codes we still use on Translatewiki.net (we should not pollute other non-wikimedia projects hosted there, even if there are now warnings on this site for such legacy private codes, notably on its language portals and their associated categories), as well as all Wikidata entries in properties that are NOT links to Wikipedia. We're reaching the point where complete cleanup can be terminated. For Wikidata it's an important goal to have it established as an important standard, as useful and powerful as CLDR.

Feb 23 2018, 2:53 AM · Wikimedia-Site-requests
Verdy_p added a comment to T172035: Blockers for Wikimedia wiki domain renaming.

Note also that this initial bug was really started many years ago, before that BCP47 registration only two years ago (before even this thread in Phabricator when it imported all bugs from former bug trackers)

Feb 23 2018, 2:43 AM · Wikimedia-Site-requests
Verdy_p added a comment to T172035: Blockers for Wikimedia wiki domain renaming.

Sorry, I should have checked if it had been recently registered (so only "simple" is not conforming and breaks BCP47 resolvers by forcing us to implement a custom fallback to "en" instead of the standard BCB 47 fallback of "en"); various templates are already converting "simple" to "en-simple" but there may remain a few that use "en-x-simple" to be compliant with HTML/CSS/XML lang="*" attributes, and with standard i18n libraries

Feb 23 2018, 2:40 AM · Wikimedia-Site-requests

Feb 14 2018

Verdy_p added a comment to T33097: Automatically created categories should be categorized: xx-y in xx, xx in <babel-footer-url>'s category.

Autocategorization should probably be configurable so that it will generate a category page containing a local template transclusion such as

  • {{Babel category|da|N}} (per level) or
  • {{Babel category|da}} (all levels for the language).

(This is the same solution as the exposed template used in huwikisource, and implemented in https://gerrit.wikimedia.org/r/#/c/332332/6/BabelAutoCreate.class.php, except that this patches enforces the generation of a parent category in the autocreated per-level category, which may not be appropriate: the "Template:Babel category" can add this itself, the autocreation bot of Babel does not need to do that itself).

Feb 14 2018, 8:38 AM · Patch-For-Review, Google-Code-In-2016, MediaWiki-extensions-Babel
Verdy_p added a comment to T187181: [[MediaWiki:Babel/am]] i18n issue.

Can we check/lint these kind of errors in Babel resources ?

  • May be just grepping for '||' or '::' would find format problems (Translatewiki already checks unpaired brackets/parentheses).
  • There may be other errors such as unpaired HTML tags (e.g. sub/sup, which may be needed for some translations), not just for Babel but for other subprojects as well, or HTML tags paired incorrectly (<x>...<y>....</x>...</y>) which cause various problems (even in HTML5 if this occurs with block elements)
Feb 14 2018, 8:26 AM · MediaWiki-extensions-Babel

Feb 13 2018

Verdy_p reopened T187181: [[MediaWiki:Babel/am]] i18n issue as "Open".
Feb 13 2018, 1:25 PM · MediaWiki-extensions-Babel
Verdy_p added a comment to T187181: [[MediaWiki:Babel/am]] i18n issue.

It is valid because there's NO resource to translate in the Babel project on Translatewiki.net for these strings.
Yes it is specific to that single language (am), and that's what was in the initial report.
So reopen please, and check the format of your *i18n* JSON data which does not come from translations Translatewiki.net itself (there's no project for these strings, only for some generic strings of the Babel box).

Feb 13 2018, 1:24 PM · MediaWiki-extensions-Babel
Verdy_p updated the task description for T187181: [[MediaWiki:Babel/am]] i18n issue.
Feb 13 2018, 1:12 PM · MediaWiki-extensions-Babel
Verdy_p updated the task description for T187181: [[MediaWiki:Babel/am]] i18n issue.
Feb 13 2018, 1:12 PM · MediaWiki-extensions-Babel
Verdy_p triaged T187181: [[MediaWiki:Babel/am]] i18n issue as Normal priority.
Feb 13 2018, 1:11 PM · MediaWiki-extensions-Babel
Verdy_p added a comment to T187181: [[MediaWiki:Babel/am]] i18n issue.

The bug is here (line 14):
https://phabricator.wikimedia.org/diffusion/EBAB/browse/master/i18n/am.json

Feb 13 2018, 1:06 PM · MediaWiki-extensions-Babel
Verdy_p added a comment to T187181: [[MediaWiki:Babel/am]] i18n issue.

Note: the bug is in the internal i18n JSON datatables used by the Babel extension (in PHP)

Feb 13 2018, 1:02 PM · MediaWiki-extensions-Babel
Verdy_p created T187181: [[MediaWiki:Babel/am]] i18n issue.
Feb 13 2018, 1:01 PM · MediaWiki-extensions-Babel

Feb 12 2018

Verdy_p added a comment to T42255: Ask additional copyright questions of users claiming "own work".

The absence of categorization for new images is a good hint that there may be copyvio attempts, in order to use Commons as a repository for those stolen files that uploaders will want to maintain "hidden" from basic viewers.

Feb 12 2018, 7:50 PM · Multimedia, UploadWizard

Jan 31 2018

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

Can this issue be solved by creating instead separate namespaces ("Hani:" and "Latn:") in the cdo wiki for articles that are not mixing scripts and not using autotranslation? And then keep the "/wiki/" path unchanged (so that it will work correctly for interwikis with other languages).
This does not man that the UI cannot be separated in its translation, however this means that namespaces should have distinct default language codes using distinct scripts; The "Hani" part would have the Hans<->Hant transliterator handled as a variant selectable by viewers, but not between Hans<->Latn and Hant<->Latn.
Some common pages would remain in the main namespace only if they support autotranslation (via the translate extension, or via templates based on PAGECONTENTLANGUAGE or UI language where applicable to generic banners)

Jan 31 2018, 9:30 PM · MediaWiki-Internationalization, I18n

Jan 23 2018

Verdy_p added a comment to T172035: Blockers for Wikimedia wiki domain renaming.

@Liuxinyu970226 the current language "status" does not matter at all for this issue for any language. Do you think that I would be arguing that supporting Narom was not needed in Wikimedia ? Certainly no, I think that Narom should be supported. But which code to use for Jerriais is still not clear (nrf ?) even if it has an official status. But we really need to free the "nrm" code for Narom as it was standardized.. And you're just confirming that need too. So really we don't disagree on this.

Jan 23 2018, 8:15 AM · Wikimedia-Site-requests

Jan 21 2018

Verdy_p added a comment to T172035: Blockers for Wikimedia wiki domain renaming.

I said "deprecated" about the incorrect use of the code by Wikimedia, it
was NOT daying anything about the status of the languages. You're clearly
misreading (or don't want to read correctly).

Jan 21 2018, 1:51 PM · Wikimedia-Site-requests

Jan 6 2018

Verdy_p added a comment to T24985: Forcing the language for {{PLURAL}} rule.

If you design an autotranslated template and you cant to reuse it on the same page to show different rendering for different languages (e.g. in language learning pages showing differences between languages, you'll still be in trouble: the page itself is clearly intended to be multilingual with some subsections purposely NOT in the page main content language and explicit changes of language in the page itself (and not necessarily the user's prefered UI language).

Jan 6 2018, 1:10 PM · Plural-Support, I18n, MediaWiki-Internationalization

Dec 15 2017

Verdy_p added a comment to T172035: Blockers for Wikimedia wiki domain renaming.

Narom is another unrelated problem: "nrm" was an incorrect code for Norman and no aliasing between "nrm" and "nrf" should be kept if we want to have Narom contents.
So it's impossible to preserve the links to Norman contents except transitionally (but this must have an end).
Of course "nrm" must be completely freed to leave space to Narom (however we've still not seen for now any interested community in creating contents for Narom)
And subdomains is not really a blocker for creating contents in Incubator (where the language would only be a path).

Dec 15 2017, 2:47 PM · Wikimedia-Site-requests

Dec 14 2017

Verdy_p added a comment to T169450: Redirect several wikis.

It's not complicate to add "mo-x-old" to direct to the readonly archive of the "mo" wiki, now that "mo" redirects to "ro". At least the previous content remains accessible by their initial users

Dec 14 2017, 1:12 PM · Operations, Wikimedia-Apache-configuration, Puppet, Wiki-Setup (Close), Wikimedia-Language-setup
Verdy_p added a comment to T169450: Redirect several wikis.

About redirects keeping the title name: as the moldavian past page is most probably written in Cyrillic, forwarding to the same page name in Romanian will likely fail (especially in Wikipedia, but less in Romanian Wiktionary which should have separate pages for titles in Cyrillic, possibly listing about the same words written in other languages like Russian with definitions given in Romanian, and less for user pages as most users should have SUL enabled already).
So I suggest redirecting user pages and Wiktionary without change of tiltle, and redirect other pages through the search tool in Romanian. The Romanian search tool should be able to find matching articles (and talk pages) using the original Cyrillic name (if it exists) or the alternate page title written in Latin.
Now there remains work to do on the Romanian sites so that they behave correctly with Cyrillic written page titles (also add mappings to their namespace names in Cyrillic to match those that were in Moldavian sites), and yes the Latin<>Cyrillic transliterator support should be added there.

Dec 14 2017, 12:19 PM · Operations, Wikimedia-Apache-configuration, Puppet, Wiki-Setup (Close), Wikimedia-Language-setup
Verdy_p added a comment to T169450: Redirect several wikis.

The consensus was only to join the two communities so they create a joint content without dividing it, Blocking all accesses to past users contents is simply against all existing Wikimedia policies. The existing Moldavian was licenced correctly and not supposed to disappear completely and suddenly.

Dec 14 2017, 11:10 AM · Operations, Wikimedia-Apache-configuration, Puppet, Wiki-Setup (Close), Wikimedia-Language-setup
Verdy_p added a comment to T169450: Redirect several wikis.

The comity can decide what they want. It was NOT requested to *delete* Moldavian but merge it to Romanian. Dropping all Moldavian user contents is very unfriendly and Romanian users should not have any problem if they see the addition of a variant selector in their wiki (and especially for user pages and user talk pages, which is NOT in scope of decision of this VERY SMALL comity which did almost no contributions to these wikis !)

Dec 14 2017, 10:42 AM · Operations, Wikimedia-Apache-configuration, Puppet, Wiki-Setup (Close), Wikimedia-Language-setup
Verdy_p added a comment to T169450: Redirect several wikis.

"ro-latn" and "ro" are the same.

Dec 14 2017, 10:39 AM · Operations, Wikimedia-Apache-configuration, Puppet, Wiki-Setup (Close), Wikimedia-Language-setup
Verdy_p added a comment to T169450: Redirect several wikis.

So now with the redirect being active, you've dropped completely the capability of contributing and displaying the UI in Cyrillic. This should be restored at least with an active transliterator.
Without it, I'm sure that Moldavian users are really unhappy (some of them possibly furious) as we force them to have the UI completely written in English Latin.
Also the previous Moldavian site should still be accessible in readonly mode (notably user pages so that users can retrieve their profiles and setup their new user page on the Romanian site.
the previous content "mo.*.org" should remain accessible via "mo-x-old.*.org" and the Moldavian databases '''not''' deleted but only made readonly.

Dec 14 2017, 10:34 AM · Operations, Wikimedia-Apache-configuration, Puppet, Wiki-Setup (Close), Wikimedia-Language-setup
Verdy_p added a comment to T169450: Redirect several wikis.

Note also that "uselang=mo" really displays a Romanian-Cyrillic UI, but "uselang=ro-latn" just renders as an English UI !!! This is still a bug as we should at least see the UI in Romanian as a fallback, possibly via the transliterator to Cyrillic.
The internationalization libraries should be updated, and existing Moldavian translations in translatewiki.net (with "mo" should be reimported there to "ro-latn" and possibly reviewed).

Dec 14 2017, 10:26 AM · Operations, Wikimedia-Apache-configuration, Puppet, Wiki-Setup (Close), Wikimedia-Language-setup
Verdy_p added a comment to T169450: Redirect several wikis.

Moldavian: about the renaming/redirect from "mo.wiki(pedia|dictionary).org" to "ro.wiki(pedia|dictionary).org", this should not alter the pagename (the path)

Dec 14 2017, 10:21 AM · Operations, Wikimedia-Apache-configuration, Puppet, Wiki-Setup (Close), Wikimedia-Language-setup

Dec 9 2017

Verdy_p added a comment to T172035: Blockers for Wikimedia wiki domain renaming.

T133548 is about certificates for HTTPS. if we create a CNAME of a subdomain project to another subdomain, it should have no impact if the certificate allows not just specific subdomains but its parent domain (e.g. wikipedia.org): there are hundreds of subdomains and having one certificate for each one is costly.

Dec 9 2017, 4:16 PM · Wikimedia-Site-requests

Sep 16 2017

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

PAGELANGUAGE is NOT the correct one. It was the user language that was expected (we won't have per-language categories, category pages won't be translated, the navbox was intended to provide coherent international navigation independantly of the English name of the categories, and without having to create and edit many translations within the page itself (this is about tens of thousands of categories). This PAGELANGUAGE would be a severe return backward where only English will be displayed on Commons.

Sep 16 2017, 1:36 PM · Performance, I18n, MediaWiki-Internationalization

Sep 14 2017

Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

And I disagree: T173194 / T173262 are not enough (they concentrate only on selective label queries, but not on selective property queries, such as T142903 for getting site links) and many other similar queries for other properties. Nothing has changed for https://commons.wikimedia.org/wiki/User:Zhuyifei1999/sandbox/3 which still does not work at all and whose FALSE result gets truncated SILENTLY (here the solution has caught the exception just to discard it, and this is probably worse than having an explicit error) !

Sep 14 2017, 2:32 AM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons
Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

It was in scope of this bug when it was first open (but then reduced by altering its title) At that time the internal HHVM behavior was not even understood. what was reported was a crash starting to occur for an unknown cause (when the page was working before).

Sep 14 2017, 2:27 AM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons

Sep 13 2017

Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

So it solves a part of the problem, but instead of having one kind of error, we have now another error (a bit more informative, but still not solving the memory overuse problem, as seen in https://commons.wikimedia.org/wiki/User:Zhuyifei1999/sandbox/3 where there are missing items in the list and too much memory used by wikidata queries for localized labels and localized wikipedia targets).

Sep 13 2017, 10:07 PM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons

Sep 11 2017

Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

Note that one or the three bugs I listed are still present, see this sample:
https://commons.wikimedia.org/wiki/User:Zhuyifei1999/sandbox/3

Sep 11 2017, 11:08 AM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons
Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

If you want a similar kind of errors (memory overuse by Wikidata client in Lua) look at

Sep 11 2017, 9:15 AM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons
Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

Thanks now you locate the only real problem:

No, the real problem here is the fact that Lua errors are being caught by HHVM.

Sep 11 2017, 8:51 AM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons
Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

@Jarekt, your cleanup has changed the list of fallbacks. Commons had more fallbacks than the default in Mediawiki (what you have named now "old fallback list in Commons" in your comments, and reported by the last function present in the modulewhere you've unexpectedly also reordered the implemented functions that were listed in dependency order)

Sep 11 2017, 8:31 AM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons

Sep 7 2017

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

Any way used by {{int:Lang}} and implemented internally by the {{int:}} parserfunction that will always need to get the correct user language should be still be made available even if we don't manually create the MediaWiki:Lang/* resources (because the "int:" extension can already internally recognize the resource name and does not need to query the database to retrieve these fake pages, all it has to do is still to get the correct user language code for any kind of {{int:*}} message needed by the Mediawiki core itself; I think it also adds some work to also mark specially the expanded pages so that they will be cached separately according to the user language)
The same should then be made for Lua, by adding into Scribunto supporting the {{#invoke:}} extension a basic module that will do the same thing as what the {{int:}} extension does, using the same logic for cache management and to return the same language code: it should then be exposed into Lua by a "mw:userLanguage()" that won't require any use of "frame:prepropress()" with its unbelieavable, and undocumented side-effects (notably the fact it fully expands prematurely all text in parent frames instead of just the wikitext given in its single string parameter !)

Sep 7 2017, 4:25 PM · Performance, I18n, MediaWiki-Internationalization
Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

My understanding of the situation is:

  • HHVM rather than Lua catches the error when the Lua memory limit is hit.
  • That can result in "503, Service Unavailable" responses.

Correct. In particular, HHVM generates a fatal error when it catches the Lua error.

This is not directly related to the 503 issue. But it's an indication of the sort of Lua errors that might be causing the bug in luasandbox to manifest.

In particular, this bug will be closed when the memory errors stop causing the 503 errors, even if the Commons template is still hitting the memory limit. If people want to track the work of improving that template in Phabricator, I'd recommend splitting it off into another task. Or you're welcome to track it on Commons if you'd rather.

  • Line 58 expands the first of 'en', 'default', or 'nocat' that isn't nil.

No, it does not expand anything there. It does only test is they are nil or not nil:

Yes, it does. Your denying the fact does not change it.

args = mw.getCurrentFrame():getParent().args

only to retrieve the list of arguments as an array (without asking for their expansion).

Correct, there's no expansion in the quoted line. But no one ever said there were expansions happening on that line (line 59).

  • Line 61 expands 'lang'.

No problem here.

I never said it was a problem. I was pointing out that it is an expansion of an argument, since you claimed that you didn't know where any argument expansions were occurring.

  • Line 65 expands all arguments, if that line is reached (i.e. 'lang' isn't provided or is empty).
    • That could be avoided by using frame:callParserFunction( 'int', 'lang' ) instead of frame:preprocess( "{{int:lang}}" ).

I don't see how this can save anything, this should be functionally equivalent and will expand the same amount of text.

frame:callParserFunction passes explicit arguments to the parser function without doing any expansion of the arguments itself. frame:preprocess processes arbitrary wikitext in the context of a frame, which means all that frame's arguments are available for use. And as I mentioned earlier, to avoid T47684 that means that all the arguments have to be pre-expanded (or we'd need to do complex things to the frame to be able to catch the expansion of each argument and exempt them from the time usage tracking).

Sep 7 2017, 3:22 PM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons
Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

I don't know where Module:Fallback "expands" any argument,

That's clear enough. But just because you don't know it doesn't mean it isn't happening, so your reasoning based on that assumption is faulty.

Glancing at the current version of c:Module:Fallback, I see several argument expansions in the course of a call to the langSwitch method.

  • Line 58 expands the first of 'en', 'default', or 'nocat' that isn't nil.

No, it does not expand anything there. It does only test is they are nil or not nil:

Sep 7 2017, 9:44 AM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons
Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

In addition I think the major problem is actually not here but with these two bugs, that are the real cause of excessive memory usage.

Sep 7 2017, 9:30 AM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons

Sep 6 2017

Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

Note that the current "kludge" using "nowiki" to avoid immediate expansion works. It proves that lazy expansion of template or module parameters works! This is the way to go, but we should not need to use such "nowiki"/"unwiki" trick in out templates.

That's a problem in Module:Fallback expanding more arguments than necessary, not a problem in MediaWiki.

Sep 6 2017, 5:19 PM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons
Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

Note that the current "kludge" using "nowiki" to avoid immediate expansion works. It proves that lazy expansion of template or module parameters works! This is the way to go, but we should not need to use such "nowiki"/"unwiki" trick in out templates.

Sep 6 2017, 8:20 AM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons
Verdy_p added a comment to T171392: Some Commons pages transcluding Template:Countries_of_Europe HTTP 500/503 due to OOM in Lua→PHP→Lua calls.

The Module:Country version is not needed at all (and in fact it is badly named). There was no issue until recently when something got changed in MediaWiki causing unnecessary expansions (notably since MediaWiki 1.28 and later, where lazy/delayed expansion is no longer used as it was before, causing ALL template (or modules) parameters to be expanded even if they are not to be returned and will be unused.
This is another case of regression in MediaWiki 1.28 that caused lot of nightmares (including problems with defered tasks/background workers that no logner work as expected and crash now in lot of wikis):
I don't understand why full expansion of parameters is needed immediately: for Mediawiki templates it should never be necessary. But if you pass parameters to a Lua modules, I wonder how Lua modules will react if they receive parameter values that are still not expanded and will auto-expand on first evaluation.
These memory exhaustion come from this full expansion of parameters. This causes lot of crashes in wikis running on small servers, or heavy load on them (and their incability to support as many coincurrent requests as before or severe degradation of performance with lot of I/O caused by heavy swaps to disk, and many concurrent tasks will crash or too many objects will be flushed too early from caches and will need to be regenerated on next evaluation, this can cause the same parameter which was lazily expanded to be expanded multiple times, because the previous evaluation was lost but its allocated memory was still not garabage collected).
There was no such problems with MW 1.27 and we did not need so many defered jobs and had much smaller job queues. MediaWiki 1.28+ is a failure since the begining, and none of the following versions or patches have solve this problem.

Sep 6 2017, 8:17 AM · Patch-For-Review, Wikimedia-log-errors, MediaWiki-extensions-Scribunto, Operations, Commons

Aug 25 2017

Verdy_p updated the task description for T173966: Like nan.wikipedia.org, redirect other nan.*.org to the proper zh-min-nan.*.org domains.
Aug 25 2017, 12:05 AM · Traffic, Operations, Wikimedia-Apache-configuration, DNS
Verdy_p updated the task description for T173966: Like nan.wikipedia.org, redirect other nan.*.org to the proper zh-min-nan.*.org domains.
Aug 25 2017, 12:03 AM · Traffic, Operations, Wikimedia-Apache-configuration, DNS

Aug 24 2017

Verdy_p added a comment to T173966: Like nan.wikipedia.org, redirect other nan.*.org to the proper zh-min-nan.*.org domains.

All this was caused by changes in dependencies in a parent task that was closed by moving it elsewhere without fixing what was in it.
It's true that this did not concern only Wikipedia (and that's why the task was already open and kept stalled bfore being closed prematurely... and forgotten in dependencies between tasks and project boards where they were also kept untriaged since long)

Aug 24 2017, 11:48 PM · Traffic, Operations, Wikimedia-Apache-configuration, DNS
Verdy_p added a comment to T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia.

Note: "als" was historically used on Wikimedia wiki projects as an interwiki code and a subdomain name for the projects, coming from an informal abbreviation of Alsatian.

Aug 24 2017, 4:56 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p moved T10217: Wikipedias with zh-* language codes waiting to be renamed (zh-min-nan -> nan, zh-yue -> yue, zh-classical -> lzh) from Backlog to Site configuration on the Chinese-Sites board.
Aug 24 2017, 4:07 PM · Wiki-Setup (Rename), Goal, Wikimedia-Language-setup
Verdy_p added a project to T10217: Wikipedias with zh-* language codes waiting to be renamed (zh-min-nan -> nan, zh-yue -> yue, zh-classical -> lzh): Chinese-Sites.
Aug 24 2017, 4:06 PM · Wiki-Setup (Rename), Goal, Wikimedia-Language-setup
Verdy_p added a comment to T173966: Like nan.wikipedia.org, redirect other nan.*.org to the proper zh-min-nan.*.org domains.

I did '''not''' made that request, it was there since years but not triaged like other pending renames all related to the Chinese language variants.
server-side redirects (for website URLs) are not the same thing as renaming wikis which includes several other operations.

Aug 24 2017, 3:50 PM · Traffic, Operations, Wikimedia-Apache-configuration, DNS
Verdy_p updated the task description for T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia.
Aug 24 2017, 3:27 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p raised the priority of T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia from Low to Normal.
Aug 24 2017, 3:27 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p updated the task description for T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia.
Aug 24 2017, 3:17 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p updated the task description for T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia.
Aug 24 2017, 3:15 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p edited projects for T169450: Redirect several wikis, added: Wiki-Setup (Rename); removed DBA.
Aug 24 2017, 3:03 PM · Operations, Wikimedia-Apache-configuration, Puppet, Wiki-Setup (Close), Wikimedia-Language-setup
Verdy_p updated the task description for T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia.
Aug 24 2017, 2:57 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p updated the task description for T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia.
Aug 24 2017, 2:55 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p added a comment to T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia.

Note that "als" also pollutes Wikidata and many other wikis or projects assuming conformance to BCP47.
Looking for localized names in Wikidata from these projects may return unexpected names translated in Alsatian/Allemanic (with possible fallbacks to German, i.e. "de") when they would expect Tosk Albanian (with most often a fallback to Standard Albanian "sq").
Talking only about the absence of need for Wikipedia to distinguish Albanian variants with distinct full wiki projects is reducing the problem that invalid codes incorrectly reassigned to completely unrelated languags in Wikimedia wikis, creates a pollution and bugs in many other third party projects, both open sourced or open data, or closed.

Aug 24 2017, 2:55 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p updated the task description for T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia.
Aug 24 2017, 2:44 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p moved T22547: Update non-standard language codes in the projects from Backlog to Wiki rename requests on the Wikimedia-Language-setup board.
Aug 24 2017, 2:33 PM · Wikimedia-Language-setup
Verdy_p moved T169450: Redirect several wikis from Backlog to Wiki rename requests on the Wikimedia-Language-setup board.
Aug 24 2017, 2:32 PM · Operations, Wikimedia-Apache-configuration, Puppet, Wiki-Setup (Close), Wikimedia-Language-setup
Verdy_p moved T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia from Backlog to Wiki rename requests on the Wikimedia-Language-setup board.
Aug 24 2017, 2:22 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p merged T25215: Rename the als.*.org projects to gsw.*.org into T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia.
Aug 24 2017, 2:20 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)
Verdy_p merged task T25215: Rename the als.*.org projects to gsw.*.org into T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia.
Aug 24 2017, 2:20 PM · Wiki-Setup (Rename), Wikimedia-Language-setup
Verdy_p updated the task description for T25215: Rename the als.*.org projects to gsw.*.org.
Aug 24 2017, 2:18 PM · Wiki-Setup (Rename), Wikimedia-Language-setup
Verdy_p edited projects for T6793: Rename Alemannic Wikipedia from als.wikipedia to gsw.wikipedia, added: Wikimedia-Language-setup; removed Wikimedia-General-or-Unknown.
Aug 24 2017, 2:14 PM · Wikimedia-Language-setup, Wiki-Setup (Rename)

Aug 23 2017

Verdy_p renamed T167513: Redirect lzh.wikipedia to zh-classical.wikipedia from Add an redirect lzh.wikipedia to zh-classical.wikipedia to Redirect lzh.wikipedia to zh-classical.wikipedia.
Aug 23 2017, 6:31 PM · Traffic, Wikimedia-Apache-configuration, Operations, DNS
Verdy_p moved T173966: Like nan.wikipedia.org, redirect other nan.*.org to the proper zh-min-nan.*.org domains from Triage to Caching on the Traffic board.
Aug 23 2017, 6:26 PM · Traffic, Operations, Wikimedia-Apache-configuration, DNS
Verdy_p added a comment to T173966: Like nan.wikipedia.org, redirect other nan.*.org to the proper zh-min-nan.*.org domains.

Note that "nan" is already defined in https://gerrit.wikimedia.org/r/#/c/285085/1/templates/helpers/langs.tmpl
However it still does not resolve on the DNS this means that we cannot easily create links to existing contents in Han Min Nan, when using the standard code, and external sites or templates still need to add a special case to convert "nan" to "zh-min-nan" when linking to Wikimedia sites.

Aug 23 2017, 6:12 PM · Traffic, Operations, Wikimedia-Apache-configuration, DNS
Verdy_p added a parent task for T173966: Like nan.wikipedia.org, redirect other nan.*.org to the proper zh-min-nan.*.org domains: T30442: Rename zh-min-nan -> nan.
Aug 23 2017, 5:57 PM · Traffic, Operations, Wikimedia-Apache-configuration, DNS
Verdy_p added a subtask for T30442: Rename zh-min-nan -> nan: T173966: Like nan.wikipedia.org, redirect other nan.*.org to the proper zh-min-nan.*.org domains.
Aug 23 2017, 5:57 PM · Wiki-Setup (Rename), Wikimedia-Language-setup
Verdy_p renamed T173966: Like nan.wikipedia.org, redirect other nan.*.org to the proper zh-min-nan.*.org domains from Redirect yue.wikipedia.org to zh-yue.wikipedia.org to Redirect nan.wikipedia.org to zh-min-nan.wikipedia.org.
Aug 23 2017, 5:56 PM · Traffic, Operations, Wikimedia-Apache-configuration, DNS
Verdy_p created T173966: Like nan.wikipedia.org, redirect other nan.*.org to the proper zh-min-nan.*.org domains.
Aug 23 2017, 5:54 PM · Traffic, Operations, Wikimedia-Apache-configuration, DNS

Aug 11 2017

Verdy_p added a comment to T134423: Deprecate nonstandard behavior of self-closed HTML tags in wikitext..

If the goal was consistency, then you would also invalidate the inconsistant extension tags (notably the <tvar>...</>). It's a fact that the notation <span id="..."/> is not inconsitant given it is supported by a wellknown standard (XML).
And contributors in Mediawiki cannot rely only on HTML5 standard and are also used to legacy HTML4 and XML and SVG and many other syntaxes that are partly supported (with restrictions and non conforming extensions that are specific to Mediawiki which selects what to support or not and modifies constantly the syntax used everywhere).

Aug 11 2017, 7:46 PM · 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
Verdy_p added a comment to T134423: Deprecate nonstandard behavior of self-closed HTML tags in wikitext..

I'm not alone, you are adding unnecessary works in pages and many plugins for absolutely no benefit, just because some browsers have difficulties to interpret and render some HTML tricks or select the appropriate parser to use (HTML4quircks, SGML, XML, HTML5...) and the behavior to adopt.
This is now a very minority of browsers, and anyway this doed not depend at all on MediaWiki parsers, but only on what Mediawiki will generate from the wikicode.
So you're pushing the burden to allow MediaWiki doing these parsing to the contributors of pages and will break millions of pages, causing unnecessary work that will need to be done in som many places. Most contributors will not understand what was wrong, or will refuse to do this very deceptive maintenance of the content to match what you desire and which is extremely easy to support in Mediawiki itself.

Aug 11 2017, 4:51 PM · 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
Verdy_p reopened T134423: Deprecate nonstandard behavior of self-closed HTML tags in wikitext., a subtask of T89331: Replace HTML4 Tidy in MW parser with an equivalent HTML5 based tool, as Open.
Aug 11 2017, 4:10 PM · TechCom-RFC (TechCom-Approved), Services (watching), User-notice, Tidy, RfC, Parsing-Team, Parsoid
Verdy_p reopened T134423: Deprecate nonstandard behavior of self-closed HTML tags in wikitext. as "Open".
Aug 11 2017, 4:10 PM · 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