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

Keyboard input does not work in Filter by date if your user locale is set to Arabic #4569

Closed
Olga8614 opened this issue May 17, 2022 · 10 comments
Labels
3 - installed Issues that have been merged to master branch and are ready for final confirmation. bug Bug reports for broken functionality. Issues should include a reproduction of the bug. estimate - 5 A few days of work, definitely requires updates to tests. i18n-l10n issues dealing with internationalization/localization needs milestone Planning workflow - pending milestone assignment, has priority and/or estimate. p - low Issue is non core or affecting less that 10% of people using the library research Issues that require more in-depth research or multiple team members to resolve or make decision.

Comments

@Olga8614
Copy link

Actual Behavior

devext, 05/17/2022
Steps:

  1. Set your user locale to Arabic (key step)
  2. Go to My Contents tab, or any other tab that has Custom range filter by date
  3. Click the Start Date or End Date and observe: calendar displays with Indic Numerals
    image
  4. Try to edit the year by manually entering 2021 or 2020 with your keyboard
    Observe: the change does not take effect

Entering 20:
image

2020 becomes 2022 again after you click Enter:
image

  1. Try to edit the Start date or End date manually by entering with your keyboard input

image

Observe: custom filter by date does not take effect.

image

  1. Set Start Date and End date with your mouse using UI controls and notice that filter is set.
    image

  2. Edit Start or End date set on Step 6 with your keyboard and notice that changes don't take effect.

image

Expected Behavior

Keyboard input should work and take effect on filter
cc @aine

Reproduction Sample

.

Reproduction Steps

Steps:

  1. Set your user locale to Arabic (key step)
  2. Go to My Contents tab, or any other tab that has Custom range filter by date
  3. Click the Start Date or End Date and observe: calendar displays with Indic Numerals
    image
  4. Try to edit the year by manually entering 2021 or 2020 with your keyboard
    Observe: the change does not take effect

Entering 20:
image

2020 becomes 2022 again after you click Enter:
image

  1. Try to edit the Start date or End date manually by entering with your keyboard input

image

Observe: custom filter by date does not take effect.

image

  1. Set Start Date and End date with your mouse using UI controls and notice that filter is set.
    image

  2. Edit Start or End date set on Step 6 with your keyboard and notice that changes don't take effect.

image

Reproduction Version

devext.arcgis.com as of 05/07/2022

Relevant Info

No response

Regression?

No response

@Olga8614 Olga8614 added 0 - new New issues that need assignment. bug Bug reports for broken functionality. Issues should include a reproduction of the bug. needs triage Planning workflow - pending design/dev review. labels May 17, 2022
@github-actions
Copy link
Contributor

More information is required to proceed with this issue:

This issue will be automatically closed in five days if the information is not provided. Thanks for your understanding.

@github-actions github-actions bot added the incomplete issue report New issues missing important information, and unless provided, they will be closed after 5 days. label May 17, 2022
@annierm18 annierm18 added the i18n-l10n issues dealing with internationalization/localization label May 17, 2022
@annierm18
Copy link
Contributor

@benelan benelan removed the incomplete issue report New issues missing important information, and unless provided, they will be closed after 5 days. label May 18, 2022
@jcfranco
Copy link
Member

@Olga8614 @annierm18 I have a few questions since there's a few moving parts in the description:

  1. Based on the codepen above, does Bug: Arabic Date Picker should display Western numbers while selecting #2095 represent the main issue? If so, we can close this as a duplicate.
  2. If the answer to☝️ is no, can you provide more info on what is not working on the component side that is affecting date filtering?

@Olga8614
Copy link
Author

@jcfranco - the answer to 1. is no.
Currently the input with Western numerals is not working.
Expected behavior: no matter if you input Western or Indic digits, the inputbox should take it and interpret as numbers.

@benelan benelan added the need more info Issues that are missing information and/or a clear, actionable description. label Jun 15, 2022
@jcfranco jcfranco self-assigned this Jul 22, 2022
@jcfranco
Copy link
Member

jcfranco commented Mar 2, 2023

This is still valid after latest updates to the component: https://codepen.io/jcfranco/pen/wvEJPEY

@jcfranco jcfranco added needs triage Planning workflow - pending design/dev review. and removed need more info Issues that are missing information and/or a clear, actionable description. needs triage Planning workflow - pending design/dev review. labels Mar 2, 2023
@jcfranco jcfranco removed their assignment Mar 2, 2023
@geospatialem geospatialem added research Issues that require more in-depth research or multiple team members to resolve or make decision. estimate - 5 A few days of work, definitely requires updates to tests. labels Mar 21, 2023
@jcfranco
Copy link
Member

@eriklharper Could you provide an effort estimate for this one?

@geospatialem geospatialem added p - low Issue is non core or affecting less that 10% of people using the library needs milestone Planning workflow - pending milestone assignment, has priority and/or estimate. and removed needs triage Planning workflow - pending design/dev review. labels Mar 21, 2023
@eriklharper
Copy link
Contributor

eriklharper commented Jun 1, 2023

I think this is fixed now on the latest 1.4.1. @Olga8614 would you be able to re-verify this with the latest calcite version? I forked Franco's codepen with the latest calcite and my keyboard edits are working after changing the value and pressing enter or blurring the input:

https://codepen.io/eriklharper/pen/wvYVvzE

@eriklharper eriklharper added the 3 - installed Issues that have been merged to master branch and are ready for final confirmation. label Jun 1, 2023
@eriklharper eriklharper removed the 0 - new New issues that need assignment. label Jun 1, 2023
@github-actions
Copy link
Contributor

github-actions bot commented Jun 1, 2023

Installed and assigned for verification.

@Olga8614
Copy link
Author

Olga8614 commented Jun 1, 2023

I think this is fixed now on the latest 1.4.1. @Olga8614 would you be able to re-verify this with the latest calcite version? I forked Franco's codepen with the latest calcite and my keyboard edits are working after changing the value and pressing enter or blurring the input:

https://codepen.io/eriklharper/pen/wvYVvzE

The year can be edited from the keyboard - fixed
The day input from the keyboard still does not take effect - not fixed

image

@eriklharper
Copy link
Contributor

I've created this issue, which explains the larger bug at play here: the inability to intuitively edit the date value text in the input when in RTL mode: #7186

@geospatialem geospatialem removed their assignment Jul 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 - installed Issues that have been merged to master branch and are ready for final confirmation. bug Bug reports for broken functionality. Issues should include a reproduction of the bug. estimate - 5 A few days of work, definitely requires updates to tests. i18n-l10n issues dealing with internationalization/localization needs milestone Planning workflow - pending milestone assignment, has priority and/or estimate. p - low Issue is non core or affecting less that 10% of people using the library research Issues that require more in-depth research or multiple team members to resolve or make decision.
Projects
None yet
Development

No branches or pull requests

7 participants