-
-
Notifications
You must be signed in to change notification settings - Fork 197
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
Problem with Japanese abbreviations. #2
Comments
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. |
@kyokou Thank you very much for comment! To sum up, there are three systems:
As you mentioned, one thousand is an exception - you can ommit number in front of kanji (千 = 1千). It's similar to "one hundred" and "a hundred" in English. Particularly, second system is commonly used for counting big amount of money. 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? |
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:
|
I am not a big fan of magic index referring to hidden things 😸 I do not know Japanese at all, so I will try to summarize what I understand, please correct me if I am wrong.
Am I right? 😄 |
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"); // 十万円 |
Thanks for the clarifications 😄 (indeed, the Could you please explain why the currency symbol has to be different? If for all other languages we use something like Is |
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
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 |
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):
What do you guys think about that? |
@kyokou Yes, everything is correct. I couldn't explain it better ;) @BenjaminVanRyseghem , are you OK with @kyokou 's solution? On the other hand, I've been thinkning about publishing separate library to deal with this problem. Regarding issues with currency, let's move your proposal to different issue. |
@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 😉 |
@lukaszkrawczyk I would rather push things directly into numbro instead of having another layer of external dependencies, don't you think? |
@BenjaminVanRyseghem 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. |
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 😉 |
@kyokou Correct. Sorry for being unclear. |
@lukaszkrawczyk any progress here? 😄 |
As another solution, GNU uses numbro(100).formatCurrency('0,0.00 $')
numbro(100).formatCurrency('0,0.00 $@arabic') |
@ArmorDarks I would like to keep locales out of the format string |
@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:
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. |
(moved from foretagsplatsen/Numeral-js/issues/9)
I've already reported this issue here adamwdraper/Numeral-js/issues/248, but as the original branch is not maintained anymore, I think it would be better to focus on your branch.
Now, Numeral.js is grouping numbers into 4 groups: thousands, milions, billions and trillions.
But, in case of Japanese (and I suppose it also applies to Chinese) numbers are grouped in slightly different way: every hundred, thousand and ten thousand.
Before I start fixing this issue, I'd like to discuss how to approach that problem.
Ideas:
Sample formatting function here: http://jsfiddle.net/tuknLbz8/1/
Anyway, I think we need more flexible architecture if we want to support even more complicated numeral systems like Indian numbering system.
The text was updated successfully, but these errors were encountered: