Console will always try to fetch an i18n namespace for all enabled plugins, regardless of whether the plugin supports i18n. The console will block loading and retry several times trying to fetch the namespace, which greatly slows down the console load. We either need a way for plugins to opt in to using i18n or we need a way to fail quickly if the namespace isn't there. (It might be difficult for plugins to opt in without making an API breaking change.)
@Sam so one solution could be to as you mentioned to have a field on the ConsolePlugin instance, which would determine if the plugin's i18n should be loaded. Other solution is to have a dedicated annotation on the ConsolePlugin instance, something like `console.openshift.io/plugins: true`. Upon console server start the backend will fetch all the enabled ConsolePlugins and check for the annotation. If the annotation is missing then we could default to `false`. I know that this second solution is not ideal but we can document the approach properly + we dont introduce breaking change. Once we decide to bump the ConsolePlugin to v1beta1 or even v1 we can handle the i18n properly.
Reopening the bug. I think we want to look more closely at this to see if we can avoid the 404 request altogether. See comment https://github.com/openshift/console/pull/10378#issuecomment-965077285
This issue was delivered by https://issues.redhat.com/browse/CONSOLE-3162 story. Now the console will pre-fetch the i18n namespace only for plugins that contain the `console.openshift.io/use-i18n` annotation. Putting on ON_QA.
If dynamic plugin doesn't have `console.openshift.io/use-i18n` annotation or set it to 'false', console will not load plugin i18n namespace /locales/resource.json?lng=en&ns=plugin__<plugin_name> verified on 4.11.0-0.nightly-2022-06-18-081846