Make tracking labels customizable


(Anton) #1

It would be nice if tracking labels were customizable in settings. I think they can be “styled” uniquely for different communities.

I mean these:

  • Muted
  • Regular
  • Tracking
  • Watching

For example, for community of musicians I’d use:

  • Muted
  • Piano
  • Forte
  • Fortissimo

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.


(Mittineague) #2

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?


Alter String Shown?
(Anton) #3

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.


(Mittineague) #4

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”?


(Anton) #5

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.


(Mittineague) #6

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”.


(Anton) #7

That’s why a single “override any translatable thing in Settings” would cover a lot of different cases.


(Mittineague) #8

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.


(Anton) #9

FYI: the amount of work for this feature to happen does not depend on the number of entries in the YML file.


(Robin Ward) #10

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.


(Anton) #11

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()

(Sam Saffron) #12

I think the best first step here is allowing localization override direct from admin UI, would pave the way for “localization” themes.