Complete text strings overhaul

+1 for this

I think that "Administration Menu" shouldn't be considered a proper noun in text strings. Instead it should be considered a substantive and be capitalized as normal - "administration menu". This is the behavior of all core modules and would bring much more consistency to the whole interface, which is a good thing.

I am willing to write a patch if the community agrees to this.

Go ahead, please :)

If we intend to break translated strings, let's break them completely.

I need several thorough reviews of all strings that are output. Attached patch updates most of them to the latest standards. There's room for improvements for sure, so please don't hesitate to comment (even nitpicky things). However, please be precise in what needs to be changed (i.e. line no., old wording, new wording, aso.).

I suggest some changes.

• Separation of URL and translation string.

>  +      $output .= t('The menu also can display the number of anonymous and authenticated users, <a href="http://drupal.org/project/devel">Devel module</a> links, and items generated by other modules.');

+      $output .= t('The menu also can display the number of anonymous and authenticated users, <a href="@devel-module">Devel module</a> links, and items generated by other modules.', array('@devel-module' => 'http://drupal.org/project/devel'));

>  +      $output .= t('Please bear in mind that the displayed menu items in the administration menu  depend on the actual permissions of a user. For example, if a user does not have the permission "@permission-access" and "@permission-users", the whole "@user-management" menu item will not be displayed.', array('@permission-access' => 'administer access control', '@permission-users' => 'administer users', '@user-management' => 'User management'));

+      $output .= t('Please bear in mind that the displayed menu items in the administration menu  depend on the actual permissions of a user. For example, if a user does not have the permission "@permission-access" and "@permission-users", the whole "@user-management" menu item will not be displayed.', array('@permission-access' => t('administer permissions'), '@permission-users' => t('administer users'), '@user-management' => t('User management')));

@Takafumi: This is already included in the latest patch.

Any native English-speakers here?

#314410: Module's project page and .info file do not match has been marked as duplicate of this issue.

We've decided in IRC to rename "Drupal Administration Menu" in all places to "Administration menu", resp. "administration menu", depending on the surrounding phrase.

I just started using this module today (and, may I say, where has this been all my life?).

I've got some ideas on many of these strings, and will go through them all tomorrow with the goal of producing a patch.

Here's a first blush attempt at this.

Oww nice! If no one has objections, I'll probably commit this as is.

Hm.

Let me come out as someone fully in support of consistency and standards. I strongly agree with the philosophy behind keeping with core's "Sentence capitalization" standard.

However, I find reading these sentences a little... jarring.

My eye goes "tum te tum te tum te tum... OH! BIG LETTER. Something important? Wait. No. Hm. Why was Administration suddenly capitalized? Is it a Really Big Deal? OH! I get it. It's the module name. Hm. OK. tum te tum te tum... OH! BIG LETTER. Something important?" Repeat each time. ;)

So in the interest of preserving some sort of consistency, I would suggest the following:
* In menu items, field labels, etc. and other short strings, particularly those dealing with settings for the module itself, use the proper Drupal "Sentence capitalization" of the module.

In other words, +1 to hunks like this:

-    'title' => 'Administration Menu',
-    'description' => 'Adjust settings for the dropdown Administration Menu.',
+    'title' => 'Administration menu',
+    'description' => 'Adjust Administration menu settings.'

However, in other user-facing text, particularly in long, drawn out sentences, I think it would be better to just call it an "administration menu."

In other words, -1 to hunks like this:

-      'description' => t('Access the administration menu, which appears at the top of the page.'),
+      'description' => t('Display the Administration menu at the top of each page.'),

I could just be more sensitive to this because we ran into it a lot with the book. Not sure.

Or, maybe more simply stated, if there's a "the" before it, make it lowercase, because you're talking about the *output* of the module. If it's about the module itself, then make it sentence capitalized.

Reviewing rest of the strings now, but overall this looks great.

Ok, here's a more thorough review. Thanks for your help with the block tests tonight, sun! :D

There are a few words that are non-hyphenated which I would personally make hyphenated; for example 'rebuilt' and 'dropdown.' But I defer to Keith on this.

+    '#description' => t('If enabled, fieldsets on the <a href="!modules-url">modules</a> page are collapsed automatically when loading the page.', array('!modules-url' => url('admin/build/modules'))),

This might be slightly out of scope, but could we add a sentence here explaining the rationale of this feature? Why would someone want to turn this feature on?

+    '#description' => t('If enabled, all menu items are displayed regardless of your site permissions. <em>Note: This debugging option should bot be enabled on production sites.</em>'),

bot => not

- ... '@permission-access' => 'administer access control', '@permission-users' => 'administer users',

I am by no means a translator. However, doesn't it make sense for these to be placeholders, since permission names aren't translated in the permission interface? Or am I totally on crack?

Since the appearance of Administrative menu is dependent on your site theme, substantial customizations require modifications to your site\'s theme and CSS files.

is it site theme or site's theme? they should both be the same.

Oh, one last thing... is

roles with the <em>Access administration menu</em> (admin_menu module) permission.

a standard employed anywhere? If not, and we're trying to establish one here, maybe we should think a bit more about what it should be.

Angie, honestly, you identified every issue where I had a debate with myself. I really should have detailed some of these things when I posted the patch, but I was tired by then.

