Comments (18)
@BenjaminVanRyseghem I would like to helping with this issue. But I think OP is not how a large numeric should be display.
Let's see what it should be look like:
Powers of 10 | Number | English | Japanese |
---|---|---|---|
1 | 10 | 10 | 10 |
2 | 100 | 100 | 100 |
3 | 1,000 | 1k | 1,000 |
4 | 10,000 | 10k | 1δΈ |
5 | 100,000 | 100k | 10δΈ |
6 | 1,000,000 | 1m | 100δΈ |
7 | 10,000,000 | 10m | 1,000δΈ |
8 | 100,000,000 | 100m | 1ε |
9 | 1,000,000,000 | 1b | 10ε |
10 | 100,000,000,000 | 100b | 100ε |
12 | 1,000,000,000,000 | 1tr | 1ε |
This is more reasonable and I think is easier to implement. Since the only different of these two system is how we separate large number (that means, >= 1,000), the problem of "ηΎ" or "1ηΎ" doesn't exist. Japanese numeric system (which is the same as Chinese), are based on 10^4, while western system are based on 10^3.
I have found this web page might help: https://www.trussel.com/jnumbers.htm
When the OP mentions we should write "100" as "ηΎ", it just like saying we should write "1 hundred" in English, doesn't make sense. Because it is how we read the number, not how we write them.
from numbro.
Please correct me if I'm wrong, seeing as you're the one living in Japan and my Japanese is rusty from lack-of-use.
Shouldn't "1ηΎ" simply be "ηΎ"? In similar fashion, wouldn't 10δΈ be εδΈ? While I'm sure both are understandable I'm thinking "ζ£γγζζ³"
Per the "languages" section of the website I think letting languages define their own formatting is the better idea.
from numbro.
@kyokou Thank you very much for comment!
Yes - both are correct and commonly used here, depending on the context.
To sum up, there are three systems:
- Arabic numerals => 10,000 100,000
- Arabic numerals + kanji (ideographs) => 1δΈ 10δΈ
- Kanji only => δΈδΈ εδΈ
As you mentioned, one thousand is an exception - you can ommit number in front of kanji (εγ= οΌε). It's similar to "one hundred" and "a hundred" in English.
Particularly, second system is commonly used for counting big amount of money.
So "two hundred twenty million yen" becomes "2ε2εδΈε".
But reading your comment and thinking about that more deeply, made me think that if a language has more than one numeral systems, user should be able to switch between them.
For example:
// Standard usage
numbro(100000).format('$0,0'); // Β₯100,000
numbro(100000).format('0a$'); // 10δΈε <- currency symbol has to be different!
// Selecting numeral system
numbro(100000).format('0a$', 1); // εδΈε
In above case, second argument is an index of selected numeral system (defined in language configuration file), but not sure if it's good idea though.
Any ideas?
from numbro.
Thanks for the info! I've never actually seen the second system used. It's still logical and easy to follow though, so I'm not too surprised it exists.
As for the different formatting for individual languages - I'm not sure the best way to go about that. I think it is relatively uncommon for languages to have multiple ways of writing. For completeness it would be best to add them, but it should be planned and thought out in a maintainable fashion.
Your solution seems like it would work fine - so long as it is standardized.
For example:
[0] - Native (δΈγδΊγδΈγεοΌ
[1] - Arabic Numerals (1, 2, 3, 4)
[2] - Hybrid/Other, if applicable (1ηΎγ1ε)
from numbro.
I am not a big fan of magic index referring to hidden things πΈ
So if we go in this direction (I am still not convinced as I am still not sure I understand everything), maybe introducing special function per language would be better
I do not know Japanese at all, so I will try to summarize what I understand, please correct me if I am wrong.
-
there is a native way to write currency in Japanese, where everything is in kanji.
To me, it sounds like the english equivalent would be something liketwo kβ¬
(I use euro as it's postfixed) -
there is a half-arabic/half-japanese way, which english equivalent would be:
2 kβ¬
Am I right? π
from numbro.
Your example is correct. I'm assuming the "k" is shorthand for "thousand"?
Native: two thousand β¬ // equal to δΊεε
Arabic: 2,000 β¬ // equal to Β₯2,000
Hybrid: 2 thousand β¬ // equal to 2εε
"Native" probably isn't the best way to describe it, since all of the above are natively used... was just the most accurate word I could think of.
Magic index referring to hidden things could be standardized and documented to not make it so hidden or magical. My only issue with magic index referring to hidden things is when it isn't documented; but I can see why you would be against it.
We could make the index less magical by passing a string as the second param instead of an index value.
numeral(100000).format('$0,0', "arabic"); // Β₯100,000
numeral(100000).format('0a$', "hybrid"); // 10δΈε <- currency symbol has to be different!
numeral(100000).format('0a$', "native"); // εδΈε
from numbro.
Thanks for the clarifications π (indeed, the k
stood for kilo
)
Could you please explain why the currency symbol has to be different?
If for all other languages we use something like 2 kβ¬
why not using a similar approach here and use 2δΈε
?
Is Β₯2k
completely weird?
(sorry for all the questions, but I try to have a clear understanding of the situation πΈ )
from numbro.
The rules are a little complex. Without trying to get too specific into nuance and semantics, this is the easiest way I can sum it up:
ε can be used anywhere, including price tags
Β₯ can only be used for prices/value
If the number uses kanji, ε must be used over Β₯.
Β₯100 // OK
100ε // Also OK
ηΎε // OK
Β₯ηΎ // NOT OK (or at least, I've never ever ever seen this)
When to use ε depends on context. When writing vertically, kanji + ε is preferred over the other forms. Same with formal/old documents/literature. There are more scenarios as well and not all of them are "hard rules, must do this or it's wrong".
It's kind of hard to explain since I'm not 100% familiar with all scenarios/contexts or without a mini-Japanese lesson in formality and counters.
@lukaszkrawczyk
If I'm wrong about Β₯ηΎ, let me know. I'd love to learn more! I've not once seen this (although after you mentioned it, I have seen the "hybrid" style for populations of cities and a few other large numbers)
from numbro.
Thanks for the explanations once again π
my proposal for currencies (which is in fact not the point of this issue πΈ maybe it should be moved in a separate issue):
- we keep the currency symbol: $, β¬, or Β₯. We use this symbol when there is no average, therefor the abbreviations or not used (and we are sure not to mix symbol with kanjis)
- we introduce a
translatedSymbol
(or we can find a better name): ε. We use this symbol when average is used, so we are sure to have a consistent translated text. Of course, if this symbol is not defined, we fallback tocurrencySymbol
What do you guys think about that?
from numbro.
@kyokou Yes, everything is correct. I couldn't explain it better ;)
@BenjaminVanRyseghem , are you OK with @kyokou 's solution?
If yes, I will modify code, write some test, add examples and send a PR during next week.
On the other hand, I've been thinkning about publishing separate library to deal with this problem.
A kind of plug-in to numbro library, where user could define custom formatting function and so on.
I'll think about that little more.
Regarding issues with currency, let's move your proposal to different issue.
Because I've got several ideas how we could improve currency formatting as well. π
from numbro.
@lukaszkrawczyk I am not sure we agreed on a solution yet π and to be honest, I am still not super convinced about the introduction of a new argument.
But we can continue to discuss it πΈ
edit: after reading again the thread, I am not sure we are talking about the same things π
from numbro.
@lukaszkrawczyk I would rather push things directly into numbro instead of having another layer of external dependencies, don't you think?
from numbro.
@BenjaminVanRyseghem
I think he's talking about my "pass a string as second argument" instead of "have a magical index as second argument" solution.
EG:
numeral(100000).format('$0,0', "arabic"); // Β₯100,000
numeral(100000).format('$0,0'); // also Β₯100,000
numeral(100000).format('0a$', "hybrid"); // 10δΈε <- currency symbol has to be different!
numeral(100000).format('0a$', "native"); // εδΈε
Without solving the currency issue and leaving just the number:
numeral(100000).format('0,0', "arabic"); // 100,000
numeral(100000).format('0,0'); // also 100,000
numeral(100000).format('0a', "hybrid"); // 10δΈ
numeral(100000).format('0a', "native"); // εδΈ
Because this may have to change on-the-fly and possibly per-call, I would prefer a second argument for Japanese over a setting in the configuration file.
from numbro.
sounds like a good idea for all the languages with a different alphabet π
@lukaszkrawczyk if you want to give this a try, I will be very pleased to read your code π
from numbro.
@kyokou Correct. Sorry for being unclear.
@BenjaminVanRyseghem OK, let's do it!
from numbro.
@lukaszkrawczyk any progress here? π
from numbro.
As another solution, GNU uses @
to denote variations in locales, like en-US@euro
to display English (USA) with Euro as a currency, so maybe we can use same principle in formatCurrency
?
numbro(100).formatCurrency('0,0.00 $')
numbro(100).formatCurrency('0,0.00 $@arabic')
from numbro.
@ArmorDarks I would like to keep locales out of the format string
from numbro.
Related Issues (20)
- Another format for negative currency balance
- Wrong output for clock format
- Setting bound for the fractional part HOT 1
- Please add Venezuela's currecy BolΓvar (VES)
- Please add the Uzbek language.
- totallength: 5 of "5033,599" results in "5033.599999999999"
- Format with abbreviations not work HOT 1
- $0.995 formats to $1.00 but how Not to average
- Formatting for decimal bytes yields "K" in result instead of "k"
- Adding custom languages HOT 3
- Improve the toolchain HOT 1
- Using lowPrecision on Old Format
- How to override the default currency format for en-US?
- format error
- Format string for rounding to nearest integer HOT 1
- BigInt support breaks in 1.10.0 and later + "Support BigInt in the operators (Incomplete NumeralJs issue/feature request #778)"
- document site is down HOT 1
- Provide an ES module in the package
- validate types seems wrong
- Negative rounding up is not consistent HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from numbro.