Programming

You might want to consider using country codes in your language identifier.

en-US en-UK en-CA

all have slight variations in dialect. I don't speak other languages but I imagine it is important in many cases.

Localization is a hard problem, but storing your translations in the DB is a bit unusual unless you're trying to translate user data or something.

I'd recommend looking into tools like Project Fluent or similar that are designed around translating.

As for the schema you have, if you're sticking with it, I would change the language into an IETF language tag or similar instead. The important part is that it separates language variants. For example, US English and British (or international) English have differences, Brazilian Portuguese and Portugal Portuguese have differences, Mexican Spanish and Spain Spanish have differences, etc.

Using an ID instead of the text content itself as part of the PK should be a no-brainer. Languages evolve over time, and translations change. PKs should not. Your choice of PK = (TextContentId, Language) is the most reasonable to me, though I still think that translations should live as assets to your application instead to better integrate with existing localization tools.

One last thing: people tend to believe that translating is enough to localize. It is not. For example, RTL languages often swap the entire UI direction to RTL, not just the text direction. Also, different cultures sometimes use different colors and icons than each other.

I'd suggest you get an i18n package for whatever language you are using and follow their conventions

Had to solve the same problem few months ago, user provided content and so, user provided translations.
We use postgres everywhere and we had to support 3 languages initially with one more eventually, so we decied to use json fields for anything that could be translated (which wasn't too much). Mind you, this was basically a (temporarily permanent) prototype project but (fresh) postgres has a good support and operators for json so it worked alright.

EDIT: I remembered that hstore might be a good alternative too, I think it was slightly less "heavy" and had better operators for the kind of access we needed

Better use a separate table for languages (int id, string language) and reference the language in your translation table by its ID.

That gives you a way to manage languages.

INSERT INTO TextContent (OriginalText, OriginalLanguage)
VALUES ("Ciao", "it");

Shouldn't that be TextContent(TextContentId, OriginalText)? Something like

(then you should make the id a primary key, index originaltext and make the id in the other table a foreign key)

I could drop TextContent too, and just have a Translations table with TextContentId

Sure, but the you would have to reference the text via TextContentId in your code, which would be very annoying.

Instead you could have a function, say t("Ciao") that kinda runs something like (of course loading all the translations in ram at startup and referencing that would be better than running a query for each and every string).

select t.translation
  from textcontent tc
       join translations t on t.textcontentid = tc.textcontentid
 where tc.originaltext = ?
   and t.language = ?

The function could also return the originaltext and log an error message if a translation is not found.

BTW 1: most frameworks/languages have i18n facilities/libraries - you may investigate one and use it instead of rolling your own.

BTW 2: why would you put the translations in a database? what's the advantage compared to files?