Following the single responsibility principle, and considering that the two implementations differ significantly, I think it would make sense to have two separate files, one for getDocsLink and another for getBlogLink. Alternatively, have getDocsLink which dynamically changes the language, and another one, e.g. getLink that uses the mapping array.

Good point. So I opted to share the same logic and architecture. Now the translatable links use a dict/object. Types force to have the english link as a type requirement. We only have a unique function to "translate" links, which I think is important for consistency.

Having the full links makes it easier to test whether they work or return a 404.

These types force the link keys to start with blog and docs, respectively.

One last nit on method signature - if we want to enforce a prefix, would it be clearer to change the method signature and add another parameter for that?

 getLink( 'en', 'docs', 'importExport' )

Alternatively, what if we skipped enforcing that, and used one array for both docs and blog links, making it generic and not tied to the resource type it stores?

const LINKS = {
	blogPhpVersions: {
		[...]
	},
	docsPhpVersions: {
		[...]
	},
	dotOrgBlogGutenber: {
		[...]
	},
}

I prefer having everything in the same object. I'm not sure if forcing a prefix is useful, but I see that it can help with decision-making when seeing the autocomplete while calling the function.

I'll leave it as it is for now. We can always merge the objects and remove the prefix check later.

Sounds good, thanks for sharing this use case.

One last nit on method signature - if we want to enforce a prefix, would it be clearer to change the method signature and add another parameter for that?

 getLink( 'en', 'docs', 'importExport' )

Alternatively, what if we skipped enforcing that, and used one array for both docs and blog links, making it generic and not tied to the resource type it stores?

const LINKS = {
	blogPhpVersions: {
		[...]
	},
	docsPhpVersions: {
		[...]
	},
	dotOrgBlogGutenber: {
		[...]
	},
}