Capitalize menu, link, etc. titles throughout core.

I think this is for sure the correct thing to do... tracking this issue :)

subscribing

Guys. ;) How about instead of subscribing, you each take a module or two? ;) Then this will actually get done much faster and we'll gave something to get committed. ;)

oh, i intend to, this way i can find the link when i've got a litte time to work on it.

Ah, good stuff. :) thanks!

(subscribe)

It took me some time to figure out what you meant by "Date and Time" (and that your point had nothing to do with either dates or times in titles).

So let me be more explicit, by rewording the rule in the last paragraph at http://www.writers.com/tips_titles.html:

The words "a, an, the, at, by, for, in, of, on, to, up, and, as, but, it, or, and nor" should be in lower case, unless they're the first word in the title. All other words should be capitalized, regardless of where they appear in the title.

There are other conventions, as indicated at that link above. I don't think anyone will complain if someone happens to follow the Chicago Manual of Style or AP or whatever, nor should they, but this explicit list of words seems like the simplest rule to have here.

Here's one for the watchdog module.

As someone noted in the list discussion, this also means all the translations have to be edited (since translations are case sensitive). So when you do a module, also do the .po files.

I think it'd make sense to just roll up all the .po files at the end wouldn't it?

agreed. it's tedious enough just doing the text. :P one thing at a time.

http://drupal.org/node/53753 was marked as a duplicate of this.

subscribing.

Is it just me or does a mega patch seem like it has little chance of ever getting committed? Would it be better to commit patches as they came in?

