the translations on the database are for entities on the db

Oh, then you could consider having one extra table per entity (one-to-many) with the translatable stuff:

create table some_entity (
    id .. primary key,
    -- fields for attributes that are not translated
    price ..,
    created_on ..,
    deleted_on ..,
    ..
);
create table some_entity_i18n(
    id .. primary key,
    some_entity_id .. foreign key references some_entity(id),
    locale ..,
    -- one field per translatable attribute
    title ..,
    description ..,
    ..
);

IMHO putting everything in one big table will only complicate things in the long run.

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?

If it’s for backup, zfs and btrfs can send incremental diffs quite efficiently (but of course you’ll have to use those on both ends).

Otherwise, both NFS and SMB are certainly viable.

I tried both but TBH I ended up just using SSHFS because I don’t care about becoming and NFS/SMB admin.

NFS and SMB are easy enough to setup, but then when you try to do user-level authentication… they aren’t as easy anymore.

Since I’m already managing SSH keys all over my machines, I feel like SSHFS makes much more sense for me.

AFAIU bluehost does not support the acme protocol, so you’ll either have to manage your certificate manually or (recommended!) move to a different dns registrar.

If you are wondering which provider you should switch to, basically all the serious ones will work… IDK if this is relevant for nginx, but here’s a list of the supported ones for the client I use https://go-acme.github.io/lego/dns/

If you are unsure and want to experiment before touching your current setup, you could register a new cheap domain (less than 1$, see https://tld-list.com/), use it for your tests, and then not renew it.