search

karthickkc / pe

0 stars 0 forks source link

Names in other languages not allowed #1

Open karthickkc opened 1 week ago

karthickkc commented 1 week ago

I tried to add names in other languages such as arabic and chinese, e.g. عمران or 伊姆兰. However, I am unable to do so, an error message pops up. You can reproduce this by copy pasting either one of the example names above into the add command. I feel that this should be allowed and is not far-fatched as a particular user might be more comfortable with storing the contact in that particular language. I also did not see the User Guide not allowing this, so maybe if the intention is to not allow storage of names other than English, it could be stated in the User Guide. Screenshot 2024-11-15 at 4.17.46 PM.png

nus-se-script commented 1 week ago

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

We have marked this as not in scope because:

  1. The Chinese script is not counted as alphabetical. The Chinese language does not contain an alphabet, and the User Guide and error message clearly state that the name should contain alphabet characters. Therefore, it cannot be said that this does not work as specified/expected if the app rejects a name with Chinese characters.

  2. Since all our documentation and interface are in English or at least using the Latin script, the expectation is that the users will realise that the alphabet characters in the screenshot above refer to the Latin alphabet and not others like the Arabic alphabet. We expect our users to want to work mainly in English due to the fact that all our documentation and the app itself is in English, hence it is expected that they would translate non-english names to their english spelling.

(Furthermore, in the screenshot above, you have only included one part of the name parameter, the first name, when it requires 2 parts)

Our current implementation is blind to languages other than English, the main reason being that resource is a constraint and it is not feasible to account for every language. Furthermore, this would definitely not be a FunctionalityBug as it still acts well within the bounds of our documentation. Thus, we have rejected this as not in scope.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: [replace this with your reason]

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your reason]