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: Topics → Threads Categories → Forums Subcategories → Subforums 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.)

If that’s the hill you want to die on (and when you ask questions here, are you going to use your language or ours?), you can look at https://github.com/discourse/discourse/blob/main/config/locales/client.en.yml and see all of them.

Depending on whether you can use 3rd-party plugins, this might be of some use? [image] Globally replace translations Plugin information_source Summary This plugin allows you to globally replace certain words in the translation hammer_and_wrench Repository Link https://github.com/Lhcfl/replace-translations-global open_book Install Guide How to install plugins in Discourse Features Literally, replace all occurrences of a word with another word For example, replace “Topic” with “Nya”: [image] [image] Configuration I believe its settings are self-explanatory slightly_smiling_face Note…

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?

Oh thank you for sharing. I worry about the possibility of it damaging UI elements per the comments…

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?

[image] alkah3st: this file is what the app interprets to populate the database with the actual values? No, I don’t think so. 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: [image]Terminology: topics vs threads Thread is a technical computer geek term, also it implies threading. So worth avoiding for both of those reasons. [image] alkah3st: Categories → Forums Subcategories → Subforums 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.

[image] alkah3st: this file is what the app interprets to populate the database with the actual values No. [image] alkah3st: That is, this is the “defaults” that the system reads from Yes. So if you do what to change them all, which is a terrible idea, you could edit that file, put it in /var/discourse/shared/standalone/whatever And then add an exec to the app.yml that copied it from /shared/whatever to /var/www/discourse/config/locales/ But you’ll then also need to watch the commits to see if it’s ever changed so you can add whatever got changed. So the API or rails way, that put the values in the database might be better.

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? Thanks.

[image] alkah3st: So the most efficient way to change these terms sitewide is just to change this file and move it into the /locales/ folder 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. [image] alkah3st: I assume then any new texts would be read from the /standalone/ version of the file rather than mine 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.

Replacing site texts efficiently?

Product Support

alkah3st (Daniel Quinn) May 22, 2025, 10:20pm 13

Thanks for the tip!

It seems like I got most (if not all) of the public-facing references via the Site texts. But I will keep that in mind if I develop a more comprehensive method.

Topic		Replies	Views
Globally replace translations Plugin	19	1040	April 19, 2026
Bulk replacement in translated strings? Product Support	11	1329	July 10, 2024
Is there a way to easily replace the word "Topic" everywhere on my site at once Product Support	5	1063	November 17, 2021
Some of Site Texts doesn't accept changes Product Support	10	1098	September 30, 2020
How can I change my sites local translate to my own settings Product Support	4	953	July 22, 2022

Replacing site texts efficiently?

Related topics