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

Optional number elongation #18

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

jopdeklein
Copy link
Contributor

@jopdeklein jopdeklein commented Feb 19, 2019

Fix #15.

For now I decided to only elongate even numbers to avoid elongating the numbers too much, it might make sense to review this later.
Our main use case is currencies, but also to exercise the UI with longer numbers like the amount of reviews, for example.

@tryggvigy
Copy link
Owner

Hey! I did a quite significant refactoring of the internals so you probably have some conflicts.
Sorry for the bother :)

@jopdeklein
Copy link
Contributor Author

Hey! I did a quite significant refactoring of the internals so you probably have some conflicts.
Sorry for the bother :)

Heyla, if you agree with the concepts in the PR I don't mind fixing the conflicts sometime soon :)

@tryggvigy
Copy link
Owner

tryggvigy commented Feb 21, 2019

It's an interesting idea. I'd love to explore the implications a bit further!

If some input value is being kept in sync in the DOM and JavaScript I'm not sure how this would affect that. For example in React it's common to use controlled inputs

@jopdeklein jopdeklein marked this pull request as ready for review February 26, 2019 17:22
@tryggvigy
Copy link
Owner

I rebased and noticed that 2 does not get superscripted image

The glyphs in strings of numbers are not as diverse as in text on average. 100, 100.000, 2019, etc will be more common. Doubling the even numbers is a good start but I'm worried about bias towards too much elongation (more than the ~30% on average we have for text) on average. Especially due to zero being common. I'm wondering if there are better numbers to pick based on frequency analysis of digits in a huge corpora of English text, like wikipedia for example.

Anyway, I like the idea of opt-in elongation of numbers. Superscript seems fine but have you explored any other options for glyphs to use in the pseudo language for numbers?

@@ -126,30 +134,40 @@ const strategies = {
};

const psuedoLocalizeString = (string, options = { strategy: "accented" }) => {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There will be conflicts on this line after rebase, I think the best fix is

{ strategy = 'accented', elongateNumbers = false } = {}

to keep deep defaults and avoid can not find elongateNumbers of undefined Errors in edge cases!


let pseudoLocalizedText = "";
for (let character of string) {
if (opts.map[character]) {
const convertedCharacter = strategyOptions.map[character]
const characterAsInt = parseInt(character)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can move this inline to line 146.

!isNaN(parseInt(character))

imo it's still totally legible and we avoid executing parseInt for every character if elongateNumbers number is false.

Now that I think about it do we need to parseInt?

would

      options.elongateNumbers &&
      EVEN_NUMBER_MAP[character]

not be enough?

@@ -126,30 +134,40 @@ const strategies = {
};

const psuedoLocalizeString = (string, options = { strategy: "accented" }) => {
let opts = strategies[options.strategy];
let strategyOptions = strategies[options.strategy];
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice rename :)

@jopdeklein
Copy link
Contributor Author

I rebased and noticed that 2 does not get superscripted image

The glyphs in strings of numbers are not as diverse as in text on average. 100, 100.000, 2019, etc will be more common. Doubling the even numbers is a good start but I'm worried about bias towards too much elongation (more than the ~30% on average we have for text) on average. Especially due to zero being common. I'm wondering if there are better numbers to pick based on frequency analysis of digits in a huge corpora of English text, like wikipedia for example.

Anyway, I like the idea of opt-in elongation of numbers. Superscript seems fine but have you explored any other options for glyphs to use in the pseudo language for numbers?

I agree that the current approach is rather naive, I can do some research at a later stage for the numbers - it would really depend on what kind of numbers we're dealing with to exercise the UI (I assume for Spotify, play counts will have a much wider range than a number of seconds, for instance - the same for our use case of review count vs distance from a certain place in km's).

As mentioned, since our use case currencies are the most urgent, I think it's best if we approach those separately. It should be easier to get a more realistic average elongation based on USD or EUR for example.

I'll look into a separate concept based on this branch for currencies and come back to a more realistic number example later based on our usage.

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

Successfully merging this pull request may close these issues.

2 participants