I'm pretty sure the Gnome Guidelines prohibit or at least discourage the use of markup in the status bar.
I know. A really stupid limitation IMHO.
While I am unsure of the reasoning behind it I would not dismiss it so quickly. I figure it is overkill and possibly distracting to have markup in the status bar messages (but I suppose if it was distracting I would have noticed it already).
If it distracts you, chances are you're seeing this particular message for the first time. Then it's a good thing because it gives you an immediate explanation of what happened. Once you get used to it, you will stop noticing it when you don't need it, markup or no markup.
The idea is simple: 1. Inkscape is a complex app. 2. To make a complex app easy to learn, you need to provide a lot of tips and explanations along the way, some of which may be quite longish. 3. To make longish tips readable, you need to highlight the important bits. That's all.
Did you find out the reasoning behind it before going to all that trouble? using non-standard widgets could come back to bite you in the ass.
gtk-label is very standard. gtk-statusbar uses it internally anyway. And we don't need gtk-statusbar for its message stack because it's too primitive for our purposes (we have our own MessageStack and MessageContexts).
Don't worry, I already did this work :) Now most messages have this
Presumably progress has been made in the past few years and markup no longer messes up translation as badly as it used to but it will at least mean extra effort for translators.
It will. So what? Do you suggest we should stop making our messages better for fear of giving translators extra work?
(where this makes sense, of course).
for the benefit of translators when does it make sense and what rules or pattern should they try and follow?
Three main rules:
1. Highlight the changing portion of the message, e.g.:
<b>3</b> objects selected.
This lets the user who knows what the message says to quickly focus on the important bit without scanning the entire message. If there are several changing portions, highlight the most important one.
2. In tips and error messages, highlight the most important part of the message so that the highlighted part makes at least some sense when read separately, e.g.:
Select <b>at least two objects</b> to group
Here, if the user is wondering why grouping did not work, he can read only the highlighted part ("at least two objects") and this will already give him a clear idea of what went wrong, without having to read the entire message.
Sometimes (sparingly), there may be two highlighted portions:
If you want to clone several objects, <b>group</b> them and <b>clone the group</b>.
This is because the message tells you to do two things, hence the two highlights.
3. In tips about keys and mouse, highlight the keys and shortcuts:
<b>Shift:</b> toggle select, force rubberband
or
<b>Rotate</b> the pattern fill; with <b>Ctrl</b> to snap angle
(this one uses rules 2 and 3).
so long as no one dares blame users for failing to notice that status bar messages, and so long t is not used as an excuse for not improving things I dont really mind.
Rather, it's used as an "excuse" to improve things. If something is broken, I won't explain this in the statusbar; instead I'll have to fix it first and then describe the correct behavior.