In a discussion titled “Make tracking labels customizable,” meglio proposes allowing users to customize tracking labels (e.g., Muted, Regular, Tracking, Watching) via settings, suggesting this would benefit non-technical users and different community types. Mittineague notes that overriding text via YAML files is possible but may be too technical for most users. meglio agrees, advocating for a plugin or UI-based solution instead. Mittineague questions whether this is necessary given existing flexibility, while meglio reiterates that this is a feature request aimed at usability for non-developers. Mittineague expresses concern about UI bloat, arguing that making everything configurable via UI could complicate things. meglio suggests a single override for any translatable string. Mittineague warns that implementing this via UI would be labor-intensive due to the volume of YAML strings. meglio counters that the effort depends on scope, not total string count. eviltrout supports the idea, proposing a simple UI with two text fields: input key and output key — a solution meglio enthusiastically endorses. Finally, sam suggests starting with allowing localization overrides directly from the admin UI. The thread reflects a balance between empowering users and avoiding unnecessary complexity.
It would be nice if tracking labels were customizable in settings. I think they can be “styled” uniquely for different communities.
I mean these:
For example, for community of musicians I’d use:
Additionally, it would be nice to be able to thematize the longer explanatory text under the labels as well.
I think all this thematisation should be available in Settings.
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.
Have you tried over-riding the yml text?
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.
So this isn’t your own personal Discourse forum that you have control over, but some kind of “service” you are providing for “non-techies”?
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”.
That’s why a single “override any translatable thing in Settings” would cover a lot of different cases.
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.
FYI: the amount of work for this feature to happen does not depend on the number of entries in the YML file.
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.
Yes, yes, excellent, that is exactly what I mean!
P.S. Most front-end translation keys can be discovered easily after running this in js debugger:
I18n.verbose_localization_session()
I think the best first step here is allowing localization override direct from admin UI, would pave the way for “localization” themes.