Sometimes form titles are questions, and the it looks rather odd to have the form render with both the question mark and colon, for example:

How old are you?: *

We could do a simple check and only append the colon when no other punctuation is detected.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Crell’s picture

Agree with the concept, and the code looks good, but how does this tie into internationalization and translation? Punctuation marks are not consistent between languages.

Steven’s picture

(Quick note on drumm's request)
Approach taken by search module: extract all appropriate character classes from the Unicode Character Database and turn it into a preg /u regexp. Can be lengthy. I have a script for that lying around somewhere, will see if I can find it.

Needs unicode drupal_str function usage then too. Should the default character (the colon) be translatable as well?

killes@www.drop.org’s picture

I think the : should be translatable.

arthurf’s picture

Maybe I'm missing something, but can't the punctuation be dropped altogether? If the user has full control to name the field names, it seems like they should be able to add the punctuation as they see fit. This would also address the translation issue I believe.

coreb’s picture

Version: x.y.z » 6.x-dev

Moving out of the "x.y.z" queue to a real queue.

elv’s picture

As an example, in french we put a space before the colon. In fact we put a space before any "double" ponctuation sign (!?;:). So yes, a translatable sign may help in some languages.

Owen Barton’s picture

Status: Needs review » Needs work

I agree with arthurf here - there are so many possibilities this will need to cater for, with the plethora of punctuation symbols and languages, that the punctuation needs to be part of the field name.
That way it can always be set appropriately for the context of the fieldname and can also be translated out or added in if desired.

Steven’s picture

Having punctuation part of the field name just makes it look odd in some other cases. It is not a general solution either.

We already have a regexp for punctuation in search.module, you can reuse that.

RobRoy’s picture

Duplicate of a won't fix at http://drupal.org/node/24482. Guess we'll continue here, just wanted to reference that one.

Owen Barton’s picture

@Steven: I don't understand the problem of having the punctuation as part of the field name.

To me, the punctuation is semantically part of the field text, and should be kept with it. Separating it out will confuse translation, for example:
English: Does Maria speak Spanish?
Spanish: ¿Habla español María?
If the question mark is separate from the phrase then the spanish punctuation in the translation becomes unbalanced, with only a leading '¿', which is just messy! Other languages could have bigger problems, of course.

RobRoy’s picture

I guess the issue is, can all languages safely put field titles in affirmative form like the following? If the use case is so small, maybe people can just override their theme function if they really need this.

Habla español María: Sí o No

aaron’s picture

I agree that punctuation should be in control of the field name itself. Of course, that means that a large part of Drupal 6/7 would be fixing up 10,000 field names. Not sure it's worth it for people who know how to modify theme_form_element. But it would be a boon for developers wanting their sites to not look like 'Drupal out of the box'.

Owen Barton’s picture

I think it would be pretty easy to write a script to do the bulk of this for the field names and the translations (at least for the major European languages).

Gábor Hojtsy’s picture

If you put the colon into the fieldname, you will have it in the error message produced by the required form field check for example, which looks quite odd. t('%title: %required') as *was* in the before part of the patch makes the colon translateable to different languages. I would suggest breaking this issue apart to two: have a t('%title %required') when punctuation is in the %title, and having ('%title: %required') when the puctuation is not there. As Steven pointed out, the punctuation code could be reused.

Owen Barton’s picture

What about creating a format_separator() function, in the style of format_plural(). This would seem to be simpler that using t(), with the odd looking parameterization that Gabor notes, and allows for all the likely ways of formatting grammatical separators (such as the Spanish ¿Habla español María? example above).

The only potential difficulty I see is how to pass in the 'type' of separator to be localized - is it sufficient to pass in the English separator ':', '?' etc?

Pancho’s picture

Title: Only show the colon after a form title when no other punctuation is found » Show colon after form title only when there is no other punctuation
Category: feature » bug
Status: Needs work » Needs review
FileSize
1.3 KB

Double punctuation is a bug, not a feature request.
I don't think that we have to come up with a solution that covers all cases and languages. If there is a solution that improves rendering the form titles in some cases and doesn't do any harm in all the other cases, that'd be fine for D6.
Therefore Matt's original patch seems to be okay. As it didn't apply anymore, I rerolled it against D6 and cleaned up the code a bit.

GreenLED’s picture

Version: 7.x-dev » 6.x-dev
Assigned: Unassigned » matt westgate
Status: Needs review » Needs work

Ran the patch.

Before:
1. Created "Taxable?" vocabulary in taxonomy.
2. Clicked through to "/node/add/page"
3. Field appears as expected.

Taxable?:*

After:
1. Refreshed "/node/add/page"
2. Field correctly changed to...

Taxable?*

Everything looks like it's in order.
What needs to be done to get this
to committed? Is there anything
lacking?

» Respectfully, GreenLED
» Stable Files . net

Pancho’s picture

GreenLED: "Code needs review" is a stage closer to the final stage "Ready to be committed".
So if you didn't find any errors, please leave it at "Code needs review" or if you feel, that this is ready to be commited, move it forward to the final stage.

GreenLED’s picture

Status: Needs work » Reviewed & tested by the community

That was my intention. I did not notice the setting
in the form.

» Respectfully, GreenLED
» Stable Files . net

Gábor Hojtsy’s picture

Version: 6.x-dev » 7.x-dev
Status: Needs review » Needs work

Well, this just introduces confusion and inconsistency for several non-English users, as already pointed out by others. The three punctuation chars you listed is just a sample of the punctuation used in languages in which Drupal is used, so working differently with different punctuation would not be desired. A more complete solution in Drupal 7 would be great. Let's keep the discussion flowing.

Pancho’s picture

Assigned: matt westgate » Unassigned
Status: Needs work » Active

While I strongly disagree that the improvements of this this stop-gap-measure were not worth the inconsistency it introduces, I respect your decision.

As the stop-gap-patch in #16 is certainly not acceptable for D7, we need to start from the scratch and figure out how we can best solve this.

EmanueleQuinto’s picture

But what about simply theming the label so anyone can change the label itself? If I want to add a graphic arrow or simply remove (as below) the colon the only way is override the form_element in template.php:

function alky_form_element($element, $value) {
  // This is also used in the installer, pre-database setup.
  $t = get_t();

  $output = '<div class="form-item"';
  if (!empty($element['#id'])) {
    $output .= ' id="'. $element['#id'] .'-wrapper"';
  }
  $output .= ">\n";
  $required = !empty($element['#required']) ? '<span class="form-required" title="'. $t('This field is required.') .'">*</span>' : '';

  if (!empty($element['#title'])) {
    $title = $element['#title'];
    if (!empty($element['#id'])) {
      $output .= ' <label for="'. $element['#id'] .'">'. $t('!title !required', array('!title' => filter_xss_admin($title), '!required' => $required)) ."</label>\n";
    }
    else {
      $output .= ' <label>'. $t('!title !required', array('!title' => filter_xss_admin($title), '!required' => $required)) ."</label>\n";
    }
  }

  $output .= " $value\n";

  if (!empty($element['#description'])) {
    $output .= ' <div class="description">'. $element['#description'] ."</div>\n";
  }

  $output .= "</div>\n";

  return $output;
}

Note the only difference is the simple ":", 30 lines of code for a colon!

But if we simply have:

  if (!empty($element['#title'])) {
     $output = theme('label', $element);
  }

We can solve this issue.

Owen Barton’s picture

@EmanueleQuinto: I don't think that works, because the appropriate symbol in many cases will depend upon the grammar and language being used. Hence, any kind or theming or FAPI layer will not work IMHO, unless someone wants to write a multilingual grammar parser to figure out what the appropriate symbol should be in each case.

I think the best and simplest option is to just move the symbol (currently ':' in almost every case) into the translated string itself. This symbol can then be translated however is appropriate for the language itself (including cases such as ¿questions? in Spanish). Updating all the translations initially will take some clever scripting, but once we have done that the additional overhead of translating the additional symbol in these strings is really minimal, more than covered by the usability improvements of having correctly punctuated sentences in each language, without doubling up of symbols.

I'll try and put together a patch for this (and more importantly a script to make the changes, so we don't get caught up in clean-HEAD commit madness!) for people to review....

