Thousands separator should default to nothing

Unfortunately, changing the defaults would actually require a custom handler just to do that, or some other changes to the handler to make it smarter. So it's not quite as easy as that.

That said it's not a bad idea to do this.

Changing to active task. Would need a developer interesting in writing this.

Would not be considered for 2.x, only 3.x.

Right now the 'active task' list is the best place. It's rather long. Every now and then I publicize it, hoping for some development, but the Drupal community is all quite busy.

Subscribing. I have this Problem on a production website using Views 6.x-2
I'll investigate that problem and hopefully can provide a possible fix.

i have this problem with using [tid] in the link path: taxonomy/term/[tid] for 'output this field as a link'

Here's a counter-proposal - why not default thousands separator to nothing?

Not all users are in the USA, which uses "," as a thousands separator. For example, "." and " " are valid separators; " " is recommended by the International Bureau of Weights and Measures.

The problem with the point and the comma as either decimal mark or digit group separator is that, internationally, they have both often been used for both meanings, and their meaning is context-dependent (one must know which notational system is being used in order to interpret them).

http://en.wikipedia.org/wiki/Decimal_mark#Digit_grouping

Additionally, operations that rely on an identifier - like a generated URL - are broken by this default when the ID exceeds 999 (root cause of carsonblack's issue).

As the controls already exist to manipulate the thousands separator, I feel that it should default to nothing, leaving the customization up to the user.

Arguably a bug, as it breaks ID fields.

I have a similar use case to #5, and agree with the proposal in #6 - seems like it would provide something for everybody.

From my perspective i would totally agree here, there should be no thousand seperator by default.
The only problem is that views doesn't allow you to change the default value without changing existing views.

If we choose to change the default value, all views which expects the thousand operator to be enabled will change.

> If we choose to change the default value, all views which expects the thousand operator to be enabled will change.

That's what change notifications are for -- tag it as 'affects site builders' :)

Also, don't default values get saved into the handler options array as soon as you save the view? Or has that been changed recently?

It seems this issue has been hibernating for a while but is actually still very active.

I have a situation where the output of an ID field is used to create an URL. This works great untill 999 but breaks at 1,000 because of the default thousand seperator.

The problem lies in the fact that in hook_views_default_views() the seperator for the field is set to ''. The default fallback to a komma kind of messes this up. Is there a way to enforce the empty seperator without editing the view on the production site?

It's possible this is a strongarm/features issue, but my views that have a numeric field seem to revert to the default separator regardless of what it was set to originally. I'm not 100% sure this is happening because of features, but to set the default in the Views code, I went into the views_handler_field_numeric class in the views_handler_field_numeric.inc file and changed the $options['separator'] default to ''.

a quiet +1 for default being 'nothing' - it is frequently tripping us up and while being a minor tweak to fix when it does become an issue, it 'feels' like the default should be 'leave integers as integers' and apply any fancy formatting (such as a comma) to the user to set. (note to self: Since it is often CiviCRM ID fields that trip us up then I may be able to flag a task to deal with it there at least for d8)

For whatever it's worth, I still agree with myself 3 years ago; it's a bad default.

After running into this for the Nth time in Views 7.x-3.x, I checked and the numeric field plugin for Views in Drupal 8 still defaults to comma as the thousands separator. This will still be an issue in D8 if people use numeric fields as tokens in generated URLs.

Can't agree more, we should certainly change that. Its super annoying actually, but i'm not sure whether it still happens in 8.0.x given that we use ordinary field formatters.

Interestingly, in Views 7.x-3.x if one selects the '-select-' option, then no thousands separator is used. That had me stumped for quite a while as I searched for the 'none' option and went down various form_alter-based rabbit holes.

So regardless of whether 'none' should be a default, it does appear to be possible to achieve. We could do with altering the text of the 'select' option though to better reflect what it does.

This is no longer an issue in D8, there the default is 'None' when adding an ID field.

Bumping back to the Views queue.

I want to share my experience which might help someone i.e

In my Drupal version 7.59 project, I have defined custom fields in hook_views_data() which are used when we create a VIEW.

My VIEW started displaying comma / thousand separator once my database table records exceed 999 value which means it was breaking up several things as correct ID can not be read due to comma in id values.

Initially I have defined my custom table ID field as something below in my_module.views.inc file i.e

// User ID table field.
$data['my_module_custom_table']['id'] = array(
'title' => t('Member ID'),
'help' => t('Member ID which is linked with users database table.'),
'relationship' => array(
'base' => 'custom_table', // The name of the table to join with.
'base field' => 'student_id', // The name of the field on the joined table.
'handler' => 'views_handler_relationship',
'label' => t('Default label for the relationship'),
'title' => t('Title shown when adding the relationship'),
'help' => t('More information on this relationship'),
),
'field' => array(
'handler' => 'views_handler_field_numeric',
'click sortable' => TRUE, // This is used by the table display plugin.
'float' => TRUE,
),
);

All I have done was to remove following line i.e 'handler' => 'views_handler_field_numeric' and can see comma issue resolved.

'field' type defaults to integer unless we define and in my case when I have removed defined field i.e views_handler_field_numeric, I can see comma has been removed and it works absolutely fine.