3.60 €/month is not bad. however i'd look for something even cheaper, given that the lowest plan gives 4 cores and 8gb of RAM, which I probably won't need
I do not mind RAID, so i won't lose data when a drive fails (the most valuable thing will be backups, which i mean, are backups, so not that critical if i can make a new one, but even losing other data would be a bit boring). I think I'd do software RAID tho, so if the controller breaks i wouldn't have to find the same model, which could be hard for old hardware i guess.
the other comments scared me about power consumption, so i'll have to investigate more of it.
Old desktop pc would be ideal, for exactly the problems you pointed out. The only thing that is making me consider this is the already included drives, which is where i'd end up spending most of my money (especially now, thanks ai)
I mean, the same capacity would cost WAY too much more. For a similar capacity + the system i'd have to spend at least double :(
yup, desktop components are what i was originally looking for, but this is 200 euros for a lot of storage, which would be way more expensive if i were to buy it separately
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
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)
I might be a robot, I don't know why but i can't solve the captcha lol
I'd love to give this a try tho so maybe I'll come back later
Just a random idea, but would you consider using anubis instead? (That new thingy that has been popping up lately, for example on the archwiki). I haven't checked it out but I bet it's also better on a privacy standpoint in respect to google's captcha
I hate that it's oracle...