Re: [Wikitech-l] [WikimediaMobile] Mobile site is now lazy loading images

2016-08-23 Thread Pine W
Whoops, I missed the link.
https://www.mediawiki.org/wiki/Reading/Web/Projects/Performance/Lazy_loading_images.
Thanks for working on this.

Pine

On Tue, Aug 23, 2016 at 8:33 PM, Pine W  wrote:

> Good to hear. Does this also mean that pages load faster?
>
> Pine
>
> On Tue, Aug 23, 2016 at 2:20 PM, Jon Robson  wrote:
>
>> FYI after much experimentation, research and testing the mobile site has
>> been lazy loading images [1] since Thursday 18th August. This means if you
>> do not see an image you will not download it. We have taken care to ensure
>> users without JavaScript can still view images and that most users will
>> barely notice the difference.
>>
>> We are currently crunching the data this change has made and we plan to
>> write a blog post to reporting the results.
>>
>> In our experiments on Japanese Wikipedia we saw a drop in image bytes per
>> page view by 54% On the Japanese Japan article bytes shipped to users
>> dropped from 1.443 MB to 142 kB.
>>
>> This is pretty huge since bytes equate to money [3] and we expect this to
>> be significant on wikis where mobile data is more expensive. In a nutshell
>> Wikipedia mobile is cheaper.
>>
>> As I said blog post to follow once we have more information, but please
>> report any bugs you are seeing with the implementation (we have already
>> found a few thanks to our community of editors).
>>
>> ~Jon
>>
>> [1] https://www.mediawiki.org/wiki/Reading/Web/Projects/Performa
>> nce/Lazy_loading_images
>> [2] https://www.mediawiki.org/wiki/Reading/Web/Lazy_loading_
>> of_images_on_Japanese_Wikipedia
>> [3] https://whatdoesmysitecost.com/
>>
>>
>>
>> ___
>> Mobile-l mailing list
>> mobil...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Mobile site is now lazy loading images

2016-08-23 Thread Pine W
Good to hear. Does this also mean that pages load faster?

Pine

On Tue, Aug 23, 2016 at 2:20 PM, Jon Robson  wrote:

> FYI after much experimentation, research and testing the mobile site has
> been lazy loading images [1] since Thursday 18th August. This means if you
> do not see an image you will not download it. We have taken care to ensure
> users without JavaScript can still view images and that most users will
> barely notice the difference.
>
> We are currently crunching the data this change has made and we plan to
> write a blog post to reporting the results.
>
> In our experiments on Japanese Wikipedia we saw a drop in image bytes per
> page view by 54% On the Japanese Japan article bytes shipped to users
> dropped from 1.443 MB to 142 kB.
>
> This is pretty huge since bytes equate to money [3] and we expect this to
> be significant on wikis where mobile data is more expensive. In a nutshell
> Wikipedia mobile is cheaper.
>
> As I said blog post to follow once we have more information, but please
> report any bugs you are seeing with the implementation (we have already
> found a few thanks to our community of editors).
>
> ~Jon
>
> [1] https://www.mediawiki.org/wiki/Reading/Web/Projects/
> Performance/Lazy_loading_images
> [2] https://www.mediawiki.org/wiki/Reading/Web/Lazy_loading_
> of_images_on_Japanese_Wikipedia
> [3] https://whatdoesmysitecost.com/
>
>
>
> ___
> Mobile-l mailing list
> mobil...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Mobile site is now lazy loading images

2016-08-23 Thread Arthur Richards
This is so rad, congratulations! I know this has been years in the making -
it's really awesome to see it working :D

On Tue, Aug 23, 2016 at 5:11 PM Adam Baso  wrote:

