One concrete reason: if the language is user-configurable, you can avoid an additional argument at the call site by putting that data in a context.
If part of that input is now bundled up in this large globally structure, then now testing it seems like it would that much more complicated. Then, I'd need to artificially construct these structures as a part of my tests, making them less transparent to readers of the codebase.
> making them less transparent to readers of the codebase
Sometimes that's exactly what you want. It's the same as hiding CSS styles behind a set of props like `<Button buttonStyle="primary" buttonSize="large">Continue</Button>`. It actually makes your codebase much safer by reducing the combination of props and values you're able to pass.
From a testing perspective, you just wrap the component being tested in a context provider that provides the necessary fixtures for your test case. However, I'd also note that this is probably not an ideal function to test since all that you could possibly be testing is that react context and i8n are working as expected, which is almost certainly outside the scope of your application's testing surface.