Verdy_p (Philippe Verdy)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Thursday

  • Clear sailing ahead.

User Details

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

Recent Activity

Wed, Feb 14

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).
Wed, Feb 14, 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)
Wed, Feb 14, 8:26 AM · MediaWiki-extensions-Babel

Tue, Feb 13

Verdy_p reopened T187181: [[MediaWiki:Babel/am]] i18n issue as "Open".
Tue, Feb 13, 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 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).

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

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

Tue, Feb 13, 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 datatables (in PHP) used by the Babel extension

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

Mon, Feb 12

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.

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

Wed, Jan 31

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)

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

Tue, Jan 23

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.

Tue, Jan 23, 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 · Services (watching), User-notice, Tidy, RfC, Parsing-Team, TechCom-RFC, 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
Verdy_p added a comment to T134423: Deprecate nonstandard behavior of self-closed HTML tags in wikitext..

So conclusion;: you are compeltely WRONG. This is not the correct scope of MediaWiki versus HTML.

Aug 11 2017, 4:09 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..

2017-08-11 9:25 GMT+02:00 Schnark <no-reply@phabricator.wikimedia.org>:

Aug 11 2017, 4:09 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

Aug 10 2017

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

As well there's no such elements in HTML5 that REQUIRE contents. Contents
are optional everywhere (including in <table> where a missing <tbody> is
implicitly infered, or in <html> where a missing <head> or <body> are also
implicitly inferred).
For HTML5 the following document <html> is perfectly valid, just like
<html/>, it has no content at all (the missing elements are infered in
the DOM after parsing, and there will be de fault empty <title> in its
default empty <head> child), so the empty document or a simple word is
also a valid HTML5 document (this is not syntaxically the same as the
HTML infered from the DOM after parsing, where elements are also
canonicalized and may also have their element names capitalized, but this
alternate canonicalized syntax gives the same DOM).

Aug 10 2017, 9:39 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..

No, even since it was defined in HTML, it inherited what was initially
defined in SGML as a shortcut to close elements that have empty content.
Except in very old HTML4 browsers (that did not comply to the HTML4
standard in their tricky mode) it has always been accepted as valid.
HTML5 is explicitly referencing XML as one of its fully supported syntaxes
(other syntaxes are the SGML/HTML4 syntax, others are possibly in JSON or
something else that can represent the normative DOM).
I don't know any browser used today (and compatible with what Mediawiki
generates) that will break on a <span id="..."/>. And anyway we are
speaking about the Wiki syntax that can be much more liberal, and will
still generate XML compatible content (so any "<br>" will still be
converted to "<br/>" to allow strict XML parsing)!
I don't know why you want to remove the old SMGL feature which is still
supported in HTML5 (that also promotes the use of compact code with the
HTML syntax, where self-closing tags like "<span/>" will be smarter than
"<span id='...'></span> which is needlessly overlong and only required for
strict conformance with XML parsers).

Aug 10 2017, 9:32 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..

So in summary, you will NOT stop supporting all self-closing tags, but will stop supporting self-closing thags on element that are not void elements: </br> will become invalid (a common mistake in Mediawiki).

Aug 10 2017, 8:26 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..

This cleanup is clearly invalid.

Aug 10 2017, 8:13 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

Aug 6 2017

Verdy_p added a comment to T127680: Rename sh.wiktionary to hbs.wiktionary.

In summary this request in invalid, it would mean we would have to rename zh to zho, en to eng, fr to fra, de to deu to match what is incorrectly expected, and which is not the best practice (BCP 47), but only based on an equivalence in ISO 639 (which is not stable and not usable for localisation purpose, only used now for some bibliographic uses by librarians, many of them having abandoned its use in favor of BCP47 which is more precise and stable)...
if one says that "sh" should not be used because it is a macrolanguage refering to multiple individiaul languages, this is true as well for Chinese and in fact as well for English, French, German that have multiple variants. So this is in fact a request to delete "sh" and ignore the fact that it has an active community and that many linguists still think that the separation of "individual" languages making "sh" is completely artificial: sr-Latn, hr and bs are actually the same language and evidences are showing that the political attempt to divide it in specific countries is failing in many domains and has not served their own communities and not helped developing their use internationally but created only a political division we should probably have avoided in Wikimedia.
But now we have distinct communities not working together as they should and the "sh" community exists that have created useful contents which is much less politically oriented than the separate sr, hs, and bs communities. I doubt any one of these 4 communities will accept the deletion of any one of the 4.
But there's absolutely no need to rename one of them whose encoding is is completely standard (and the target "hbs" is not standard). This request seems to be only a political attack against one of the 4 communities, and will help nobody.

