I mean for now it’s not being requested to add other languages beside italian and english, and i’m pretty sure my employer will never care about languages he doesn’t speak, so chances of languages that require some work other than translations are basically null.

Sorry, I didn’t think to add in the post that the translations are in fact of user generated content, and are themselves provided by users.

Project Fluent is still a good resource tho, thank you.

And also yeah, I’ll use a better schema for language tags, that’s a clear fault

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.

I still don’t get why having a separate table for languages is useful. I mean, even if the translation changes, the language itself will remain the same, right?

Oh, right. Taking into account language variants makes VERY obvious why I’d want to use a table to store them.

people tend to believe that translating is enough to localize. It is not.

Onestly, I just hope that won’t be something i should have to worry about. The rest of the codebase is as shitty as it gets, and I don’t want to be the one to refactor it for proper localization. I’m implementing a new feature that allows me some degree of movement to think about a good design for that, and new, features, but this is as far as I’ll go (Yes I know I probably sound like an ass but it really is that bad)

But why would I need that? (Onest question, I hope I don’t sound rude)

I mean, I could easily retrieve the list of available languages, and it makes it faster to delete them using an ON DELETE CASCADE (right?), but it also complicates stuff a bit for general use

That’s probably a good call, thanks :)

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)

Yup, TextContentId is PK, and I’d set to auto_increment so that i wouldn’t have to worrya bout it.

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

Not really, the translations I keep in the database are for entity that would be retrueved from the client with already the translated values instead of ID (should have specified this in the post maybe)

BTW1/2: the translations on the database are for entities on the db (stuff like user generated content, which will also input the translations). For general text on the page I’m using a specific framework, which would be difficult to use for the user generated content, at least how it’s set up now (it’s angular’s ngx-translate)