Where would I put a request to support delivery of translations on a page basis, rather than "just" on a wiki one?
As in:
the system understands that if it's targeting fr.wiki*, it needs to use the French version of the text.
What I want is that it understands that if I am targeting a page like "Commons:Village pump/fr", then it also uses French there, even though the wiki itself is English by default.

FWIW, I'm aware I could "just" mass message French wikis separately and include that page among those targets, but we're aiming at reducing the complexity here.

@Elitre - We're using the target page language to determine the language in which to deliver the message. Please see the documentation here - https://www.mediawiki.org/w/index.php?title=Help:Extension:MassMessage#Sending_a_translated_page_as_message

In case of https://commons.wikimedia.org/w/index.php?title=Commons:Bistro&action=info, the page content language is French, so the "page sent as message" will be delivered in French, if available, else in fallback languages, if available, finally falling back to the source language of the page. Same will be the case for pages under fr.wiki*

Right. I'm sure Johan had explained this to me already. Will look more into it, TYVM.

In T254481#6303436, @abi_ wrote:

@Elitre - We're using the target page language to determine the language in which to deliver the message. Please see the documentation here - https://www.mediawiki.org/w/index.php?title=Help:Extension:MassMessage#Sending_a_translated_page_as_message

That documentation mentions that Extension:Translate needs to be present on the target wiki. As Tech News is distributed to many monolingual wikis in addition to multilingual ones, most of its target pages don’t have Translate installed, but they should get translated versions as well. The distribution module takes care of monolingual wikis well; now I tweaked it to work on multilingual wikis, too.

The Translate extension need not be installed on the wiki where the target page is present.

In T254481#6326691, @Nikerabbit wrote:

The Translate extension need not be installed on the wiki where the target page is present.

Sorry, looks like I can’t read… That said, the delivery currently doesn’t happen with this mode AFAIK, so the module change still makes sense.

It just came up that MassMessage can’t substitute templates. Supporting substitution is a new requirement, so it’s not needed in the first iteration, but it would be necessary in the (preferably near) future to support translating the newsletter efficiently (avoid translating the same sentences again and again).

@Tacsipacsi If it is important, it should be filed as a separate task. Based on feedback we will decide if it fits under the work under this epic task or not.

In T254481#6710855, @Tacsipacsi wrote:

It just came up that MassMessage can’t substitute templates. Supporting substitution is a new requirement, so it’s not needed in the first iteration, but it would be necessary in the (preferably near) future to support translating the newsletter efficiently (avoid translating the same sentences again and again).

Where is the template that gets substituted? If in a MassMessage message a template is used, the template that inserted is one from that local wiki where the message gets posted. In the various wikis there is not a single template that is the same with exact functionality on every wiki. (In the past this caused caused several issues!)

Also outsiders from the local community that create local templates without knowing the local policies and customs, is also not appropriate.

In T254481#6747837, @Romaine wrote:

Where is the template that gets substituted?

Of course I’d like to have the substitution happen on Meta, exactly to avoid the issues you mention.

I used this today! It was glorious! Less work for me (no need to manually make sure I've added all languages) and this week the Portuguese translation (pt-br) was actually delivered, after languishing on Meta for years.

I'll need to evaluate it a bit more, but the one thing that comes to my mind is that when using the "Body of the message" box for the timestamp and sending as a page, there's a line (----) between the part sent by page and the timestamp, which means that the timestamp doesn't really look like it belongs to the rest of the message.

I don't remember if we had any specific reason for having the line other than trying to separate page contents from message contents. Do you think we should let senders decide if that is needed?

Yes, or just remove it.

The code currently is $pageContent . "\n\n----\n\n" . $message. I'm thinking I'm leaving just \n\n so that the message starts on its own line in the rendered text. Otherwise you would have to manually add empty lines in beginning of the message. This does mean that if you want, for example, to have the signature on the same line as page content, you cannot do it. But I guess this is less of an issue that accidentally having them on the same line.

Change 666364 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/MassMessage@master] Remove mandatory line separator between page content and message

https://gerrit.wikimedia.org/r/666364

Change 666364 merged by jenkins-bot:
[mediawiki/extensions/MassMessage@master] Remove mandatory line separator between page content and message

https://gerrit.wikimedia.org/r/666364

@Nikerabbit Sounds like a good plan.

Sorry, I don't know if it's relevant to this task but last Tech News were delivered without section tags. Was it just an oversight or is it one of the things left to do?

