[Wikitech-l] Upload tools configuration changes on testwikis

[Bartosz Dziewoński]

Hi, I had two changes deployed today that change how UploadWizard and 
the upload dialog are configured on testwiki and test2wiki. I don't 
think this affects anybody but us at Multimedia, but just in case:


* test2wiki no longer has UploadWizard [1] enabled. The configuration
  has always been somewhat broken and hardly anyone used it. It's
  still enabled on testwiki. [2]

* test2wiki can now upload files cross-wiki to testwiki using the
  upload dialog [3]. Upload dialog uploads from testwiki now also
  go to testwiki (locally). Previously they both uploaded to Commons,
  like production wikis. [4]

You can think of these as testwiki acting more like Commons and 
test2wiki acting more like a Wikipedia site. Have fun testing!


[1] https://www.mediawiki.org/wiki/UploadWizard
[2] https://gerrit.wikimedia.org/r/287944
[3] https://www.mediawiki.org/wiki/Upload_dialog
[4] https://gerrit.wikimedia.org/r/285708

--
Bartosz Dziewoński

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

Re: [Wikitech-l] [Mediawiki-i18n] Providing the effective language of messages

[Brion Vibber]

Tagging language and directionality on fallback entries sounds reasonable,
and not a huge addition.

I'm not sure why the fallbacks are cached in the main body instead of
letting them through to the backing language's cache, but if that's a
necessary or useful choice I've no reason to hop in and change it. I also
am a bit mystified why we moved from a filesystem-backed database to a
giant in-memory cache that requires deserializing the entire language cache
on every request (if I'm reading correctly) but apparently that performs
better than I think it should, so take me with a grain of salt... :)

I would recommend getting someone from Performance to weigh in on this to
confirm the proposed solution has no surprises. Probably best to have at
least a preliminary patch which can be run through some paces...

More generally, we should capture the other note in the mediawiki-i18n
thread about having the templating system pick up language and
directionality and fill out the necessary buts for tagging and isolation on
the HTML end.

We may want to think about a class to represent a bit of text or HTML
that's tagged with a language and an isolation factor (not sure if
necessary), which can be mixed and matched with Message objects and passed
into Html class generators or template things. And of course, equivalent on
the JS side.

-- brion
Hi everyone,

Niklas brought this message[1] to my attention as something that
probably deserves more attention than it has gotten, and I trust he's
correct.  What he said back in April: "I added
wikitech-l to CC in hopes that people who have worked on localisation
cache more recently would comment on whether [Adrian's proposed option
to not merge
messages in LocalisationCache] would make more sense nowadays."

Adrian: assuming Niklas and I are correct, my suggestion for moving
this forward would be to turn your design thoughts into an
ArchCom-RFC[2] for more explicit consideration by ArchCom.  My attempt
at abstract for those who haven't followed this:

Adrian was trying to figure out how to output pages that need to have
multiple languages in a single page, which becomes difficult when
fallbacks are missing.  It results in some oddball behavior where
placeholder text is output with incorrect i18n attributes in the
surrounding div.  He provided several alternatives for how to solve
the problem in his mail to mediawiki-i18n.  Niklas replied, providing
the "if we stick with the status quo" answer (tag message strings in
LocalisationCache with the correct language), and then is trying to
figure out if the status quo makes the right space vs speed tradeoff
given the quantity of languages and messages we have in 2016.

Adrian & Niklas: did I get the gist of it?

Rob

[1]: The April 2016 mediawiki-i18n thread: "Providing the effective
language of messages"
 <
https://lists.wikimedia.org/pipermail/mediawiki-i18n/2016-April/thread.html#1059
>
[2]: My unofficial guide on how to turn something into an ArchCom-RFC:


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

[Wikitech-l] Revision Scoring weekly update

[Aaron Halfaker]

Hey folks,

This is the weekly update for the Revision Scoring project for the week of
April 2nd through April 8th.