Aug 6 2017, 12:13 PM · Wiki-Setup (Rename), Wikimedia-Language-setup, I18n

Jul 25 2017

Verdy_p added a comment to T127680: Rename sh.wiktionary to hbs.wiktionary.

This request should not be "stalled" but just "closed" since long as completely unnecessary (bad request).
"sh" is perfectly valid in BCP 47 and is still recommanded over "hbs" which is exactly the same thing (with exactly the same status with regard to ISO 639).

Jul 25 2017, 7:44 AM · Wiki-Setup (Rename), Wikimedia-Language-setup, I18n
Verdy_p added a comment to T127679: Rename sh.wikipedia to hbs.wikipedia.

This request should not be "stalled" but just "closed" since long as completely unnecessary (bad request).
"sh" is perfectly valid in BCP 47 and is still recommanded over "hbs" which is exactly the same thing (with exactly the same status with regard to ISO 639).

Jul 25 2017, 7:43 AM · Wiki-Setup (Rename), Wikimedia-Language-setup, I18n

Jul 10 2017

Verdy_p added a comment to T143788: Deprecation warnings about mcrypt_* functions in PHP 7.1.

Just a basic concept (not a proof of concept): can we create a pool of preinitialized random generators, with unpredictable max lifetime, fed possibly by network services querying multiple external pools (possibly from various local or remote servers), then cached and selected randomly by one of them, and switched from one to another at unpredictable time, in order to increase the total entropy available ? And can we protect this pool from time attacks to avoid someone knowing when (and then which one) a PRNG sequence is used, or when it was initialized from its entropy source ?

Jul 10 2017, 9:14 PM · MW-1.28-release-notes, MW-1.27-release-notes, MW-1.30-release-notes, MW-1.28-release, MW-1.29-release-notes, NewPHP, Technical-Debt, MediaWiki-General-or-Unknown
Verdy_p added a comment to T143788: Deprecation warnings about mcrypt_* functions in PHP 7.1.