> Good question - the code tries to fetch the images ahead of them coming
> into the viewport. That can mean upon section expansion, as well.
>
> On Tuesday, August 23, 2016, Justin Ormont 
> wrote:
>
>> This sounds great. Are the images pre-loaded when the user gets close, or
>> once it's scrolled into view?
>>
>> --justin
>>
>> On Tue, Aug 23, 2016 at 3:48 PM, Volker Eckl 
>> wrote:
>>
>>> Amazing work! Enjoying the further speed improvements and the detailed
>>> analysis of Japanese Wikipedia testcase.
>>>
>>> On Tue, Aug 23, 2016 at 2:20 PM, Jon Robson 
>>> wrote:
>>>
 FYI after much experimentation, research and testing the mobile site
 has been lazy loading images [1] since Thursday 18th August. This means if
 you do not see an image you will not download it. We have taken care to
 ensure users without JavaScript can still view images and that most users
 will barely notice the difference.

 We are currently crunching the data this change has made and we plan to
 write a blog post to reporting the results.

 In our experiments on Japanese Wikipedia we saw a drop in image bytes
 per page view by 54% On the Japanese Japan article bytes shipped to users
 dropped from 1.443 MB to 142 kB.

 This is pretty huge since bytes equate to money [3] and we expect this
 to be significant on wikis where mobile data is more expensive. In a
 nutshell Wikipedia mobile is cheaper.

 As I said blog post to follow once we have more information, but please
 report any bugs you are seeing with the implementation (we have already
 found a few thanks to our community of editors).

 ~Jon

 [1]
 https://www.mediawiki.org/wiki/Reading/Web/Projects/Performance/Lazy_loading_images
 [2]
 https://www.mediawiki.org/wiki/Reading/Web/Lazy_loading_of_images_on_Japanese_Wikipedia
 [3] https://whatdoesmysitecost.com/



 ___
 Mobile-l mailing list
 mobil...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l


>>>
>>> ___
>>> Mobile-l mailing list
>>> mobil...@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>>
>> ___
> Mobile-l mailing list
> mobil...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Mobile site is now lazy loading images

2016-08-23 Thread Adam Baso
Good question - the code tries to fetch the images ahead of them coming
into the viewport. That can mean upon section expansion, as well.

On Tuesday, August 23, 2016, Justin Ormont  wrote:

> This sounds great. Are the images pre-loaded when the user gets close, or
> once it's scrolled into view?
>
> --justin
>
> On Tue, Aug 23, 2016 at 3:48 PM, Volker Eckl  > wrote:
>
>> Amazing work! Enjoying the further speed improvements and the detailed
>> analysis of Japanese Wikipedia testcase.
>>
>> On Tue, Aug 23, 2016 at 2:20 PM, Jon Robson > > wrote:
>>
>>> FYI after much experimentation, research and testing the mobile site has
>>> been lazy loading images [1] since Thursday 18th August. This means if you
>>> do not see an image you will not download it. We have taken care to ensure
>>> users without JavaScript can still view images and that most users will
>>> barely notice the difference.
>>>
>>> We are currently crunching the data this change has made and we plan to
>>> write a blog post to reporting the results.
>>>
>>> In our experiments on Japanese Wikipedia we saw a drop in image bytes
>>> per page view by 54% On the Japanese Japan article bytes shipped to users
>>> dropped from 1.443 MB to 142 kB.
>>>
>>> This is pretty huge since bytes equate to money [3] and we expect this
>>> to be significant on wikis where mobile data is more expensive. In a
>>> nutshell Wikipedia mobile is cheaper.
>>>
>>> As I said blog post to follow once we have more information, but please
>>> report any bugs you are seeing with the implementation (we have already
>>> found a few thanks to our community of editors).
>>>
>>> ~Jon
>>>
>>> [1] https://www.mediawiki.org/wiki/Reading/Web/Projects/Performa
>>> nce/Lazy_loading_images
>>> [2] https://www.mediawiki.org/wiki/Reading/Web/Lazy_loading_
>>> of_images_on_Japanese_Wikipedia
>>> [3] https://whatdoesmysitecost.com/
>>>
>>>
>>>
>>> ___
>>> Mobile-l mailing list
>>> mobil...@lists.wikimedia.org
>>> 
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>>
>>
>> ___
>> Mobile-l mailing list
>> mobil...@lists.wikimedia.org
>> 
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [AI] Deployment of ORES review tool in Englis Wikipedia as a beta feature

