[Wikitech-l] Re: Use case for sha1 in revisions

[Vi to]

Afair this avoids a new rev to be createad if you click "save" without
changing contents.

Vito

Il giorno gio 23 mar 2023 alle ore 11:35 Bináris  ha
scritto:

> Thanks!
>
> Brian Wolff  ezt írta (időpont: 2023. márc. 23., Cs,
> 7:06):
>
>> This kind of sounds like a non-answer, but its mostly useful if you want
>> a hash of the revision. I dont think mw core really uses it, but it can be
>> useful for quickly detecting duplicate revisions. I think primarily it is
>> for external users.
>>
>> --
>> Brian
>>
>> On Wednesday, March 22, 2023, Bináris  wrote:
>>
>>> Hi,
>>> can someone please tell me a use case for sha1 in revisions?
>>> https://www.mediawiki.org/wiki/API:Revisions
>>>
>>> (Of course, I tried first on talk page.)
>>> --
>>> Bináris
>>>
>> ___
>> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
>>
>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
>
>
> --
> Bináris
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: 🚀 Amir Sarabadani receives Web Perf Hero award!

[Vi to]

Lol, true, I was having volunteers in mind.

Vito

Il giorno gio 26 mag 2022 alle ore 20:39 Daniel Zahn 
ha scritto:

> > awards should be accompained with some merch giveaway.
>
> or how about an extra day off? :)  Congratulations Amir!
>
> On Thu, May 26, 2022 at 10:51 AM Vi to  wrote:
> >
> > Half joking half seriously I think awards should be accompained with
> some merch giveaway.
> >
> > Vito
> >
> > Il giorno gio 26 mag 2022 alle ore 16:22 Krinkle 
> ha scritto:
> >>
> >> I'm happy to share that the first Web Perf Hero award of 2022 goes to
> Amir Sarabadani!
> >>
> >> This award is in recognition of Amir's work (@Ladsgroup) over the past
> six months, in which he demonstrated deep expertise of the MediaWiki
> platform and significantly sped up the process of saving edits in
> MediaWiki. This improved both the potential of MediaWiki core, and as
> experienced concretely on WMF wikis, especially on Wikidata.org.
> >>
> >> Refer to the below medawiki.org page to read about what it took to cut
> latencies by half:
> >>
> https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Web_Perf_Hero_award#Amir_Sarabadani
> >>
> >> This award is given on a quarterly basis, and manifests as a
> Phabricator badge:
> >> https://phabricator.wikimedia.org/badges/view/17/
> >>
> >> -- Timo Tijhof, on behalf of WMF Performance Team.
> >>
> >> ___
> >> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> >> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> >>
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
> >
> > ___
> > Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> > To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> >
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
>
>
> --
> Daniel Zahn 
> Site Reliability Engineer
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: 🚀 Amir Sarabadani receives Web Perf Hero award!

[Vi to]

Half joking half seriously I think awards should be accompained with some
merch giveaway.

Vito

Il giorno gio 26 mag 2022 alle ore 16:22 Krinkle  ha
scritto:

> I'm happy to share that the first Web Perf Hero award of 2022 goes to Amir
> Sarabadani!
>
> This award is in recognition of Amir's work (@Ladsgroup) over the past six
> months, in which he demonstrated deep expertise of the MediaWiki platform
> and significantly sped up the process of saving edits in MediaWiki. This
> improved both the potential of MediaWiki core, and as experienced
> concretely on WMF wikis, especially on Wikidata.org.
>
> Refer to the below medawiki.org page to read about what it took to *cut
> latencies by half*:
>
> https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Web_Perf_Hero_award#Amir_Sarabadani
>
> This award is given on a quarterly basis, and manifests as a Phabricator
> badge:
> https://phabricator.wikimedia.org/badges/view/17/
>
> -- Timo Tijhof, on behalf of WMF Performance Team.
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: [Commons-l] Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery)

[Vi to]

One could argue market economy inevitably ends up in monopolies, similarly
projects drawing less attention or offering no short-term benefits die of
starvation. Fixing Wikidata technical weaknesses, for example, didn't draw
enough attention for years.

Vito


Il giorno lun 3 gen 2022 alle ore 02:22 Lars Aronsson  ha
scritto:

> On 2022-01-01 21:37, Mike Peel wrote:
> > Hi Asaf,
> >
> > That's a good response, but I'm not sure it provides a practical way
> > forward. How can volunteers bring this issue to the attention of the
> > WMF leadership to get the allocation of the time of Wikimedia staff
> > who can take ownership implement changes here?
>
> We have thousands of volunteers. And that's a problem. We wish
> that we had millions of volunteers.
>
> Even with only thousands of volunteers, bringing more things "to
> the attention" of WMF leadership would be disasterous. The
> solution must lie in the opposite direction: solving issues without
> having to bring them to the attention of the top leadership.
>
> This whole discussion reminds me of inefficiencies of the Soviet
> economy. How can central planning be so inefficient? If only
> Stalin or Brezhnev knew, he would put things straight, right?
> How can we bring more details to the Kremlin's attention?
>
> The western, non-communist approach is to empower
> individuals to run enterprises without bringing everything to
> the attention of the top leadership. In a free market economy.
>
> But a market economy for us, must mean that resources are
> allocated to those who are able to offer solutions that saves
> resources for other volunteers. How can we do this without
> paying actual money for the solutions? If your video upload
> costs you dozens of hours, and I can design a solution that
> saves your time, how can your saving benefit me? And after
> the new solution is in place, free for all, how will anybody
> know that it saves them dozens of hours? This is the big
> question that we should focus on answering.
>
>
>
> --
>Lars Aronsson (l...@aronsson.se)
>Linköping, Sweden
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Gsoc 2022 contribution

[Vi to]

Mine was self-irony about my mistake. To be clear, I apologize since I
wasn't able to locate that page, thus I made an useless comment.

Vito

Il giorno mar 30 nov 2021 alle ore 09:25 Andre Klapper <
aklap...@wikimedia.org> ha scritto:

> Hi Vito,
>
> On Mon, 2021-11-29 at 22:39 +0100, Vi to wrote:
> > [directed by Robert B. Weide]
> > *Michielini's "frolic" plays in background*
>
> Ah, okay. Would you also consider answering my questions and not just
> share your playlist?
>
> Thanks,
> andre
>
> > Il giorno lun 29 nov 2021 alle ore 15:42 Andre Klapper
> >  ha scritto:
> > > On Mon, 2021-11-29 at 15:14 +0100, Vi to wrote:
> > > > I think we should make an help page for people googling "GSoC
> > > > Mediawiki" or similar.
> > >
> > > Errm, did you try googling "mediawiki gsoc"? The first result is
> > > https://www.mediawiki.org/wiki/Google_Summer_of_Code .
> > >
> > > What's a "help page", and what would it change (and why)?
> > >
> > > For the records, there's also some info under "Summary" on
> > > https://lists.wikimedia.org/postorius/lists/wikitech-
> > > l.lists.wikimedia.org/
> > >
> > > andre
> > > ___
> > > Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> > > To unsubscribe send an email to wikitech-l-
> > > le...@lists.wikimedia.org
> > > https://lists.wikimedia.org/postorius/lists/wikitech-
> > > l.lists.wikimedia.org/
>
> --
> Andre Klapper (he/him) | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Gsoc 2022 contribution

[Vi to]

Thank you for this insight Sohom, listing this mailing list there is ok,
but a link to https://www.mediawiki.org/wiki/Google_Summer_of_Code would be
quite more useful for readers.

Vito

Il giorno mar 30 nov 2021 alle ore 07:43 Sohom Datta 
ha scritto:

> @AndreKlapper We should probably remove this mailing list from the
> description page in Google Summer of Code (this
> <https://summerofcode.withgoogle.com/archive/2021/organizations/5270263742070784/>
> was what the page looked like last year) and add links to more
> beginner-friendly starting points (New_Developers,
> How_to_become_a_MediaWiki_hacker, Zulip chat, IRC etc) instead.
>
> IMO, that page is more popular among new developers compared to the one
> hosted on mediawiki.org, since quite a lot of new developers will go
> through lists of previously chosen organizations that are available on the
> Summer of Code website and then choose a few cool projects rather than
> Googling for a specific organization and their status wrt to GSoC.
>
> Regards,
> Sohom Datta
>
>
> On Tue, Nov 30, 2021 at 10:38 AM Siddharth VP 
> wrote:
>
>> The comment above on creating a help page for GSoC MediaWiki was not
>> directed at you, Viren Variya and Ashish Tiwari. Please just refer to
>> https://www.mediawiki.org/wiki/New_Developers for now. Pick a project,
>> explore the codebase, understand what the software does, understand what
>> are the issues or feature requests, and ask smart questions when in doubt.
>>
>> While working on any project, it's good to ensure that it's needed and
>> identify the requirements before you start working on it, neither of which
>> has happened here. If creating a help page were a project (it is not), you
>> would have been given more context and details about what needs to be done.
>>
>> On Tue, 30 Nov 2021 at 09:46, Viren Variya 
>> wrote:
>>
>>> Ashish tiwari can we work by collaboratively because I am also working
>>> on same page and having good knowledge in web development. If you ready so
>>> we can conform with organization too
>>>
>>> Thanks & Regards
>>>
>>> On Tue, 30 Nov 2021, 3:02 am Ashish tiwari,  wrote:
>>>
>>>> good morning sir
>>>> As you have told about the help page " GSOC Mediawiki " in earlier chat
>>>> . I have clone a static and a basic design using html and css please
>>>> review it and please guide what are the content or hyperlink we should add
>>>> to help the people to contribute in wikimedia, sir please tell me about ,
>>>> how should i share the code with you . I should make repository in my
>>>> github account and share the link with you or in some other way
>>>>
>>>> On Mon, Nov 29, 2021 at 8:15 PM Ashish tiwari 
>>>> wrote:
>>>>
>>>>> OK, thank you for your suggestion  sir , I will make it .
>>>>>
>>>>> On Mon, Nov 29, 2021, 7:45 PM Vi to  wrote:
>>>>>
>>>>>> I think we should make an help page for people googling "GSoC
>>>>>> Mediawiki" or similar.
>>>>>>
>>>>>> Vito
>>>>>>
>>>>>> Il giorno dom 28 nov 2021 alle ore 18:45 Jay prakash <
>>>>>> 0freerunn...@gmail.com> ha scritto:
>>>>>>
>>>>>>> Hi Viren,
>>>>>>>
>>>>>>> Please see https://www.mediawiki.org/wiki/New_Developers and
>>>>>>> https://www.mediawiki.org/wiki/Outreach_programs.
>>>>>>>
>>>>>>>
>>>>>>> Jay Prakash,
>>>>>>> Volunteer Developer, Wikimedia Community
>>>>>>>
>>>>>>> On Sun, Nov 28, 2021 at 11:04 PM viren 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Respected organization,
>>>>>>>>
>>>>>>>> I am variya viren 2nd year undergraduate Computer science student I
>>>>>>>> want to contribute to your open source project. As I am intermediate in
>>>>>>>> open-source platform any have experience of it because I am a part of
>>>>>>>> hactoberfect 2021 and girlsScript winter for contribution this both 
>>>>>>>> are of
>>>>>>>> open source event.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I know C++, C, Python, HTML, CSS, JavaScript, React, and 

[Wikitech-l] Re: Gsoc 2022 contribution

[Vi to]

[directed by Robert B. Weide]
*Michielini's "frolic" plays in background*

Vito

Il giorno lun 29 nov 2021 alle ore 15:42 Andre Klapper <
aklap...@wikimedia.org> ha scritto:

> On Mon, 2021-11-29 at 15:14 +0100, Vi to wrote:
> > I think we should make an help page for people googling "GSoC
> > Mediawiki" or similar.
>
> Errm, did you try googling "mediawiki gsoc"? The first result is
> https://www.mediawiki.org/wiki/Google_Summer_of_Code .
>
> What's a "help page", and what would it change (and why)?
>
> For the records, there's also some info under "Summary" on
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
> andre
> --
> Andre Klapper (he/him) | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Gsoc 2022 contribution

[Vi to]

I think we should make an help page for people googling "GSoC Mediawiki" or
similar.

Vito

Il giorno dom 28 nov 2021 alle ore 18:45 Jay prakash <0freerunn...@gmail.com>
ha scritto:

> Hi Viren,
>
> Please see https://www.mediawiki.org/wiki/New_Developers and
> https://www.mediawiki.org/wiki/Outreach_programs.
>
>
> Jay Prakash,
> Volunteer Developer, Wikimedia Community
>
> On Sun, Nov 28, 2021 at 11:04 PM viren  wrote:
>
>> Respected organization,
>>
>> I am variya viren 2nd year undergraduate Computer science student I want
>> to contribute to your open source project. As I am intermediate in
>> open-source platform any have experience of it because I am a part of
>> hactoberfect 2021 and girlsScript winter for contribution this both are of
>> open source event.
>>
>>
>>
>> I know C++, C, Python, HTML, CSS, JavaScript, React, and apart from this
>> I have good problem-solving skills because I am a competitive programmer
>> and active user at codeforces, codechef, and leetcode
>>
>>
>>
>> I am very curious to contribute to your project and expand my knowledge,
>> Please give your guidance and proper direction to more ahead
>>
>>
>>
>> Regards,
>>
>> Viren Variya
>>
>>
>>
>> Sent from Mail  for
>> Windows 10
>>
>>
>> ___
>> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
>>
>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Wikimedia Enterprise HTML dumps available for public download

[Vi to]

 "Great", "cool" and "impressive" are the first adjectives which pop out in
