Use global i18n strings instead of global env vars in our i18n strings

[johncowen]

Description

This issue is split off from #1478

Instead of using env for "i18n global variables", we should just use i18n for a group of select i18n keys that we define as being available "globally". We can collect these "globals" at i18n service start up (using @kong-ui-public/i18n#t and then always feed them into our own t). In doing this we remove the dependency on env and then we should be closer to only having a single place for defining application strings.

---

TLDR;

kuma-gui/src/app/application/services/i18n/I18n.ts

Lines 32 to 36 in e865b09

	const globals = {
	KUMA_VERSION: env('KUMA_VERSION'),
	KUMA_DOCS_URL: env('KUMA_DOCS_URL'),
	KUMA_UTM_QUERY_PARAMS: i18n.t('common.product.utm_query_params' as Parameters<typeof i18n['t']>[0]),
	KUMA_PRODUCT_NAME: i18n.t('common.product.name' as Parameters<typeof i18n['t']>[0]),

See the env usage above? We should try and reduce that and replace it with the t usage shown above.

This code makes these GLOBAL_VARIABLES available within i18n files.

---

Coming back to look at this after some time I think we've actually done most of this, some examples:

• KUMA_VERSION should be an env var as its not static
• KUMA_DOCS_URL is weirder, as it should use a static i18n derived URL, appended with KUMA_VERSION
• KUMA_PRODUCT_NAME can probably be removed from env entirely (but kept as being i18n derived)

Ideally all i18n 'globals' should live in global.NAME_OF_VAR or similar so its super obvious how to make a new i18n global var.

The final aim is to finally have env not deal with static variables (we only use env for historical reasons because we didn't have i18n when we originally needed injectable strings).