FIX: Set text title for desktop push notifications

FIX: Set text title for desktop push notifications

Fixes a broken translation on some browser push notifications, same as 4c23083c57531f0388950aeed7ff48fc3c6b3bdc but for client-side translations.

diff --git a/config/locales/client.en.yml b/config/locales/client.en.yml
index 9084946..2611da1 100644
--- a/config/locales/client.en.yml
+++ b/config/locales/client.en.yml
@@ -407,7 +407,7 @@ en:
         reviewable_count: "Count"
         reported_by: "Reported by"
         deleted: "[Topic Deleted]"
-        original: '(original topic)'
+        original: "(original topic)"
         details: "details"
         unique_users:
           one: "1 user"
@@ -1678,6 +1678,7 @@ en:
         watching_first_post: '{{username}} created a new topic "{{topic}}" - {{site_title}}'
         confirm_title: "Notifications enabled - %{site_title}"
         confirm_body: "Success! Notifications have been enabled."
+        custom: "Notification from {{username}} on %{site_title}"
 
     upload_selector:
       title: "Add an image"

GitHub sha: c5fecdd5

1 Like

Custom notifications are the worst, we really should force all plugins to register a specific notification type id with core (simply by checking it into core repo)

2 Likes

It’s quite hard though, since they are numeric ids.

Sorry, I don’t think I fully explained:

I mean the plugin would submit a PR to core here:

With say:

+ post_assigned: 21,
+ post_unassigned: 22,

This does not mean we are folding assign into core, just that the ids are now reserved by core and all the localization and so on becomes a lot simpler for the plugin.

I see, but that does mean each plugin that wants to do this has to wait on a submission to core. And we are carrying those enums presumably forever even if the plugin ceases to exist.

2 Likes

Yeah it is a balancing act, but as it stands stuff like the mobile app and api consumers now have a real tough time figuring out what “custom” even means, core has a pretty icon for it and there is currently no mechanism for figuring out what icon “custom” has or what type “custom” notification is. Having a hard coded number at least gives us a fighting chance short of designing a brand new api for working with custom.