It is quite possible to change some text via plugin over-ride of yml file text. Possible problems including if the text is used as attribute values. But with thorough testing not impossible and easily doable.
I shudder to think of everything be made as a setting, but then I’m old-school and don’t mind configuration, and I’m not fond of UI bloat.
I tend not to do so. Most “regular” people would not even be able to understand how to do it.
A more generic solution would be to create a plugin that allows overriding ANY translatable string (I’d make it a core functionality, to be fair, as I proposed early a few times already). Customizing text, captions and icons per-setup is crucial for adapting the look and feel to various communities.
This is a feature proposition that both a) would be useful for me and b) I believe would be useful for many non-technical people who want to use Discourse as their discussion platform.
I want to stress this: being able to customize the look and feel is one of the crucial aspects of adapting a discussion platform to various types of communities.
OK, thanks for clarifying. So what you are requesting is what I would consider “UI bloat”. that is, making everything changeable via a UI. But I think that only because this is already very easy to do.
I’m not saying it’s a bad idea, only that I think some balance should be maintained. It’s a fuzzy line between “it’s too much and it’s confusing”, and “it’s not enough I’m not a dev, make it easy”.
Yes, but have you looked at the yml files?
There are literally hundreds of lines. To get all of these into a a UI would be a lot of work and most likely make things more complicated and unused for most Discourse users.
You can already do what you are wanting to do. Sorry, but I’m not seeing why this should be a Core change.
I’m not saying it can’t happen, only why should if.
I actually agree that this is a good feature to implement. It comes up quite a bit.
A simple version could just be two text fields. Type the input key, type the new output key.
It would be up to the person overriding it to know what the keys are. I think that would be sufficient in 90% of cases. A version 2 could include searching for keys to override.