2016-08-23 Thread Aaron Halfaker
Thanks Luis!  :)

And I just finished setting up a new labeling campaign for English
Wikipedia.  This data will help us train/test more accurate models.

See https://en.wikipedia.org/wiki/Wikipedia:Labels/Edit_quality for
instructions on how to get started.

-Aaron

On Tue, Aug 23, 2016 at 4:05 PM, Luis Villa  wrote:

> Thanks for the detailed explanation, Aaron. As always your work is a model
> in transparency for the rest of us :)
>
>
> On Tue, Aug 23, 2016 at 12:40 PM Aaron Halfaker 
> wrote:
>
>> Hi Luis!  Thanks for taking a look.
>>
>> First, I should say that false-positives should be expected.  We're
>> working on better signaling in the UI so that you can differentiate the
>> edits that ORES is confident about and those that it isn't confident about
>> -- but are still worth your review.
>>
>> So, in order to avoid a bias feedback loop, we don't want to feed any
>> observations you made *using* ORES back into the model -- since ORES'
>> prediction itself could bias your assessment and we'd re-perpetuate that
>> bias.  Still, we can use these misclassification reports to direct our
>> attention to problematic behaviors in the model.  We use the Wiki Labels
>> system[1] to gather reviews of random samples of edits from Wikipedians in
>> order to train the model.
>>
>> *Misclassification reports:*
>> See https://meta.wikimedia.org/wiki/Research:Revision_
>> scoring_as_a_service/Misclassifications/Edit_quality
>>
>> We're still working out the Right(TM) way to report false positives.
>> Right now, we ask that you do so on-wiki and in the future, we'll be
>> exploring a nicer interface so that you can report them while using the
>> tool.  We review these misclassification reports manually to focus our work
>> on the models and to report progress made.  This data is never directly
>> used in training the machine learning models due to issues around bias.
>>
>> *Wiki labels campaigns:*
>> In order to avoid the biases in who gets reviewed and why, we generate
>> random samples of edits for review using our Wiki Labels[1] system.  We've
>> completed a labeling campaign for English Wikipedia[2], but we could run an
>> additional campaign to gather more data.  I'll get that set up and respond
>> to this message when it is ready.
>>
>> 1. https://meta.wikimedia.org/wiki/Wiki_labels
>> 2. https://en.wikipedia.org/wiki/Wikipedia:Labels/Edit_quality
>>
>> -Aaron
>>
>> On Tue, Aug 23, 2016 at 1:30 PM, Luis Villa  wrote:
>>
>>> Very cool! Is there any way for users of this tool to help train it? For
>>> example, the first four things it flagged in my watchlist were all false
>>> positives (next 5-6 were correctly flagged.) It'd be nice to be able to
>>> contribute to training the model somehow when we see these false-positives.
>>>
>>> On Tue, Aug 23, 2016 at 11:10 AM Amir Ladsgroup 
>>> wrote:
>>>
 We (The Revision Scoring Team
 )
 are happy to announce the deployment of the ORES
  review tool
  as a beta feature
 
  on *English Wikipedia*. Once enabled, ORES highlights edits that are
 likely to be damaging in Special:RecentChanges
 , Spec
 ial:Watchlist  and
 Special:Contributions
  to help you
 prioritize your patrolling work. ORES detects damaging edits using a
 basic prediction model based on past damage
 .
 ORES is an experimental technology. We encourage you to take advantage of
 it but also to be skeptical of the predictions made. It's a tool to support
 you – it can't replace you. Please reach out to us with your questions and
 concerns.
 Documentationmw:ORES review tool
 , mw:Extension:ORES
 , and m:ORES
 Bugs & feature requests
 https://phabricator.wikimedia.org/tag/revision-scoring-as-a-
 service-backlog/IRC#wikimedia-aiconnect
 
 Sincerely,Amir from the Revision Scoring team
 ___
 AI mailing list
 a...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/ai