EmanueleQuinto’s picture

I know it's at this point a different issue, but using a theme function with your patch moved there will allows developers complete flexibility configuring the visualization of the semantic value (the label itself) i.e. form_element process the logic and theme_label the presentation. Two for the price of one...

If someone would try to create a multilingual parser...

Owen Barton’s picture

Status: Active » Needs review
FileSize
5.14 KB

OK, here is a very basic patch - just for node module for now, we can polish this off once we have some consensus. We take the hardcoded ':' out of the theme_form_item, and put it into each t() string. This allows you to use alternate puntuation without causing duplicates, and also translate each sentence with punctuation included (even for sentences where you need punctuation at the front of the sentence, or you need to change a 'statement' into a question for it to read right in that language).

Here are the regex used (just in my editor for now), we would need to add a conditional to avoid fieldset form items (and perhaps others), but this basically does the trick. We would want to save some kind of list on the original strings, and then use that to automatically add 'starter' colons to each translation po/pot file (or the translation database?), so translators don't need to find and fix each string individually.

'#title' => t\('([^']*)'\)
'#title' => t\('$1:'\)

Note that I haven't done the 'Title' and 'Body' labels for now, since those needed a little more work/discussion (i.e. do we want to translate them later on in the flow, and add the colon in just before the configured string is sent to t(), or should the colon be added to the default strings at the UI level, so that people see 'Title:' when editing?).