*New developments:*

   - Solved some issues that block a major performance improvement for
   score requests using multiple models[2]


   - Improved the performance of feature extraction for features that use
   mwparserfromhell[3,4]


   - We applied regex performance optimizations to badwords and informal
   word detection for many languages[9]


*Maintenance and robustness:*

   - Solved a regression in ScoredRevisions that caused most revisions in
   RecentChanges to not be scored[1]


   - Set ORES load balancer to rebalance on 500 responses from a web node[5]


   - Enabled CORS for error responses from ORES -- this makes it easier to
   report errors from a gadget on a wiki[6]


   - Sade the staging instance of Wikilabels[7] look a lot more like the
   production instance[8]


1. https://phabricator.wikimedia.org/T134601
2. https://phabricator.wikimedia.org/T134781
3. https://mwparserfromhell.readthedocs.io
4. https://phabricator.wikimedia.org/T134780
5. https://phabricator.wikimedia.org/T111806
6. https://phabricator.wikimedia.org/T119325
7. https://labels-staging.wmflabs.org/gadget/
8. https://phabricator.wikimedia.org/T134627
9. https://phabricator.wikimedia.org/T134267

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

Re: [Wikitech-l] [Mediawiki-i18n] Providing the effective language of messages

[Rob Lanphier]

Hi everyone,

Niklas brought this message[1] to my attention as something that
probably deserves more attention than it has gotten, and I trust he's
correct.  What he said back in April: "I added
wikitech-l to CC in hopes that people who have worked on localisation
cache more recently would comment on whether [Adrian's proposed option
to not merge
messages in LocalisationCache] would make more sense nowadays."

Adrian: assuming Niklas and I are correct, my suggestion for moving
this forward would be to turn your design thoughts into an
ArchCom-RFC[2] for more explicit consideration by ArchCom.  My attempt
at abstract for those who haven't followed this:

Adrian was trying to figure out how to output pages that need to have
multiple languages in a single page, which becomes difficult when
fallbacks are missing.  It results in some oddball behavior where
placeholder text is output with incorrect i18n attributes in the
surrounding div.  He provided several alternatives for how to solve
the problem in his mail to mediawiki-i18n.  Niklas replied, providing
the "if we stick with the status quo" answer (tag message strings in
LocalisationCache with the correct language), and then is trying to
figure out if the status quo makes the right space vs speed tradeoff
given the quantity of languages and messages we have in 2016.

Adrian & Niklas: did I get the gist of it?

Rob

[1]: The April 2016 mediawiki-i18n thread: "Providing the effective
language of messages"
 

[2]: My unofficial guide on how to turn something into an ArchCom-RFC:


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

Re: [Wikitech-l] ResourceLoader addModuleStyles() issues

[Krinkle]

Next steps now written up at
https://phabricator.wikimedia.org/T92459#2281878

On Mon, May 9, 2016 at 7:45 PM, Krinkle  wrote:

>
>
> On Mon, May 9, 2016 at 7:17 PM, Brion Vibber 
> wrote:
>
>>
>>
>> So, step 2 happens at least 30 days after deploying step 1? Or step 2
>> retains same behavior for Output A?
>>
>> -- brion
>>
>>
> 14 days [1]. But yes, we'll need some breathing room after step 1.
>
> After step 2, old output A would try to load "site" as style module still
> (which no longer has styles). Though after a FOUC, it would still fallback
> by loading 'site.styles' on-demand as dependency of "site".
>
> [1] https://phabricator.wikimedia.org/T124954
>
> -- Krinkle
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [Breaking Change] Scap change for deployers

[Tyler Cipriani]

tl;dr: Our beloved scap is changing to use subcommands rather than a
bunch of scripts, but the existing scripts will work for a short time.

Starting with the 3.2.0 release[0], which will hit production in the
next day or so, scap will use subcommands rather than using many
different scripts that all call the same underlying code. The scripts
(e.g., deploy, sync-file, sync-dir, sync-wikiversions.) will continue
to work as usual, but they will issue a deprecation warning until the
next release when they will disappear.