>>>
>>> ___
>>> AI mailing list
>>> a...@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/ai
>>>
>>>
>> ___
>> AI mailing list
>> 

Re: [Wikitech-l] [AI] Deployment of ORES review tool in Englis Wikipedia as a beta feature

2016-08-23 Thread Luis Villa
Thanks for the detailed explanation, Aaron. As always your work is a model
in transparency for the rest of us :)

On Tue, Aug 23, 2016 at 12:40 PM Aaron Halfaker 
wrote:

> Hi Luis!  Thanks for taking a look.
>
> First, I should say that false-positives should be expected.  We're
> working on better signaling in the UI so that you can differentiate the
> edits that ORES is confident about and those that it isn't confident about
> -- but are still worth your review.
>
> So, in order to avoid a bias feedback loop, we don't want to feed any
> observations you made *using* ORES back into the model -- since ORES'
> prediction itself could bias your assessment and we'd re-perpetuate that
> bias.  Still, we can use these misclassification reports to direct our
> attention to problematic behaviors in the model.  We use the Wiki Labels
> system[1] to gather reviews of random samples of edits from Wikipedians in
> order to train the model.
>
> *Misclassification reports:*
> See
> https://meta.wikimedia.org/wiki/Research:Revision_scoring_as_a_service/Misclassifications/Edit_quality
>
> We're still working out the Right(TM) way to report false positives.
> Right now, we ask that you do so on-wiki and in the future, we'll be
> exploring a nicer interface so that you can report them while using the
> tool.  We review these misclassification reports manually to focus our work
> on the models and to report progress made.  This data is never directly
> used in training the machine learning models due to issues around bias.
>
> *Wiki labels campaigns:*
> In order to avoid the biases in who gets reviewed and why, we generate
> random samples of edits for review using our Wiki Labels[1] system.  We've
> completed a labeling campaign for English Wikipedia[2], but we could run an
> additional campaign to gather more data.  I'll get that set up and respond
> to this message when it is ready.
>
> 1. https://meta.wikimedia.org/wiki/Wiki_labels
> 2. https://en.wikipedia.org/wiki/Wikipedia:Labels/Edit_quality
>
> -Aaron
>
> On Tue, Aug 23, 2016 at 1:30 PM, Luis Villa  wrote:
>
>> Very cool! Is there any way for users of this tool to help train it? For
>> example, the first four things it flagged in my watchlist were all false
>> positives (next 5-6 were correctly flagged.) It'd be nice to be able to
>> contribute to training the model somehow when we see these false-positives.
>>
>> On Tue, Aug 23, 2016 at 11:10 AM Amir Ladsgroup 
>> wrote:
>>
>>> We (The Revision Scoring Team
>>> )
>>> are happy to announce the deployment of the ORES
>>>  review tool
>>>  as a beta feature
>>> 
>>>  on *English Wikipedia*. Once enabled, ORES highlights edits that are
>>> likely to be damaging in Special:RecentChanges
>>> , Special:Watchlist
>>>  and
>>> Special:Contributions
>>>  to help you
>>> prioritize your patrolling work. ORES detects damaging edits using a
>>> basic prediction model based on past damage
>>> .
>>> ORES is an experimental technology. We encourage you to take advantage of
>>> it but also to be skeptical of the predictions made. It's a tool to support
>>> you – it can't replace you. Please reach out to us with your questions and
>>> concerns.
>>> Documentationmw:ORES review tool
>>> , mw:Extension:ORES
>>> , and m:ORES
>>> Bugs & feature requests
>>> https://phabricator.wikimedia.org/tag/revision-scoring-as-a-service-backlog/
>>> IRC#wikimedia-aiconnect
>>> 
>>> Sincerely,Amir from the Revision Scoring team
>>> ___
>>> AI mailing list
>>> a...@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/ai
>>>
>>
>> ___
>> AI mailing list
>> a...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/ai
>>
>>
> ___
> AI mailing list
> a...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ai
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki code review stats update

2016-08-23 Thread Federico Leva (Nemo)
For those of you who follow 
http://koti.kapsi.fi/~federico/crstats/extensions.txt or other 
https://www.mediawiki.org/wiki/Development_statistics : I just recloned 
all the MediaWiki extensions and rerun the stats, which were no longer 
correct.


Given that either git pull or the ref/notes/review fails every few 
months, I now also run check-sync.sh from the mediawiki/extensions.git 
repo so that http://koti.kapsi.fi/~federico/crstats/git-sync.log 
(hopefully) tells you whether the data is actually up to date.


I also finally set the character-encoding so that UTF-8 is recognised as 
such in all its glory without browser guesses/instructions. ;-)


Nemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [AI] Deployment of ORES review tool in Englis Wikipedia as a beta feature

2016-08-23 Thread Aaron Halfaker
Hi Luis!  Thanks for taking a look.

First, I should say that false-positives should be expected.  We're working
on better signaling in the UI so that you can differentiate the edits that
ORES is confident about and those that it isn't confident about -- but are
still worth your review.

So, in order to avoid a bias feedback loop, we don't want to feed any
observations you made *using* ORES back into the model -- since ORES'
prediction itself could bias your assessment and we'd re-perpetuate that
bias.  Still, we can use these misclassification reports to direct our
attention to problematic behaviors in the model.  We use the Wiki Labels
system[1] to gather reviews of random samples of edits from Wikipedians in
order to train the model.

*Misclassification reports:*
See
https://meta.wikimedia.org/wiki/Research:Revision_scoring_as_a_service/Misclassifications/Edit_quality

We're still working out the Right(TM) way to report false positives.  Right
now, we ask that you do so on-wiki and in the future, we'll be exploring a
nicer interface so that you can report them while using the tool.  We
review these misclassification reports manually to focus our work on the
models and to report progress made.  This data is never directly used in
training the machine learning models due to issues around bias.

*Wiki labels campaigns:*
In order to avoid the biases in who gets reviewed and why, we generate
random samples of edits for review using our Wiki Labels[1] system.  We've
completed a labeling campaign for English Wikipedia[2], but we could run an
additional campaign to gather more data.  I'll get that set up and respond
to this message when it is ready.

1. https://meta.wikimedia.org/wiki/Wiki_labels
2. https://en.wikipedia.org/wiki/Wikipedia:Labels/Edit_quality

-Aaron

On Tue, Aug 23, 2016 at 1:30 PM, Luis Villa  wrote:

> Very cool! Is there any way for users of this tool to help train it? For
> example, the first four things it flagged in my watchlist were all false
> positives (next 5-6 were correctly flagged.) It'd be nice to be able to
> contribute to training the model somehow when we see these false-positives.
>
> On Tue, Aug 23, 2016 at 11:10 AM Amir Ladsgroup 
> wrote:
>
>> We (The Revision Scoring Team
>> )
>> are happy to announce the deployment of the ORES
>>  review tool
>>  as a beta feature
>> 
>>  on *English Wikipedia*. Once enabled, ORES highlights edits that are
>> likely to be damaging in Special:RecentChanges
>> , Special:Watchlist
>>  and Special:
>> Contributions  to
>> help you prioritize your patrolling work. ORES detects damaging edits using
>>  a basic prediction model based on past damage
>> .
>> ORES is an experimental technology. We encourage you to take advantage of
>> it but also to be skeptical of the predictions made. It's a tool to support
>> you – it can't replace you. Please reach out to us with your questions and
>> concerns.
>> Documentationmw:ORES review tool
>> , mw:Extension:ORES
>> , and m:ORES
>> Bugs & feature requests
>> https://phabricator.wikimedia.org/tag/revision-scoring-as-a-
>> service-backlog/IRC#wikimedia-aiconnect
>> 
>> Sincerely,Amir from the Revision Scoring team
>> ___
>> AI mailing list
>> a...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/ai
>>
>
> ___
> AI mailing list
> a...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ai
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [AI] Deployment of ORES review tool in Englis Wikipedia as a beta feature

