[Wikitech-l] Re: MediaWiki Insights - December/January double edition

[Felipe Schenone]

Amazing work and reports! It's a breath of fresh air to see so many good
things happening with MediaWiki, in contrast with the rather bleak tech
situation being discussed in wikimedia-l. Thanks for all the quality work!

On Thu, Feb 1, 2024 at 7:07 PM Birgit Müller  wrote:

> Hi All,
>
> Happy 2024 and welcome to the monthly MediaWiki Insights email!
>
> We’re starting this year with celebrating contributors who got their first
> patch merged in MW core, WMF deployed extensions or services in the
> months of December and January:
>
> A big thanks to Doğu Abaris, apasternak, Abador, Mehdi Zidani,
> Oudedutchman, Cyn, Dominic mayers, and Houseblaster for their
> contributions! Welcome :-)
>
> Enable more people to know MediaWiki and contribute effectively
>
> As shared in the previous MW insights email
> ,
> we have been thinking about ways to improve first time MediaWiki (core)
> contributors’ experience. One key part of that is knowing who is new to be
> able to say hi (and thank you). Bartosz created a script
> 
> to find new MediaWiki contributors for a given month that got their first
> patch merged (see above!). Another key part is code review for patches
> submitted by (new) volunteer contributors. We’re currently thinking about
> how we could organize code review for volunteer-submitted patches better
> across MediaWiki Engineering and want to give a shared MW-Engineering
> Gerrit dashboard a try, with primary focus on the components the group is
> responsible for.
>
> We ran a WMF-internal MediaWiki CodeJam event
>  in December,
> with 54 participants (16 from the MW team) and 21 Phabricator tickets
> completed. Areas of improvement included MediaWiki itself and multiple
> essential extensions. See the project page for details!
>
> Two notable “side projects” of the CodeJam: To support new contributors,
> Timo has created a series of tutorials
> 
> going over core MediaWiki concepts. The videos are also available on
> youtube (part I: MediaWiki core concepts
> , part II: Wikipedia’s
> extensions ).
>
> A "Quick" MW install
>  was created
> to make it possible to install MediaWiki in 3 steps and under 5 minutes.
> See this ticket for the evaluation
>  on how this worked out for
> testers during code jam. Thanks to Alex Paskulin, Timo Tijhof and Kosta
> Harlan for their work <3
>
>
> The materials as well as lessons learned from this first MW code jam will
> help us run a second edition for everyone who’s interested, possibly ahead
> of, and at the Wikimedia Hackathon
> .
>
> Project snapshot: Virtual domains, great namespaceisation, and first MW
> Engineering cross-sub-team quarterly planning
>
> We finalized the Q3 plan (= Jan-March) for MediaWiki Engineering in early
> January. This is the first time where we applied a “cross-sub-team”
> planning approach across MediaWiki Engineering & engaged as a group on
> gathering proposals and then prioritized these. A few examples for high
> priority work:
>
>
>- Evolve central login to meet requirements of a changing environment
>(“SUL3”): T348388  
>- Support upgrade of WMF production from PHP 7.4 to 8.1: T319432
>
>- Continue work to move off RESTBase
>
>- Continue work on exploring how essential workflows on the Wikimedia
>projects are currently supported through the MediaWiki software ecosystem
>(see below)
>- Prepare MW-platform team owned components
> for compatibility with the
>upcoming Temporary Accounts for Unregistered Editors
> project.
>
> We’ve already checked the box on preparing auth components
>  (OATHAuth and WebAuthn) for
> compatibility - many thanks to Piotr and Gergö for their work on this!
>
> Other highlights:
>
>
>- We’ve made progress towards supporting Less 3.13
> behavior: A series of bugs
>were fixed in Less v2.5.3 to pave the way to enable new Less.js
>capabilities to be used in the frontend.
>- The Content Transform team has moved functionality out of Parsoid
>and into Cite extension ,
>which allows both Parsoid and the default 

[Wikitech-l] Re: Comments like Google Docs

[Felipe Schenone]

Thanks everyone for all the info, pointers and comments!
@Subbu: Indeed that was the one I read about, thanks!
@Thiemo: What I'm thinking of is a *gadget*, so it would be available on
Wikimedia wikis (and any other) but only for users that choose to enable it
(similar to my gadget MiniEdit <https://www.mediawiki.org/wiki/MiniEdit>).

The gadget would allow its users to highlight some text and publish a
comment to the talk page along with the highlighted text and parent
paragraph (for context). Like so:

In ancient times, the use of solar energy was believed to have existed in
> civilizations amidst the Greeks
> <https://en.wikipedia.org/wiki/Ancient_Greece>, Romans
> <https://en.wikipedia.org/wiki/Ancient_Rome> and the Chinese
> <https://en.wikipedia.org/wiki/Ancient_China>, though not for cooking.[3]
> <https://en.wikipedia.org/wiki/Solar_cooker#cite_note-3>

Did it exist or not? The source says it did, so if no objections are
raised, I'll remove this.


Only users with the gadget enabled would be able to see the highlighted
text and comment in the article itself. The rest would only see it in the
talk page.

Because of the way I'm thinking the gadget would work, if the wikitext/HTML
of the parent paragraph changes (for example because the issue got fixed),
then the comment would stop showing in the article to users with the gadget
enabled. This is because the wikitext/HTML of the paragraph itself would
act as the anchor or identifier that would allow the gadget to know where
to insert the comment. This may be sub-optimal in some cases, but it's the
only way I can think of doing it without having the gadget insert things
into the wikitext of the article (which would be a definitive no-no). In
any case, the comments would always be available in the talk page.

To be honest though, some of your comments have made me question if this
could be useful, but I think given the way it would work, and considering
it would be an optional gadget that won't be available to random visitors,
it should be harmless, and time will tell if it ever becomes popular. I'm
working on a crude prototype and will share it shortly. Any insights, ideas
or comments are welcome!

Kind regards,

On Sun, Dec 10, 2023 at 11:28 PM Subramanya Sastry 
wrote:

> On 12/8/23 03:12, Felipe Schenone wrote:
>
> > Hi! I'm thinking on writing a gadget to add inline comments to
> > articles, similar to how Google Docs comments work.
> >
> > However, I'm sure I recently read somewhere about someone developing
> > an extension or something with the same goal, but now I can't find it
> > anywhere. Anyone knows?
>
>
> https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/Extension_for_creating_and_managing_inline_comments
> may be what you heard about?
>
> Subbu.
> ___
> 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] Comments like Google Docs

[Felipe Schenone]

Hi! I'm thinking on writing a gadget to add inline comments to articles,
similar to how Google Docs comments work.

However, I'm sure I recently read somewhere about someone developing an
extension or something with the same goal, but now I can't find it
anywhere. Anyone knows?

Thanks!
___
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: Global Lua modules and templates

[Felipe Schenone]

*. This gives the
> gadget a stable surface, greatly reduces complexity of the implementation,
> and automatically does all the right things.
>
> I really like that the gadget goes the extra mile of cleverly figuring out
> why a local template that differs from the central one. For example, does
> the local copy match one of the previous versions of the central template?
> Or was it locally forked in a new direction? It then also allows you to
> preview a diff before syncing any given wiki. This is really powerful and
> empowers people to understand their actions before doing it.
>
> To show what could happen if someone didn't use the provided mw.Api JS
> utility and naively made requests directly to the API endpoint:
> * edit() takes care of preventing unresolved *edit conflicts*. It uses
> the Edit API's `basetimestamp` parameter, so that if someone else edited
> the template between when Synchronizer fetches metadata and when the actor
> saves their edit, it will not overwrite that edit but instead fail safely.
> * edit() takes care to ensure the user *remains logged-in* so that if
> cross-wiki logins expire or become invalid for any reason, the edit won't
> be saved as an anon but fail safely.
> * edit() takes care to *not (re-)create a page* if the page in question
> was deleted in the mean time. It uses the Edit API's `createonly` and
> `nocreate` parameters.  https://www.mediawiki.org/wiki/API:Edit
>
>
> --
> Timo Tijhof,
> Principal Engineer,
> Wikimedia Foundation.
>
> On Wed, 26 Jul 2023, at 14:08, Felipe Schenone wrote:
>
> Hi! As many of you know, a central global repository for Lua modules and
> templates has been a frequent request since the early days of the movement.
>
> This year, I programmed a JavaScript tool called Synchronizer
> https://www.mediawiki.org/wiki/Synchronizer
> (inspired on a previous tool called DiBabel by User:Yurik)
> The tool allows to synchronize (that is, automatically copy) Lua modules
> across Wikimedia wikis, and provides other features to help developers
> update and maintain global modules.
>
> I also re-wrote the documentation at
> https://www.mediawiki.org/wiki/Multilingual_Templates_and_Modules to
> account for the new tool. It basically describes how to develop a Lua
> module that can be copied unchanged to any wiki, by abstracting things like
> user-readable strings and config.
>
> Admittedly, this is a "poor man's version" of a proper solution to the
> problem, but one I find invaluable while developing and maintaining
> modules. Hopefully some of you may find it useful too!
> ___
> 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: Global Lua modules and templates

[Felipe Schenone]

Hi! Thanks for taking the time to poke around and write back!

1. "Update all outdated" is designed for mass updates once a module has
been effectively "globalized". In other words, once a developer has
analyzed the situation of a particular module, went through the process of
designing the master version of a module so that it works in all wikis
(following the guide
<https://www.mediawiki.org/wiki/Multilingual_Templates_and_Modules>), and
carefully updated one-by-one all the copies to the master version, then,
whenever a new version of the master module goes live, all the other copies
can be updated in a single click (but after a confirmation message). At
least, that's what I did and currently do with the modules I developed and
maintain (Module:Excerpt and Module:Transcluder).

2. I've had a long conversation
<https://www.mediawiki.org/wiki/Talk:Synchronizer> with User:Uzume in which
we discussed this topic (and many others). Probably the best solution will
be to set a "sitelink badge" in Wikidata to set the master version of each
module. However, most modules will start out without such a badge, so a
fallback system and corresponding UI will be needed, which does take a few
hours to write. I'll do so eventually, but until some people actually start
using the tool, I see little point in continuing to throw hours into it.
It's quite sophisticated and friendly already.

3. If you hover over the terms and buttons, a tooltip will appear with an
explanation. Some modules don't have an Update button because they are
already updated to the latest version. The Analyze button appears only next
to Forked modules because it displays information only relevant to such
cases. Let me know if you can think of a better way to convey any of this.

Finally, thanks for letting me know about those sharing channels, I'll drop
a note!
Kind regards,

On Fri, Jul 28, 2023 at 8:43 PM Srishti Sethi  wrote:

> Hi! I poked around it a bit; it looks super neat! I had a few
> design-related questions while digging into this:
>
>- "Update all outdated" looks like a scary button. In which scenarios
>someone might want to edit all modules at once?
>- Is there a way to automatically populate the master version for a
>module without letting users hunt for it?
>- Why don't some modules have an analyze/update button next to them?
>Certain terminologies used on the tool page are confusing, for example,
>what unrelated means?
>
>
> As the target is Lua developers, which maybe aren't that many in
> Wikiverse, I wonder how to recruit them to use this tool and share more
> feedback. If you haven't done so already, you could consider dropping a
> note in two of these Telegram channels (Wikimedia Hackathon
> <https://t.me/wmhack>, Small wiki toolkits
> <https://t.me/+Z_b1MR8O0wAzZmVh>)  and consider sharing more about the
> tool in a synchronous format here: <
> https://meta.wikimedia.org/wiki/Grants:Knowledge_Sharing/Connect/Resources#Other_Wikiproject-related_or_technical_skills
> >.
>
>
> Cheers,
>
> Srishti
>
> On Wed, Jul 26, 2023 at 6:09 AM Felipe Schenone 
> wrote:
>
>> Hi! As many of you know, a central global repository for Lua modules and
>> templates has been a frequent request since the early days of the movement.
>>
>> This year, I programmed a JavaScript tool called Synchronizer
>> https://www.mediawiki.org/wiki/Synchronizer
>> (inspired on a previous tool called DiBabel by User:Yurik)
>> The tool allows to synchronize (that is, automatically copy) Lua modules
>> across Wikimedia wikis, and provides other features to help developers
>> update and maintain global modules.
>>
>> I also re-wrote the documentation at
>> https://www.mediawiki.org/wiki/Multilingual_Templates_and_Modules to
>> account for the new tool. It basically describes how to develop a Lua
>> module that can be copied unchanged to any wiki, by abstracting things like
>> user-readable strings and config.
>>
>> Admittedly, this is a "poor man's version" of a proper solution to the
>> problem, but one I find invaluable while developing and maintaining
>> modules. Hopefully some of you may find it useful too!
>> ___
>> 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] Global Lua modules and templates

[Felipe Schenone]

Hi! As many of you know, a central global repository for Lua modules and
templates has been a frequent request since the early days of the movement.

This year, I programmed a JavaScript tool called Synchronizer
https://www.mediawiki.org/wiki/Synchronizer
(inspired on a previous tool called DiBabel by User:Yurik)
The tool allows to synchronize (that is, automatically copy) Lua modules
across Wikimedia wikis, and provides other features to help developers
update and maintain global modules.

I also re-wrote the documentation at
https://www.mediawiki.org/wiki/Multilingual_Templates_and_Modules to
account for the new tool. It basically describes how to develop a Lua
module that can be copied unchanged to any wiki, by abstracting things like
user-readable strings and config.

Admittedly, this is a "poor man's version" of a proper solution to the
problem, but one I find invaluable while developing and maintaining
modules. Hopefully some of you may find it useful too!
___
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] CDN for Wikimedia code

[Felipe Schenone]

Brion, that's just brilliant. But wouldn't the extension need to be
installed on each Wikipedia for the module to be available?

On Fri, Apr 7, 2017 at 4:12 PM Chico Venancio <chicocvenan...@gmail.com>
wrote:

> Brian,
> No, and I always felt there was a better way to do this. I'll look into
> that, thanks,
>
> Chico Venancio
>
> 2017-04-07 15:45 GMT-03:00 Brian Wolff <bawo...@gmail.com>:
>
> > On Friday, April 7, 2017, Felipe Schenone <scheno...@gmail.com> wrote:
> > > Hi all! I'm the main developer of the ProveIt gadget
> > > <https://commons.wikimedia.org/wiki/Help:Gadget-ProveIt>, a reference
> > > manager for Wikipedia. The code is tracked via Phabricator, reviewed
> via
> > > Gerrit, and served to the various Wikipedias from Commons. Each wiki
> has
> > a
> > > unique initialization code
> > > <https://en.wikipedia.org/wiki/MediaWiki:Gadget-ProveIt.js> that sets
> > some
> > > local config and then requests the main code from Commons (JavaScript,
> > CSS
> > > and JSON). Every time I merge a new change via Gerrit, I need to
> manually
> > > update the Commons pages so that the Wikipedias have the latest code.
> > >
> > > This is sub-optimal. Ideally, the Wikipedias should request the code
> > > directly from Diffusion, so that when developers merge new changes,
> they
> > > are immediately available (and we don't need interface rights or manual
> > > work in Commons). However, when I go to the Diffusion of the gadget
> > > <https://phabricator.wikimedia.org/diffusion/1884/>, click on the main
> > > proveit.js file, and click on "View Raw File", I get to a URL like the
> > > following:
> > >
> > https://phab.wmfusercontent.org/file/data/iapd7kogqo5x2naywwlq/PHID-
> > FILE-dkxynh42aocsg5gmepxw/proveit.js
> > > The URL of the raw file changes with every click and doesn't have the
> > > proper MIME type header, so it's useless for serving the code.
> > >
> > > I think it would be very useful, for my case and others, to have a
> stable
> > > URL that serves the latest code with the proper MIME type heading. In
> > other
> > > words, a CDN, which may or may not be integrated with Diffusion.
> > >
> > > Thanks!
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> > Hmm, we should do something better for this. In the mean time, have you
> > considered packaging the javascript as a mediawiki extension that just
> adds
> > it as a module? Then the gadget could simply be a mw.loader.load(
> > moduleName ) call.
> >
> > --
> > 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] CDN for Wikimedia code

[Felipe Schenone]

Hi all! I'm the main developer of the ProveIt gadget
, a reference
manager for Wikipedia. The code is tracked via Phabricator, reviewed via
Gerrit, and served to the various Wikipedias from Commons. Each wiki has a
unique initialization code
 that sets some
local config and then requests the main code from Commons (JavaScript, CSS
and JSON). Every time I merge a new change via Gerrit, I need to manually
update the Commons pages so that the Wikipedias have the latest code.

This is sub-optimal. Ideally, the Wikipedias should request the code
directly from Diffusion, so that when developers merge new changes, they
are immediately available (and we don't need interface rights or manual
work in Commons). However, when I go to the Diffusion of the gadget
, click on the main
proveit.js file, and click on "View Raw File", I get to a URL like the
following:
https://phab.wmfusercontent.org/file/data/iapd7kogqo5x2naywwlq/PHID-FILE-dkxynh42aocsg5gmepxw/proveit.js
The URL of the raw file changes with every click and doesn't have the
proper MIME type header, so it's useless for serving the code.

I think it would be very useful, for my case and others, to have a stable
URL that serves the latest code with the proper MIME type heading. In other
words, a CDN, which may or may not be integrated with Diffusion.

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