Files
Vishal Kumar Singh 6e7e28306c fix(admin): use ISO 639-1 da for Danish admin locale (#26322)
* fix(admin): use ISO 639-1 da for Danish admin locale

Rename admin translation bundles from dk to da, normalize legacy dk in
app config, custom translation keys, localStorage, and stored user language.

Closes #25761

* fix(admin): add dk json fallback and admin user language migration

Register internal migration admin::migrate-prefered-language-dk-to-da to
rewrite admin_users.prefered_language from dk to da.

Export importLocaleJsonWithLegacyDkFallback from strapi-admin and use it in
core loadAdminTrads plus every bundled plugin registerTrads so third-party
plugins that still ship only dk.json keep loading when the UI locale is da.

Add @strapi/admin devDependency where the helper is imported from JS or
packages that did not already list it.

Refs #26322

* fix(types): add importLocaleJson to strapi-admin registerTrads typing

* fix(admin): expand plugin locale list and merge under canonical codes

Moves legacy dk handling into StrapiApp.loadTrads (flatMap + uniq + normalize merge) so registerTrads keeps a stable API without importLocaleJson. Core admin bundles use try/catch dynamic imports per locale code.

* fix(admin): route plugin translations through importLocaleJson

Pass StrapiApp.importLocaleJson into registerTrads so core and third-party plugins share legacy locale JSON fallback (da -> dk) and one-shot deprecation warnings. Relax admin test console.warn filter for those messages. Refs #26322.

* fix(admin): keep plugin locale fallback internal

---------

Co-authored-by: Bassel Kanso <basselkanso82@gmail.com>
2026-05-29 18:26:00 +03:00
..
2021-04-29 12:03:54 +02:00
2021-04-29 12:03:54 +02:00
2021-04-29 12:03:54 +02:00
2026-05-20 09:09:00 +00:00

Strapi plugin Sentry

The official plugin to track Strapi errors with Sentry.

Features

  • Initialize a Sentry instance when your Strapi app starts
  • Send errors encountered in your application's end API to Sentry
  • Attach useful metadata to Sentry events, to help you with debugging
  • Expose a global Sentry service

Installation

To install this plugin, you need to add an NPM dependency to your Strapi application.

# Using Yarn
yarn add @strapi/plugin-sentry

# Or using NPM
npm install @strapi/plugin-sentry

Configuration

property type (default) description
dsn string (null) Your Sentry data source name (see Sentry docs).
sendMetadata boolean (true) Whether the plugin should attach additional information (like OS, browser, etc.) to the events sent to Sentry.
init object ({}) A config object that is passed directly to Sentry during the Sentry.init(). See all available options on Sentry's docs

Example

./config/plugins.js

module.exports = ({ env }) => ({
  // ...
  sentry: {
    enabled: true,
    config: {
      dsn: env('SENTRY_DSN'),
      sendMetadata: true,
    },
  },
  // ...
});

Global Sentry service

You can access a Sentry service throughout your app.

const sentryService = strapi.plugin('sentry').service('sentry');

This service exposes the following methods:

sendError(error, configureScope)

Use it to manually send errors to Sentry. The configureScope is optional, it allows you to customize the error event. Read more about Sentry's scope system on their docs.

Example

try {
  // Your code here
} catch (error) {
  // Either send a simple error
  strapi.plugin('sentry').service('sentry').sendError(error);

  // Or send an error with a customized Sentry scope
  strapi
    .plugin('sentry')
    .service('sentry')
    .sendError(error, (scope, sentryInstance) => {
      // Customize the scope here
      scope.setTag('my_custom_tag', 'Tag value');
    });
  throw error;
}

getInstance()

Use it if you need direct access to the Sentry instance, which should already be initialized. It's useful if sendError doesn't suit your needs.

Example

const sentryInstance = strapi.plugin('sentry').service('sentry').getInstance();

Disabling for non-production environments

If the dsn property is set to a nil value (null or undefined) while enabled is true, the Sentry plugin will be available to use in the running Strapi instance, but the service will not actually send errors to Sentry. That allows you to write code that runs on every environment without additional checks, but only send errors to Sentry in production.

When you start Strapi with a nil dsn config property, the plugin will print a warning:
info: @strapi/plugin-sentry is disabled because no Sentry DSN was provided

You can make use of that by using the env utility to set the dsn config property depending on the environment.

Example

./config/plugins.js

module.exports = ({ env }) => ({
  // ...
  sentry: {
    enabled: true,
    config: {
      // Only set `dsn` property in production
      dsn: env('NODE_ENV') === 'production' ? env('SENTRY_DSN') : null,
    },
  },
  // ...
});

Disabling altogether

Like every other plugin, you can also disable this plugin in the plugins configuration file. This will cause strapi.plugins('sentry') to return undefined.

Example

./config/plugins.js

module.exports = ({ env }) => ({
  // ...
  sentry: {
    enabled: false,
  },
  // ...
});