danielb’s picture

Version: 6.x-dev » 7.x-dev
Assigned: matt westgate » Unassigned
Status: Reviewed & tested by the community » Needs review

It would be good to get a span tag with a class around the themed punctuation too please

and to remove default colon when someone types their own colon

cdale’s picture

This would be a very useful feature to have. I have an alternative implementation that might be easier to implement and use than the translatable and theme options, that shifts control to the form creator, rather than the themer, or the end user, but should still allow an end user to alter it via the use of t() if they so desire.

I propose the addition of a new FAPI element, #title_terminal. This would default to the colon, and as such, would not alter any of the exsiting forms code currently used, however, it would make it possible where the form is created to either change the value, or remove it all together.

I've attached a preliminary patch against the latest HEAD and given a possible example of how this might be used to remove the colon. Or, change it to something else entirely. At present, the patch passes the string though check_plain (via t()), I wasn't sure on opinions of allowing html tags in the terminal for possible extra theming. I felt allowing plain text only would be sufficient, but I could be wrong.

$form['element2'] = array(
  '#type' => 'textfield',
  '#default_value' => 'VALUE',
  '#title' => t('Textfield type'),
  '#title_terminal' => '',
);

I'd love to know what people think of this, or if I'm just being silly. :)

cdale’s picture

Anonymous’s picture

Status: Needs review » Needs work

The last submitted patch failed testing.

Xano’s picture

I suggest we simply stop adding the colon in FAPI and let developers add punctuation themselves. This allows the code to be as simple and fast as possible and to give as much control to developers and translators as possible. If we do this, we should add a rule to the coding standards that it is advised to end all labels with some form of punctuation.

yoroy’s picture

I'm in favor of not adding the colon (as the default). It is not a must to have them and it prevents us from using more natural language for forms.

Have a look at the signup form for yahoo for example:

It's friendly, clear and has flow, whereas every colon is one more tiny little pause, breaking the flow. There are enough examples of the colon making things more difficult in the comments above. Instead of trying to juggle all kinds of checks for adding the colon, let's do what core should do and provide the sanest possible default: no colon.

