[Wikitech-l] Production Excellence #32: May 2021

[Krinkle]

How’d we do in our strive for operational excellence last month? Read on to
find out!

Read on Phabricator at
https://phabricator.wikimedia.org/phame/post/view/236/
Incidents

Zero incidents recorded in the past month. Yay! That's only five months
after November 2020, the last month without documented incidents (Incident
stats ).

Remember to review Preventive measures
 in Phabricator,
which are action items filed after an incident.

---
Trends

In May, we unfortunately saw a repeat of the worrying pattern we saw in
April
,
but with higher numbers. We found 54 new errors. This is the most new
errors in a single month, since the Excellence monthly began three years
ago in 2018. About half of these (29 of 54) remain unresolved as of
writing, two weeks into the following month.

Figure 1, Figure 2: Unresolved error reports stacked by month.


Month-over-month plots based on spreadsheet data

.

---
New errors in May

Below is a snapshot of just the 54 new issues
 found
last month, listed by their code steward
.

Be mindful that the reporting of errors is not itself a negative point
per-se. I think it should be celebrated when teams have good telemetry,
detect their issues early, and address them within their development cycle.
It might be more worrisome when teams lack telemetry or time to find such
issues, or can't keep up with the pace at which issues are found.
Anti Harassment Tools None.
Community Tech None.
Editing Team +2, -1 Cite (T283755
); OOUI (T282176
).
Growth Team +17, -4 Add-Link (T281960
); GrowthExperiments (T281525
 T281703
 T283546
 T283638
 T283924
); Echo (T282446
); Recent-changes (T282047
 T282726
); StructuredDiscussions (T281521
 T281523
 T281782
 T281784
 T282069
 T282146
 T282599
 T282605
).
Language Team +1 Translate extension (T283828
).
Parsing Team +1 Parsoid (T281932 
).
Reading Web None.
Structured Data None.
Product Infra Team +1 WikimediaEvents (T282580
).
Analytics None.
Performance Team None.
Platform Engineering +16, -11 MediaWiki-API (T282122
); MediaWiki-General (T282173
); MediaWiki-Page-derived-data (
T281714  T281802
 T282180
 T283282
), MediaWiki-Revision-backend (
T282145  T282723
 T282825
 T283170
); MediaWiki-User-management (
T283167 ); MW Expedition (T281526
 T281981
 T282038
 T282181
 T283196
).
Search Platform +3, -2 CirrusSearch (T282036
 T282207
); GeoData (T282735
).
WMDE TechWish +2, -1 Revision-Slider (T282067
); VisualEditor Template dialog (
T283511 ).
WMDE Wikidata +3, -1 Wikibase (T282534
 T283198
 T283862
<

[Wikitech-l] Code style poll: return typehint spacing

[Gergő Tisza]

There's an ongoing discussion about how PHP return typehints should be
formatted in MediaWiki code:

function foo(): int {

or

function foo() : int {

If you are interested, please vote here:
https://phabricator.wikimedia.org/T220719

(The permission system for votes is somewhat inflexible. If you want to
vote but can't, please leave a comment.)
___
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: Feature idea: data structure to improve translation capabilities

[Wolter HV]

[2021-06-20 17:39 +0100] Wolter HV:
> You can find the script attached.  To experiment with this, simply run
>
> .read feature_showcase.sql
>
> within an interactive sqlite3 session.  (There may be other ways of doing it 
> but this is how I tested it.)

I found out, unsurprisingly, that my attachment didn't make it into the mailing
list :D

Here is a pastebin link with the aforementioned sqlite3 SQL script:

https://paste.gnome.org/pca7e7y0v

Regards,
Wolter HV
___
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: Need Help for MediaWiki Skin Development

[Nasir Khan]

Thanks for your reply Bartosz.

I can see that the PHP based skins are working now (Mediawiki 1.35.*) but
the same skin does not work on Mediawiki 1.36+.
I mentioned in my previous email that I built a skin long ago and  Jon
Robson helped to upgrade that afterwards.

My concern is that Mediawiki is moving towards Mustache and old skin docs
are marked as outdated. But I found only one single page doc about this new
system. Though you are saying those are valid.
The core team who are working on this skin section can create the
equivalent amount of docs which are available for PHP based skins. I can
help to write the docs as well but as I am not building the system I have a
number of queries regarding this. If I get the answers then I can create
the related docs.

Is there anyone who can help me to improve the skin docs of MediaWiki and I
will get the help to build the skin from that.

--
*Nasir Khan Saikat*
www.nasirkhn.com



On Sun, 20 Jun 2021 at 21:01, Bartosz Dziewoński 
wrote:

> I can't help much with Mustache, but I'll note that all of the older
> documentation is still valid. Skins that do not use Mustache templates
> are still supported.
>
> --
> Bartosz Dziewoński
> ___
> 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: Feature idea: data structure to improve translation capabilities

[John]

Off hand isn’t this something that wikidata was setup to handle?

On Sun, Jun 20, 2021 at 12:40 PM Wolter HV  wrote:

> Hello,
>
> I have been thinking of a way to organise data in Wiktionary that would
> allow
> for words to automatically show translations to other languages with much
> less
> work than is currently required.
>
> Currently, translations to other languages have to be added manually,
> meaning
> they are not automatically propagated across language pairs.  What I mean
> by
> this is showcased in the following example:
>
>  1. I create a page for word X in language A.
>  2. I create a page for word Y in language B.
>  3. I add a translation to the page for word X, and state that it
> translates to
> word Y in language B.
>  4. If I want the page for word Y to show that it translates to word X in
> language A, I have to do this manually.
>
> Automating this seems a bit tricky.  I think that the key is acknowledging
> that
> meanings can be separated from language and used as the links of
> translation.
> In this view, words and their definitions are language-specific, but
> meanings
> are language-agnostic.
>
> Because I may have done a bad job at explaining this context, I have
> created a
> short example in the form of an sqlite3 SQL script that creates a small
> dictionary database with two meanings for the word "desert"; one of the
> meanings has been linked to the corresponding words in Spanish and in
> German.
> The script mainly showcases how words can be linked across languages with
> minimal rework.
>
> You can find the script attached.  To experiment with this, simply run
>
> .read feature_showcase.sql
>
> within an interactive sqlite3 session.  (There may be other ways of doing
> it
> but this is how I tested it.)
>
> I believe this system can also be used to automate other word relations
> such as
> hyponyms and hypernyms, meronyms and holonyms, and others.  It can also
> allow
> looking up words in other languages and getting definitions in the
> language of
> choice.  In short, it would allow Wiktionary to more effortlessly function
> as
> a universal dictionary.
>
> Has something like this been suggested before?  I would be pleased to
> receive
> feedback on this idea.
>
> With kind regards,
> Wolter HV
> ___
> 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] Feature idea: data structure to improve translation capabilities

[Wolter HV]

Hello,

I have been thinking of a way to organise data in Wiktionary that would allow
for words to automatically show translations to other languages with much less
work than is currently required.

Currently, translations to other languages have to be added manually, meaning
they are not automatically propagated across language pairs.  What I mean by
this is showcased in the following example:

 1. I create a page for word X in language A.
 2. I create a page for word Y in language B.
 3. I add a translation to the page for word X, and state that it translates to
word Y in language B.
 4. If I want the page for word Y to show that it translates to word X in
language A, I have to do this manually.

Automating this seems a bit tricky.  I think that the key is acknowledging that
meanings can be separated from language and used as the links of translation.
In this view, words and their definitions are language-specific, but meanings
are language-agnostic.

Because I may have done a bad job at explaining this context, I have created a
short example in the form of an sqlite3 SQL script that creates a small
dictionary database with two meanings for the word "desert"; one of the
meanings has been linked to the corresponding words in Spanish and in German.
The script mainly showcases how words can be linked across languages with
minimal rework.

You can find the script attached.  To experiment with this, simply run

.read feature_showcase.sql

within an interactive sqlite3 session.  (There may be other ways of doing it 
but this is how I tested it.)

I believe this system can also be used to automate other word relations such as
hyponyms and hypernyms, meronyms and holonyms, and others.  It can also allow
looking up words in other languages and getting definitions in the language of
choice.  In short, it would allow Wiktionary to more effortlessly function as
a universal dictionary.

Has something like this been suggested before?  I would be pleased to receive
feedback on this idea.

With kind regards,
Wolter HV
___
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] Extending the SelectQueryBuilder

[Ostrzyciel]

Hi,

The SelectQueryBuilder class was introduced a year ago 
 
and it's seen some adoption, mostly in core. I've also noticed that 
there are two classes that extend it in core, the PageSelectQueryBuilder 
and UserSelectQueryBuilder. I really like how this approach allows for 
better separation of DB code from the rest, which has always been a 
complete and utter mess in MW. I would like to do something similar in 
an extension, but the base class is currently not explicitly marked as 
stable to extend and thus, according to the stable interface policy 
, 
the interface could be broken at any time. My question is – are there 
any plans to make the class stable to extend? Is there a rough roadmap 
for its development? If the class is unstable to extend for some reason 
– what are the expected changes to come?


Thanks!

--

Ostrzyciel

___
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: Need Help for MediaWiki Skin Development

[Bartosz Dziewoński]

I can't help much with Mustache, but I'll note that all of the older 
documentation is still valid. Skins that do not use Mustache templates 
are still supported.


--
Bartosz Dziewoński
___
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/