l10n: Align notification messages for server version and apps

[rakekniven]

Actually the wording server and app updates is different.

Target is to unify this two messages.

Notification for server update looks like:

server/apps/updatenotification/lib/Notification/Notifier.php

Line 131 in 04f6862

$notification->setParsedSubject($l->t('Update to %1$s is available.', [$parameters['version']]));

Notification for an app update looks like:

server/apps/updatenotification/lib/Notification/Notifier.php

Line 145 in 04f6862

->setRichSubject($l->t('Update for {app} to version %s is available.', [$notification->getObjectId()]), [

First improvement for server is a change to:
Update to version %1$s is available.

Second improvement for server is adding product name:
Update for Nextcloud to version %1$s is available.

[rakekniven]

My PR to this issue had been hijacked by another improvement. This issue is still open.

[rakekniven]

@nickvergessen does not want to split productname and server version into two variables. As long as this is the case there is no way to align the update notification messages.

[nickvergessen]

Closing as not planned as per discussion in #35769

[rakekniven]

This time I am really sad. There was no discussion, just a statement and this is an example that the Nextcloud company and the community are not on the same level when it comes to decisions.
I can't provide code ok, but to justify this with non-existent discussion is bad.
This issue is not a bug report or a great improvement, but one of several examples where supporters have no voice.

Unknown to me, my screenshot is now gone ...

[nickvergessen]

Unknown to me, my screenshot is now gone ...

It's in the review which is "resolved" which automatically folds it away:
#35769 (review)

There was no discussion

Sorry for the poor choice of wording then: s/discussion/comment thread
The data string comes from a remote server, it could be Nextcloud followed by a version number, it could be something else, so splitting it is not a good idea.

I even tried to outline that using the same wording is not a good idea, because they have different impact levels for admins in terms of the effort they may need to invest.

This issue is not a bug report or a great improvement, but one of several examples where supporters have no voice.

I made a suggestion after some comments and you commented on the proposed approach "Your suggestion will solve this partly."
So I thought it's done. There was never any intention to outweigh a supporters voice here!

[nickvergessen]

Background / information

Because I didn't want to make you sad, I went to check it again:

• https://github.com/nextcloud/updater_server/blob/946ae1b79fd78d8cf8ce8063caccdd7dc4f09844/src/Response.php#L120 Nextcloud X.Y.Z
• https://github.com/nextcloud/updater_server/blob/946ae1b79fd78d8cf8ce8063caccdd7dc4f09844/src/Response.php#L151 Nextcloud daily

But I just remembered that daily could be special and indeed the notifications are skipped in that case:

server/apps/updatenotification/lib/Notification/BackgroundJob.php

Lines 102 to 105 in a0f6a65

	if (\in_array($this->getChannel(), ['daily', 'git'], true)) {
	// "These aren't the update channels you're looking for." - Ben Obi-Wan Kenobi
	return;
	}

So we can ignore that.

---

Option 1: combine app name and version

If alignment is so strongly desired that it would make you sad, we could try to do it the other way around and replace

server/apps/updatenotification/lib/Notification/Notifier.php

Lines 143 to 149 in d9151ff

	$notification->setRichSubject($l->t('Update for {app} to version %s is available.', [$notification->getObjectId()]), [
	'app' => [
	'type' => 'app',
	'id' => $notification->getObjectType(),
	'name' => $appName,
	]
	]);

with:

			$notification->setRichSubject($l->t('Update to {app} is available.'), [
				'app' => [
					'type' => 'app',
					'id' => $notification->getObjectType(),
					'name' => $appName . ' ' . $notification->getObjectId(),
				]
			]);

resulting in Update to **Mail 4.2.0** is available
But might be worse translation-wise?

---

Option 2: attempt careful string split

Alternatively we could try to regex match the versionstring of server to something like ^Nextcloud\ (\d+\.\d+\.\d+)$
If it matches, we can try the string split and otherwise we keep the old translation string where we just insert whatever the updater server sent?

[rakekniven]

As a user I do not understand why the product name and version info needs to be bundled. But if the code is like that and there is no easy way to split it we should keep it as it is. Using regex to split it sounds like a workaround to me. But as stated before I am not deep into the code. I will close here as it is not that important for the project.