Hey, I have a new topic I'd like to discuss. It's about mbstring and
whether do we really need to support running without it.
The RFC is at https://gerrit.wikimedia.org/r/#/c/267309/
Here's a copy:
MediaWiki currently relies heavily on Unicode support to provide support
for 300+ languages yet does not require the mbstring PHP extension to
function. Instead, we create PHP-only fallbacks if a native support is not
available. This creates a few problems:
* These fallbacks are extremely slow. The script in P2734
<https://phabricator.wikimedia.org/P2734> demonstrates that fallbacks are
roughly order of magnitude slower on PHP 5.6. In extreme cases, it can be
100+ times slower, per comment in Fallback.php).
* These fallbacks cover only a few functions. If there's no fallback,
either ad-hoc solutions are used in places, or, like in SwiftFileBackend,
we just say "mbstring is required".
* This also means that extensions can't expect any consistent Unicode
support.
* Won't somebody please think of the children!
Now that we've dramatically increased PHP requirements, we've already cut
off a lot of crappy environments so this change will likely not affect too
many users.
OS support:
* On Debian-based systems, a simple apt-get install php5 gives you mbstring
by default.
* On RPM-based, a separate package is required
* On Windows, people tend to use *AMP all-in-one packages that have
mbstring.
Current mbstring usage in core (excluding fallbacks themselves):
mediawiki/includes$ grep -orEh '\bmb_\w+' . | sort | uniq -c
7 mb_check_encoding
6 mb_convert_encoding
12 mb_strlen
4 mb_substr
Some time ago, I committed https://gerrit.wikimedia.org/r/#/c/267309/ to
start a discussion, but it went largely unnoticed so I'd like to start a
formal RFC.
--
Best regards,
Max Semenik ([[User:MaxSem]])
Assuming there's no easy way to merge the databases, we are fine with
dropping the old db. I believe most content was imported to the current
wiki at the time of the migration, see
https://phabricator.wikimedia.org/T25537. An xml dump was used, not an SQL
one, so I suppose stuff like logs may not have been preserved, but in any
case it's not critical that we preserve all that historical info. I mean,
it would certainly be nice, but we can live without it.
Or we could use the pt2wikimedia, as that would allow future archeologists
to recover the data from the beginning of the wiki :) Either option is fine.
On Wed, Feb 24, 2016 at 12:13 PM, This, that and the other <
at.light(a)live.com.au> wrote:
> Why not just delete the old ptwikimedia site and put the new one in its
> place, using the same dbname?
>
> The old wiki is inaccessible, since pt.wikimedia.org redirects offsite,
> so it's unclear if the old DB even needs to be preserved. And presumably
> any configuration bits that refer to ptwikimedia will still be relevant to
> the new site.
>
> If for some reason that is not feasible, I guess pt2wikimedia is
> acceptable, though only as a last resort. As I've said before, there really
> needs to be a better way to rename wikis without wasting hours of
> everyone's time...
>
> TTO
>
> --
> "Alex Monk" wrote in message
> news:CALMPGzX_E4ML0xD2A_2vTRZ+2a+nWtpC9KkJe58x=mdG-uOxEQ@mail.gmail.com...
>
>
> Hi all,
>
> A request has come up (https://phabricator.wikimedia.org/T126832) to
> re-create pt.wikimedia.org on the wikimedia cluster. Unfortunately it was
> previously hosted there and so the 'ptwikimedia' database name is already
> taken.
> Since database renaming does not really appear to be an option, does anyone
> have any objections to using 'pt2wikimedia' (or similar, suggestions
> welcome) instead for the new wiki? I know this doesn't fit the existing
> pattern so I'm unsure about just going ahead without asking for input from
> a wider audience.
>
> Alex
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Hi all,
As you might have seen in the Signpost or other venues, next week is
the CODFW failover testing. To help limit the moving parts for that week,
all train deployments (including branching) and non-emergency SWAT
deployments are cancelled for that week.
Assuming the testing all goes according to plan, we'll resume with our
normal schedule (that'd be 1.27.0-wmf.18) the week of March 28th.
I'll be updating the calendar and roadmaps today.
-Chad
Hello Developer,
I am Rupinderjit Kaur. I am pursuing B.Tech in Information Technology
from Guru Nanak Dev Engineering College, Ludhiana, India. I am 2016
GSoC aspirant. I'm interested in contributing and working on the
project "Reading List" https://phabricator.wikimedia.org/T120756.
Kindly suggest me from where I should start contributing to it.
Thanks :).
--
Rupinderjit Kaur
https://roopwadali.wordpress.comhttps://github.com/Rupinderwadali/
The best way to predict the future is to create it
Thanks for your participation in the recent Code of Conduct discussions.
The "Marginalized and underrepresented groups" discussion had a lot of
feedback. There was not consensus to use the exact original wording,
but many people expressed willingness to support a modified text.
I've proposed such a new text, based on Neil P. Quinn's text, with a
small modification to account for discrimination required by law (e.g.
age of people who can sign certain contracts).
Please participate at
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#New_proposed_word…
.
The "Enforcement issues" section received general support, but some of
that was conditional, or expressed preference for wording that developed
during the discussion. The original wording also did not address the
appeals body, which was raised in the discussion.
Please participate at
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Circumvention_tex…
Update regarding completed discussions:
The "Clarification of legitimate reasons for publication of private
communications and identity protection" and "Definitions - trolling,
bad-faith reports" discussions have been closed.
They both had support, and I've incorporated the text into the draft.
Thanks,
Matt
Hi,
I am writing to give you a quick summary of which RFCs we are currently
working on in the ArchCom. Each RFC has the name of its 'shepherd' listed
next to it. A shepherd is responsible for working with the RFC author to
move the RFC forward, publicize it, and represent it in the architecture
committee.
Please have a look, and join the conversation on the RFCs that are of
interest to you.
Gabriel
New RFCs:
T129435 RFC: drop support for running without mbstring
<https://phabricator.wikimedia.org/T129435> (Gabriel): New, very focused
RFC by Max, discussion started.
Upcoming IRC sessions:
T124792 Service Locator for MediaWiki core
<https://phabricator.wikimedia.org/T124792> (Daniel): Introduce a service
locator (aka DI container) to allow code in mediaWiki core to make use of
the Dependency Injection (DI) and Service Locator (SL) patterns.
Under discussion:
T108655 Standardise on how to access/register JavaScript interfaces
<https://phabricator.wikimedia.org/T108655> (Roan): Considering to split
out contentious part (file-based require, or something like it; to support
embedding libraries), move forward on less controversial part (basic
module-name-based require infrastructure)
T18691 RFC: Section headings should have a clickable anchor
<https://phabricator.wikimedia.org/T18691> (Timo): Reworking proposal with
designers & Volker
T124504 Transition WikiDev '16 working areas into working groups
<https://phabricator.wikimedia.org/T124504> (RobLa) Finding folks to fully
assume ownership on following up from each session has been difficult
T128351 RfC: Notifications in core
<https://phabricator.wikimedia.org/T128351> (Brion): Discussed last week,
now clarifying interfaces & scope.
T66214 Use content hash based image / thumb URLs & define an official thumb
API <https://phabricator.wikimedia.org/T66214> (Brion): Discussion last &
this week.
T118517 [RFC] Use <figure> for media
<https://phabricator.wikimedia.org/T118517> (Brion): Revisit soon.
T124752 [RFC] Expiring watch list entries
<https://phabricator.wikimedia.org/T124752> (Daniel): Iterating on the
design, discussion on the task.
T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap
<https://phabricator.wikimedia.org/T113034> (Daniel): Has been discussed
before, needs somebody to actually take this on.
T114444 [RFC] Introduce notion of DOM scopes in wikitext
<https://phabricator.wikimedia.org/T114444> (Tim): Under discussion in the
parsing team, early stage.
on wiki: https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-03-16
= 2016-03-16 =
== Product ==
=== Reading ===
==== iOS ====
* '''Updates''':
** 5.0.0 was released - all the new things
** 5.0.1 was submitted - fix all the new things that crashed
* '''Upcoming''':
** 5.0.1 - release (blocked on Apple review)
** 5.0.2 - a little bit of this and that, second round of bug fixes, some small functionality tweaks
** 5.1.0 - still in planning stage for some larger adjustments to some of the new 5.0.0 functionality
* '''Blocking''':
** nothing comes to mind atm
* '''Blocked''':
** 5.0.1 - release (blocked on Apple review)
** "mw-mobilefrontend-leadsection" leaking in to mobileview lead section (broke our transform but we pushed a workaround in 5.0.1)
** powering through 5.0.0 OTRS feedback firehose (not so much blocked as just time consuming) - digesting this feedback will inform what goes into 5.0.2 and 5.1.0
** this also isn't really a blocker, just something we'll need to do sometime in the future - audit mobile content service output for any android-specific bits which may need to be tweaked before iOS can adopt - i doubt there will be issues, but we'll need to check
==== Mobile Content Service ====
* '''Blocking''':
** None
* '''Blocked''':
** potential blocker: https://phabricator.wikimedia.org/T118306 "File: pages of images stored on commons result in 404s". Would be really nice to get that one fixed before we roll out MCS usage to Android production app.
** We need a new Android prod app release for the roll out of MCS usage in Android production app
* '''Updates''':
** Considering starting roll out of MCS usage to Android production app next week since DC-switchover test is delayed until mid April. Might as well do it now.
** Working on fixing lead paraph transformation in the service.
==== Reading Infrastructure ====
* AuthManager is still coming! (see two weeks ago for details)
** Behind schedule though.
==== Android ====
* 2.1.143 beta coming soon.
=== Community Tech ===
* Numerical category sorting - Need to get https://gerrit.wikimedia.org/r/#/c/272416/ merged
* Pageview stats tool is basically finished, going to add support for redirects as well
* Deadlink logging interface for internet archive - http://tools.wmflabs.org/deadlinks/
=== Editing ===
==== Collaboration ====
* '''Blocking''':
** External Store - Continuing work. Some local stuff merged that will help with testing.
* '''Blocked''':
** No new blockers. Work on dump continues
* '''Updates''':
** Good feedback from cross-wiki notification roll out some far.
** Some small issues, e.g. people feeling spammed by welcome bots from wikis they visited one time (or maybe just a load.php reference).
==== Language ====
* '''Blocking''':
** None
* '''Blockers''':
** None
* '''Updates'''
** Work on improving ContentTranslation continue.
==== Multimedia ====
* '''Blocking'''
** None
* '''Blockers'''
** None
* '''Updates'''
** Another A/B test for the core upload dialog (esp. regarding VisualEditor uploads) to be released soon in an effort to reduce garbage uploads, heads up
== Discovery ==
* '''Blocked''':
** Security: SVG sanitizer
* '''Updates''':
** Completion suggester deployed on all wikis as default starting March 16th
** New portal improvements deployed
** Started weekly status updates: https://www.mediawiki.org/wiki/Discovery/Status_updates
** Working on enabling encryption for search traffic
** Preparing for A/B test of phrase match boost for search
== Technology ==
=== Security ===
* Deploying 2FA to wikis next week (disabled for almost all users initially)
* Tarball release planned for next week
=== Research ===
* Blocking: none
* Blocked: none
* Updates: none
=== RelEng ===
* Blocking:
** Security wants to do a release of MW, working on timing
** Fundraising tech needs patch merged for jjb config, gerrit 277563
* Blocked: None
* Updates:
** Code freeze is not happening next week, April 18th instead. See wmfall, wikitech-l announcement coming today too.
=== Technical Operations ===
* Blocking: Research on ORES, started assigning LVS this week
* Blocked: none
* Updates:
** Jobqueue woes https://phabricator.wikimedia.org/T129517
** Got minor services (citoid, cxserver, mathoid, graphoid, apertium, zotero) working in CODFW
=== Fundraising Tech ===
* need one patch merged by RelEng: https://gerrit.wikimedia.org/r/277563
* tested backup credit card processor for an hour
** fixing the bugs that shook out
* burst of DonationInterface refactoring
* draining some molasses out of the CentralNotice campaigns page
* testing strategies to make contact merges reversable in CiviCRM
=== Services ===
* Going to set up redirects for commons image description pages (blocker for mobile apps deployment): https://phabricator.wikimedia.org/T118306
* DC switch-over for RESTBase, node services happening tomorrow European morning (3 hours): https://phabricator.wikimedia.org/T127974
** Services already running in Dallas, Cassandra master-master replication
** No user impact expected
* REST API CDN caching: Most entry points now purged & cached in Varnish. Going to redirect titles with spaces to underscores next week.
* EventBus multi-DC support discussion wrapping up: https://phabricator.wikimedia.org/T127718
* "Pageviews" turns out to be disliked by ad blockers; working on alternative URLs for pageview API with analytics: https://phabricator.wikimedia.org/T126947
=== Analytics ===
* Working on goals for next quarter: will share soon with dependencies
* Finishing up work on the request breakdown reports to replace wikistats reports: OS and Browser breakdowns
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi,
I want to get an idea how many times the Score extension is invoked
but could find no way to go about that, nor to get a list of pages
using <score> or variants thereof on a per-wiki or per-category basis.
Any pointers?
Thanks,
d.
I'm using the portal much more these days! Two thoughts, a few days in:
= Is there a way to turn on thumbnailing on the individual language wikis
too?
= Auto-suggesting language based on charset would be nice. when searching
in multiple languages I always forget once to switch to the target language
and end up getting search results for kanji on he.wp or for hebrew on ja.wp
Thanks, SJ
On Tue, Mar 15, 2016 at 4:25 AM, Michael Jahn <michael.jahn(a)wikimedia.de>
wrote:
> I've played around a bit. Feels very cool!
> Michael
>
> 2016-03-11 3:27 GMT+01:00 Deborah Tankersley <dtankersley(a)wikimedia.org>:
>
> > Hello!
> >
> > I'm very pleased to announce that we've updated the Wikipedia.org
> > <http://wikipedia.org/> portal page with a brand new search box that is
> > more prominent and will now display meta data with images (as available)
> in
> > the search results (see attached image).
> >
> > This was a large effort by the Discovery Portal team to develop a
> > JavaScript-only version of the language picker, so that JavaScript
> enabled
> > browsers will see all the new meta data. Alongside that effort, we also
> > ensured that in JavaScript (JS) disabled browsers (or older Internet
> > Explorer versions), our visitors won't have a bad experience when
> choosing
> > a language to search in. (Note: in older IE versions and JS disabled
> > browsers, the type-ahead and meta data search results information will
> not
> > be displayed.)
> >
> > We also implemented a shorter language code (ie: EN for English, ES for
> > Spanish, etc) to allow for more characters to be typed into the search
> box.
> > When a user toggles the language selector, the full language name will be
> > displayed in the dropdown for easy finding of the language you prefer to
> > search in. For the more technical minded - I've attached a screenshot of
> > one of the ways we test our code, visually.
> >
> > We're interested in hearing your feedback or if you have any questions!
> >
> > On behalf of the very happy Wikipedia.org Portal Team,
> >
> > Deb
> >
> > --
> > Deb Tankersley
> > Product Manager, Discovery
> > Wikimedia Foundation
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > New messages to: Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
>
>
>
> --
> Leiter Kommunikation
> Head of Communications
>
> Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
> Tel. (030) 219 158 260
>
> http://wikimedia.de <http://www.wikimedia.de>
>
> Stellen Sie sich eine Welt vor, in der jeder Mensch freien Zugang zu der
> Gesamtheit des Wissens der Menschheit hat. Helfen Sie uns dabei!
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
> der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
> Körperschaften I Berlin, Steuernummer 27/029/42207.
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
--
Samuel Klein @metasj w:user:sj +1 617 529 4266