Add <reset> before new color in smart formating mode

[MorkaZ]

While formatter: smart is enabled, it translates a bit wrongly legacy color codes. For example, this is how formatting works in minecraft - &b&ltes&bt should result in Test as bolded and Test not, all in light blue color. Meanwhile, using smart translation mode, it makes whole text bold. Same thing is happening with any other format.

How to fix it?
Well, solution is very simple:
Add <reset> before translating any & color to MiniMessage, just to make it work like it does in minecraft standard to avoid issues
For example, while you are translating something to "<"+colour+">", simply add "<reset><"+colour+">" and it will completly solve problem. Make sure <reset> will be added only before colors, not before formats like &l, &o, &m, &n, &k, &r.

Why?
Simply because it works differently from minecraft standard. Also there are some people like me who update their servers from older version (for example from 1.20) and have database/setups of big amount of custom set prefixes, titles, nickname formats and other things which were made in classic formating style where &r was not used because it was (and is still) being used automatically by default in minecraft formatting. Also, results in DisplayNameTags is different than in anything else, for example minecraft chat while using smart formatter which makes it at some point not compatible with other plugins/papi placeholders.

Just to visualise the problem, here are some screens:

Here is how Title look like in plugin's gui & chat which uses classic formating with &+symbol:

And here is how it look like in this plugin:

Used format: "&f&l✧&5&lN&F&L&NEA&D&LND&F&L&NE&5&LR&D&LT&F&L&NH&5&LA&D&LL&F&l✧&r "

This issue makes it worser when, for example, matrix formats are used, here is example from permission plugin.
Here is how it look like on chat:

And in nametag of this plugin:

Used Format: &c&k!&4&lWlasciciel&c&k!

[Matt-MX]

From my experience using legacy formatting this is how it always behaved, requiring &r to be used to reset the formatting. I'm still a little confused about what the issue is..

Are you suggesting to essentially append a &r whenever the formatting changes?

[MorkaZ]

No, it was never like this. You never had to use &r to reset formats after using new color. All you had to do is start with different color and formats were always reseted. You can check it with

// typed from memory, should be ok
String testText = ChatColor.translateAlternateColorCodes('&', "&b&lTes&ctttttt");
player.sendMessage(testText);

Are you suggesting to essentially append a &r whenever the formatting changes?

Only while using new color. I can help fixing method which translate it, just please point where it is located

[Matt-MX]

Ahh I see the issue now. The smart formatter translates legacy -> minimessage which doesn't contain the ending clause (e.g., </red>).

Easiest solution to this is adding a <reset> for new colors when translating i suppose?

[MorkaZ]

Easiest solution to this is adding a for new colors when translating i suppose?

Yes, exactly.
Add <reset> while translating &+symbol to MiniMessage colors (do not do it with formats!).
First you need to make sure it is not &+format (formats are &m &n &l &o &k &r - colors are all rest.
If color will be found, apply at start while translating, for example "<reset><"+miniMessageColor+">", if not - do not do anything new. Thats all - it should work in minecraft formatting standards after that change