Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

point_count_abbreviated is specific to English #110

Closed
1ec5 opened this issue Nov 26, 2018 · 3 comments
Closed

point_count_abbreviated is specific to English #110

1ec5 opened this issue Nov 26, 2018 · 3 comments

Comments

@1ec5
Copy link

1ec5 commented Nov 26, 2018

The point_count_abbreviated property is set to a string that abbreviates “thousands” as “k”. This convention is specific to English, whereas lots of languages have very different conventions for abbreviating thousands, sometimes depending on plurality.

supercluster/index.js

Lines 321 to 323 in cd687ab

const abbrev =
count >= 10000 ? `${Math.round(count / 1000) }k` :
count >= 1000 ? `${Math.round(count / 100) / 10 }k` : count;

This library should either have built-in support for abbreviating based on CLDR rules or allow the developer to customize the format.

/cc @mourner @kkaefer @julianrex

@mourner
Copy link
Member

mourner commented Nov 27, 2018

The property was introduced before we implemented expessions in GL, so I'm only leaving it there for legacy compatibility reasons — I don't think we should introduce any customization options for it because you can do the same more flexibly with expressions (edit: if it's not flexible enough, I'd rather push for a proper format expression than build upon an outdated concept).

@julianrex
Copy link

Given that this is here for legacy reasons - I'm tempted to remove it from the iOS/macOS PR. Any reasons why it should stay?

@1ec5
Copy link
Author

1ec5 commented Nov 30, 2018

The property was introduced before we implemented expessions in GL, so I'm only leaving it there for legacy compatibility reasons

Cool, that makes sense. It certainly is possible to implement the same functionality using expressions today: mapbox/mapbox-gl-native#12952 (comment). For mapbox/mapbox-gl-native#12952, I think we should omit the constant but continue to document the property as a legacy attribute in mapbox/mapbox-gl-native#12952 (comment).

if it's not flexible enough, I'd rather push for a proper format expression than build upon an outdated concept

I agree, mapbox/mapbox-gl-js#4119 would be the most correct solution for formatting these numbers, and it would benefit styling needs beyond clustering as well. Until then, we should document the expression from mapbox/mapbox-gl-native#12952 (comment) somewhere in the iOS/macOS map SDK’s headers or guides.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants