[Wikitech-ambassadors] Re: Data center switch to happen on March 1

[Tisza Gergő]

On Wed, Feb 15, 2023 at 9:34 AM Benoît Evellin (Trizek) <
bevel...@wikimedia.org> wrote:

> A quick message to inform you of one change in the translation. One
> sentence was changed to avoid future translation work.
>
> Direct link:
> https://meta.wikimedia.org/w/index.php?title=Special:Translate=page-Tech%2FServer+switch=page=fuzzy=
>

FWIW, some languages will need future translation work anyway (because
fully autogenerated dates would only be possible in a very inelegant way,
at least with the current level of support in MediaWiki), so a heads-up to
translators when the message is going to be reused would be appreciated.
___
Wikitech-ambassadors mailing list -- wikitech-ambassadors@lists.wikimedia.org
To unsubscribe send an email to wikitech-ambassadors-le...@lists.wikimedia.org

[Wikitech-ambassadors] Re: Server switch, June 29

[Tisza Gergő]

Hi Szymon, thanks for preparing the message!

https://meta.wikimedia.org/wiki/Translations:Tech/Server_switch_2020/11/en
should be updated to use CEST instead of CET (not sure about the other
zones). Also it should say Wednesday June 30, not 29.
https://meta.wikimedia.org/wiki/Translations:Tech/Server_switch_2020/11/qqq
should be updated.

On Fri, Jun 18, 2021 at 8:04 AM Szymon Grabarczuk 
wrote:

> Hello,
>
> On June 29, all traffic from all wikis will be switched to the secondary
> data center (like we did in 2020). *All wikis will be in read-only mode on
> June 29 around 14:00 UTC*. A message to inform our communities has been
> written, to be sent to wikis:
> https://meta.wikimedia.org/wiki/Tech/Server_switch_2020
>
> Please don't bother with the page title. We may move the page to
> [[m:Tech/Serwer switch]] and if we do, we'll leave a redirect so the link
> above will be working.
>
> As for the content of the message, we have kept the previous messages, and
> made small changes. Please review all messages.
>
> More information will be published in Tech News and will also be posted on
> individual wikis.
>
> Please inform your communities about this event!
>
> Thank you for your help,
>
> Szymon Grabarczuk (he/him)
>
> Community Relations Specialist
>
> Wikimedia Foundation
> ___
> Wikitech-ambassadors mailing list --
> wikitech-ambassadors@lists.wikimedia.org
> To unsubscribe send an email to
> wikitech-ambassadors-le...@lists.wikimedia.org
>
___
Wikitech-ambassadors mailing list -- wikitech-ambassadors@lists.wikimedia.org
To unsubscribe send an email to wikitech-ambassadors-le...@lists.wikimedia.org

Re: [Wikitech-ambassadors] Is MassMessage ever used for delivering identical content to the same page multiple times?

[Tisza Gergő]

On Fri, Sep 13, 2019 at 9:07 PM Nick Wilson (Quiddity) <
nwil...@wikimedia.org> wrote:

> I.e. It would make it impossible to send *exactly the same message* to
> the *same page* regardless of timing.
>

I doubt the job queue would somehow deduplicate current jobs with already
finished ones, so probably it would make it impossible to send the same
message to to the same page twice in parallel.
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] New PDF Render decommissioned on 1st January 2020?

[Tisza Gergő]

On Sun, Mar 17, 2019 at 1:40 PM Alex Monk  wrote:

> I could be misremembering but wasn't that the thing that nobody knew how
> to reproduce the setup of and was one of the last things left in pmtpa?
>

Yeah, and also on Ubuntu Hardy (which was EOL for over a year by then).
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] New PDF Render decommissioned on 1st January 2020?

[Tisza Gergő]

On Sun, Mar 17, 2019 at 12:50 PM Dirk Hünniger 
wrote:

> A Chromium based solution is certainly one
> of the best you can get. Its cheap in computational resources and
> updates should be available for a long time.


I think computationally it's actually more expensive (OCG transformed the
wikitext syntax tree into TeX, while Chromium does full HTML layouting).
That's one of the reasons PDF rendering for collections is not avaible
anymore; Chromium would just crash when trying to render a thousand-page
book.

On the other hand, Chromium-rendered PDF will actually look the way it
looks in the browser, without any maintenance effort needed (other than
occasional tweaks to the print CSS), while with non-browser-based tools
every template, extension and wikitext feature that had a visual component
required dedicated handling, and common layout concepts like tables or
multiple columns were extremely hard to get right.


> I just figured out from the following link
> that the new renderer was based on mwlib and reportlab.


Neither of those are mentioned on the page though.

I think the WMF ran its own mwlib service a long time ago (2013-ish?) but
it didn't work well and was replaced by OCG (which eventually proved
unmaintainable due to the above issues and lack of resourcing).
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] New PDF Render decommissioned on 1st January 2020?

[Tisza Gergő]

There are two different PDF renderer tools: the single page PDF renderer
("Download as PDF" link in the sidebar, via the ElectronPdfService
extension [1]) and the article collection renderer ("Create a book" link,
via the Collection extension [2]).

The single page renderer is today served by a tool called Electron [3];
it's in the process of being replaced by a new tool called Proton [4].
These are both node.js services which manage headless Chromium instances -
which means the actual rendering engine will stay the same, so no
user-facing changes are expected. The switch is for operational reasons:
Electron crashes periodically, and has been written before the Chromium
project provided an official library for remote-controlling headless
browsers, so it didn't take advantage of that. Proton is currently getting
mirrored traffic (ie. it is deployed in production for testing purposes,
and both it and Electron render the PDF files requested by users, but only
the one from Electron is returned).
The collection renderer used to be served by a tool called OCG [5], which
has been decommissioned about a year ago. It also functions as a frontend
to PediaPress [6], who create print-on-demand books of Wikipedia content.
They use mwlib internally (and are the main developers of it). I believe
they plan to provide PDF download functionality eventually.

So in short, the WMF is not involved with mwlib development, you should
probably contact PediaPress (see [7]) if you have questions about that. The
PDF renderer project at the WMF is not related to mwlib and not affected by
the Python 2 life cycle.


[1] https://www.mediawiki.org/wiki/Extension:ElectronPdfService
[2] https://www.mediawiki.org/wiki/Extension:Collection
[3] https://www.mediawiki.org/wiki/Electron
[4] https://www.mediawiki.org/wiki/Proton
[5] https://www.mediawiki.org/wiki/Offline_content_generator
[6]
https://meta.wikimedia.org/wiki/Book_tool/Help/Books/Frequently_Asked_Questions#What_is_PediaPress?
[7] https://pediapress.com/code/
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] Removal of unblockself rights on wiki

[Tisza Gergő]

On Sun, Dec 16, 2018 at 7:51 AM stjn  wrote:

> I was endorsing the whole sentiment, not exactly the topic it belongs to.
> But even then, self-unblocking was a default option, so it could’ve been
> discussed what must be done with it.
>

You can still go to the Phabricator task and do that. (It was linked before
but for convenience it is https://phabricator.wikimedia.org/T150826 .) The
patch was about five lines, it's not hard to rewrite if someone has a
better idea of what to do.
What's frustrating to me in these kinds of threads is that people are very
eager to discuss how the discussion should have happened, but don't seem
very interested in the discussion itself.
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] Removal of unblockself rights on wiki

[Tisza Gergő]

On Sat, Dec 15, 2018 at 7:47 AM stjn  wrote:

> The approach to major changes (not talking about some design fix) should
> involve community and be entirely international
>
You *are* talking about some design fix. When blocking was added as a
feature, it was only integrated with some actions - it was checked during
editing, but not during unblocking. That was an oversight that has started
causing problems now so it's being fixed.
Even our largest wikis only see about ten self-unblocks a year, most of
which are unblocks of self-blocks (which are not affected by the change).
By no sane definition is this a major change. Had it not been announced
here, no one would even have noticed it.
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] Mass message delivery error code: readonly

[Tisza Gergő]

See https://phabricator.wikimedia.org/T139380

On Thu, Oct 4, 2018, 10:52 Deryck Chan  wrote:

> Hello ambassadors,
>
> Can someone explain this error message to me?
>
> 2018年10月4號 (四) 12:03 Delivery of "Reminder: No editing for up to an hour
> on 10 October" to Wikipedia:城市論壇 (技術)
> 
> failed with an error code of readonly
>
> -- Deryck
> ___
> Wikitech-ambassadors mailing list
> Wikitech-ambassadors@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
>
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] Grievances about future technical administrator group

[Tisza Gergő]

Hi Oleg,

I am sorry if the change or the way I communicated about it is frustrating
to you . I'm happy to provide more insight into the motivation behind the
change, if that helps.

On Tue, Jul 24, 2018 at 12:41 AM Saint Johann  wrote:

> — Some tell that, apparently, after working for 2 years already and
> doing more edits than all sysops combined in JS/CSS, engineers do not
> have ‘at least as much trust as being an administrator’ since they
> weren’t elected like administrators (we are electing sysops with a vote
> and engineers are being elected with a discussion, so people argue that
> engineers do not have trust because they weren’t subjected to a vote).
>

I think someone who had those rights for a while and did not abuse them can
be reasonably trusted with them (which is why I suggested simple opt-in as
the migration process).
>From what I could understood with Google Translate, this seems to be the
current community consensus as well.

— Others claim that, because MediaWiki developer community decided to
> unite those rights under one group, merging any groups with it is not
> acceptable, and, moreover, the engineer group shouldn't be given those
> rights at all.
>

One goal with the change was to reduce the number of people with JS editing
permissions as much as possible without preventing them from doing their
work. If a group is primarily about JS editing, it might makes sense to
merge (that might be the case with interface-editor on some wikis, although
not all). If a group has a wider range of roles, then merging would mean
giving the permission to people who might not be interested in JS editing,
and avoiding that situation was the entire point. I 'm not  sure which of
those applies to engineers - at a glance, out of the 12 of them 4 have
never edited CSS/JS and one almost never [1], so probably it makes sense to
separate interface-admins from engineers?

— Moreover, some people claim that if a group would be too small, like
> engineers right now (12 accounts with 85 sysops), they could, in opinion
> of those people, usurp all editing of JS/CSS, decline to revert edits
> that are deemed controversial by community, and this justifies giving
> the permissions to all 85 existing sysops, even those that didn’t edit
> JS/CSS at all.
>

Again, as far as I can understand the discussion this was a fringe opinion
and the current consensus proposal requires admins to opt in.

I really think that it all comes down to focusing on
> projects that didn’t have any technical administrators and not
> explaining anything to projects that did.
>

For projects which do have some kind of non-admin JS editor role (engineer,
interface-editor, templateeditor, botadmin) there were two "social" goals:
- Warn them against handing out JS editor too easily. With the current
structure, that does happen sometimes, and can you get things like the
fawiki incident. JS editing should only be given to people who can be
trusted not to abuse their privileges to attack the site.
- Do not completely discourage people from handing it out to non-admins.
Trust is important, but it's a somewhat different kind of trust (admins
need to be socially competent, level-headed, fair etc; JS editors don't
really need to be all those things, they just need to not be malicious) and
there are people who can absolutely be trusted not to be malicious, but
don't have the social skills or the good judgement to be admins (or just
don't want be one), and there is no reason to prevent them from doing good
work on JS pages.

[1] https://quarry.wmflabs.org/query/28510

Hope that helps!
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] Code Review for new language converter?

[Tisza Gergő]

On Fri, Nov 17, 2017 at 1:05 PM, Trey Jones  wrote:

>
> Since there was some discussion about changes to language converters here
> a few days ago, I was hoping someone here could help me figure out who to
> ask, or what to do to get code review from someone who is familiar with
> language converters and has +2 rights on mediawiki/core.
>