On the dev list, Drumm and/or Dries (sorry, can't remember who) said it all needs to go at once. This makes sense, as otherwise we have totally inconsistent capitalization throughout core.

@Wesley - this patch has very little chance of ever getting written (properly, as one consistent patch). If it did, I am pretty sure it would be committed.

So we also want to get at all the fieldset and field #titles correct? So on the user edit page it will be...

Account Information
E-mail Address
Comment Settings
etc.

Just making sure. I'm 100% behind this patch. So the battle plan is to have one patch per file? So one patch for user.module, another patch for node.module, etc.? I'd like to know who is working on what so I know where to concentrate my efforts. Thanks webchick for taking charge!

@RobRoy: the end patch needs to be one huge patch for all of core, but it's much easier to work on individual parts. So go ahead and roll one patch for user.module, etc. I (or whoever) can roll all the patches into one at the end.

Not sure about fieldsets and whatnot... the only thing we'd discussed on the dev ML was menu titles, so I guess keep it to that for now, and we can talk about other stuff in a separate patch.

capitalised aggregator modules menu links

there were 2 occassions where the title was
[code]
'title' => $category['title'],
[/code]

I just left those alone.

block.module menu capitalised.

i dont think there is a need to capitalise the theme names (only thing we can really control from block.module is the name of bluemarine) which are sub menu's thus i left them alone.

blog.module

blogapi.module

book.module

Correct / Easy on the eyes / Uncomplicated / Reads like a sentence:

"This is a Drupal title and reads like any other sentence"

Examples:
http://news.bbc.co.uk/
http://www.lemonde.fr/
http://hinduonnet.com/
http://www.torontosun.com/
http://www.theage.com.au/
http://www.iht.com/
http://www.elpais.es/

Incorrect / Overcomplicated / Tough on the eyes / A touch of Yanqui sensationalism :P :

"This is a Drupal Title and is Likely to Give You a Heart Attack"

Examples:
http://www.washingtonpost.com/
http://nytimes.com/

http://cnn.com appears to sit on the fence on this one.

My 0.10p,
-K

just an update

So far the following modules have been 'capitalised' :

So for now that leaves the following modules which need to be capitalised (capitalisation of _menu):

so grab one and dig in :D

ok i think thats it for the last of the modules....

combined everything together...please review

Simple and straightforward. Applied clean to CVS without any problems..
This is ready, so let's get this in...

Awesome job, Shakur!!

However, there's one problem: the capitalization of the menu titles in the help text is now inconsitent; it's done in watchdog, but not in others. I'd recommend removing those portions of the patch and either make the help text fixes a separate one, or removing those links altogether frrom help if http://drupal.org/node/84414 makes it in.

ok, removed the _help msgs of watchdog and rerolled everything against head.

To address Zen's comments in #22:

1. Switching titles to be "This is a title" is inconsistent with core's usage of US English throughout. You'll notice that the sites you've cited are from Canada, UK, Australia, etc.
2. You can't programmatically re-create "Date and Time" without a lot of server-side processing.
3. You can, using only CSS, re-create all other formatting options such as "this is a title" and "This is a title" and "THIS IS A TITLE"

therefore, this way seems the way to go.

hmm some people having problem using the patch. rerolled.

http://drupal.org/node/84414 introduced a By Module tab into admin and that seems overlooked by this patch. Flk did ask me to reroll but he's off to bed and, well, I'm in the same timezone as he! Me off to bed too!

Here's a re-roll for HEAD but it looks like that By Module is already taken care of.

1. Switching titles to be "This is a title" is inconsistent with core's usage of US English throughout. You'll notice that the sites you've cited are from Canada, UK, Australia, etc.

http://bostonherald.com/
http://www.boston.com/ [Boston globe]
http://sfgate.com/chronicle/
http://www.chicagotribune.com/

This doesn't appear to be something all American papers do.. It looks to be about 50/50. In other words, this is not a "locale" issue. It is an issue of readability, simplicity, elegance and ease of use.

Also, el jefe has an opinion on this as well.

-K

Please leave this for review. You've stated your opinion, that doesn't necessarily mean the patch needs work. We'll let one of the core committers chime in on which method they'd like to see and adjust the patch accordingly if need be.

PS: Yeah I know Dries said that, but it was early on in the conversation and before the discussion about the impossibility of fixing with CSS, etc. If he still feels that way, then that's cool with me.

Patch in #32 fails to apply for the same reason patch in #28 fails to apply. All line ends have the Windows end of line character (^M) appended.

Using a utility like dos2unix should convert the line breaks in the patch for you. Otherwise, update your version of patch. patch 2.5.8 on OS X is working fine for me.

Patch in #32 applied ok (after stripping ^M line ends). All seems well but I can't help an enourmous sense of "extended camel case" in the new admin/ by modules page. What do I mean, well, be exmaple:-

Why is configure permissions and get help always lower case? What's so special about Pages or Referrers that give them a capital but neither the former? The whole page looks "unbalanced". That's what I meant in my previous comment about this page, obviously didn't make myself clear.

@webchick Yep, I know about dos2unix. In fact, my Windows text editor of choice (EditPad Pro) is set to always save in Unix format. On patches that I fetch which turn out to have ^M endings I use vi :1,$! tr -d '\015' to remove the ^M. The only reason I point this out is that the Drupal handbook for HOWTO: Submit patches for Drupal is aimed at the patch maker and not at the committer (and by proxy any intermediate patch reviewer). Pointing it out is just to remind patch makers they need to make this step, not the reviewer/committer.

Okay, in this patch I think I've...

- Fixed a few stragglers like get help, configure perms, log in, etc.
- Changed my doc type to Unix. Let me know if you find the ^M's in this patch.

RobRoy,

Looks good. I'm assuming that the column Name in admin/build/modules is derived from the modules themselves and are therefore up to module maintainers to get correct.

Some more "stragglers":-

Under Navigation >> Create Content :-

Poll ok but the others not, likewise on the main page itself except here it's poll so they all wrong?

regards,
--AjK

Fixed the above. 'page' and 'story' are done in system_install() so you'll have to reinstall Drupal to see those change.

Keeping up with HEAD. I also found that Search and Search Settings were mixed up, fixed that.

Can we get a big boy/girl to check this out? Looks good to me.

looking good guys.

reviewed it and works fine with head.

Looks good. Some hunks failed to apply though. Also, what is the guideline with regard to form titles? I'd like to see some written guidelines that can be posted as soon this patch gets committed.

rolled against head.

Written guidelines, which could be added to the updating modules docs:

Menu titles capitalized

All menu titles within Drupal and its modules should be capitalized according to U.S. English. All words in the title should be capitalized, apart from articles, prepositions, and conjunctions.

For example, a title such as 'edit category' should now be 'Edit Category' and 'date and time' should now be 'Date and Time.'

Here is an example of old code:

Here is an exaple of new code:

(note that the title "Story" has been captalized)

If you wish to use different capitalization rules on your site's menu items, you may use CSS in your theme."

If someone could create some examples of how to change the capitalization rules in CSS that would be a nice thing to add to this. I'm not much of a CSS person.

@webchick: Regarding Dries' request for guidelines for form titles (both fields and fieldset titles), do you think all form fields/fieldset titles should follow the same rules as menu items? As it is now, they are all first letter capitalized and the rest lowercase (like Project information, New comment, File attachment, etc.). Thoughts?

Btw, I still think that 'Edit category' is much more elegant than 'Edit Category'.

Read: I want it to read 'Edit category' (even if that means we have to use CSS for that).

I agree with Dries on that, but now we can do it all with CSS for menu items at least.

For form titles, I think Capitalizing Each Form Title Would Look Pretty Bad and think we could stick to the current scheme. In other words, it isn't as pressing to change all the form titles from 'Form title' to 'Form Title' since they look alright like that and are a little more consistent with the menu items (as opposed to the all lowercase menu items).

Hmmm...but something just came up. If we're going to use CSS to make 'Menu Item Link' turn into 'Menu item link' then we'd need to use the same CSS to perform that change of case to the breadcrumb, page title, etc. But what about breadcrumb titles, page titles that we don't want to go lowercase or that have Proper Nouns in them or acronyms like RSS?

D'oh! I misunderstood.

I agree that it should remain "Sentence capialization" for form fields and such. Only menu items and page titles (which are derived from menu items) should be "Proper Case Capitalized," imo.

But you're right about "RSS Aggregator"=> "Rss aggregator" with "sentence capitalization" CSS. I'm not aware of a great solution around this, apart from introducing some PHP logic. I guess we need to make a judgment call about which is harder to do... server-side logic to uncapitalize "the, and, a, for..." or server-side logic to keep capitalized "RSS, OPML..."

Zen's made the case for U.S. news sources using "Sentence type capitalization" and this is what Dries prefers, too. Grammar geeks cringe when they see it. I'm a grammar geek, but could go either way, since we have an international audience and "Sentence type capitalization" is used more often throughout the world.

But basically, we have to pick one. And people who want it a different way are going to have to do some work.

Or, we could just leave it all lowercase which ticks everyone off. ;)

