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

The "K" suffix is not localised #37

Open
agharbeia opened this issue Jul 18, 2017 · 3 comments
Open

The "K" suffix is not localised #37

agharbeia opened this issue Jul 18, 2017 · 3 comments

Comments

@agharbeia
Copy link
Contributor

In the statistics line of each entry in the index, the suffix "K" of the number of views is not localised.
Both Arabic and Farsi are affected:
wikipedia-top-100-k-suffix-localisation-bug

In Arabic it should be "ك"

@mahmoud
Copy link
Member

mahmoud commented Jul 18, 2017

Hehe, you're really going over this with a fine-tooth comb! In this case however, I don't think this suffix is necessarily localization-worthy. For one, it's been my experience in Iran that "K" is pretty well-understood and used in signage (e.g., km for distance). It's also an international standard. It's basically part of the lingua franca that one can reasonably expect our audience to grasp. I'm more concerned that the numbers in those screenshots appear not to be localized!

@agharbeia
Copy link
Contributor Author

agharbeia commented Jul 18, 2017

Well, ك is used in Arabic in physics and mathematics. And being a standard is not a reason not to localise it ;)
Also the "K" causes BiDi problems, both in Arabic and Farsi, specially when tweeting.
It would be great to solve if possible.

As for the numerals, I had written a issue about the opposite situation: In Chromium the numerals looked enforcedly localised to the eastern variety of Arabic numerals while my personal preference is the western. I hesitantly deduced that you must be hard-coding the text for Arabic and Farsi to the unicode points in the ranges U+0660 to U+0669 and the U+06F0 to U+06F9 respectively, which is not a good thing in my opinion because it doesn't leave the choice to the reader/user.

But it turns out that I had set Firefox to always display the western variety of Arabic numerals but not Chromium. So I didn't submit that issue. This screenshot is from Firefox.

So in short: leave the numerals as is. They're fine. Users can choose in their client application. Arabic readers are almost equally divided in their preference for numerals. It's a historical Maghrib vs. Mashriq thing.

@agharbeia
Copy link
Contributor Author

Now that I fetched the page using wget and looked at the source, you are indeed hard-coding the numerals. I really recommend that you don't. This should be handled by user preferences in the client.
It will look funny in some clients when some numerals are displayed in one variety and the other in the other variety in the same page.

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