Kolibri: Numerals are not localized in some places (and use 0-9 arabic numerals by default)

[jonboiser]

Observed behavior

Here are places on https://kolibri-beta.learningequality.org/mr that I was able to find (annotations are within the screenshots)

Version numbers on https://kolibri-beta.learningequality.org/mr/device/#/content

Number of learners in class on https://kolibri-beta.learningequality.org/mr/facility/#/a3f606630690237bbe94fe2a1a850af4/classes

KTextbox maxlength validations

Time elapsed messages on various Coach Pages
https://kolibri-beta.learningequality.org/mr/coach/#/10c12cbfc4b67630511d67f7b7895f17/reports/quizzes/70a26038f8dddffcb93f05bcec8b2095/learners (same on lessons pages)

Birth years on profile page and other places

Expected behavior

If appropriate, numerals should use the Intl API's number formatter, so numbers in e.g. the Marathi (mr) locale use those numerals consistently and so on.

User-facing consequences

…

Errors and logs

…

Steps to reproduce

…

Context

…

[Kalovelo]

Hey @jonboiser, could I work on this? As I can see here, {v} should be replaced with {v, number, float}. If that seems like the right approach, I plan on updating the rest of those occurrences :smiley:

[jonboiser]

Sure @Kalovelo, thanks for offering to help. For most of the examples, we only expect integer values, so {v, number} should be fine, or {v, number, integer}.

I have seen another issue #7598 , where it seems we do want counting numbers like "3 learners" to be localized using Marathi numerals, but I'm not sure about the birth year example.

I'll ask around and see if we should also localize the birth year to numerals as well.

[jonboiser]

@Kalovelo , I just checked to see if the the Intl API for datetimes localized calendar dates for Marathi, and they do. So please include the User Profile pages that display birth year. I believe the component is BirthYearDisplayText.vue

[Kalovelo]

A question @jonboiser, I see that integer string is in commonCoachStrings, however, it may be used in core views such as facility views. Should I refactor the code and move the integer string instance from commonCoachStrings to commonCoreStrings?

Importing commonCoachStrings doesn't seem like a good idea since there's no such importing under facility folder.

A simpler way would be to add integer in commonCoreStrings, but I believe this is not the best solution since there would be duplications :thinking:

[jonboiser]

I think this might depend on the situation. I really think that if a number is just by itself in the template, we should be using the $formatNumber method instead of using $tr('integer', ...). Could you see if that approach works?

Here are the doc explaining how $formatNumber works. https://github.com/learningequality/vue-intl#instance-methods

It is like a wrapper around Intl.NumberFormat

[Kalovelo]

@jonboiser, I have fixed every instance except the maxLength occurrence in the KTextBox component, since it is imported from kolibri's design system and there's no corresponding prop assigning label values to current/max text of the textarea. Can a better solution be provided through the design system's repository?

[nucleogenesis]

@Kalovelo - if you are actively working on this issue, can you please assign yourself to it (or I'll assign you if you cannot assign yourself).

The issue w/ KTextBox in the design system can be fixed separately as it may require that we include vue-intl as a dependency in that package to allow for i18n on the numbers there.

Most numbers that will run through design system components would be passed as props and rendered directly to the user (aka, not used for mathematics).

Seems like we might need to {{ $formatNumber(valueLength) + '/' + $formatNumber(maxLength) }} in KTextBox#113

---

Feel free to create a PR with the work you've completed so far though and we can track that other requirement about the design system in a follow-up issue in the Kolibri Design System repository

[Kalovelo]

Thank you for your answer @nucleogenesis , I will proceed with a PR 🚀