my mind!

[screen of my ADSL7 trying downloading en.wiki 90GB dump]

Vito

Il giorno mar 19 ott 2021 alle ore 16:57 Ariel Glenn WMF <
ar...@wikimedia.org> ha scritto:

> I am pleased to announce that Wikimedia Enterprise's HTML dumps [1] for
> October 17-18th are available for public download; see
> https://dumps.wikimedia.org/other/enterprise_html/ for more information.
> We expect to make updated versions of these files available around the
> 1st/2nd of the month and the 20th/21st of the month, following the cadence
> of the standard SQL/XML dumps.
>
> This is still an experimental service, so there may be hiccups from time
> to time. Please be patient and report issues as you find them. Thanks!
>
> Ariel "Dumps Wrangler" Glenn
>
> [1] See https://www.mediawiki.org/wiki/Wikimedia_Enterprise for much more
> about Wikimedia Enterprise and its API.
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Re: [Wikitech-l] Wikimedia service interruptions; phab task https://phabricator.wikimedia.org/T232224

[Vi to]

We've been under a DDoS attack for more than two hours.

Vito

Il giorno ven 6 set 2019 alle ore 22:20 Pine W  ha
scritto:

> Discussion in https://phabricator.wikimedia.org/T232224. I had trouble
> connecting to Phabricator also, so I'm guessing that IRC is a good
> alternate channel for communications. However, as usual, let's not all pile
> into IRC, email, and/or Phabricator and say "I'm having problems connecting
> to Wikimedia sites" when the technical ops folks are working on this.
>
> Regards,
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> ___
> 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] Abusefilter and Content Translator

[Vi to]

If usage of Google translate at any stage is detected by such a raw
technology as abusefilter is, then there's something wrong with the
subsequent editing.

It seems zh.wiki is struggling against poor translations, it would be *so*
wrong to go in the opposite direction.

Vito

Il giorno dom 28 apr 2019 alle ore 11:01  ha scritto:

> Hi all,
>
> We are doing an edit-a-thon and some participants are using the content
> translator with some complicated issues.
>
>
>
> The main one is that the content translator is now integrating Google
> translator but when a participant publishes the translation, the
> AbuseFIlter
> says that it is an automatic translation from Google even if the
> participant
> has modified the text.
>
>
>
> This happens specifically in the Chinese Wikipedia. Is that normal?
>
>
>
> We have seen that modifying the wiki links and the external references it
> solves the problem, but in other linguistic versions the Content Translator
> does it automatically.
>
>
>
> In addition it doesn’t work for tables and for infoboxes.
>
>
>
> May someone confirm that these issues are connected with some bugs and that
> we are not doing some mistakes?
>
>
>
> Kind regards
>
>
>
> ---
>
> Ilario Valdelli
>
> Education Program manager and community liaison
>
> Wikimedia CH
> Verein zur Förderung Freien Wissens
> Association pour l’avancement des connaissances libre
> Associazione per il sostegno alla conoscenza libera
> Switzerland - 8008 Zürich
>
> Wikipedia:   Ilario
>   http://www.wikimedia.ch
>
>
>
> ___
> 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] Question to WMF: Backlog on bugs

[Vi to]

Regardless of definition-related issues, I concur editors' most
shared/fundamental needs deserve being addressed spending some money.

Vito

Il giorno mar 12 mar 2019 alle ore 11:50 John Erling Blad 
ha scritto:

> Without the editors there would be no content, and thus no readers,
> and without readers there would be no use for the software provided.
> So is the actual users subsidizing the software? Definitely yes! The
> content is the primary reason why we have readers. The software is
> just a tool to provide the content in an accessible form to the
> readers.
>
> Whether an editor is a customer by subsidizing the product directly or
> indirectly is not much of a concern, as long as there will be no
> subsidizing at all, from any party – ever, without the content.
>
> The primary customer of the software is the editors, but the primary
> customer of the content is the readers.
>
> On Tue, Mar 12, 2019 at 2:18 AM David Barratt 
> wrote:
> >
> > A customer, by definition (https://en.wikipedia.org/wiki/Customer)
> > exchanges something of value (money) for a product or service.
> >
> > That does not mean that a freemium model (
> > https://en.wikipedia.org/wiki/Freemium) is not a valid business model.
> > However, if there is no exchange of value, the person consuming the free
> > version of the product or service, is not (yet) a customer.
> >
> > If MediaWiki is the thing we give away for free, what do we charge money
> > for?
> > Are our customers successfully subsidizing our free (as in beer)
> software?
> >
> > On Mon, Mar 11, 2019 at 7:33 PM John Erling Blad 
> wrote:
> >
> > > > 2- Everything is open-source and as non-profit, there's always
> resource
> > > > constraint. If it's really important to you, feel free to make a
> patch
> > > and
> > > > the team would be always more than happy to review.
> > >
> > > Wikipedia is the core product, and the users are the primary
> > > customers. When a group of core customers request a change, then the
> > > service provider should respond. Whether the service provider is a
> > > non-profit doesn't really matter, the business model is not part of
> > > the functional requirement. The service provider should simply make
> > > sure the processes function properly.
> > >
> > > If the service provider has resource constraints, then it must scale
> > > the services until it gets a reasonable balance, but that does not
> > > seem to be the case here. It is more like there are no process or the
> > > process is defunc.
> > >
> > > The strange thing is; for many projects the primary customers aren't
> > > even part of a stakeholder group, the devs in the groups defines
> > > themselves as the "product user group". That tend to skew development
> > > from bugs to features. Perhaps that is what happen in general here,
> > > too much techies that believe they are the primary customers.
> > >
> > > ___
> > > 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] UserMerge extension on Wikimedia sites

[Vi to]

AFAIR it was at very risk of breaking the Internet, so it went into a limbo
of being installed but never used.

Vito

Il giorno mar 22 gen 2019 alle ore 08:46 Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il> ha scritto:

> Hi,
>
> Is the UserMerge extension actually used on Wikimedia sites?
>
> As far as I can see, it is only installed on Wikivoyage, and the last log
> entries of its usage are from 2015. However, it's possible that I'm missing
> something.
>
> The reason I'm asking is that I'd love to know how to configure it best in
> translatewiki. If it's not actually used on Wikimedia sites or developed
> significantly, then it should be filed under "Legacy".
>
> Thanks! :)
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
> ___
> 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] blocking - unblocking, wikivoyage

[Vi to]

Though some of these points are incorrect or simply false none of them are
relevant to this mailing list.

Vito

Il giorno lun 7 gen 2019 alle ore 11:54 80hnhtv4agou--- via Wikitech-l <
wikitech-l@lists.wikimedia.org> ha scritto:

