I’ve read that the only way to nab all the texts to replace is by using the Site texts settings and replacing each one. I’m trying to change the verbiage:
Because that just makes way more sense to me with message boards. I was able to change a lot of them with Site texts but it’s such an inefficient way to go about it. Is there any other way?
(Also, because it will only return the first 50 results, I can’t actually change them all with Site texts anyhow.)
Lol, I’ll use your language to keep things sane! RE: this file, can I just change the contents of it for my local install and things will change everywhere in the site?
That’s mostly to let you see what all of them are.
You could edit that file and then contrive to have your version copied over the one in the container.
Another thing you could do would be to edit it and then contrive to update the stuff in the database via the API. Or you might do it in rails. Actually, it might not be too hard to get some Ai to write a script to do the updates.
I really don’t recommend it, but it could be amusing.
So do you mean, this file is what the app interprets to populate the database with the actual values? That is, this is the “defaults” that the system reads from?
This doesn’t hit the database (I think it would be too slow).
I believe most of the locale stuff is processed in memory for speed, using Redis as a cache (happy to be corrected on that).
the only thing that gets stored in the database are your modifications (in the table translation_overrides), which will be read when you initialise the app or piecemeal when you make a single modification whilst online.
I would just point out a couple of things:
increasing the number of modifications significantly might extend your app initialisation time (I’m not sure anyone has benchmarked this).
these may become an administrative pain to maintain as Discourse evolves but maintains its own nomenclature. You are inventing work for yourself here.
given it’s now arguably the most popular forum platform, lots of people already use at least one Discourse site and are very used to the nomenclature, so maybe consider not confusing your users by changing what they’ve already got used to back to prior norms?
Also see:
This implies that each Category has its own administrators, URL, settings, purpose … e.g. Meta is a forum. It is not made up of several forums … I’m really not sure how you’d argue that? But I digress.
Respectfully, you guys don’t know my use case. Saying it’s a “terrible idea” or that I may be damaging the user experience without knowing why I’m doing what I’m doing assumes I’m doing it out of ignorance. I’m not interested in getting into a debate about taxonomy or user experience. For my use case and audience, the terminology Discourse uses to describe its content types doesn’t make sense.
So to recap:
Discourse reads this file to populate its labels by default; any changes I make in translation override this and end up saved in the database. So the most efficient way to change these terms sitewide is just to change this file and move it into the /locales/ folder.
It would seem the only concerns here are if that file is updated by the core. I assume then any new texts would be read from the /standalone/ version of the file rather than mine, so I’d need to update mine to accommodate that. I’m not sure how performance is an issue in this case, since the database isn’t involved and it’s just reading from a file?
That’s one way to do it. You’d need to edit your app.yml to make it to it every time you build a new container.
If you do what I described above your version will overwrite the version that is supplied with the current version. The version in the locales directory is what I think you mean by the “standalone version”. So, if you do it this way, the file will eventually be missing stuff unless you watch when it changes. Worst case, though, is you’ll just see the name of the thing that’s missing, so maybe you won’t care. It won’t crash, just look confusing.
I’m saying it’s a bad idea because these are things that can cause problems if you don’t understand, so when it ends up being a disaster, I’m on record saying that I did not recommend the very changes that I told you how to do.