Is much easier to use server-side logic to capitalize "RSS, OPML, etc" than to uncapitalize other words.

The reason is simple: the only words that will be fully capitalized are acronyms. So it is easy (and much more correct) if all acronyms within drupal would be inside an acronym tag, that would be styled as needed.

I agree that it should remain "Sentence capialization" for form fields and such. Only menu items and page titles (which are derived from menu items) should be "Proper Case Capitalized," imo.

For me, both menu titles and form titles should consistently use "Sentence capialization".

magico: Oh, good call! Then we could even just use CSS to capitalize those!

Dries: So that's your final answer? :) Ok, I'll try and go through later and re-work the patch to use sentence capitalization, if Shakur doesn't beat me to it. ;)

@webchick: So the final answer from Dries is "Sentence capitalization" for form titles and fieldset titles, but we are still sticking with "Proper Case Capitalized" for menu items. Just making sure that was clear. I think the bulk of this patch (if not all) is covering menu items so there shouldn't be much to change, right?

I'm an idiot, completely disregard my last comment.

Btw, we can't use <abbr> ... check_plain around menu titles. Nice idea anyway though. :)

@Dries, what's the word on hook_link()s? Should we change those to sentence as well? For example, "Add new comment", etc. so they are consistent?

I'm OK with updating links to, as long we add it to the guidelines and as long we use sentence capitalization.

hmmm i am bit confused now...
we can do hook_link etc in another patch...but what more is need for this patch to get in?

Shakur, we need to change all "Capitalized Menu Items" to "Capitalized menu items". I've already started this and will take another stab at finishing it later today if I can. I've already started doing the hook_link()s in the same patch as I'm just searching for 'title' => and it's easier. Should I separate them out you think?

If it's just a find/replace, go ahead and do them all in one go, imo.

Okay, here is the whole patch with "Sentence capitalization" for menu titles, links, etc. I think I got them all but would appreciate someone else's eyes on this.

The patch does no longer apply cleanly.
And shouldnt we wrap the content type menu titles (e.g. node.module line 1071/1129) in 'title' => drupal_ucfirst(t($type->name)) to make sure these titles fit into the capitalization schema?

Here is a re-rolled patch. Regarding content types, new content types will be renamed in their respective modules. This patch covers core content types though.

Can we get a higher up (i.e. Dries) to check this out? Should be what he requested above. Thanks!

Hold off, bad patch. Arg...gimme one sec.

Here we go.

Personally I think the "Sentence capitalization" for menu and page titles looks rather ugly. But it's better than lowercase :P.

The last patch was missing node and user module too. I fixed that.

Committed to HEAD.

Missed a few in node.module...

... some more in node.module and one in user.module ...

please document this in the upgrade guide - http://drupal.org/node/64279

Looks good.

Committed. Marking as 'code needs work' until this is documented. See Moshe's request.

Done at http://drupal.org/node/64279#sentence_capitalization.

Sorry about that re-roll, I thought the second one I put up re-included the node/user stuff. Oh, well! :P

One more minor thing, I don't think we should be doing a drupal_ucfirst() on the node type name. These types are now being defined in "Sentence capitalization" so they will come in correctly and don't need to be forced. This is documented in the aforementioned handbook page.

Too hasty as usual. Found another spot where there was a ucfirst but no t() around node type. Fixed that too.

Not sure about t() around node type name, but it was already there in the first spot so I just made it consistent. Should we remove those t()s?

I think this is when are using the internal node type identifier (e.g. forum) instead of the human-readable name "Forum topic". The $node->type should not be presented in the UI and never t()'d.

It seems to me this is because the module .info API is somewhat broken, as there is no easy way to retrieve a single info field for a module, without using module_rebuild_cache(). That's too heavy and potentially even destructive to call at random times IMO.

Okay, in that last patch I only have t() around the node type name, not the node type type so I think it's okay. Do you agree?

Some capitalization stuff got reverted in user.module. Here is a simlple patch to fix it.

Applies. 'Works' as intended -- no code change.

Added that 'page' and 'story' type names are capitalized in system_install()... it was only in the update_X() before.

Committed to CVS HEAD. Thanks.