Gábor Hojtsy’s picture

FileSize
1.15 KB

I think the reason we have the colon automatically added is to have more consistency in forms. I've rolled a patch to remove the colon (but not to add it to all form labels). Adding it to form labels makes error messages on required fields include the colon as well, which would be bad [TM] (see my comment in #14). Question is whether Drupal forms look good without the colon added.

yoroy’s picture

Status: Needs work » Needs review

what say you, testbot?

Status: Needs review » Needs work

The last submitted patch failed testing.

catch’s picture

Status: Needs work » Needs review

If this doesn't mean going through hundreds of form labels and adding the colon back manually (which I think it probably won't once our eyes adjust), let's do it like this.

catch’s picture

Fixed test failure.

Dries’s picture

It might be personal taste but I like the titles better with a colon. It provides some extra guidance.

I'm worried that, if we drop the colon, a lot of people will start to mix : and ? and no colon at all.

Though call. I'll have to think about it a bit more -- feel free to chime in.

Xano’s picture

I say drop the punctuation. If necessary, it needs to be added to the string.

JohnAlbin’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
17.75 KB

I'm worried that, if we drop the colon, a lot of people will start to mix : and ? and no colon at all.

Adding the colon per label would screw up the required field validation error messages as Gábor said in #32. So if we remove colons from Drupal forms by default, we should not be adding them back in at all. So it would be a mixture of no colon and natural language punctuation like ?.

For example, I prefer the admin/user/settings page without colons. And "no colons" on other forms look fine to me too.

Comparison of admin/user/settings page before and after patch

webchick’s picture

Status: Reviewed & tested by the community » Needs review

Hm. That particular screenshot makes the grammar freak in me scream because one has punctuation and the other doesn't.

The typical game I play in a situation like this is "What does the Internet do?"

Colons
Google: https://www.google.com/accounts/NewAccount (Though Google Calendar uses no punctuation)
Facebook: http://www.facebook.com/
Amazon: https://www.amazon.com/gp/sign-in.html (though you'd never know it because that original form is a horrible Frankenstein mix of ?, :, and no punctuation)
Survey Monkey: https://www.surveymonkey.com/MyAccount_Join.aspx (though once you get in there I'm not sure what they let you do on their form)

No punctuation
Yahoo: https://edit.yahoo.com/registration
WordPress: http://en.wordpress.com/signup/ (well. on this form. their login block uses colons)

Even though colons win, I'm wondering if we're probably better off not to force anything, so that people can do whatever they want. Certainly the ? at the end is a common use case. It's also possible that in other languages they want to end their form selections with a ÷ or something.

Because this needs more discussion, per Dries, it's not RTBC yet.

yoroy’s picture

This was recently discussed on ixda.org (Interaction Design Association): http://www.ixda.org/discuss.php?post=38531 with references to this: http://www.usabilitynews.com/news/article3112.asp and http://www.usabilitynews.com/news/article3200.asp

To summarize http://www.usabilitynews.com/news/article3112.asp:

The fact is that in over 15 years of testing all sorts of forms – paper, web, application, you name it – NEVER ONCE has any user commented on the presence or absence of colons. They don’t notice them. They don’t care.

http://www.usabilitynews.com/news/article3200.asp investigates the use of the colon in context of screen readers:

So I contacted Ginny Redish (www.redish.net) who has done a lot of usability testing with blind and partially sighted people. Many of them use JAWS, the most popular screen-reader in the USA. She replied:

'I have watched people using a screen-reader on forms, but I do not recall whether the forms had colons on the screen or what the tags for the fields said.' (Same experience as mine.)

She went on to explain that when working through forms, users prefer to remain in the ‘edit’ mode of the screen-reader, where it interprets key presses as entries for the field and moves from field to field according to whatever it finds tagged as labels. The crucial point, therefore, is the tagging – as mentioned in the other articles. Whether or not you include a colon in the tag will not make any difference.

http://www.ixda.org/discuss.php?post=38531 goes back and forth on the issue, but most advise to leave it out:

Every element on a screen is visual noise. Less noise means less information the brain has to process (it's called cognitive load).

The best resource I have seen of late is from the iPhone User Interface Design video. In this video, the UX guy from Apple says in plain english that colons are unnecessary in the UI for any platform. You will need an Apple ID to access the video in iTunes.

And the extra hassle for internationalisation is mentioned too there. You'll also find references to Luke Wroblewski's book "Web Form design, filling in the blanks" (http://www.lukew.com/resources/web_form_design.asp) which is the best book available on the topic. It doesn't discuss using colons or not (more reason to believe that users don't care). But. Luke W. is Senior Principal Designer at Yahoo! The same yahoo that doesn't use colons on their signup form :-)

So.

If users don't care, internationalisation is a big concern and we want room to use more natural language in our labels (like simple questions etc.) then we should remove the colon. And not add it back in anywhere.

yoroy’s picture

Status: Needs review » Reviewed & tested by the community

So, RTBC me thinks

danielb’s picture

Good job yoroy, I am happy the research supports a no colon approach. The point made in post #39 though about the validation/error messages if someone did put in a colon via an interface is a good point, and perhaps such interfaces should have an extra field for suffixing the label which is then inserted via the theme, not via fapi arrays. Unless there is support for something like #label_prefix and #label_suffix.

sun’s picture

I'm very concerned about this patch.
But not eager to apply it.
I always liked those colons for consistency, and bashed on non-Drupal stuff that doesn't use them.
But the research and reasoning makes sense, too.

Recommendation:

Let's test it, temporarily or permanently in HEAD.

There is sufficient time and the patch is sufficiently small to revert, if we happen to face unforeseen issues.

webchick’s picture

Well, I find it difficult to argue with yoroy's reasoning. Dries, what do you think?

Dries’s picture

Status: Reviewed & tested by the community » Fixed

yoroy's research results are convincing indeed. I decided to commit this patch. Thanks!

sun’s picture

Would it make sense to add a "unsure" (or similar) tag for issues like this for later QA & reconsideration?

Most probably it will be re-opened anyway if someone finds an issue with it. However, in either case, it might be worth to look at such issues once more with a fresh pair of eyes before releasing.

jrabeemer’s picture

+1 for leaning more on removal

IMO, less is more. I agree colons add "noise". It also looks awkward after end punctuation.

Traditionally, they make sense on labels that are immediately to the left of form fields. You see this in the Mac control panel.

The purpose is to visually delimit and associate a label to some kind of form input. It says, "After this colon, provide some information."

Ultimately the question is, in its absence, does it cause confusion? I think another usability session would provide some insight.

Though, I think most people will not notice.

webchick’s picture

Issue tags: +revisit before beta

@sun: How about this?

Status: Fixed » Closed (fixed)
Issue tags: -revisit before beta

Automatically closed -- issue fixed for 2 weeks with no activity.

Status: Closed (fixed) » Needs review

slsawhney requested that failed test be re-tested.

Status: Needs review » Needs work
Issue tags: +revisit before beta

The last submitted patch failed testing.

webchick’s picture

Status: Needs work » Closed (fixed)

This issue was fixed long ago. Re-closing.

tormi’s picture

I just killed the kitten. Any chance to backport #36 to D6?

JohnAlbin’s picture

@tormi, nope. But you can remove the colons by overriding theme_form_element() in your theme. That's the kitten-resurecting fix I use all the time in D6.

schampion’s picture

An alternative solution: Instead of trying to remove the colon from the prompt, you could use #prefix instead of #title for your form fields. It does lose some other functionality (eg the prompt isn't wrapped in a label tag and doesn't get the asterisk for required), but it may solve the problem for some people better than overriding the whole of theme_form_element(), especially if you only need to do it for one or two specific fields.