The most notable exception is the `scap` command which must be invoked
as `scap sync [message]`.

The docs are updated[1] and you can see new help output there or on
phabricator[2].

Long story short, you will now run:

scap sync-file  [message]

Instead of:

sync-file  [message]

This change has been cherry-picked on beta cluster and is currently live there.

<3,
Tyler Cipriani and the Deployment Working Group

[0]. https://gerrit.wikimedia.org/r/#/c/287918
[1]. https://doc.wikimedia.org/mw-tools-scap/
[2]. https://phabricator.wikimedia.org/P3027

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

Re: [Wikitech-l] historical trivia: who first picked UTC as Wikimedia time, when and why?

[Daniel Friesen]

On 2016-05-10 1:23 AM, Jaime Crespo wrote:
> On Mon, May 9, 2016 at 6:15 PM, Brion Vibber  wrote:
>> In 2001 when Magnus was writing the initial attempt at a custom wiki engine
>> in PHP backed by MySQL, he chose to use the TIMESTAMP column type.
>>
>> TIMESTAMPs in MySQL 3 were automatically filled out by the server at INSERT
>> time, normalized to UTC, and exposed in the 14-digit MMDDHHMMSS format
>> we still know and love today.
> By the way, if we had to design this from the scratch, TIMESTAMPs now
> allow to not be auto set
> https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html
> This would save 15 - 4 = 11 bytes per row. However, both in code and
> migration effort + potential bugs + backwards compatibility, this is
> not worth it.
Plus TIMESTAMP suffers from the year 2038 problem.
https://en.wikipedia.org/wiki/Year_2038_problem

DATETIME only needs to worry about the Y10K problem.
https://en.wikipedia.org/wiki/Year_10,000_problem

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

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

[Wikitech-l] MediaWiki codesniffer updates on extensions

[Niklas Laxström]

I noticed that lots of extensions were recently updated to use
mediawiki-codesniffer 0.7.1 [1].

This has some implications I think are worth being aware of:

1) Many open patches will need manual rebasing and conflict resolution.
2) Those extensions will now depend on at least PHP 5.4 due to short
array syntax [2] instead of PHP 5.3.

Both can cause inconveniences, (1) mainly for developers and (2)
mostly for users.

Some patches doing this update in a more thorough and tested way [3]
existed but were ignored. It would be nice to avoid that in the
future.

Please also watch out for code that might have got removed
unexpectedly due to a bug [4]. On quick inspection I did not see this
happening in those patches.

[1] https://gerrit.wikimedia.org/r/#/q/status:merged+topic:bump-dev-deps,n,z
[2] https://secure.php.net/manual/en/migration54.new-features.php
[3] For example https://gerrit.wikimedia.org/r/#/c/287315/
[4] https://phabricator.wikimedia.org/T134857

  -Niklas

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

[Wikitech-l] WatchedItemStore - What, Why & How

[Addshore]

Over the past few months the TCB team at WMDE has been working on
re-factoring code in core surrounding watchlists.

You can find a full blog post about what we did, why we did it and how we
did it at the link below:
http://addshore.com/2016/05/refactoring-around-watcheditem-in-mediawiki

tl;dr This was work put into making introducing expiring watchlist entries
easier. Code was removed from various API modules, special pages and other
random places. The new extracted code now has basically 100% unit &
integration test coverage.

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

Re: [Wikitech-l] historical trivia: who first picked UTC as Wikimedia time, when and why?

[Jaime Crespo]

On Mon, May 9, 2016 at 6:15 PM, Brion Vibber  wrote:
> In 2001 when Magnus was writing the initial attempt at a custom wiki engine
> in PHP backed by MySQL, he chose to use the TIMESTAMP column type.
>
> TIMESTAMPs in MySQL 3 were automatically filled out by the server at INSERT
> time, normalized to UTC, and exposed in the 14-digit MMDDHHMMSS format
> we still know and love today.

