Verdy_p (Philippe Verdy)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Monday

  • Clear sailing ahead.

User Details

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

Recent Activity

Yesterday

Verdy_p added a comment to T164658: Recursive "bdi" elements incorrectly parsed.

OK this looks good when testing it effectively on Mediawiki wiki. The bug can be closed (until the new version fully deployed on other wikis).

Fri, Aug 17, 2:03 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 2:02 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 2:01 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 2:01 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p added a comment to T164658: Recursive "bdi" elements incorrectly parsed.

I am testing it, I'll reply after that

Fri, Aug 17, 1:54 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 1:53 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 1:53 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 1:51 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 1:47 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 1:46 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 12:08 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 12:06 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 12:03 PM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 11:50 AM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL
Verdy_p updated the task description for T164658: Recursive "bdi" elements incorrectly parsed.
Fri, Aug 17, 11:49 AM · MediaWiki-Internationalization, MediaWiki-Parser, I18n, RTL

Tue, Aug 7

Verdy_p added a comment to T199106: wgULSGeoService and https://freegeoip.net/ out of service.

This breaks all wikis using the ULS (most of them). Pages refuse to load, saying that an attempt was made to load an unsecured script over HTTP (even if it was requested by HTTPS): FreeGeoIP in fact redirects the HTTPS requests to an HTTP-only error page.
As this cans cause a whole wiki to get broekn in a secure browser, you should provide a default catcheer that will detect such redirects from HTTPS to HTTP and will not break the browser by trying to follow the redirect for the error returned (JSON) insterad of the actual result. Actually no script part of MediaWiki should tolerate such unsafe redirects to another site or protocol, unless it is specifically configured to allow it.
ULS should then provide the safe checking.

Tue, Aug 7, 11:30 PM · Language-2018-July-September, UniversalLanguageSelector

Sat, Aug 4

Verdy_p added a comment to T165585: Make creating a new Language project easier.

Frankly, do we really need things like "-formal" and "-informal"? They can't be recognized by browser as no browser think that both are country codes.

Sat, Aug 4, 8:58 AM · MediaWiki-extensions-WikimediaIncubator, I18n, Release-Engineering-Team, Epic
Verdy_p added a comment to T165585: Make creating a new Language project easier.

@Verdy_p:

cbk-zam -> should be aliased to ???

should be renamed back to cbk, see T124657

map-bms -> aliased to "bms"

Huh? Banyumasan = Bilma Kanuri?

simple -> should be aliased to "en-x-simple"

Just en-simple, no need to use "-x-" here.

Sat, Aug 4, 8:44 AM · MediaWiki-extensions-WikimediaIncubator, I18n, Release-Engineering-Team, Epic

Thu, Aug 2

Verdy_p added a comment to T165585: Make creating a new Language project easier.

stop limiting the language codes to 3 characters

The following languages with more than 3 characters already exist in production:

~/dns/templates/helpers$ cut -d\' -f2 langs.tmpl | grep -E '^[a-z-]{4,}'
(...)

bat-smg -> aliased to "sgs"
be-tarask -> conforming to BCP 47
be-x-old -> aliased to "be-tarask"
cbk-zam -> should be aliased to ???
fiu-vro -> aliased to "vro"
map-bms -> aliased to "bms"
minnan -> aliased to "nan"
nds-nl -> conforming to BCP 47
roa-rup -> aliased to "rup"
roa-tara-> should be aliased to "it-x-tara"
simple -> should be aliased to "en-x-simple"
zh-cfr -> aliased to "nan"
zh-classical -> aliased to "lzh"
zh-min-nan -> aliased to "nan"
zh-yue -> aliased to "yue"

Thu, Aug 2, 11:11 AM · MediaWiki-extensions-WikimediaIncubator, I18n, Release-Engineering-Team, Epic
Verdy_p added a comment to T165585: Make creating a new Language project easier.

My suggestion is not just for Wikimedia wikis. This is a general need for deployement of various wikis which would like to be more flexible in what is shared and what is not, and without necessarily needing a specific domain for each wiki sharing common namespaces (notable "User:" and "User talk:", as well as user preferences for a single registration, possibly even other namespaces like "Template:", "Template talk:", "Module:", "Module talk:", "File:", "File talk:", "Category:", "Category talk:", "Help:", "Help talk:"; with only "Project:", "Project talk:", being specific, and hosted under their own "interwiki" code).

Thu, Aug 2, 11:04 AM · MediaWiki-extensions-WikimediaIncubator, I18n, Release-Engineering-Team, Epic

Tue, Jul 31

Verdy_p added a comment to T165585: Make creating a new Language project easier.

Note that there's absolutely NO need to create "temporary" domains for languages codes and project in Incubator. We can just use the existing interwiki prefixes as they work now as rewriter rules for URLs, and they can already be resolved in the incibunator domain and its path structure.
All that is needed is to path the rewrite rules for their language prefix and project prefix.
This way we could still use normal interwiki links across all projects so that "lang:Articlename" in any wikipedia edition or in any wikipedia incubator subproject will link to "incubator:Wp/lang:Articlename". and this would also apply to Wikidata which could also accept already Wikipedia links using also "lang:Articlename" instead of "incubator:Wp/lang:Articlename".

Tue, Jul 31, 9:32 AM · MediaWiki-extensions-WikimediaIncubator, I18n, Release-Engineering-Team, Epic

