User alkah3st seeks an efficient method to globally replace Discourse site texts, specifically changing terms like “Topics” to “Threads” and “Categories” to “Forums.” They note that the standard Site Texts interface is limited to 50 results and requires tedious manual entry.
In response, pfaffman suggests editing the source locale file (client.en.yml) directly or using the API/Rails console to update the database. merefield provides technical clarification, explaining that the locale file serves as the default in-memory configuration, while only modifications are stored in the database’s translation_overrides table. Merefield strongly advises against extensive custom nomenclature, citing potential maintenance issues, increased initialization times, and the risk of confusing users accustomed to standard Discourse terminology. They also quote codinghorror regarding the technical implications of the word “thread.”
alkah3st maintains their position, stating their specific use case justifies the changes and clarifying their understanding of the file override mechanism. To mitigate risks, merefield proposes using sed commands within app.yml to automate specific replacements, a suggestion pfaffman agrees is superior to overwriting the entire file. The discussion concludes with alkah3st acknowledging they have covered most public-facing terms via Site Texts but remaining open to the proposed methods, while stephtara asks for feedback on a similar French localization project.
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.
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.
Good one! That’s definitely better than overwriting the whole thing as I suggested. . . . as long as those sed operations don’t change the names of the texts!
@alkah3st did you manage to get this working the way you wanted to? I am also considering changing the terminology (albeit in French) and would find your feedback precious if you actually went through this.