By the way, if we had to design this from the scratch, TIMESTAMPs now
allow to not be auto set
https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html
This would save 15 - 4 = 11 bytes per row. However, both in code and
migration effort + potential bugs + backwards compatibility, this is
not worth it.

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

Re: [Wikitech-l] JetBrains licenses for Volunteers and Staff

[Pine W]

Thanks for the info. I may request a license in mid to late Fall, when I
hope to be participating in Wikimedia software development.

Pine
On May 9, 2016 23:06, "Yuri Astrakhan"  wrote:

> Hi Pine,
>
> They are not upgrades, they are full one year renewable free licenses for
> the powerful ide with php, js, puppet, Ruby, Python, c++, ... , donated to
> help with Wiki development.
>
> You basically need to be a volunteer or a staff developer working on Wiki
> projects with some history of code contributions.   Resharper is a great
> product and it is part of the license, but I am not sure we have any .net
> code (I think we used to run bits of mono code somewhere, but that was a
> while ago). Have you submitted any patches? In what languages?
>
> Thanks!
> On May 10, 2016 08:48, "Pine W"  wrote:
>
> > Hi Yuri,
> >
> > ReSharper interests me. This email refers to license upgrades. What is
> > involved in initially qualifying for a license?
> >
> > Thanks,
> >
> > Pine
> > On Apr 18, 2016 09:44, "Yuri Astrakhan" 
> wrote:
> >
> > > PhpStorm, InteliJ IDEA, Resharper and other JetBrain users, we just
> > > received free upgraded licenses for all of their products.
> > >
> > > Check your account at https://account.jetbrains.com/licenses and login
> > > with
> > > that account inside your application to automatically use that license.
> > If
> > > you don't see the license, contact me or Sam Reed, and we will add you
> > > right away.  On IRC: yurik or reedy, or via email.  We could also use a
> > few
> > > more admins for these licenses. You will no longer need to copy/paste
> any
> > > licenses manually.
> > >
> > > IDEA:  use for PHP, JavaScript, Puppets, Ruby, and other web-related
> > > technologies
> > > https://www.jetbrains.com/idea/
> > >
> > > Resharper: for C# and Microsoft Visual Studio C++
> > > https://www.jetbrains.com/resharper/
> > >
> > > CLion: for C++
> > > https://www.jetbrains.com/clion/
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] JetBrains licenses for Volunteers and Staff

[Yuri Astrakhan]

Hi Pine,

They are not upgrades, they are full one year renewable free licenses for
the powerful ide with php, js, puppet, Ruby, Python, c++, ... , donated to
help with Wiki development.

You basically need to be a volunteer or a staff developer working on Wiki
projects with some history of code contributions.   Resharper is a great
product and it is part of the license, but I am not sure we have any .net
code (I think we used to run bits of mono code somewhere, but that was a
while ago). Have you submitted any patches? In what languages?

Thanks!
On May 10, 2016 08:48, "Pine W"  wrote:

> Hi Yuri,
>
> ReSharper interests me. This email refers to license upgrades. What is
> involved in initially qualifying for a license?
>
> Thanks,
>
> Pine
> On Apr 18, 2016 09:44, "Yuri Astrakhan"  wrote:
>
> > PhpStorm, InteliJ IDEA, Resharper and other JetBrain users, we just
> > received free upgraded licenses for all of their products.
> >
> > Check your account at https://account.jetbrains.com/licenses and login
> > with
> > that account inside your application to automatically use that license.
> If
> > you don't see the license, contact me or Sam Reed, and we will add you
> > right away.  On IRC: yurik or reedy, or via email.  We could also use a
> few
> > more admins for these licenses. You will no longer need to copy/paste any
> > licenses manually.
> >
> > IDEA:  use for PHP, JavaScript, Puppets, Ruby, and other web-related
> > technologies
> > https://www.jetbrains.com/idea/
> >
> > Resharper: for C# and Microsoft Visual Studio C++
> > https://www.jetbrains.com/resharper/
> >
> > CLion: for C++
> > https://www.jetbrains.com/clion/
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l