Capitalize menu, link, etc. titles throughout core.

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

subscribing

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

(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?

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?

@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!

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' :

aggregator.module
block.module
blog.module
blogapi.module
book.module
comment.module
contact.module
drupal.module
filter.module
forum.module
help.module
legacy.module
locale.module
menu.module
node.module
system.module
watchdog.module

for convenience sake i have combined the patches submitted so far into one big patch...please review those.

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

path.module
ping.module
poll.module
profile.module
search.module
statistics.module
taxonomy.module
throttle.module
tracker.module
upload.module
user.module

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...

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

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

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.

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:-

    * configure permissions
    * Access Log Settings
    * Recent Hits
    * Top Pages
    * Top Referrers
    * Top Visitors
    * get help

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 :-

# Create Content
 * forum topic
 * page
 * Poll
 * story

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.

@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?

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".

@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.

@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?

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

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.