Per the maintainer page [1], Parsing team or Liangent or SPQRobin.

[1] https://www.mediawiki.org/wiki/Developers/Maintainers
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] Possible changes needed to MediaWiki:Citethispage-content

[Tisza Gergő]

If a B/C break is needed anyway, wouldn't this be a good chance to kill
that weird special behavior and just use {{#time:..format...}} for the
current date and {{#time:...format|{{REVISIONTIMESTAMP for the last
revision's date like on all normal pages? Undiscoverable easter eggs like
this do not make wiki administration any easier.

On Thu, Sep 22, 2016 at 11:34 PM, Legoktm 
wrote:

> Hi,
>
> If your wiki has modified the "Citethispage-content" message, it may
> need some small modifications  to continue working properly.
>
> Background: The CiteThisPage special page shows different citations for
> wiki articles. It mentions two different times: the first being the time
> the specific revision of the article was edited, and the second being
> the current time.
>
> Special:CiteThisPage modified the parser so that any of the {{CURRENT*}}
> time magic words would use the revision timestamp, and anything wrapped
> inside of a special ... tag would use the current
> timestamp. However there was a bug in this implementation where the
> {{#time:...}} parserfunction would always use the current timestamp,
> even if it was outside the  tags.
>
> That bug has now been fixed[1], and will be deployed to all wikis
> starting on October 4th. To retain existing behavior, simply wrap any
> {{#time:..}} in  tags. I know this might be a little
> confusing, so please let me know if this isn't clear.
>
> [1] https://gerrit.wikimedia.org/r/#/c/311627/
>
> Thanks,
> -- Legoktm
>
> ___
> Wikitech-ambassadors mailing list
> Wikitech-ambassadors@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
>
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] AuthManager getting enabled in production

[Tisza Gergő]

On Thu, Jun 16, 2016 at 8:59 AM, Federico Leva (Nemo) 
wrote:

> You should probably work a bit on translations (and on getting them
> backported to 1.27): for instance, there are currently only 17 translations
> for the/a message one receives after entering an incorrect password.
>
> https://translatewiki.net/wiki/Special:Translations/MediaWiki:Authmanager-authn-no-primary/en


After entering an incorrect password you get wrongpassword

which
has been around for a while. You typically get the no-primary message when
not entering any password.

These are the new messages that you are likely to encounter:

authmanager-authn-no-primary
authmanager-authn-not-in-progress
authpage-cannot-login-continue
authpage-cannot-create-continue
changecredentials
changecredentials-submit
credentialsform-provider
credentialsform-account
authprovider-resetpass-skip-label
resetpass-validity-soft (not new but needs update)
authmanager-authn-autocreate-failed
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-ambassadors] Urgent problem on the Beta Wikiversity

[Tisza Gergő]

On Sun, Jun 22, 2014 at 7:21 PM, R W romaine.w...@gmail.com wrote:

 I am not sure if this is appropriate here, but I do not know where to ask
 otherwise...

 On Beta Wikiversity someone is active now who uses the project as his
 personal notepad/sandbox. The pages created in Dutch are short Wikipedia
 articles, copy of a message of the yearplan of WMNL, texts of Wikisource,
 Wikinews articles, and for every person he contacted he creates a page. In
 his communication towards those people he presents himself as Wikiversity
 and says such in these pages. All these pages do not contain educational
 content.

 Another major issue is that private information is added to these pages,
 privacy violation for no reason.

 Another issue is the adding of copyrighted material

 Because of there is no Dutch community there, nobody takes action. At the
 moment the Dutch chapter is working on setting up an education program, but
 the current material would discredit the attempt and we do not consider it
 realistic to start up this project at Beta Wikiversity.

 How to act?


If you need admin action on a wiki which has no admins, ask the stewards:
https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous

If you just want advice then some non-technical forum like wikimedia-l
might be more helpful.
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors