Usability : unify "reply" and "add new comment"

I like the idea. +1

On our site, we renamed everything to "reply" for the same reason - on most forum systems there's very little differentiation between even the original forum topic (node in Drupal's case) and subsequent comments - either in the db or the ui. I'd strongly support using one word to apply to both "comments" and "replies" regardless of which gets chosen.

Either proposal would be better than what we have now. Consistent user interfaces are always easier to use.

I renamed them both to reply as well. TBH, I never knew there was a difference between replies and comments. I thought it was just a mistake in naming.

Michelle

OK here's a patch to change the two instances of "Add new comment" to "reply".

This inconsistency has annoyed me endlessly. +1 for consistency.

I haven't looked at this in situ, but should the "reply" in instances of this:

-                'title' => t('Add new comment'),
+                'title' => t('reply'),

be capitalized?

Otherwise, I'm all for this renaming.

keith.smith - I kept them lowercase to be consistent with 'reply' elsewhere (like on issue followups), personally I prefer those links lowercase. Either way it's trivial to change them with css text-transform or a single line in settings.php.

Shai:

OK a new (untested) patch which I think addresses most of your concerns. I dont' think we should remove the idea of 'comment' in general, just use 'reply' as a verb in the context of the comment form. This should catch most instances. If you could try again, see what happens on preview etc. that'd be great.

Shai: did you clear your cache after applying?

catch: I applied this patch, and after clearing my cache, everything looked good.

There is still a "Add new comment" line in comment.module though. Should this one be changed as well?

Sorry, that was in the first patch I posted, but I managed to leave it out of the last one.

Here's another, which really should get all of them.

Keith Smith reported in IRC an issue with preview/saves - I've fixed that in this patch so it ought to be good to go. Just needs a review.

I didn't get a chance to test this, but on visual inspection...

-            'title' => format_plural($all, '1 comment', '@count comments'),
+            'title' => format_plural($all, '1 reply', '@count comments'),

That should either be '@count replies', or should be '1 comment'. The way it is now, we're showing a different label when there is more than one than when there is only one comment, which is going to be confusing.

-              'title' => format_plural($new, '1 new comment', '@count new comments'),
+              'title' => format_plural($new, '1 reply', '@count new comments'),

Same thing here. If we keep reply, let's make sure the label is "1 new reply" because this string is different than the one above -- the new is important.

I kept them lowercase to be consistent with 'reply' elsewhere (like on issue followups), personally I prefer those links lowercase.

The only problem with this is all the other node links (for example "Printer-friendly page" and "Read more" are capitalized, so this one is going to look very odd. So I would capitalize it, and maybe move discussion to another issue over whether the lowercased delete/edit/reply on comments are a bug (seems like they are...).

Great work, folks!

Thanks for the review, webchick. I enabled book module and saw the oddness with the node links, agree with your assessment so have capitalised that. Also included the reply / replies omissions.

I quite like the lowercase links on comments - neater imo, but they need to be consistent (and are trivial to change in either direction anyway). There's going to be other incidences of this probably so agree with moving it into a new issue.

Doesn't fix everything mentioned in comment #18.

webernet, I'm assuming you mean the lowercase edit/delete links? If so I've capitalised these this time.

edit: ack wrong patch.

OK this should have all the changes, and also be the right patch this time, sorry.

The patch in #22 previews and saves comments correctly now. Yay!

Everything looked consistent to me, and I even scanned and grepped through comment.module and friends for other instances of things to change -- catch seems to have...well...caught them all.

I cannot adequately express my thoughts and opinions about how happy I am to no longer have to share my thoughts and opinions related to people's postings.

-              'attributes' => array('title' => t('Share your thoughts and opinions related to this posting.')),
+              'attributes' => array('title' => t('Reply to this post.')),

On the other hand, I worry that the solitary "Reply" is a bit too stark, at least on a page with no comments:

-              'title' => t('Add new comment'),
+              'title' => t('Reply'),

I have no solution for changing it right now though. "Add new reply" is a silly way of saying "Reply". "Reply?" seems more engaging but is out-of-line with the rest of the interface.

Given that this patch is consistent, works, and solves a very real UI problem with mixing terminology, and given that my grief with "Reply" is probably overblown, let's RTBC this.

I agree with

- uppercasing the comment links
- moving to "Preview" and "Save" from "Preview comment" and "Post comment"

However, I don't agree calling all comments replies. First of all this underlines the inconsistency in naming. Ie. these are called comments on the admin interface, in the module, etc. Also, if we have a news item or an image, a comment is rather 'opinion', 'note' or whatever, not a 'reply'. We reply to questions or opinions (sort of), not news items or images. Repeat this "14 replies posted to this news item" or "16 replies posted to this image".

How about going the other way, and standardising on "comment". And making it just "Comment", not "Add new comment" which is overly long.

The link title="" can always be "Add new comment" or "Reply to comment" to disambiguate.

I've split the Save and Preview changes over to #195678.

There's currently four issues dealing with this, here's the other three:
http://drupal.org/node/195161
http://drupal.org/node/169938
http://drupal.org/node/137100

Given that, I don't think it's going to be straightforward to patch all this behaviour in D6. I won't bump this to D7 yet in case someone else steps in, but it probably needs more thought and time than we have at this stage.

The attached patch attempts to go in the other direction -- renaming reply to comment.

Keith - renaming reply to comment looks good to me. However the split out Save/Preview patch at #195678 just got committed so this needs a re-roll.

Attached is a rerolled patch after the latest commits.

Does the double-titled "Comment" a problem for anyone when the comment submission form is set to display on a separate page (see attached screenshot). If so, we have a bit more work to do on this (although this may have been the old behavior, I haven't checked yet). Things look fine when the comment submission form is displayed below the post.

This would break the string freeze, so bumping to 7.x.

Patch no longer applied.

Hi,

This was a long thread, and I'm not sure, from reading all the back and forth, what was finally done, and if/when it will be commited.

Would it be possible for someone in the loop to summarize what exactly ended up in this patch? And will it ever end up in a 6.x release, or is it going to be 7.0 only? (This started as a thread about 6.0, but seems to have morphed to a 7.0 dev issue...)

-Daniel

You don't even need to read the whole thread:

#34: It breaks strings therefore it can't be in 6.x. It has to go in 7x.
#35: The patch doesn't apply anymore. Therefore someone has to re-roll it before it will even be considered.

Michelle

>> #34: It breaks strings therefore it can't be in 6.x. It has to go in 7x

34: I think this refers not to any strings breaking in a programmatic sense, but rather to the patch breaking the "string freeze", ie the prohibition of any changes that affect user visible text (I think this is in effect to prevent the need for changes in documentation and translations each time a patch is applied).

35: This is confusing--"Patch no longer applied" implies that it _was_ applied to the current code base, but is no longer. That may be the case, but it wouldn't invalidate individual use of the patch. In fact, nothing in the thread indicates that it doesn't work, just that it's not going to be applied to 6.x due to it's implicit changing of user-accessible text strings.

Although the patch represents a change to a core module (something I'm not keen on doing) I would use it on my site f it does indeed correct the cited issues with the comment modules comment labeling. (It's messy to catch all of it via theming the way it's implemented now.)

So...assuming I'm not totally mistaken and the patch is indeed viable, my big question, even after reading the thread (twice) is.....what exactly did make it into the patch?

--Daniel

can anyone answer daneyuleb's #38?

I'm unsure what "The patch doesn't apply anymore" means, too.

my guess is: "because the patch was compiled to make specific changes to the code of the D6.x Comment module; and because strings are now frozen for D6, therefore the language changes can only go into D7; but the relevant code, line numbers etc. should be presumed to be different in D7's version of Comment module, ergo the patch mechanics must be reviewed/corrected to convert ["re-roll"] the patch to D7 readiness." is that right?

cheers,

Adrian
Adrian Russell-Falla

1. breaking strings means breaking string freeze - more correctly it means breaking any translations which may have been completed during string freeze, which we try only to do if critical bugs come up that involve unavoidable changes.
2. Patch doesn't apply any more means that if you download the patch and try to apply it to your Drupal install, the code has changed enough that the 'patch' program won't be able to apply it properly. This happens quite a lot in Drupal since we frequently have changes which touch a lot of lines of code, and we always have a lot of pending patches.

Also in answer to #38, if you want to change strings on your own site, use the string overrides module to do so - this issue is about changing defaults on every Drupal 7 site, but individual sites can change strings to whatever they want via string overrides or locale module - no need to hack core for that.

Ran into this issue on a D6 site I'm working on: clicking "Add new comment" on a node takes me to a page entitled "Reply to comment". Reply to what? There may not even be any comments!

I'd not even noticed this behavior on d.o before - I guess it just shows that you pay that much more attention on your own site!

Also note that the "Reply to comment" text appears to be untranslateable: comment_menu() includes

  $items['comment/reply/%node'] = array(
    'title' => 'Reply to comment',
    'page callback' => 'comment_reply',
    'page arguments' => array(2),
...

which implies to be that this string at least could be fixed in 5.x, 6.x without breaking any translations?

Translations for menu items work differently with drupal 6 and the menu titles are not to be wrapped with a t().

Is think this is a duplicate of a recently fixed issue for Drupal 7: #307422: Usability: Make comment text consistent

Thanks for the update, and yes, stringoverrides can be used to work its magic on menu titles in 6.x.

Closing comments (due to spam)