wasn't there also security alerts about the excessive use of urandom in the same system user account (used by the PHP instance) because it can easily exceed the available entropy, and so it is also easily attackable ?
Are there ways to improve it by using a mix of "urandom" entropy for stateless generation and some limited use of a stateful PRNG (with some constraints, notably if they are used from online external website accesses: is there a way then to delay the speed of random number generation for clients that exceed the threshold (i.e. reducing their experimented performance) to limit attacks and force them to use an unpredictable urandom number once the urandom entropy has been "refilled" with reasonnably unpredictable entropy sources ?

Jul 10 2017, 9:05 PM · MW-1.28-release-notes, MW-1.27-release-notes, MW-1.30-release-notes, MW-1.28-release, MW-1.29-release-notes, NewPHP, Technical-Debt, MediaWiki-General-or-Unknown

Jun 18 2017

Verdy_p added a comment to T120380: RFC: Allow JSON values to be included in the API results .

@Anomie write: It's not that "JSON-in-XML" is a use case, it's that the API tries to be output-format agnostic, and currently supports output in JSON, XML, and PHP serialize() formats. Ideally the actual data structure output is the same no matter what the format it's being represented in, which is something this proposal wants to change.

Jun 18 2017, 9:03 PM · Patch-For-Review, TechCom-RFC, MediaWiki-API

Jun 14 2017

Verdy_p added a comment to T165648: Add monolingual language codes nrf-gg (for Guernésiais), nrf-je (for Jèrriais).

@Mbch331 "Labels aren't monolingual strings". Of course they are (or should be) monoligual as we request users to provide monolingual translations for them.
There are a few exceptions with some *official* toponyms that are multinguals, or trademarks, but verncular toponyms are monoligual or should be (it just happens that some verncular toponyms have synonyms with orthographic/dialectal variants, but for that we have "aliases" in labels, and if we want to distinguish dialectsal/orthographic differences, we should be able to do that also by adding separate monolingual labels using more specific BCP47 locale tags (a non-specific locale tags will use the most common form but should be monolingual).

Jun 14 2017, 8:37 PM · Wikidata
Verdy_p added a comment to T165648: Add monolingual language codes nrf-gg (for Guernésiais), nrf-je (for Jèrriais).

The issue i see is that to add a name in a given language, it must still be supported in the Universal langauge selector or by using "?uselang=" parameter, so that we can give it a label.
We annot add any label in Wikidata in a language that is not selectable as the user language, so a minimal support for MediaWiki localisation is needed so that the language becomes "supported" and not just "valid" (accorrding to BCP47 rules, as currently implemetned with ICU's library used to check it). It seems that the languages Lua module to implement and check validity is not used there and there's no workaround for missing locales in MediaWiki "support".
IOdeally Wikidata should not depend on this MediaWiki support because we actually don't need this supprot for creating a MediaWiki UI, but only to enter labels for Wikidata. This is a limitation of the Wikidata UI which incorrectly assumes such Mediawiki support is needed: there's no way to add an additional "custom" (but valid) BCP47 locale code to associate a label to a Qnnn entry: the "more" languages buttons requires us to select a supported locale so that the input form will propose a field to fill in. Probably we could still add it in Wikidata, but not with the current Wikidata UI, only via its API (this would require some privilege to submit data via the API and bypass the validation currently performed by Wikidata's UI).

Jun 14 2017, 7:51 PM · Wikidata

Jun 12 2017

Verdy_p added a comment to T25216: Move the Nourmande Wikipedia from nrm to nrf.

@Verdy_p:

It would be simpler to first create a CNAME alias redirection of the subdomain

Are you absolutely sure that non of our Wikimedians have knowledge of Narom?

Jun 12 2017, 2:47 PM · Wiki-Setup (Rename), Patch-For-Review, Wikimedia-Language-setup

Jun 11 2017

Verdy_p added a comment to T165648: Add monolingual language codes nrf-gg (for Guernésiais), nrf-je (for Jèrriais).

Actually ISO 639 also references The Ethnologue entry that lists:
Andorra and France https://www.ethnologue.com/map/ADFR
Ireland and United Kingdom https://www.ethnologue.com/map/IEGB

Jun 11 2017, 7:48 PM · Wikidata
Verdy_p added a comment to T165648: Add monolingual language codes nrf-gg (for Guernésiais), nrf-je (for Jèrriais).

@GerardM: what do you read ? We all know that, but you are still pretending that the request above by @Esc3300 is invalid, when it is in fact perfectly correct. You are the only one to read it incorrectly.

Jun 11 2017, 4:33 PM · Wikidata
Verdy_p added a comment to T165648: Add monolingual language codes nrf-gg (for Guernésiais), nrf-je (for Jèrriais).

@Esc3300: Guernésiais and Jérriais still have no separate ISO 639 code. "nrf" is encoding Norman as a whole (i.e. a single language) encompassing all its regional or dialectal variants, and still not as a macrolanguage (see ISO 639-3 for reference).
But for BCP47 "nrf" is fully conforming, just like "nrf-JE", "nrf-GG", "nrf-FR" (it uses regions subtags registered in IANA and inherited from ISO 3166-1, which have NO restriction for specific language). This is for now the only way to represent them in BCP 47.

Jun 11 2017, 4:23 PM · Wikidata
Verdy_p added a comment to T165648: Add monolingual language codes nrf-gg (for Guernésiais), nrf-je (for Jèrriais).

@GerardM I don't take it backward. This is perfectly correct, there's no mess at all except in your mind:

  • NOWHERE it was proposed to add nrm-je or nrm-gg (if that's what you are still reading incorrectly, and that neither me wrote, nor what @Esc3300 asked for): the mess is in Wikimedia everywhere in its wikis with its incorrect use of "nrm" that should have been renamed since long.
  • But nrf-je and nrf-gg (also nrf-fr) are perfectly correct, and FULLY conforming to the BCP 47 standard (and "nrf" is still wanted for Norman and asked for since years)
Jun 11 2017, 4:06 PM · Wikidata
Verdy_p added a comment to T165648: Add monolingual language codes nrf-gg (for Guernésiais), nrf-je (for Jèrriais).

The request is not for adding codes that are already standard according to
BCP 47 where nrf-GG and nrf-JE arr oerfectly valid and confirming. But what
is still blocking is that "nrm" in Wikimedia has ALWAYS been valid in BCP47
but incorrectly assigned for another unrelated language. To add nrf-GG and
nrf-JE, we still need that Wikimedia renames its existing and incorrect use
of nrm to nrf. This done, we still need the two variants for Jériais and
Guernesiais and notably the first one which has official status in Jersey.
For now there's still no ISO639-3 code assigned for the two languages
(Jersiais is not locally considered as a "variant" of Norman as it has its
own official status, its own nornative dictionary. But nrf-JE and nrf-GG
are still valid and conforming substitutes, even if BCP 47 now prefers, but
does not require, using a single ISO 639 code instead of using region codes
from ISO 3166 or UN-M49.
Many but not all legacy BCP 47 codes using region codes are now replaced by
single codes from ISO 639-3 but none if these legacy codes are made invalid.
For now there's not even any pending request to split code "nrf" as a
macrolanguage for its 3 variants encoded separately (continental, Jériais
and Guernésiais) so "nrf" is still a simple language encompadding its 3main
variants so we still need to add region codes (fr, gg, je) where
distinctions are needed.

Jun 11 2017, 2:19 PM · Wikidata

May 23 2017

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

It is structured, each paragraph has its topic.

May 23 2017, 7:42 PM · MediaWiki-extensions-WikimediaIncubator, Language-Team, I18n, Release-Engineering-Team, Epic
Verdy_p added a comment to T165585: Make creating a new Language project easier.

In fact many languages are now supported only in MediaWiki, when minority
languages are not supported anywhere else in the software industry (except
formally in standards for assigning tem a language code, which is typically
used first for archiving purpose by librarians (that use these codes in
their database to sort their corpus collection, most of them being
computerized only in form of facsimiles, or for precious books in rare
libraries and museums that cost a lot to preserve them in good state).
But there's no standard existing for the basic needs for full computer
support. The CLDR is still the first and only working project to create
basic localisation data that will allow initiate the repositories we need,
but many languages do not have the minimum support in CLDR with its basic
coverage level.

May 23 2017, 3:49 PM · MediaWiki-extensions-WikimediaIncubator, Language-Team, I18n, Release-Engineering-Team, Epic

May 20 2017

Verdy_p added a comment to T18036: Number of category members (PAGESINCATEGORY) is inaccurate for large categories.

I don't understand why counters are not just refreshed using a scheduled date on the job queue: the current counter value will help schedule this refresh in some future (if no other schedule has been programmed, using a delay based on the last time the counter was refreshed + a delay depending on the current counter value; if this still falls in the past, schedule the job to run immmediately).

May 20 2017, 2:13 AM · Wikimedia-maintenance-script-run, MediaWiki-Categories

May 19 2017

Verdy_p added a comment to T85495: (2) Restyle category pagination links as buttons.

I don't see why this should be buttons, they don't perform any action, they are just standard navigation links to other pages.
The category names to display are definitely not isolately buttons like "Submit", "Edit", "OK", "Cancel", "Reply", "Create page", but in the mobile version they would still need to be easily clickable with enough margins. That's why they should fit better in the lateral menu (which is itself collapsed by default at top of page).
So I see good reson to organize them as a list. In the mobile version, this list takes too much space and would preferably rendered in the side menu where other navigation tools are found (including "what links here", "history", "related edits" and so on), as a standard vertical list that may be collapsed and unrolled from a single button, but not needing any bullet, just rectangular areas stacked vertically (and collapsed if there are more than a couple of categories to display) as in common mobile menus (see the items in Preferences menus on Android for example).

May 19 2017, 12:27 PM · Mobile, MediaWiki-Categories

May 17 2017

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

So we have "Incubator" only because of unified patrolling across all their "subwikis". May be it would be simpler to use the capabilities of "SUL" to allow single subscription of users over Incubator projects. I.e. sharing their "User:" and "User talk:" namespaces to the same one independantly of the domain using it.

May 17 2017, 1:29 PM · MediaWiki-extensions-WikimediaIncubator, Language-Team, I18n, Release-Engineering-Team, Epic

May 13 2017

Verdy_p added a comment to T163503: Decide on city/region label priorities.

Many labels are missing everywhere, notably at high zoom levels. Apparently you won't display any place name below admin_level 8, so we miss many villages, hamlets or locations interesting from the touristic point of view exposed in Wikivoyage). Also transport stations have no visible names.

May 13 2017, 1:43 AM · Maps (Maps-data)