>
> I do not see what community this is being controlled by;
>
> 1. there is no notice boards, or request for administrators, etc..
>
> 2. there is no arbitration commity to go to, etc..
>
> 3. there are no rules on who may be blocked.
>
> 4. there is no unblocking feature, and yet there is a review page.
>   https://en.wikivoyage.org/wiki/Category:Requests_for_unblock
>
> 5. there is nothing in place to punish administrators that abuse there
> blocking powers etc..
>
> 6. there is no active user talk page to request an
> unblock.
> ___
> 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] Unblocking 79 IPs blocked as open proxies 12 years ago (T189840)

[Vi to]

Sorry for being late. I've just globally blocked these IPs, now we can
start the examination of their current status.

Vito

2018-03-24 0:26 GMT+01:00 Pine W :

> Hello,
>
> Thanks for looking into these issues. I would like to suggest that good
> forums for this discussion prior to removing blocked IPs, and good places
> to notify Wikimedians who are likely to be interested in these subjects,
> would be the Stewards' Noticeboard on Meta at
> https://meta.wikimedia.org/wiki/Stewards%27_noticeboard, and the ENWP
> Administrators' Noticeboard at
> https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard. I
> would like to suggest that further discussion take place at those locations
> and/or the Phabricator ticket.
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
>
> > > >
> > > > >
> > > > > On March 21, 2018 at 11:50:50 AM, Brad Jorsch (Anomie) (
> > > > > bjor...@wikimedia.org) wrote:
> > > > >
> > > > > In 2005–2006 a sysadmin blocked 79 IP addresses on all wikis as
> being
> > > > > automatically-detected open proxies, without recording them in the
> > > block
> > > > > log or attributing the block to any user account. These incomplete
> > > > records
> > > > > are now causing errors when MediaWiki tries to access them in
> various
> > > > > places, see https://phabricator.wikimedia.org/T189840.
> > > > >
> > > > > Since these are all over 12 years old, it seems reasonably likely
> > that
> > > > many
> > > > > of these are no longer open proxies. Rather than trying to fix the
> > > > > incomplete records, I'm just going to remove them.
> > > > >
> > > > > Any existing blocks of these IPs that are not causing errors will
> not
> > > be
> > > > > removed. At first glance this seems relevant mainly to enwiki,
> where
> > > > only 5
> > > > > of the IPs have incomplete records. 21 are currently blocked there
> > with
> > > > > complete records (19 since 2005 or earlier), and the other 53 are
> not
> > > > > currently blocked there.
> > > > >
> > > > > The list of IPs is at https://phabricator.wikimedia.org/P6876 in
> > case
> > > > > anyone wants to review them for potential reblocking.
> > > > >
> > > > > --
> > > > > Brad Jorsch (Anomie)
> > > > > Senior Software Engineer
> > > > > Wikimedia Foundation
> >
> ___
> 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] Unblocking 79 IPs blocked as open proxies 12 years ago (T189840)

[Vi to]

Indeed, but I'd convert them to ordinary blocks as first step, so I'll have
more time for checking.

Vito

2018-03-22 7:49 GMT+01:00 Dora Winterstorm :

> Should we check if any of the IPs are still used as proxies before mass
> blocking them?
>
>
>
> 
> From: Wikitech-l  on behalf of Vi
> to 
> Sent: Wednesday, March 21, 2018 10:39:29 PM
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] Unblocking 79 IPs blocked as open proxies 12
> years ago (T189840)
>
> If you give me a list of stuffs blocked in this legacy manner I'll convert
> them to regular global blocks to be handled by the usual community means.
>
> Vito
>
> 2018-03-21 19:52 GMT+01:00 James Hare :
>
> > I think deleting those block records is acceptable, and if they need to
> be
> > blocked again, we can just block them again. Instituting blocks like this
> > seems like an anti-pattern we should avoid.
> >
> >
> > On March 21, 2018 at 11:50:50 AM, Brad Jorsch (Anomie) (
> > bjor...@wikimedia.org) wrote:
> >
> > In 2005–2006 a sysadmin blocked 79 IP addresses on all wikis as being
> > automatically-detected open proxies, without recording them in the block
> > log or attributing the block to any user account. These incomplete
> records
> > are now causing errors when MediaWiki tries to access them in various
> > places, see https://phabricator.wikimedia.org/T189840.
> >
> > Since these are all over 12 years old, it seems reasonably likely that
> many
> > of these are no longer open proxies. Rather than trying to fix the
> > incomplete records, I'm just going to remove them.
> >
> > Any existing blocks of these IPs that are not causing errors will not be
> > removed. At first glance this seems relevant mainly to enwiki, where
> only 5
> > of the IPs have incomplete records. 21 are currently blocked there with
> > complete records (19 since 2005 or earlier), and the other 53 are not
> > currently blocked there.
> >
> > The list of IPs is at https://phabricator.wikimedia.org/P6876 in case
> > anyone wants to review them for potential reblocking.
> >
> > --
> > Brad Jorsch (Anomie)
> > Senior Software Engineer
> > Wikimedia Foundation
> > ___
> > 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unblocking 79 IPs blocked as open proxies 12 years ago (T189840)

[Vi to]

If you give me a list of stuffs blocked in this legacy manner I'll convert
them to regular global blocks to be handled by the usual community means.

Vito

2018-03-21 19:52 GMT+01:00 James Hare :

> I think deleting those block records is acceptable, and if they need to be
> blocked again, we can just block them again. Instituting blocks like this
> seems like an anti-pattern we should avoid.
>
>
> On March 21, 2018 at 11:50:50 AM, Brad Jorsch (Anomie) (
> bjor...@wikimedia.org) wrote:
>
> In 2005–2006 a sysadmin blocked 79 IP addresses on all wikis as being
> automatically-detected open proxies, without recording them in the block
> log or attributing the block to any user account. These incomplete records
> are now causing errors when MediaWiki tries to access them in various
> places, see https://phabricator.wikimedia.org/T189840.
>
> Since these are all over 12 years old, it seems reasonably likely that many
> of these are no longer open proxies. Rather than trying to fix the
> incomplete records, I'm just going to remove them.
>
> Any existing blocks of these IPs that are not causing errors will not be
> removed. At first glance this seems relevant mainly to enwiki, where only 5
> of the IPs have incomplete records. 21 are currently blocked there with
> complete records (19 since 2005 or earlier), and the other 53 are not
> currently blocked there.
>
> The list of IPs is at https://phabricator.wikimedia.org/P6876 in case
> anyone wants to review them for potential reblocking.
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
> ___
> 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] Persian Wikimedia cryptocurrency mining incident

[Vi to]

How many external (non WMF-sites) js do we need?

Vito

2018-03-15 0:28 GMT+01:00 John Bennett :

> *On 14 March 2018, evidence of cryptocurrency mining software was
> discovered on Persian Wikipedia. It was identified by the community and
> removed within 10 minutes of being added to the site. Additionally, the
> rights of the user responsible have been revoked and their account has been
> globally locked. At this time there is no evidence of any user's computer
> or account being compromised or otherwise affected. However, we encourage
> everyone to take some routine steps to maintain a secure computer and
> account - including regularly changing your passwords, actively running
> antivirus software on your systems, and keeping your system software up to
> date. The Wikimedia Foundation's Security team is investigating this
> incident as well as potential improvements to prevent future incidents. If
> you have any questions, please contact the Security team
> (security-team{{@}}wikimedia.org ). Apologies for
> only posting in English, translating and reposting in Fārsi would be
> greatly appreciated.Thanks,John Bennett*
> ___
> 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] FLIF for Wikimedia

[Vi to]

Changing a crucial element of the fifth most popular website on the
Internet may be a good example for an article about [[PITA]] :D

While I'm open to new formats/technologies I think a fundamental
prerequisite is a widespread support among browsers/clients. JS-only
support will severely weaken user experience for high-latency users,
destroying it for non-JS users.

Also, we currently have not enough resources to pioneer and, furthermore,
we are bound -per mission- to serve our content in the most accessible way.

Vito

2017-12-04 23:09 GMT+01:00 Brian Wolff :

> An encode latency of 7 seconds and decode latency of 1 second arent what I
> would call "very fast" (the decode latency measurement probably isnt
> realistic as decode and encode to png is different from just display in
> browser. Then again all these measurements are going to vary by filesize,
> not to mention low power devices like phones)
>
> If it indeed takes 1 second to decode, thats probably more time than the
> space savings would save time wise on a moderate speed internet connection.
>
> And time is only one metric. Often image encoding is limitted by memory.
>
>
> Anyways i'd be opposed to this unless the bandwidth saving was extreme.
> Wikipedia is not the place to be a testing ground for experimental image
> formats that browsers arent even supporting.
>
>
> --
> bawolff
>
> p.s.lossless rotatio /cropping of jpegs is actually very common due to
> rotatebot
>
> On Monday, December 4, 2017, Ruben Kelevra  wrote:
> > Hey Thiemo,
> >
> > On 04.12.2017 10:43, Thiemo Kreuz wrote:> I consider myself an image
> > file format nerd, so thanks a lot for
> >> sharing this! FLIF was new to me.Don't mind it! :)
> >
> >> I would like to share two important notes:
> >>
> >> 1. Unfortunately the flif.info website does not say a word about the
> >> CPU resources their current implementation burns when converting a,
> >> let's say, PNG to FLIF.Well, currently it's single core and not
> > optimized at all. You should know CABAC encoding from x264/x265 so it's
> > slow, but not dead slow.
> >
> > The website doesn't mention it because it highly depends on the subject
> > as well as the setting on encoding named effort.
> >
> > Currently, effort is default 60, I tried 100 a lot, but there's nearly
> > nothing to gain. So I assume we always want to use the good default. :)
> >
> > PNG Encoding of the current featured picture of today[1] at a medium
> > image size for the web, 1.280×868 Pixel, opened in Gimp, converted to
> > sRGB and exported as maximum compression without any checkbox done in
> > Gimp ... takes Gimp 3 seconds to write it to the Harddisk.
> >
> > Transcoding this PNG to FLIF takes on my machine (i3-2330M@2.20GHz; 12
> > GB RAM):
> > real 0m7,405s
> > user 0m7,320s
> > sys 0m0,053s
> >
> > decoding the file again to PNG on the same machine (with FLIF)
> > real 0m1,077s
> > user 0m1,067s
> > sys 0m0,007s
> >
> > For comparison, we save 708 KByte in comparison to PNG in this case, and
> > the PNG exported by FLIF is just 14 KByte bigger than the one created by
> > Gimp.
> >
> >> It's pretty important to realize that CPU
> >> resources are even more valuable than storage space and network
> >> bandwidth. Sure, It's not really possible to come up with an exact
> >> threshold. But if, let's say, converting a PNG to FLIF saves 100 KiB,
> >> but takes a minute, this minute will never pay off.
> > So my Point was more: Get rid of this bloody Download a JPG, do some
> > Stuff & Upload a 3 Times locally saved JPG again, calling it an
> improvement.
> >
> >> If you follow the discussions on Wikimedia Commons, you will find this
> >> argument quite often: Downloading PNGs, optimizing them, and uploading
> >> them again is practically never worth it. Think of all the resources
> >> that are burned to do this: CPU time, download and upload, database
> >> storage and time, disk storage for the new revision, and not to forget
> >> the user doing all this.
> > Yep, but enabling FLIF for new files would do nothing to the old Data at
> > all, I don't want to start a discussion about converting petabytes of
> > Data, but all new revisions should be done in FLIF, if you ask me.
> >> Sure, your suggestion avoids a lot of this. But the CPUs involved will
> >> experience heavy load, both on the server as well as clients that need
> >> to recode FLIF files via a JavaScript library first.
> > FLIF is very fast to decode via JavaScript, and in general, as the
> > example shown above, it takes just 1 second to decode and encode a
> > medium size image as PNG with just one thread on a pretty outdated
> > notebook with an unoptimized decoder and encoder. :)
> >
> > Try adding a FLIF to a website and test out if the website load anywhat
> > slower with the FLIF ... at the small image sizes you get on articles,
> > the performance impact is neglectable and comparable to loading a font
> > file to the browser.
> >> 2. Lossy file formats like JPEG should never be converted t

Re: [Wikitech-l] More Detailed Browser Stats for Desktop Sites

[Vi to]

>
>
> @Vito
> > I see a huge % of "other", what does it include?
> It is explained a couple emails back in this thread.
> Please, ping me if you can not see that, and I will paste that again.
>

Thank you! I don't know how I missed a part of the thread!

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

Re: [Wikitech-l] More Detailed Browser Stats for Desktop Sites

[Vi to]

I see a huge % of "other", what does it include?

Vito

2017-07-17 20:33 GMT+02:00 Nuria Ruiz :

> Hello:
>
>
> Please take a look at the new browser report with more detailed desktop
> site data (all wikimedia projects agreggated):
>
> https://analytics.wikimedia.org/dashboards/browsers/#
> desktop-site-by-browser
>
> Some highlights:
>
> * Data is very stable over the last year
>
> * Chrome in the lead with 45% of traffic, closely followed by IE (18%) and
> FF (13%)
>
> * The bulk of IE traffic is IE11 and IE7
>
> * Edge shows up with 4% slowly catching up to Safari (5%)
>
> * This data is still subject to fluctuations due to bot traffic not
> identified as such.  We will be working on this next year.
>
>
> Thanks,
>
> Nuria
> ___
> 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] Share your experience and feedback as a Wikimedian in this global survey

[Vi to]

There area few flaws in survey, for instance in the "most important factor
to be involved" (I'm translating back from Italian) the "other (please
specify) field doesn't allow to add text.

(Btw if that was the survey spread via a massmessage also please not 
in talkpages posts are way so problematic)

