Register a notification extension without its language string and the entire ACP Notification Settings screen breaks for the whole site, including other applications' notifications.

The symptom

UnderflowException: lang_not_exists__notifications__myapp_Thing
#0 /applications/core/modules/admin/membersettings/notifications.php(78): IPS\Lang->get(...)

The cause

That screen loops every registered notification extension with no error handling:

foreach ( Application::allExtensions( 'core', 'Notifications' ) as $k => $extension )
{
    $types[ $k ] = array( 'title' => Member::loggedIn()->language()->get( 'notifications__' . $k ) );
}

Lang::get() throws on a missing key, so one application without its string kills the page.

The trap

The key is built from <app>_<ExtensionClassName> — the class file name, not the notification type declared inside it. An extension in extensions/core/Notifications/Live.php needs:

'notifications__myapp_Live'      => "Live topics",
'notifications__myapp_Live_desc' => "Notifications about live topics.",

If the configuration group inside that class is called golive, you also need notifications__myapp_golive for the group itself. Both sets are required.

Core follows the same rule: Files.php in Downloads uses notifications__downloads_Files.

Related: A module shows as module__myapp_thing on the administrator restrictions screen, Why your app shows menutab__content or module__myapp_thing to customers, The core/Notifications extension in Invision Community 5