Jun 25 2018

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

Finally,

some ot them may look like language/locale codes but are not.

What's "ot" here? fire? grass? eight?...

Jun 25 2018, 6:26 PM · Wikimedia-Site-requests

Jun 20 2018

Verdy_p added a comment to T196371: Provide a multi-language user-faced warning regarding AES128-SHA deprecation.

Will that affect Wikipedia Zero, given it is freely hosted by third party volunteer ISPs that provide their own caching proxy? Can their proxies support the new security requirement for conencting to Wikimedia sites and delivering their contents (and optionally allow their users to contribute via their proxies)?

Jun 20 2018, 1:00 PM · User-notice, User-Johan, Operations, Traffic

Jun 14 2018

Verdy_p added a comment to T196371: Provide a multi-language user-faced warning regarding AES128-SHA deprecation.

Not able to even read the wiki in an enforced incognito mode (removing all private session keys, disabling some scripts, just render the content)?

Jun 14 2018, 1:51 PM · User-notice, User-Johan, Operations, Traffic
Verdy_p added a comment to T196371: Provide a multi-language user-faced warning regarding AES128-SHA deprecation.

Note that because of ULS, using "Wikipedia" instead of "Wikimedia" is still accurate: the secure logon will be made on other wikis simultaneously, including Wikipedia, when you are on any other Wikimedia site (there's a small exception for some internal Wikimedia wikis that are not connected with ULS but use a separate logon, these internal wikis are used mostly by English-speaking users, except possibly the WM conference wikis created each year and whose users may be using another local language, and some old wiki projects whose editing has been stopped and kept online as a readonly archive where no logon is necessary via ULS, and their few administrators will very likely have the way to use decent alternate browsers if needed, or can contact another admin in case of problems to perform some emergency action).

Jun 14 2018, 1:13 PM · User-notice, User-Johan, Operations, Traffic
Verdy_p added a comment to T196371: Provide a multi-language user-faced warning regarding AES128-SHA deprecation.

Isn"t there a way for the wiki server to autodetect those browsers that are still using the legacy TLS implementation and add some flag whose fvlue that can be used to conditionally display the warning?

Jun 14 2018, 1:04 PM · User-notice, User-Johan, Operations, Traffic

Jun 13 2018

Verdy_p added a comment to T127680: Rename Serbo-Croatian Wikipedia and Wiktionary from sh.wiki* to hbs.wiki*.

Once again the deletion from ISO 639-1 is not relevant, the code is still conforming to BCP47; there's no need at all to rename this one (and "sh" cannot be reallocated to any other language). We just want to conform to BCP47 which is stable (ISO 639 is not stable and in fact ambiguous in many other cases, ISO 639-1 is no longer a normative source of BCP47, this informative reference exists for historic purpose only and we do not conform to ISO 639 and will never be able to conform to it; all the web standards are based on BCP47 which explains in iuts RFC the difference and why not all ISO639 codes are accepted, as it contains numerous classification errors and ISO 639 is inconsistant; ISO 639 remains used only for old bibliographic purpose, for libraries of printed books and old legal archives, not for technical tagging; many libraries have stopped using ISO 639 and have converted to BCP47 which is consistant, stable, and much more precise)

Jun 13 2018, 2:19 PM · Wiki-Setup (Rename), Wikimedia-Language-setup, I18n

May 31 2018

Verdy_p added a comment to T135969: Saved edited page is truncated on supplementary characters (e.g. Emojis, or supplementary chinese, in Unicode planes 1 or 2) when your database doesn't support that.

Whever you like it or not, it is a fact that MediaWiki will have already been installed with the "utf8" option in the scripts already delivered since long for creating the initial database for MySQL.
Now you say you don't support it, but this was supported as long as no one was attempting to use supplementary characters (outside the BMP, needing 4 bytes and not just 3 bytes).
It is a fact that MySQL silently truncate strings when storing them, no error is returned. The preview before saving is still correct (so it is not a problem of PHP or HHVM or OS compatibility).

May 31 2018, 3:36 PM · MediaWiki-Database

May 6 2018

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.

May 6 2018, 12:11 PM · Core-Platform-Team, TechCom-RFC (TechCom-Approved), User-ArielGlenn, HHVM, 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).

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

May 5 2018

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

May 5 2018, 11:07 PM · Core-Platform-Team, TechCom-RFC (TechCom-Approved), User-ArielGlenn, HHVM, 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.

May 5 2018, 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).
The initial bug did not contain any cause. But someone decide that a unique cause was effective, but this was just one symptom of other underlying bugs causing it.
I'm still not sure that every cause has been solved, and the crash on memory exhaustion is still occuring and not solved (a general problem somewhere in the memory allocator used in the Scribunto "sandbox" which still causes the PHP worker process to crash, along with other threads, with uncaught exceptions, so the sandbox is still not perfect).
We still have to limit the full expansion of templates frames when it is clearly not needed at all and causes many Lua scripts to use excessive memory and processing time: the frame:preprocess() is still a problem when it expands the whole frame instead of concentrating to expanding only its parameter (this expansion will ues nothing from the frame except global variables for magic value,s and the global cache where it can retrieve copies of pre-existing expansion of template invokations, and store new expansions if needed; it does not need to expand all parameters in the parent frame directly, so expanding "{{int:lang}}" should really have a zero cost as it clearly does not depend on the expansion of all parameters in the parent frames).

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