Vito

2017-01-21 16:00 GMT+01:00 Edward Galvez :

> Hello volunteer developers & technical contributors!
>
> The Wikimedia Foundation is asking for your feedback in a survey. We want
> to know how well we are supporting your contributions on and off wiki, and
> how we can change or improve things in the future.[1] The opinions you
> share will directly affect the current and future work of the Wikimedia
> Foundation. To say thank you for your time, we are giving away 20 Wikimedia
> T-shirts to randomly selected people who take the survey.[2] The survey is
> available in various languages and will take between 20 and 40 minutes.
>
> Use this link to take the survey now:
> https://wikimedia.qualtrics.com/SE/?SID=SV_6mTVlPf6O06r3mt&Aud=DEV&Src=DEV
>
>
> You can find more information about this project here[3]. This survey is
> hosted by a third-party service and governed by this privacy statement[4].
> Please visit our frequently asked questions page to find more information
> about this survey[5]. If you need additional help or have questions about
> this survey, send an email to surv...@wikimedia.org.
>
> Thank you!
> Edward Galvez
> Survey Specialist, Community Engagement
> Wikimedia Foundation
>
>
>
> [1] This survey is primarily meant to get feedback on the Wikimedia
> Foundation's current work, not long-term strategy.
>
> [2]Legal stuff: No purchase necessary. Must be the age of majority to
> participate. Sponsored by the Wikimedia Foundation located at 149 New
> Montgomery, San Francisco, CA, USA, 94105. Ends January 31, 2017. Void
> where prohibited. Click here for contest rules.
>
> [3] About this survey:
> https://meta.wikimedia.org/wiki/Community_Engagement_
> Insights/About_CE_Insights
>
> [4] Privacy statement: https://wikimediafoundation.
> org/wiki/Community_Engagement_Insights_2016_Survey_Privacy_Statement
>
> [5] FAQ:
> https://meta.wikimedia.org/wiki/Community_Engagement_
> Insights/Frequently_asked_questions
> ___
> 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] Update on WMF account compromises

[Vi to]

That's obvious, anybody knows only bag inspectors are allowed to inspect
wallets.

Coming back to be serious, imho, Wikimedia should apply the "phabricator
model" to a 2FA open source app: collaborating in development and making it
perfectly fit with our needs

Vito

2016-11-17 13:06 GMT+01:00 Dmitry Brant :

> Don't give your wallet to anyone claiming to be a Wallet Inspector.
>
> On Nov 17, 2016 4:48 AM, "Vi to"  wrote:
>
> So are you telling me that tool "test if your credit card was cloned" is a
> fraud? But its test included my ccv2 too! :p
>
> Vito
>
> 2016-11-17 9:33 GMT+01:00 Chad :
>
> > On Thu, Nov 17, 2016 at 12:18 AM Antoine Musso 
> wrote:
> >
> > > Le 16/11/2016 à 19:19, Pine W a écrit :
> > > >
> > > > (0) Consider testing your password strength with a tool like
> > > > http://www.testyourpassword.com/; be sure that the tool you use does
> > not
> > > > send your chosen password over the Internet and instead tests it
> > locally.
> > >
> > > By using an online testing tool, you are effectively breaking the very
> > > first rule:
> > >
> > >  DO NOT GIVE OUT YOUR PASSWORD.  EVER.
> > >
> > > Using that site is exactly like sharing your password with a random
> > > stranger in the world.  Even if you trusted that website, and audited
> > > the code at a given point in time, you have no guarantee the site
> hasn't
> > > changed or that it is not collecting passwords.
> > >
> > >
> > Not to mention, it's plain-old-insecure HTTP, so of course anyone and
> > their mother's uncle could be sniffing the traffic ;-)
> >
> > Same rule goes for a "generate a random password" site. Don't use
> > them.
> >
> > -Chad
> > ___
> > 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] Update on WMF account compromises

[Vi to]

So are you telling me that tool "test if your credit card was cloned" is a
fraud? But its test included my ccv2 too! :p

Vito

2016-11-17 9:33 GMT+01:00 Chad :

> On Thu, Nov 17, 2016 at 12:18 AM Antoine Musso  wrote:
>
> > Le 16/11/2016 à 19:19, Pine W a écrit :
> > >
> > > (0) Consider testing your password strength with a tool like
> > > http://www.testyourpassword.com/; be sure that the tool you use does
> not
> > > send your chosen password over the Internet and instead tests it
> locally.
> >
> > By using an online testing tool, you are effectively breaking the very
> > first rule:
> >
> >  DO NOT GIVE OUT YOUR PASSWORD.  EVER.
> >
> > Using that site is exactly like sharing your password with a random
> > stranger in the world.  Even if you trusted that website, and audited
> > the code at a given point in time, you have no guarantee the site hasn't
> > changed or that it is not collecting passwords.
> >
> >
> Not to mention, it's plain-old-insecure HTTP, so of course anyone and
> their mother's uncle could be sniffing the traffic ;-)
>
> Same rule goes for a "generate a random password" site. Don't use
> them.
>
> -Chad
> ___
> 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] Should we switch the default category collation to uca-default?

[Vi to]

Meanwhile it.wiki entusiastically joined UCA wikis.

Vito

2016-06-02 21:42 GMT+02:00 Purodha Blissenbach :

> Yes, that sounds reasonable :-)
> Purodha
>
>
> On 02.06.2016 19:24, Ryan Kaldari wrote:
>
>> OK, so it sounds like the best way forward is:
>>
>> 1. For any wikis that have specific language versions of uca collation
>> available (for example, uca-fr), but haven't yet switched to it, go ahead
>> and switch them to that collation. This should take care of a few dozen
>> wikis.
>>
>> 2. Start a discussion on Meta wiki about potentially changing the default
>> collation from uppercase to uca-default and (hopefully) find out if this
>> would cause any problems or if there are wikis that would want to opt out
>> (or if it's just a bad idea in general).
>>
>> Does that sound reasonable to everyone?
>>
>> On Sat, May 28, 2016 at 8:54 AM, Brian Wolff  wrote:
>>
>> On Friday, May 27, 2016, John Mark Vandenberg  wrote:
>>> > Yes, of course, & a meta discussion will likely unearth many reasons to
>>> > opt-out ;)
>>> >
>>> > Does uca (or extension) do the right thing for West Frisian (fy) wrt y
>>> &
>>> i ?
>>> >
>>> > Or, ... it would be helpful to put the list of 94 wiki somewhere easy
>>> to
>>> > consume.
>>>
>>> Fy is not on the list at
>>>
>>>
>>> https://ssl.icu-project.org/trac/browser/icu/trunk/source/data/coll?order=name
>>> . As a general rule any language not on that list that does something
>>> that
>>> either conflicts with english, or has something complicated (such as
>>> having
>>> letters with diacretics being considered a full letter to be sorted
>>> seperately (in the terminology of UCA having a primary weight
>>> difference) )
>>> will probably not work fully correctly with the uca collation. Of course
>>> uca-default still might be a better fallback then the current system
>>> depending on the language.
>>>
>>> --
>>> bawolff
>>> ___
>>> 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] Reducing the environmental impact of the Wikimedia movement

[Vi to]

Then the foundation should assign higher priority to projects (to fund)
which take into account environmental impact. For example a GLAM project
printing fliers would rank better if fliers are printed on recycled paper.
Same for suppliers/providers of any kind of good: the less the impact the
higher the rank.

Dealing with black skins...you know that would mean, more or less, "turning
trees into pulp to print fliers against turning trees into pulp" ^^

Vito

2016-05-24 1:40 GMT+02:00 Ricordisamoa :

> Server consumption of course but what about the impact of email, food,
> transport etc?
> Earth Hour: switch the wikis to a dark skin
>
>
> Il 30/03/2016 09:27, Lukas Mezger ha scritto:
>
>> Dear readers of the Wikitech mailing list,
>>
>> I am a member of the Wikipedia community and I have started a project to
>> reduce the environmental impact of the Wikimedia movement
>> . The main idea is
>> to
>> use renewable energy for running the Wikimedia servers and the main reason
>> for this is that by doing so, Wikipedia can set a great example for
>> environmental responsibility in the entire internet sector.
>>
>> My project was started after Greenpeace USA published a report
>>  about the
>> energy consumption of the biggest sites on the Internet in 2015 and in
>> which Wikipedia, to my astonishment, performed poorly, receiving a "D"
>> score and only passing because of the Wikimedia Foundation's openness
>> about
>> its energy consumption.
>>
>> I would very much like to change that and set up a page called
>> "Environmental
>> impact " on Meta. I
>> have already discussed the issue with a few people both from the Wikimedia
>> Foundation's management and from the Wikimedia community and have received
>> positive responses.
>>
>> In order to further advance the project, I would like to learn more about
>> how much energy Wikipedia's servers use. As far as I can tell, these
>> figures are not public, but I believe they could very well be.
>>
>> Also, I am interested to learn how changing a server site's energy sources
>> can be carried out on the operations side since the United States energy
>> sector hasn't been completely deregulated yet.
>>
>> So, thank you very much for any comments! Maybe there also is an even
>> better forum to discuss these questions?
>>
>> Finally, if you would like to support my project, please consider adding
>> your name to this list
>> .
>> Thank you.
>> Kind regards,
>>
>> Lukas Mezger / User:Gnom 
>> ___
>> 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] Audit of inline styling in the main namespace of the English Wikipedia

[Vi to]

Do you have a old dump to check whatever the ratio has increased?

Vito

2015-10-26 4:27 GMT+01:00 MZMcBride :

> K. Peachey wrote:
> >Is this direct usage of the styling, or does it include styling introduced
> >by templates as well?
>
> Just direct usage of styling, specifically anything approximately matching
> 'style="[...]"'. The script only looked at the wikitext directly used in
> pages as that's what's provided by the XML dumps.
>
> I think having styling in templates is at least a much better place for
> it, as template invocations are tracked/indexed by MediaWiki and the use
> of templates means that the styling code is a lot more centralized.
>
> MZMcBride
>
>
>
> ___
> 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] Do you run mediawiki on shared hosting? Tell us about it

[Vi to]

For small and simple wikis shared hosting is still the best option:
*it's cheap
*it's easy to mantain
*it can become pretty fast
IMHO shared hosting support shouldn't be dropped.

Vito

2015-09-26 23:14 GMT+02:00 Isarra Yos :

> On 24/09/15 17:46, Daniel Barrett wrote:
>
>> Brian Wolff writes:
>>
>>> I feel like the types of people who use shared hosting are very unlikely
>>> to be following this list.
>>>
>> I am one of those people. I happily use shared hosting for MediaWiki
>> because (1) it is very cheap and (2) I don't have to maintain the OS.
>>
>> DanB
>>
>
> I used shared hosting initially. Another thing it was very good for was
> processing power - it could actually handle intensive tasks like
> instantcommons or semantic queries fairly well. When I switched to
> dedicated initially (this was a very crappy one a few years back) I
> couldn't use instantcommons at all because it just didn't have the needed
> power.
>
> -I
>
>
> ___
> 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] Idea: Cryptographically signed wiki pages.

[Vi to]

2015-09-13 18:47 GMT+02:00 Max Semenik :

> Obligatory XKCD: https://xkcd.com/538/
>
>
Gotta draw another version with "try using 'password1' as password"

>
> >>> On Sun, Sep 13, 2015 at 5:39 AM, Purodha Blissenbach <
> >>> puro...@blissenbach.org> wrote:
> >>>
> >>> > In a discussion in the German Pirate Party the idea came up that we
> >>> might
> >>> > want to have cryptographically signed wiki pages.
> >>> > I could not find that this has been implemented already anyhow.
> >>> >
> >>> > Thus, can we develop an extsion which provides cryptographically
> signed
> >>> > wiki pages?
> >>> >
> >>> > A brief and preliminaly scetch would mean that any user who provides
> a
> >>> > matching public key could sign any existing page.
> >>> > Before a page + signature is saved, the signature is checked for
> >>> vadility.
> >>> > Editing a siged page is possible without resigning it.
> >>> > There must be a page display allowing to copy+paste the page with
> >>> > signature for external verification.
> >>> > Therre should be a button triggering the verifivation via an external
> >>> > online service.
> >>> > Maybe signature display of signed pages should be suppressable.
> >>> > Any numer of independent signatures must be possible to a page.
> >>> >
> >>> > Does that make sense? Anything vital forgotten?
> >>> >
> >>> > Feedback welcome.
> >>> >
> >>> > Greetings -- Purodha
> >>> >
>

IMHO a more legally binding solution would be attaching a signed plaintext
containing page wikicode. This was identity check could be done also
offline, without exclusively relying on site's infrastructure.

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

Re: [Wikitech-l] Code of Conduct: Intro, Principles, and Unacceptable behavior sections

[Vi to]

I cannot find any possible lost by applying those principles neither.

Vito

2015-09-06 14:49 GMT+02:00 Quim Gil :