In T254481#6865334, @Sakretsu wrote:

Sorry, I don't know if it's relevant to this task but last Tech News were delivered without section tags. Was it just an oversight or is it one of the things left to do?

Is it somehow causing a problem somewhere? I believe those <section> tags were just for splitting up the various translations, and only used by the delivery-software. For reference (examples always help!) here are diffs for the last 2 deliveries:

• Tech News: 2021-07
• Tech News: 2021-08

Oh... I see that it also no longer includes the <div class="plainlinks mw-content-ltr" lang="en" dir="ltr"> with the English version... I imagine that might cause problems in untranslated versions on RTL wikis?
Yes, that is a problem...

• Tech News: 2021-07 on Fawiki (in English)
• Tech News: 2021-08 on Fawiki (in English) - is now mis-aligned to the right.

Is that the specific problem you noticed, or is there anything else?

Section tags allow selective transclusion of text. For instance, enwiki community portal automatically transcludes the latest Tech News from https://en.wikipedia.org/wiki/Wikipedia:Tech_news.

I've not had time to properly dig into why, but delivering using "Page to be sent as a message" didn't work today. Tried three times; no delivery. Using body as message, the newsletter was delivered immediately.

These attempts were made using "Page to be sent as a message":

https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=40608085
https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=40607807
https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=40607957

Uh thanks for the report and sorry about inconvenience. Looking at Logstash the error is: Argument 1 passed to MediaWiki\MassMessage\LanguageAwareText::__construct() must be of the type string, null given.

from /srv/mediawiki/php-1.36.0-wmf.35/extensions/MassMessage/includes/LanguageAwareText.php(18)
#0 /srv/mediawiki/php-1.36.0-wmf.35/extensions/MassMessage/includes/MassMessage.php(384): MediaWiki\MassMessage\LanguageAwareText->__construct(NULL, NULL, NULL)
#1 /srv/mediawiki/php-1.36.0-wmf.35/extensions/MassMessage/includes/MassMessage.php(461): MediaWiki\MassMessage\MassMessage::getRemoteContent(Title, string)
#2 /srv/mediawiki/php-1.36.0-wmf.35/extensions/MassMessage/includes/MassMessage.php(420): MediaWiki\MassMessage\MassMessage::getContent(string, string, string)
#3 /srv/mediawiki/php-1.36.0-wmf.35/extensions/MassMessage/includes/Job/MassMessageJob.php(324): MediaWiki\MassMessage\MassMessage::getContentWithFallback(string, string, string, string, string)
#4 /srv/mediawiki/php-1.36.0-wmf.35/extensions/MassMessage/includes/Job/MassMessageJob.php(230): MediaWiki\MassMessage\Job\MassMessageJob->makeText(boolean)
#5 /srv/mediawiki/php-1.36.0-wmf.35/extensions/MassMessage/includes/Job/MassMessageJob.php(69): MediaWiki\MassMessage\Job\MassMessageJob->sendMessage()
#6 /srv/mediawiki/php-1.36.0-wmf.35/extensions/EventBus/includes/JobExecutor.php(79): MediaWiki\MassMessage\Job\MassMessageJob->run()
#7 /srv/mediawiki/rpc/RunSingleJob.php(76): MediaWiki\Extension\EventBus\JobExecutor->execute(array)
#8 {main}

The code in question is:

		$content = new LanguageAwareText(
			$pageInfo['revisions'][0]['slots']['main']['*'],
			$pageInfo['pagelanguage'],
			$pageInfo['pagelanguagedir']
		);

Example response: https://meta.wikimedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=info%7Crevisions&titles=Tech%2FNews%2F2021%2F12&rvprop=content&rvslots=main

The code is failing to strip one level of the response, so it doesn't see the correct properties.

I'll submit a fix tomorrow and see if we can backport that this week.

Fix is backported.

@Sakretsu The section tags were re-introduced and the new method of delivery was used again this week, please let us know if there's anything related to them that doesn't work.

Still not working since Tech news sections are now marked by the new static name "tech-newsletter-content". It would be great if it was the same as before, e.g. "technews-2021-W12".

In T254481#6954394, @Sakretsu wrote:

Still not working since Tech news sections are now marked by the new static name "tech-newsletter-content". It would be great if it was the same as before, e.g. "technews-2021-W12".

The name of the section should be customizable. The section name used here: https://meta.wikimedia.org/wiki/Tech/News/2021/13?veaction=editsource can be updated to follow the technews-2021-{week} structure.