Implement i18n

[Mateusz-Dobrzynski]

Resolves #5:

• Introduces an i18n framework (i18n-intl),
• Updates dependencies,
• Internationalizes existing views,
• Extracts repetitions into separate components.

[jakubmanczak]

Suggested change

	return "Polski";
	return "polski";

:P

[Mateusz-Dobrzynski]

I remember us having this conversation a while back and your argument (correct me, if I'm wrong) that while lowercase "polski" is ugly, it's the standard. Since then, I've found more than enough counterpoints (e.g. Chrome and Firefox language settings) to support the decision of keeping it consistent. Notable apps use the version we like better anyway, so why force ourselves for the worse?

[jakubmanczak]

My argument was that it's correct, in regards to language rules. And also used, more or less standard.

[Mateusz-Dobrzynski]

If you were to use that word in a sentence, surely (My first language is English, but Moim językiem ojczystym jest polski). However, that's not the case here. In many contexts it's common to start words with capital letters, even though there are no grammatical rules enforcing that (unlike in e.g. German). We don't have to cling on to the rules, especially when we're not breaking any.

@julesity, what's your opinion on this? Context: should "Polski" should be lowercase here or can it be the way it is – and why?

[jakubmanczak]

As far as I'm aware, while aren't required to get consent for 'strictly necessary' cookies like language or color schemes under GDPR, we do need to disclose the details of their use somewhere. A thing to keep in mind - maybe a subpage about it somewhere?

[Mateusz-Dobrzynski]

By default, next-intl uses session cookies to be "compliant out of the box". I'm leaving it that way until we come up with a sensible idea to present cookie disclaimers.

[jakubmanczak]

I can't seem to be able to log in as initial infrastructure admin. Can you? If yes, we should schedule a chat to sort out the differences in our approaches, because one of us is doing something wrong.

Also featuring: miscellaneous string changes.

[jakubmanczak]

Compilation is broken due to eslint errors on unused variables. Might be nice to add an ignore clause to the eslint config. Offhand comment: what version npm are you using, that you're not getting this?

rules: {
      "@next/next/no-img-element": "off",
      "@typescript-eslint/no-unused-vars": "off",
    },

Otherwise, it complains about malformed JSON responses. Again, we must be doing something very differently; it's really worrying that I'm unable to even handtest the frontend while you're presumably unaffected.

[Mateusz-Dobrzynski]

Changes to eslint config were made.

What version npm are you using, that you're not getting this?

Well, I was. However, unused variables were already present in the code, so I assumed it's fine by our standards and ignored it (maybe if I remembered to build the app, would've done it differently).

Otherwise, it complains about malformed JSON responses.

Unclear, not sure what to do about it. I double-checked functionality of the app using 0713216 as backend. The fix introduced in debatecore/tau#74 is necessary, it won't work with what's present master branch (otherwise I wouldn't have made the fix to begin with).

[jakubmanczak]

As it turns out, the malformed JSON response was due to another bug that only occurs when no tournaments are present in the database - an empty response is sent instead of an empty json array. (Clearing your tau_dbdevdata docker volume when doublechecking such things is expected as it lands you a clean starting point!). This being said, this is an issue with another part of the codebase, making no difference here.

[jakubmanczak]