Localized Database Notifications.

[ahmed-rashad-alnaggar]

Package

Notifications

Package Version

v5.0

How can we help you?

Hi there,
I was wondering why the ability to have localized database notifications isn't there, I know that the Notification class toArray() function evaluates the title or the body to its value, but why is that, can't it just serialize them if they are closures which will add more consistency? (this is the current behavior of mine).

Has anyone else tackled this? Would it make sense to add a ->translatableTitle() method or something similar? Or is there already a recommended pattern for localizing persisted notifications?

[mohammedelkarsh]

Database notifications are snapshots. When Filament/Laravel persists a notification, title / body are stored as concrete values (via toArray()), so later renders don’t re-run closures against a new locale.

That’s why there’s no first-class “live translation” for already-stored DB notifications: the DB row would either need to store keys + params, or you’d re-translate on every read.

Practical patterns

1) Translate at send-time (simplest)
Send the notification in the recipient’s locale:

$locale = $user->preferred_locale ?? app()->getLocale();

app()->setLocale($locale);

Notification::make()
    ->title(__('notifications.order_shipped.title'))
    ->body(__('notifications.order_shipped.body', ['id' => $order->id]))
    ->sendToDatabase($user);

The stored text matches the user at the moment it was created.

2) Store translation keys yourself (true “translatable later”)
Don’t rely on evaluated strings — put keys in data and render in your UI:

Notification::make()
    ->title('order_shipped') // treat as key
    ->body(json_encode(['id' => $order->id]))
    ->sendToDatabase($user);

// when displaying:
__("notifications.{$notification->data['title']}.title");

or a custom database notification class that writes structured data and a Blade/Livewire renderer that runs __().

3) A ->translatableTitle() helper
Would be nice DX sugar, but under the hood it still has to choose (1) evaluate-now or (2) persist key+params. Closures can’t be serialized safely into JSON the way people usually expect.

Recommendation

For most apps: translate when sending into the user’s locale. Only store keys if users regularly switch language and need old notifications to flip language on the fly.

So the current “evaluate to string” behavior is intentional consistency for persisted mail/history — not missing i18n, just deferred i18n lives in your persistence format.