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

Comma should be Thousands separator #82

Open
wade-welles opened this issue Sep 7, 2019 · 3 comments
Open

Comma should be Thousands separator #82

wade-welles opened this issue Sep 7, 2019 · 3 comments

Comments

@wade-welles
Copy link

You already took the time to put English pluralization in its own folder, it seems to make it more possible to internationalize. So you should also move away from calling it commas for "Thousands Separator", because many countries use "." not comma. Basically it is flipped. You don't have to internationalize yet but it would be much more clear for an international audience if you used the term Thousands Separator over commas.

@dustin
Copy link
Owner

dustin commented Jun 10, 2020

What would the Comma* functions be called? How would you imagine the function signature should look? Should Indian-style formatting be considered?

@wade-welles
Copy link
Author

Sorry, I wrote a message for you earlier, but lost the window.

The Indian style is typically not considered necessary since many people who would require this style are familiar with English (UK) localization (and speak English).

Typically, I would use the term Format for the verb of applying them.

"The thousands separator (none, comma, dot, or space). The decimal separator (dot or comma)."

The two major thousands separators though divide major computer using parts of the world. And it is true that there was a time period that this was not considered important and so many people from these regions are able to read it, it does present issues; primarily because the fact that many people are providing proper localization support and so now new computer users are starting to expect it.

The difference can be compared to how US style of date MM/DD/YYYY can cause issues if you see the international method of DD/MM/YYYY; because some of the options are not invalid so it is not immediately obvious.

So to ensure the best support for use in UI libraries (which is what I would like to use this library for) it would be best to adopt a more international approach to ontological naming.

This is important because we work with developers working in multiple languages, just so it is clear that this does have a reason behind the preference, and its not just arbitrary. Comma separator has no meaning to people who unlike us did not grow up using it.

Hope this was helpful. Thanks for your work on this library by the way, I have quite a few potential additions for this version I can show you after I push m version live.

@wade-welles
Copy link
Author

If there is anything I can do to help, I would gladly do it. If you want to submit a pull request with my suggested changes, I would be happy to. I just don't want to step on any toes, or generate code that no one has interest in at least considering.

I'm working on a Go web-framework that is essentially Rails, from my long history with Rails, I can do more than just make on inspired by Rails like I have seen. And a library like this would not just help with that project, but work with essentially all my UI projects. And I would be more interested in contributing to a group effort, over rebuilding and constructing my own international focused version. But my requirements are internationalization from the start (as in not a afterthought), to satisfy my primary projects design requirements.

Let me know how you feel if you have time.

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

No branches or pull requests

2 participants