• On capitalization of the module name, I agree with the suggestions and will try to go back through these again. There's no doubt it looks very odd to have "blah blah blah Administration menu blah blah blah". "blah blah blah Administration Menu blah blah blah" actually looks better to me in that situation, but it's not consistent with core. This problem becomes especially problematic when you talk about something like "blah blah Administration menu's settings page blah blah" because then the lowercase menu does not look like it can support the apostrophe.
• On core help pages we don't capitalize anything, so we could do that. We talk about "The path module blah blah" and "The aggregator module blah blah". So, to be consistent we should probably do that, but use sentence capitalization otherwise. A second option would be to italicize Administration menu so that it is obvious it is a "thing". This is the approach we took in the content type descriptions.
• I think rebuilt and dropdown are ok. The general rule these days is that if the word actually appears in a dictionary (and who knew "dropdown" did), then you don't hyphenate. I am not entirely consistent on this, but I'm trying to do better.
• These permission things are somewhat problematic. They definitely should appear in italics, in the exact form they appear on the Permissions screen, but... unless you search for the string they can be hard to find, especially when we're talking about strings provided by multiple modules (here, admin_menu, system, user). That's why I added the module name/header text behind the permission in parenthesis. I don't really like that, and this reminds me to go look for an existing issue (or create one) to perhaps do something different with that header line on the permissions page.

thanks for the reviews, everybody!

New patch.

This one uses the core standard of seldom capitalizing module names at all in help unless they involve an acronym (like "Blog API"). And, in a lot of instances, I either reworded the sentence to avoid the issue, or just referred to the "menu" since the user is on a page clearly about Administration menu. I think this most closely follows the standard set by core, but I can certainly be convinced otherwise. Upon reflection, an exception we have to this rule is in the "For more help" at the end of the embedded documentation for each module. I think I added the line at http://drupal.org/node/24566 that specifies this should be a capital letter (which indeed it is in Drupal 6 and on). There's not one of those lines in this help, though possibly there should be (though what should it link to? The project page?)

This patch adds the README.txt changes (and I'll close the other issue); it was just a pain to futz around with my workspace to keep these separate.

There were at least one or two instances (and one that Angie quoted but did not mention) that referred to "Administrative menu" rather than "Administration menu". I've hopefully found all those and made them consistent.

I've not done anything with the placeholder-for-permission-string issue. I'll see if I can find goba to ask, but I don't think we made them placeholders in core help text (but could be wrong).

Hmm. I accidentally forgot about this patch. It still seems to apply, so I thought I would bump it up.

No, sorry, my fault - had a busy week :-/

I promise to have a look at this and commit it this weekend. I was already happy in #13 - now that you reviewed and worked on this even more, this should be ready to go. :)

Ok, first of all, the new strings are awesome!

However, I've done a technical review now and found some things that do not sound correct to me: (but that could also be limited to me ;)
Note: First line is of previous patch, second my suggested change.

-    '#description' => t('If enabled, site output is shifted down approximately 20 pixels from the top of the viewport to display the administration menu. If disabled, absolute- or fixed-position page elements may sometimes display over the administration menu.'),
+    '#description' => t('If enabled, the site output is shifted down approximately 20 pixels from the top of the viewport to display the administration menu. If disabled, absolute- or fixed-positioned page elements may be displayed below the administration menu sometimes.'),

Actually, I think the previous wording that used "covered by the menu" is visually and technically more correct. But it is pretty hard to express this correctly in a comprehensive way...

-    $form['tweaks']['admin_menu_tweak_modules']['#description'] .= '<br /><strong>'. t('If the utility module was installed for this purpose, it can be safely disabled and uninstalled.') .'</strong>';
+    $form['tweaks']['admin_menu_tweak_modules']['#description'] .= '<br /><strong>'. t('If the Utility module was installed for this purpose, it can be safely disabled and uninstalled.') .'</strong>';

http://drupal.org/project/util is called "Utility" and thus should be a proper noun here, no?

I have committed the rest of this patch with slight fixes already (some lines did not wrap at 80 chars in README.txt, aso.), so we only need to deal with the remaining strings above now.

-    '#description' => t('If enabled, the output of this site will be shifted for approx. 20 pixels from the top of the viewport to make room for the Administration Menu. If this setting is disabled, some absolute or fixed positioned page elements at the top of the viewport may be covered by Administration Menu.'),
+    '#description' => t('If enabled, the site output is shifted down approximately 20 pixels from the top of the viewport to display the administration menu. If disabled, absolute- or fixed-positioned page elements may be displayed below the administration menu sometimes.'),

How about, instead, we do:

+    '#description' => t('If enabled, the site output is shifted down approximately 20 pixels from the top of the viewport to display the administration menu. If disabled, some absolute- or fixed-positioned page elements may be covered by the administration menu.'),

Is that accurate?

-    $form['tweaks']['admin_menu_tweak_modules']['#description'] .= '<br /><strong>'. t('If you installed Utility module for this purpose, you can safely uninstall it now!') .'</strong>';
+    $form['tweaks']['admin_menu_tweak_modules']['#description'] .= '<br /><strong>'. t('If the Utility module was installed for this purpose, it can be safely disabled and uninstalled.') .'</strong>';

This change looks good.

Thanks!

@all: It's time to update all translations!