2016-08-23 Thread Luis Villa
Very cool! Is there any way for users of this tool to help train it? For
example, the first four things it flagged in my watchlist were all false
positives (next 5-6 were correctly flagged.) It'd be nice to be able to
contribute to training the model somehow when we see these false-positives.

On Tue, Aug 23, 2016 at 11:10 AM Amir Ladsgroup  wrote:

> We (The Revision Scoring Team
> )
> are happy to announce the deployment of the ORES
>  review tool
>  as a beta feature
> 
>  on *English Wikipedia*. Once enabled, ORES highlights edits that are
> likely to be damaging in Special:RecentChanges
> , Special:Watchlist
>  and
> Special:Contributions
>  to help you
> prioritize your patrolling work. ORES detects damaging edits using a
> basic prediction model based on past damage
> .
> ORES is an experimental technology. We encourage you to take advantage of
> it but also to be skeptical of the predictions made. It's a tool to support
> you – it can't replace you. Please reach out to us with your questions and
> concerns.
> Documentationmw:ORES review tool
> , mw:Extension:ORES
> , and m:ORES
> Bugs & feature requests
> https://phabricator.wikimedia.org/tag/revision-scoring-as-a-service-backlog/
> IRC#wikimedia-aiconnect
> 
> Sincerely,Amir from the Revision Scoring team
> ___
> AI mailing list
> a...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ai
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Deployment of ORES review tool in Englis Wikipedia as a beta feature

2016-08-23 Thread Amir Ladsgroup
We (The Revision Scoring Team
)
are happy to announce the deployment of the ORES
 review tool
 as a beta feature

 on *English Wikipedia*. Once enabled, ORES highlights edits that are
likely to be damaging in Special:RecentChanges
, Special:Watchlist
 and Special:Contributions
 to help you
prioritize your patrolling work. ORES detects damaging edits using a basic
prediction model based on past damage
.
ORES is an experimental technology. We encourage you to take advantage of
it but also to be skeptical of the predictions made. It's a tool to support
you – it can't replace you. Please reach out to us with your questions and
concerns.
Documentationmw:ORES review tool
, mw:Extension:ORES
, and m:ORES
Bugs & feature requests
https://phabricator.wikimedia.org/tag/revision-scoring-as-a-service-backlog/
IRC#wikimedia-aiconnect

Sincerely,Amir from the Revision Scoring team
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W34 ArchCom-RFC meeting: Schema change for page content language

2016-08-23 Thread Rob Lanphier
Hi everyone,

For this week's office hour, let's discuss [T69223: schema change for
page content language][1]  Jaime Crespo has asked that the developers
seeking this change get general consensus for the change.  A
discussion at an ArchCom IRC meeting isn't strictly necessary for
this, it can't hurt, so let's do it.

My understanding of the key commit[2] is that the new "page_lang"
field was added to the "page" table and that the other schema changes
in the commits are just the ripple effects from changing the page
table.

The discussion is scheduled for 2016-08-24 UTC:
Time: Wednesday 21 UTC (2pm PDT, 23 CEST)
Place: #wikimedia-office
Phab event: [E263]3]
[ArchCom/Status][4]

Rob

[1]: 
[2]: 
[3]: 
[4]: 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l