You are not logged in.
I personally loathe Capitalising Every Word — I prefer sentence case. When I added the Write tab stuff like Custom Fields and Article Image, I added them to the language server as Article image and Custom fields but there were complaints that it wasn’t consistent. Changing those isolated (new) cases was the path of least resistance but I’d prefer to go and do it properly one way or the other. Same with ‘Styles’ vs ‘Style’ on the Presentation tab. They’re just strings in the RPC server so simple to change once we have a chosen direction.
Plugins of course are a law unto themselves at the moment — probably due to a lack of style guide :-)
Last edited by Bloke (2011-07-21 10:00:38)
Let’s not beat around the bush: Textpattern User Interface Style Guide
Robert and Stef are document owners to do with it as they like.
I would be happy if the first section added to the guide address the use of text elements (e.g., capitalizations styles, and where used), as we’ve been talking about here (and let drop-downs be sentence case, obviously) so that I can sync the editorial guide with formatting examples that use UI elements correctly.
And, since there are inconsistencies in the current UI that need fixed (one way or the other), maybe a table in the UI guide would be good that shows the expected changes. It could (and should) be removed when actual UI changes have been made.
Last edited by Destry (2011-07-21 10:48:47)
I personally loathe Capitalising Every Word
I Feel Your Pain. I Do Too.
Same with ‘Styles’ vs ‘Style’ on the Presentation tab
It’s plural in some translations if that has any value. Other thing is the consistency across translations. For example in Finnish translation portion of the strings start with lowercase word, meaning that we have option lists with options that start lowercase while others use sentence case. But then again many of the translations outside English are pretty outdated.
The casing issues in Finnish are caused by the fact that the language strings are re-used in different places. When you make it correct elsewhere, it becomes incorrect somewhere else.
Last edited by Gocom (2011-07-21 10:22:47)
Rah-plugins | What? I’m a little confused… again :-)
I spoke with Robert a few weeks back and he seems quite happy to revise the language string file for TXP5 including making additions if needed.
Was any decision made on whether to shorten “Textpattern CMS User Documentation”? Maybe to “Textpattern CMS Documentation” as at least it’s 5 characters shorter and surely all documentation is for user of some sort?
I’m going to open an issue for changing the wording for various parts of a default install (the What do you want to do next? article, external links and possibly the cateogories) to match your style guide where appropriate and just need a decision on the docs text.
Textpattern CMS Documentation – documents about the Textpattern CMS
Textpattern CMS User Documentation – documents about Textpattern CMS Users
I like the first one better myself.
There are two kinds of documentation for just about everything manufactured:
Sometimes there’s a little overlap, and with software this is especially true, but by and large they are two different blue prints.
“Textpattern CMS Documentation” sounds like manufacturer docs to my ears, while the other makes it clear it’s for people like me. But the distinction in this case—for an open source CMS—is probably small or lost on most people. If you want to save 5 characters, I’m not going to complain.
But where was this a problem, again? Because maybe this is a context thing and we can simply use “User Documentation”. E.g., a logo already identifies the product as “Textpattern CMS”, so a tagline or whatever doesn’t have to repeat that.
Ed. Ah, I realize now you mean for links, perhaps? Well, if we had decided a one official abbreviation to use (i.e., Txp or TXP), then I would have said just use“Txp User Docs” or “TXP User Docs”, but since the majority rule was to leave abbreviations free-wheeling, then we’re forced to write it out on an official level. Otherwise, we lose having any consistent identity in links at all.
Last edited by Destry (2011-07-28 20:06:23)
I’m not too keen on shortening “Textpattern CMS” to “TXP” as it sets a precedent that abbreviation is fine to use. For Search engine optimisation TXP is pretty meaningless, unless someone is already familiar with Textpattern – it’s all about brand recognition these days.
I agree with the setting a precedent part as far as it goes for authoring. But, I’m less concerned about SEO for SEO’s sake; rather I more concerned for human understanding and the content being properly marked up.
I mean we could (and probably should) be doing things like this when a link label itself is not written out fully for whatever reason:
<abbr title="Textpattern CMS">TXP</abbr>
<a href="#" title="Textpattern CMS User Documentation">TXP User Docs</a>
But again, it demands a constant use of abbreviation, not just what anybody feels like using.
How about using this? Textpattern CMS User Docs I think it’s a lot less confusing to abbreviate “documentation” than to drop “user”.
Of course, we could say Textpattern User Docs and it’s shorter still without losing any brand identity. Remember, it’s about context. So if a link reads like this one, and then brings a person to a page where they see Textpattern CMS somewhere. It’s fine. It’s in context. People will make the mental cross-over easily enough. ‘Oh, this thing is a CMS…cool’.