Do we have a policy regarding use of the <menuchoice> ... </menuchoice> tag? The typographical guidelines mentiones only menu choices. Common practice also includes other named entities in the GUIs, such as buttons, textfields, dialogs etc. I assume this is all OK (IMHO it should be).
Recently I have come across a number of examples, where ordinary reference to things, that can be done in a GUI have also been enclosed in these tags, even though they do not specify a GUI element. An example might look something like this:
I think this is potentially confusing and should be avoided. In cases like the above I don't think emphasizing is needed at all, but if some general terms must be emphasized, I think it is preferable to use ordinary bolding.
Should I remove superfluous menuchoice tags when I find them?
Yes. I talked to Yurchor about this, this afternoon, see User_talk:Yurchor#x.22Chatty.22_pages_-_hard_to_mark_up__414. Sorry for the extra work.
Yes. I talked to Yurchor about this, this afternoon, see User_talk:Yurchor#x.22Chatty.22_pages_-_hard_to_mark_up__414. Sorry for the extra work.
I came across a similar issue within link texts. Link texts already stand out, and adding extra emphasis to words in a link doesn't look good in my opinion. I haven't done anything about these - I know that there are other considerations, such as compliance with docbook, but does that apply to links?
I want to stick to compliance with docbook, and I'm honestly not sure of the answer to this. I suspect that the markup within the link may be unnecessary, but I'd like Yurchor to confirm this.
In fact, there is no such thing as compliance ;)
I have to re-write wiki2docbook to replace <menuchoice> with ''' and parse <keycap>Ctrl+F</keycap> to get <keycombo><keycap>Ctrl</keycap><keycap>F</keycap></keycombo>.
To understand things better, you can compare XML (exported from UserBase and slightly fixed) and DocBook from rekonq pages here, Amarok pages here, and KrossWordPuzzle pages here.
The only thing that is needed for successful conversion is the consistent markup in UserBase itself. Nothing more. There must not be markup like <keycap>OK</keycap>.
The stable rules (and of course, great look of pages) is the only thing that matter for documentation. Should we separate clearer what pages are and what pages are not documentation?
Surely, there is not much sense to prompt someone to use "this markup is a mess!"© just to write their plans on Telepathy, which are far from the real-world implementation. ;)
Thanks in advance
[quote]I have to re-write wiki2docbook to replace
I don't think there's much we can do to help with the keycap parsing, though. Sorry about the "OK" - I think I've only done it once, and it certainly wasn't intentional. I have a bad habit of thinking that I just need to get to a certain point before stopping work, when it would have been better if I had stopped a little earlier.
Maybe we need a thread somewhere more central about which pages need strict markup, and which are better served by just bold and italic carefully applied.
It is useful. It makes GUI elements on UserBase pages mauch more prominent.
For example, <menuchoice>Ok</menuchoice> gives , but '''Ok''' gives just Ok which is not so visible. If you are trying to follow some instruction the former variant is much better, imho. ;)
I just want to say that DocBook compliance and UserBase markup have to be treated separately.
KDE UserBase Wiki 