The thousand_separator for numeric fields should default to '' (nothing) instead of ' ' (space).

I would support this proposal. A space is definately not a good default. Empty string would certainly be better.

I support this also. I think in addition there needs to be a way to change the thousands separator via Drupal's web interface (perhaps under "Regional and language" configuration).

Upon further review, I see that there is (in theory, at least) a way to change the thousands separator, by going to admin/structure/types/manage/{content-type}/display. However, the thousands separator configuration doesn't actually work on my D7 site (version 7.8). However, even after changing the configuration I still get a space instead of a comma when I try to create formatted output by invoking:

field_view_field('node', $job, 'field_assignment_hours')

ok, will do

The patch no longer applies and needs to be rerolled. I'll take a look at it.

I think I dare RTBC this just from reading the patch. Thank you Zgear!

I am fine either way.

Makes sense to me, 1000 seems more common than 1 000. Committed/pushed to 8.x.

Sorry folks, this actually got committed with #1077566: Convert html.tpl.php to HTML5 in http://drupalcode.org/project/drupal.git/commit/67c299d

Hmm, might as well. It's a small change but there's a chance someone has a module overriding the default we'll no longer need or something.

Tagging.

Draft at http://drupal.org/node/1388376 - needs review.

#6, I couldn't actually find the thousand separator in the interface where expected. Possibly a bug, possibly just me?

Thanks, the change notice looks good to me. Maybe a followup issue for the other bit?

Just ran into Drupal 7, I think this is probably backportable.

Drupal 7 patch ported from thousand_separator-1275978-12.patch

I tested #25. It correctly changes the default thousands separator of the number field from a space to nothing. I added two fields, one before and one after the patch. The field display configurations are displayed in the images below.

I'm marking this as RTBC.

Is this sentence in the change notification correct?

Similarly if your site or theme relies on the separator being a space, you may need to adjust it after upgrading.

My impression is that it's not correct (and that changing the default will never affect any existing fields on the site because they will have already had their settings saved to the database). But I'm not sure if that's true under all circumstances.

If that sentence in the change notification is true, then I don't think we can backport this (at least not without an update function) since it would introduce inconsistencies on existing sites. If it's not true, seems like we can, but the change notification needs to be clarified?

Trivial grammar correction: moved a comma.

Great that @cck's patch still applies nicely. Would be great to know if this function could be backported. At this point it seems like it can't.

I really don't think that the sentence in the change record is correct. Like you said, existing fields should be pulling their settings from the database. I can't even imagine how an existing field would know about the change. If the default value were a config setting or something, then I could understand how it could happen, but it's not. It's a line in number_field_formatter_info().

For an existing field to get that setting, it would need to have a custom formatter that invokes hook_field_formatter_info() or calls number's implementation directly to find out what the default is. That seems kind of ludicrous.

I did test the patch just now on a site with an existing number field. The existing setting did not change after applying the setting. I realize we're more concerned that there might be some one-off case where the setting will change with the default, but I can't think of what that might be.

Committed to 7.x - thanks!

Yeah after some testing I don't see how this could affect existing fields, only new ones. So I'm going to remove that sentence from the change record and also mark the change record as affecting Drupal 7 too.

Change notice updated: https://www.drupal.org/node/1388376/revisions/view/7031047/8983337