Hello everybody,
According to lua wiki
<http://lua-users.org/wiki/LuaLocales%20In%20Lua%205.1>, in Lua 5.1
"identifiers [are] locale dependent, and from the reference manual which
states that "[the documentation] derived from the Lua 5.1 reference
manual <http://www.lua.org/manual/5.1/index.html>", I guess tha
Scribunto is still derived form Lua 5.1.
So, what I would like is being able to set the locale for a module and
use identifiers with locale characters. But `os.setlocale` isn't
accessible in scribunto modules.
Might I have some information about reasons to disabling it and feedback
related to the possibility to enable it?
Ĝis baldaŭ
Today, the HHVM developers made an announcement[1] that they have plans of
ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
instead.
While this does not mean that we need to take an action immediately,
eventually we will have to decide something. As I see it, our options are:
1) Continue requiring that MediaWiki uses a common set of HHVM and Zend
PHP. This, however, is a dead end and will make things progressively harder
as the implementations will diverge and various Composer libraries we use
will start requiring some Zend-specific features.
2) Declare our loyalty to HHVM. This will result in most of our current
users being unable to upgrade, eventually producing what amounts to a
WMF-only product and lots of installations with outdated MediaWiki having
security holes. At least we will be able to convert to Hack eventually.
This is a very clean-cut case of vendor lock-in though, and if Facebook
decides to switch their code base to something shinier, we'll be deep in
trouble.
3) Revert WMF to Zend and forget about HHVM. This will result in
performance degradation, however it will not be that dramatic: when we
upgraded, we switched to HHVM from PHP 5.3 which was really outdated, while
5.6 and 7 provided nice performance improvements.
I personally think that 3) is the only viable option in the long run. What
do you think?
----
[1] http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hi all -
I wanted to share a cool demo with you recorded by Dmitry Brant from the
apps team at the Wikimedia Foundation. Dmitry demos an alpha version of the
app that adds support for offline ZIM files.
https://www.youtube.com/watch?v=iESP20HGPiE
The feature will be undergoing some changes based on the research Dmitry
mentions. To learn more about the research Dmitry mentions in the video,
see
https://www.mediawiki.org/wiki/Wikimedia_Apps/Offline_support/V1_User_resea…
.
Enjoy!
-Adam
https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-09-27
= 2017-09-27 =
contact: https://www.mediawiki.org/wiki/Wikimedia_Engineering
== Callouts ==
* Selenium Ruby framework deprecation (September)
https://phabricator.wikimedia.org/phame/post/view/75/selenium_ruby_framewor…
* Discovery: Maps: Figuring out what to do with code no one on the team is
in charge of
* New linter category coming up - html5-misnesting - which triggers when
misnested tags behave different in Tidy vs. HTML5 (<span> is notably one of
them).
*Eventlogging purging progressing much too slowly, it is becoming clear we
cannot sustain mysql backend for EventLogging, we are prioritizing
sunsetting mysql, replacing it with a better EventLogging analytics
experience on the Hadoop cluster
*Please resolve comments that can be resolved in proposal of redesign of
Scrum of Scrums meeting:
https://docs.google.com/document/d/11gMloAKqtOJsKaDhpx_oIE8-vXvJs7pyLsDhqik…
== Technology ==
-
=== Analytics ===
* Blockers: none
* Updates
**Working full steam to hit our goal of having a backend for wikistats 2.0
to support editing metrics (unique devices and pageviews are alredy
supported on ui). It is looking like we are going to split our current
druid cluster (6 hosts) into two clusters: one private, one public so
restbase services connect to public cluster. The security concerns arising
from this decision will probably make the goal spill into next quarter but
we will have an alpha next quarter if no suprises arise.
**We have use differential for 1 quarter and we are going back to gerrit,
not much value added.
**Eventlogging purging progressing much too slowly, it is becoming clear we
cannot sustain mysql backend for EventLogging, we are prioritizing
sunsetting mysql, replacing it with a better EventLogging analytics
experience on the Hadoop cluster
**Removing outdated instrumentation of events from EventLogging that are
now automagically available via eventbus, like “page create”.
https://gerrit.wikimedia.org/r/#/c/379137/
== Audiences ==
=== Readers ===
==== Multimedia ====
* Pushing out 3D to test/test2 today (Wednesday)
* Need read-only time on s4 for a schema change related to 3D (adding a new
media type)
* Beginning work on MediaInfo extension for Wikibase, which will continue
for some time.
==== iOS native app ====
* Blocked by: none
* Blocking: none
* Updates:
** Finally released 5.6.1 with minor bug fixes (
https://phabricator.wikimedia.org/project/view/2898/ )
** Continuing work on 5.7.0 (
https://phabricator.wikimedia.org/project/view/2899/ ) - Onboarding
updates, Improved analytics, iOS 11 support, iPhone X support
====Discovery====
* Putting together plan for automating portal deployments
=====Maps=====
* nodejs 6.11 done
* Figuring out what to do with code no one on the team is in charge of
==== Web ====
* Turning off OCG. Investigating using chromium for printing.
==== Reading Infrastructure ====
* MCS: Dealing with sectioning issues before Parsoid adds <section> tags
* Reading Lists: finishing RESTBase part; MediaWiki part going through
security review
=== Contributors ===
==== Global Collaboration ====
===== Language =====
* Blocked:
** Request services in help to debug:
https://phabricator.wikimedia.org/T173801 This again blocks cxserver
deployment(s)
* Blocking:
* Updates:
** CX-VE work continue: saving, restoring.
** cxserver now using readable and splitted registry files.
===== Collaboration =====
* Updates
** RCFilters:
*** Features
**** {{git|b747307a}} - WLFilters: Live update and View newest
({{phabricator|T176348}})
**** {{git|5c499174}} - RCFilters: Make 'lastRevision' filter include
non-rev types ({{phabricator|T176328}})
*** Bug fixes
**** {{git|f1340739}} - RCFilters: restore watch/unwatch link
({{phabricator|T176264}})
**** {{git|a0c00f00}} - RCFilters: Make the interface not jump around while
loading ({{phabricator|T176300}})
**** {{git|78703ae9}} - RCFilters: Don't grey out results area when
initializing, unless there's a default saved query ({{phabricator|T173533}})
*** Performance
**** {{git|0005805a}} - RCFilters: Cache
ChangesListSpecialPage::buildChangeTagList() ({{phabricator|T176652}})
**** {{git|32e6b77d}} - RCFilters: Log performance data
({{phabricator|T176652}})
**** {{git|20bcfec0}} - RCFilters: Don't load all of OOUI
**** {{git|8de793cb}} - RCFilters: Make live update polling configurable
==== Parsing ====
* New linter category coming up
** html5-misnesting: This triggers when misnested tags behave different in
Tidy vs. HTML5 (<span> is notably one of them).
* Repeat update from last week as an FYI
** Heads up for Parsoid clients (VE, CX, Flow, MCS)
*** <section> wrapping code is now out of WIP and in review (
https://gerrit.wikimedia.org/r/#/c/364933/) -- please test your code to
make sure you can handle <section> wrappers. If necessary, you can
pre-process the DOM to strip out <section> tags. Parsoid's output is
guaranteed to preserve template wrapping semantics with / without <section>
tags. Parsoid can also accept DOMs with / without <section> tags (for
serializing back to wikitext).
*** We plan to switch Parsoid DOM output to use <figure-inline> tags
instead of <span> for inline images (
https://gerrit.wikimedia.org/r/#/c/370227/ ) -- please test your code to
make sure you can handle the new markup. VE can handle this.
=== Community Tech ===
* Blocking: none
* Blocked by: none
* Report:
** Currently populating ip_changes
** Working on GlobalPreferences
** HTML5 sections IDs are in stage 1 population
=== Services ===
* Not attending
* Blockers: none
* Updates
** All mobile traffic served from the new Cassandra 3 cluster exclusively
** Preparing to test Parsoid with Cassandra 3
=== Technical Operations ===
* '''Blocked''':
** Flow dumps speed issue still, waiting on Collab Team T164262
* '''Blocking''':
** None
* Updates
** Resuming Asia DC work
** Salt removal ongoing, almost fully done
** Possibly fixed a long standing varnish issue with mailbox lags
=== Scoring Platform ===
* Blocked by: none.
* Blocking: Still blocking ORES deployment to the new cluster.
* Updates:
** Working on the statistics-derived thresholds changes, on the
MediaWiki side now. This is a blocker to us releasing the next major
version of ORES. Deployment will be messy since the new code breaks v1 of
the API.
=== Search Platform ===
* Blocked by: none
* Blocking: none
* Updates:
* Explore similar language links test concluded. Unfortunately, the result
was negative - this functionality doesn't seem to be used by real users.
** Widgets are still available for users that want to experiment with them
(see
https://www.mediawiki.org/wiki/Discovery/Status_updates/2017-09-18#Highligh…)
* Announced turning of usage of messaging language fallbacks for analysis (
https://www.mediawiki.org/wiki/Wikimedia_Discovery/Disabling_Messaging_Fall…
)
* Running A/B test on ML ranking for top 18 wikis
* Chinese & Hebrew wikis were reindexed, which means they now have new
analyzers enabled
* Vagrant setups now have new language plugins
* Working on porting Selenium tests from Ruby to JS
* Working on upgrade to Elastic 5.5
== RelEng ==
* Blocking
** None?
* Blocked
** None
* Updates
** Selenium Ruby framework deprecation (September)
https://phabricator.wikimedia.org/phame/post/view/75/selenium_ruby_framewor…
*** "This is your friendly but penultimate warning..."
** 1.30 REL branch cut last week, 1.31-alpha/1.31.0-wmf.1 starting this week
== Fundraising Tech ==
* Quieting down error logs by fixing small bugs
* Refining fraud detection
* Handling more conflicts in CiviCRM contact deduplication
* Moving last ganglia bits over to Prometheus
* Deploying CentralNotice bug fixes
---------- Forwarded message ----------
From: Adam Stevenson <astevenson(a)mozilla.com>
Date: Wed, Sep 27, 2017 at 2:07 AM
Subject: [mozilla-wikimedia-discuss] Firefox Quantum is in Beta
To: mozilla-wikimedia-discuss(a)mozilla.com
Cc: Harald Kirschner <harald(a)mozilla.com>
Dear Wikimedia,
This year Mozilla has been working on our most significant release,
possibly ever. Firefox Quantum is going into Beta today [1]. It will be
shipping to users on November 14, 2017 as a major upgrade of Firefox’s
internals, building the foundation to make Firefox faster with every
release after. We’ve been actively testing these improvements in our
Nightly channel with great results.
To make sure that we have not regressed Wikimedia properties but made them
faster, we would like your help in testing Firefox Beta. In particular
we’re interested in differences in rendering or functionality inadvertently
introduced and any impact on performance metrics.
One of the major components of Firefox Quantum is Quantum CSS [2]. This new
CSS engine takes advantage of modern hardware, parallelizing work across
multiple cores. Some websites may depend on assumptions about the ordering
and timing of events that occur during the browser's rendering cycle,
particularly on page load.
If you discover any issues, please report them to us through Bugzilla [3]
or reach out via our discuss mailing list. We are also here to help,
like setting up Firefox in your automated testing, running performance
benchmarks, or any other questions you have about the web & Firefox.
Thanks for helping us push the web forward.
Adam Stevenson
Mozilla
[1]: https://www.mozilla.org/en-US/firefox/channel/desktop/
[2]: https://hacks.mozilla.org/2017/08/inside-a-super-
fast-css-engine-quantum-css-aka-stylo/
[3]: https://bugzilla.mozilla.org/enter_bug.cgi?product=
Firefox&component=Untriaged
--
You received this message because you are subscribed to the Google Groups
"mozilla-wikimedia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to mozilla-wikimedia-discuss+unsubscribe(a)mozilla.com.
To post to this group, send email to mozilla-wikimedia-discuss(a)mozilla.com.
To view this discussion on the web visit https://groups.google.com/a/mozilla.com/d/msgid/mozilla-wikimedia-discuss/70C0C1E1-7C0F-4205-BEA8-D22A4EA95AD7%40mozilla.com
<https://groups.google.com/a/mozilla.com/d/msgid/mozilla-wikimedia-discuss/7…>
.
I’m trying to improve my coding practices for our MW extensions, and I’m very confused by whether my problem with PHPUnit is a problem with the test I’m writing or with the extension object class I’m trying to test.
My extension uses some custom database tables to store the properties of objects that are created during execution. In older versions of MW, I could just create an object and test that the methods of the object class returned appropriate values for known data that was already in the database. Now, instantiating an object is creating temporary tables that don’t exist and causing fatal errors. Example:
7) CacaoModelAnnotationTest::testNewCacaoModelAnnotationSuccess
Wikimedia\Rdbms\DBQueryError: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: SELECT annotation_id,row_id,original_row_data,annotation_timestamp,user_id,team_id,session_id,annotation_inning FROM `unittest_cacao_annotation` INNER JOIN `unittest_cacao_user` ON ((annotation_user = cacao_user.id)) WHERE annotation_id = "6057"
Function: CacaoModelAnnotation::load
Error: 1054 Unknown column 'cacao_user.id' in 'on clause' (localhost)
This is the load method from class CacaoModelAnnotation:
public function load() {
try{
wfProfileIn( __METHOD__ );
if ( $this->loaded ) {
return false;
}
MWDebug::log( __METHOD__ . ' called for annotation_id: ' . $this->id );
$dbr = wfGetDB( DB_SLAVE );
// query to get annotation attributes
$result = $dbr->select(
array( 'cacao_annotation', 'cacao_user' ),
array(
'annotation_id', 'row_id', 'original_row_data', 'annotation_timestamp',
'user_id', 'team_id', 'session_id', 'annotation_inning'
),
'annotation_id = "' . $this->id . '"',
__METHOD__,
array(),
array(
'cacao_user' => array('INNER JOIN', 'annotation_user = cacao_user.id' ),
)
);
if ( $dbr->numRows($result) == 0 ) {
throw new CacaoException( wfMessage('cacao-annotation-load-returned-zero-rows', $this->id)->text() );
}
$resultRow = $dbr->fetchObject( $result );
$this->loadFromResultRow($resultRow);
wfProfileOut( __METHOD__ );
}catch(CacaoException $e){
if(!isset($thrown)){
throw $e;
}
$thrown = true;
}
}
Is there a good example of an extension that uses custom database tables that I can use as a role model?
I'm trying to solve the problem exposed here:
https://meta.wikimedia.org/wiki/User_talk:Psychoslave#Template:Participants
(in French)
In a nutshell, the goal is to be able to ping a group of user on meta.
so ideally, you just type something like {{ping|my_group}}
But as ping and the underlying "Module:Reply_to" are expecting one user
per argument
my current idea is to make something like {{ping|{{:/some_group/members}}}}
so instead of
{{ping|Amqui|Ariel1024|Aryamanarora|Benoît_Prieur|Daniel_Kinzler_(WMDE)|Delarouvraie|Epantaleo|Ernest-Mtl|GastelEtzwane|JackPotte|Jberkel|Jitrixis|Kimdime|LA2|LaMèreVeille|Lydia_Pintscher_(WMDE)|Lyokoï|M0tty|Malaysiaboy|Marcmiquel|Micru|Nattes_à_chat|Nemo_bis|Noé|Otourly|Pamputt|psychoslave|Rich_Farmbrough|Rodelar|Satdeep_Gill|Sebleouf|Shavtay|Stalinjeet|S_The_Singer|TAKASUGI_Shinji|TaronjaSatsuma|Thibaut120094|Thiemo_Mättig_(WMDE)|tpt|Trizek_(WMF)|VIGNERON|Vive_la_Rosière|Xabier_Cañas|Xenophôn}}
I can just write
{{ping|{{:Wiktionary/Tremendous Wiktionary User
Group/affiliates}}}} for example
but even if I put verbatim in a template:
Amqui|Ariel1024|Aryamanarora|Benoît_Prieur|Daniel_Kinzler_(WMDE)|Delarouvraie|Epantaleo|Ernest-Mtl|GastelEtzwane|JackPotte|Jberkel|Jitrixis|Kimdime|LA2|LaMèreVeille|Lydia_Pintscher_(WMDE)|Lyokoï|M0tty|Malaysiaboy|Marcmiquel|Micru|Nattes_à_chat|Nemo_bis|Noé|Otourly|Pamputt|psychoslave|Rich_Farmbrough|Rodelar|Satdeep_Gill|Sebleouf|Shavtay|Stalinjeet|S_The_Singer|TAKASUGI_Shinji|TaronjaSatsuma|Thibaut120094|Thiemo_Mättig_(WMDE)|tpt|Trizek_(WMF)|VIGNERON|Vive_la_Rosière|Xabier_Cañas|Xenophôn
in the page
and call ping with this template as argumement, it will end up with a
"Error in Template:Reply to: Input contains forbidden characters."
This message is generated by the module Reply_to but I can't change it
since it's protected.
So I'm looking for a way to bypass whatever generate this error, or more
broadly any idea to resolve the exposed problem.
https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-09-20
*= 2017-09-20= *
Grace out of office, please self-organize
contact: https://www.mediawiki.org/wiki/Wikimedia_Engineering
== callouts ==
* Ops => Collaboration. Flow dumps speed issue still
https://phabricator.wikimedia.org/T172025 and (T164262)
== Audiences ==
=== Readers ===
==== Reading Web ====
* Actively working on OCG replacement
* Refactoring & adding electron support to Collection extension
* Working on Marvin
* Got a green light to enable Popups on en wiki
==== Multimedia ====
* Pushing 3D to Test/Test2 sometime next week barring any further blockers
* Would still like feedback from Performance on
https://phabricator.wikimedia.org/T166699 but since we asked and didn't get
any last week, I no longer consider it a blocker
==== Discovery ====
* Blocked by: none
* Blocking: none
* Updates:
** (Maps) Reimaged test-servers, updating to Node 6.11
** (Maps) enwiki looking at maps
** (Front-end) Mirgating CirrusSearch Selenium tests from Ruby to Node
** (Front-end) Running AB test on Special:Search
==== iOS native app ====
* Blocked by: none
* Blocking: none
* Updates:
** Still releasing 5.6.1 with minor bug fixes (
https://phabricator.wikimedia.org/project/view/2898/ )
** Continuing work on 5.7.0 (
https://phabricator.wikimedia.org/project/view/2899/ ) - Onboarding
updates, Improved analytics
==== Reading Infrastructure ====
* Blocked by: Security (ReadingLists review
https://phabricator.wikimedia.org/T174126 )
* Blocking:
* Updates:
** fixed some bugs with Electron multipage rendering, testing again this
week
** continuing work on reading lists
** MCS/PCS: Reverted to old sectioning code
** PCS: Comparison tables of old and new implementation of text extracts
for various languages
=== Community Tech ===
* Blocked by: none
* Blocking: none
* Updates:
** ACTRIAL started
** Getting database population script for range contributions fixed
** Working on GlobalPreferences
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
Working on Wikistats2 back-end: loading easy-to-query data into Druid,
implementing AQS endpoints, vetting metrics data
- adding proxy to Druid cluster for authentication
Working on Wikistats2 front-end: UI improvements, bug fixes
Ongoing EL purging: improvement to script, that now works fine, not
sure if the purging will finish before end of quarter
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
Mostly freaking out about our database replication lag
Can once again A/B test payments form variations with query string
parameters
More work on new API integration for main CC processor
Fixing CN bug where campaigns that haven't started yet can still
pre-empt existing campaigns: https://phabricator.wikimedia.org/T175358
=== Release Engineering ===
* Blocked by:
* Blocking:
* Updates:
* it's happening: All trebuchet-deployed services have been ported to
scap. https://phabricator.wikimedia.org/T129290
=== Search Platform ===
* Blocked by: none
* Blocking: none
* Updates:
* Machine-learning driven ranking is deployed as ranking algorithm on
enwiki: https://phabricator.wikimedia.org/T175772
* Running A/B test for machine-learning driven ranking on 18 other wikis:
https://phabricator.wikimedia.org/T175771
* Running A/B test on displaying other language links under search result:
https://phabricator.wikimedia.org/T175647
* Analyzed language fallback usage in Mediawiki search:
https://phabricator.wikimedia.org/T147959
** Conclusion: a lot of misuse, needs work to clear it up
* Published blog post by Trey explaining human-graded relevance test:
https://blog.wikimedia.org/2017/09/19/search-relevance-survey/
* Categories are now exported into RDF:
https://lists.wikimedia.org/pipermail/wikitech-l/2017-September/088799.html
** Weekly for now, daily updates coming soon
* New logstash servers set up: https://phabricator.wikimedia.org/T175045
* New stats dashboard: How long Wikipedia searchers stay on the search
result pages: https://discovery.wmflabs.org/metrics/#spr_surv
* Results of A/B test swapping 2nd and 3rd search result analyzed:
https://commons.wikimedia.org/wiki/File:Swap2and3_Search_Test_Analysis.pdf
=== Security ===
* Blocked by:
* Blocking:
* Updates:
** Reviews:
*** ReadingLists
*** vue.js (sorry for the delay)
*** wikiba.se
=== Services ===
* Blocked by: none
* Blocking: none
* Updates:
** Cassandra 3 and new storage model rollout to production is happening
right now
*** Beginning with mobile tables at first, but still in test mode,
serving from old storage
** EventBus based job queue double-processes the first job successfully
=== Technical Operations ===
* Apologies, Alex/Fillippo won't be able to make it today. Riccardo will
attend
* Blocked by:
** Collab Team on Flow dumps speed issue still T172025 and T164262
* Blocking:
** None
* Updates:
** We had some spikes of 503s at the cache layer, under control now, see
T175803, T174932 and T145661 if interested
** luasandbox 2.0.14 rollout completed
** New appservers will be put in production in the next days
** Reminder: Salt (the foundation upon Trebuchet was built) will be removed
before the end of next week, replaced by Cumin. All projects that were
deployed with Trebuchet, have already been migrated to scap3 or Debian
packages.
=== Contributors ===
==== Global Collaboration ====
===== Language =====
* Blocked: none
* Blocking: none
* Updates:
* cxserver deployment is unblocked; Registry refactoring targetted in
next deployment. Request for review:
https://gerrit.wikimedia.org/r/#/c/377713/
* CX2 is in progress. Lots of work done here.
===== Collaboration =====
* Updates
** RCFilters - Rolled out new Recent Changes Filters to be on by default
for all users on he.wiki, ca.wiki, fr.wiki, but you can opt out. Watchlist
Filters are now part of the Beta feature. Various new features and bug
fixes.
*** {{git|85df9a3a}} - Move New Filters opt-out preference to own section
({{phabricator|T175765}})
*** {{git|ceb02fbf}} - RCFilters: make live update part of the beta feature
({{phabricator|T175766}})
*** {{git|004b72e3}} - RCFilters: Add an initialization hook
*** {{git|f5d587d3}} - Hide RC/WL related preferences as appropriate
({{phabricator|T175611}})
** {{git|210946c3}} - (GuidedTour) Allow directly launching tour from
server without ?tour= or cookies ({{phabricator|T167262}})
==== UI Standardization ====
* Blocked: none / none
* Updates:
** Working on extending WikimediaUI Base to include vars already needed in
Marvin, especially `font` specifics
** OOUI v0.23.1 released
*** Code hygiene fixes and icon deprecation
* Ongoing:
** OOUI:
*** preparation work on responsive toolbars design part
*** icons: Work on icon set to be more harmonious and align to WikimediaUI
Style Guide's guidelines
** Continuation on WikimediaUI Style Guide, continuing updating imagery on
color section
https://wikimedia.github.io/WikimediaUI-Style-Guide/visual-style_colors.html
** Aligning arbitrary, historically grown colors to WikimediaUI color
palette https://phabricator.wikimedia.org/T148708 – now for the remaining
blues
** Make TransparencyReport fully accessible –
https://gerrit.wikimedia.org/r/#/c/376875/ merged, now for the build update
==== Parsing ====
* Blocked by: https://gerrit.wikimedia.org/r/378774 (html5 ids in Cite
extension)
* Blocking:
* Updates:
** C.Scott is porting over the html5 section id support into Parsoid
(Parsoid had html5 section ids till last year - switched to html4 ids last
year to match core -- now updating to html5 with legacy support again)
*** Requires some fixes to Cite and LanguageConverter :(
** Kunal (legoktm) is running a script to lint all pages on all wikis so
that linter errors are initialized on all wikis to get baseline information
in place
** Last week, we switched MediaWiki and TestWiki to use Remex instead of
Tidy.
*** Individual wikis can file subtasks of
https://phabricator.wikimedia.org/T175706 to switch their wikis over.
** Heads up for Parsoid clients (VE, CX, Flow, MCS)
*** <section> wrapping code is now out of WIP and in review (
https://gerrit.wikimedia.org/r/#/c/364933/) -- please test your code to
make sure you can handle <section> wrappers. If necessary, you can
pre-process the DOM to strip out <section> tags. Parsoid's output is
guaranteed to preserve template wrapping semantics with / without <section>
tags. Parsoid can also accept DOMs with / without <section> tags (for
serializing back to wikitext).
*** We plan to switch Parsoid DOM output to use <figure-inline> tags
instead of <span> for inline images (
https://gerrit.wikimedia.org/r/#/c/370227/ ) -- please test your code to
make sure you can handle the new markup. VE can handle this.
Dear Dev Community,
This is a reminder that the call for participation in the Developer Summit is ongoing, and and that the deadline for submitting position papers is coming up on September 29th.
The topic this year is a reflection about the movement strategy and how our technology can support this vision in the long term. Such strategic discussions should take into consideration voices and perspectives we might not regularly hear from, but that carry significant value to our movement and our vision.
We would like to take the opportunity and specifically encourage people from diverse backgrounds to apply. We would like to hear from you.
Please take a look at the thematic overview of the Developer Summit <https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018#Thematic_Ove…>, and submit your position papers by September 29th, 2017.
Thank you,
Victoria (on behalf of the Dev Summit Program Committee)