> As I tried to explain at
> https://lists.wikimedia.org/pipermail/wikitech-l/2015-August/082778.html,
> there is a potential correlation between being opposed to a Code of Conduct
> and having a community profile needing less such Code of Conduct. This
> doesn't mean that our community doesn't need a Code of Conduct, though. We
> want to be an open and diverse community, with profiles definitely more
> diverse than the ones of the people active in this discussion.
>
> For the sake of the argument, let's say that those community members
> opposing completely to a Code of Conduct for Wikimedia tech wouldn't gain
> anything in case it is approved. Fine, but would they have anything to
> lose? Would the Wikimedia Tech community lose anything or be harmed in any
> way for the approval of a Code of Conduct? Is there anything harmful or
> counterproductive (or politically tendentious, as it has been suggested) in
> the three sections that are being proposed right now?
>
> https://www.mediawiki.org/wiki/Code_of_conduct_for_technical_spaces/Draft
> (intro paragraph / section 0 only)
>
>
> https://www.mediawiki.org/wiki/Code_of_conduct_for_technical_spaces/Draft#Principles
>
>
> https://www.mediawiki.org/wiki/Code_of_conduct_for_technical_spaces/Draft#Unacceptable_behavior
>
> Looking at these part of the current draft, it is hard for me to see how
> this could not be beneficial, or at the very least how it could be
> counterproductive, something we should avoid.
> ___
> 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] Code of conduct

[Vi to]

But as a collaborative project a decent amount of netiquette is definitely
needed.


Vito

2015-08-13 23:30 GMT+02:00 rupert THURNER :

> On Aug 13, 2015 10:16 PM, "Oliver Keyes"  wrote:
> >
> > On 13 August 2015 at 16:10, Antoine Musso  wrote:
> > > Le 07/08/2015 02:17, Matthew Flaschen a écrit :
> > >> We're in the process of developing a code of conduct for technical
> > >> spaces.  This will be binding, and apply to all Wikimedia-related
> > >> technical spaces (including but not limited to MediaWiki.org,
> > >> Phabricator, Gerrit, technical IRC channels, and Etherpad).
> > >>
> > >> Please participate at
> > >>
> https://www.mediawiki.org/wiki/Code_of_conduct_for_technical_spaces/Draft
> .
> > >>  Suggestions are welcome here or at
> > >>
>
> https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Draft
> > >> .
> > >
> > > Hello Matt,
> > >
> > > It seems the code of conduct is fairly similar to the friendly space
> > > policy. Though the later was meant for conferences, it can probably be
> > > amended to be applied to cyberspace interactions.
> > >
> > > https://wikimediafoundation.org/wiki/Friendly_space_policy
> > >
> > > Do we have any examples of unfriendly behaviour that occurred recently?
> > >
> >
> > The thread you are replying to contains both examples of unfriendly
> > behaviour in a technical context and discussion over the direct
> > applicability of the friendly spaces policy; reviewing it may be a
> > good idea.
>
> Oliver,  I must be a little blind but I do not see examples of unfriendly
> behaviour in this thread.
>
> In general,  Matt, I do experience that the wikimedia movement is
> criticized having too many rules and policies. Add another one does not
> help. At the end of the day your target group is code contributors,  not
> policy readers. If somebody does not behave and not contribute,  the person
> is easily shut up. If somebody contributes a lot, some diplomacy is
> required. What you do here is, imho, an example of an organization busy
> with itself. I won't be angry if you stop this thread and delete the wiki
> page. Let me add,  I really appreciate and find very valuable all the other
> technical contributions and discussions. And Matt, of course I appreciate
> that you know what you are talking about beeing software and Wikipedia
> content contributor.
>
> Best,
> Rupert
> ___
> 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] [Mediawiki-api] Bikeshedding a good name for "the api.php API"

[Vi to]

I support Bob or leaving it as it currently is, with time we will simply
start using "mediawiki" or "core api" more and more often.

Vito

2015-08-11 15:24 GMT+02:00 Brad Jorsch (Anomie) :

> On Mon, Aug 10, 2015 at 7:13 PM, Ricordisamoa <
> ricordisa...@openmailbox.org>
> wrote:
>
> > Since the current REST API is available under "v1", my take is "the v0
> > API" :-)
>
>
> That name sucks because it implies that the REST API is supposed to replace
> it.
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
> ___
> 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] http://dumps.wikimedia.org went off

[Vi to]

Btw some dumps seem to have hanged up.

Vito

2015-08-03 17:52 GMT+02:00 Jaime Crespo :

> It should be up now.
>
> On Mon, Aug 3, 2015 at 5:21 PM, Bináris  wrote:
>
> > About 10 minutes ago it became unrechable.
> >
> > --
> > Bináris
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> Jaime Crespo
> 
> ___
> 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] global cleanup of

[Vi to]

I still see too many pointless  in
https://it.wikipedia.org/w/index.php?title=Speciale:UltimeModifiche&tagfilter=nowiki

I'm currently cleaning up [^\']\(\s{,8})\<\/nowiki\> (more than 8
spaces means there could be something terribly wrong), using June 2th dump.
When finished I hope I'll be able to estimate whatever fixes did the trick.

Vito

2015-06-19 19:21 GMT+02:00 Daniel Barrett :

> Here is another practical example where  may be required:
> https://www.mediawiki.org/wiki/Extension:Arrays#Using_arrayprint
>
> DanB
>
> ___
> 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] global cleanup of

[Vi to]

Starting by replacing \\s\ would be safe enough imho.

Vito

2015-06-19 10:38 GMT+02:00 Amir E. Aharoni :

> Hi,
>
> In the last few days I've been looking for reasons for the appearance of
> unnecessary  tags. This mostly happens because of various
> VisualEditor and Parsoid issues. The developers have been very good at
> fixing them, and now it happens very rarely, but there are still lots of
> these useless tags lurking in pages.
>
> Two examples are:
> * '' - this doesn't do anything at all. I couldn't reproduce
> it in any way, so it's probably a bug that was fixed.
> *   in the beginning of a paragraph. This was added in the
> past to avoid putting the paragraph in , but it's entirely useless,
> because the spaces are trimmed. Now they are pre-trimmed, so this is also a
> fixed bug, but a lot of pages still have it.
>
> There may be more - I'm still looking for these.
>
> It would be easy to write bots to fix such easy common cases, but they
> would have to run on every project. Would it make sense to write them as
> maintenance scripts that update them everywhere when people upgrade VE?
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
> ___
> 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] Please help a patch not to become two years old

[Vi to]

There's a weird loophole in devs' brain which will make any dev want to
merge your patches NOW!

Vito

2015-06-08 23:44 GMT+02:00 Brian Wolff :

> On 6/8/15, Andre Klapper  wrote:
> > On Sat, 2015-06-06 at 21:40 +0200, Ricordisamoa wrote:
> >> https://gerrit.wikimedia.org/r/67588 needs love.
> >> Less than 2 days left! Thanks in advance.
> >
> > For future reference, adding basic context (e.g.: "Scribunto" here) is
> > very welcome if you would also like to reach people who normally do not
> > click links named "50 things that will make you say Oh!" or "You cannot
> > imagine what will happen at the end of this video".  :)
> >
> > Thanks,
> > andre (obviously surprise-averse)
> > --
> > Andre Klapper | Wikimedia Bugwrangler
> > http://blogs.gnome.org/aklapper/
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> You won't believe this one weird trick to get your patch reviewed in
> under 2 years.
>
> --
> bawolff
>
> ___
> 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