soc-pe-bot
commented
2 years ago Team's Response
It is stated in our UG that we would only be accepting alphabetical characters for service name. The user would have to adapt to the constraints given.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: 
Given in your UG, you did not specify a geographical constraint on your intended target users. It is reasonable to think that your application is designed for international use. This by extension would mean that you should also reasonably accommodate for vendors in other countries that do not primarily speak English.
My issue mentions that a hotel front desk staff based in a Chinese-speaking country, such as Bei Jing, would not be able to input a non-English service name (E.g. 北京烤鸭).
Based on the user story given above, your users will be able to input vendor details.
Your use case given above shows that inputting vendor details is a feature implemented in v1.4
My issue claims that vendors in countries that do not primarily speak English would not be able to input non-English service names. Essentially, the user will not be able to input vendor details appropriately. This means that the implementation of the feature input vendor details falls short of fulfilling your user story for your intended target users.
Allowing non-English characters should just involve changing the validation check for service names and shouldn't require much additional effort to implement.
Given that my issue is related to features promised in v1.4 and that it can be implemented in a way that better suits the needs of the application's intended target users without much additional effort, I believe that it should be accepted.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: I believe that not being able to input a service name using non-English characters would cause a huge inconvenience to your users (which should be from an international context).
There are many non-English characters that when converted into English words would lose a lot of meaning. Take Chinese Pin Yin for example. The Pin Yin xi when given in strictly English characters would lose its intonation and hence lose meaning. It could mean 洗 or 西 or 细 or many more other Chinese characters.
This is only for Chinese, which already has a phonetic system much like English and an internationally standardized romanized spelling. Imagine the loss in meaning for service names in other languages, such as Japanese, Thai or Vietnamese, which share little similarities with the English language.
This loss in meaning caused by the application forcing its front desk staff to convert service names into English characters will cause trouble for the front desk staff who has to spent extra effort to come up with appropriate English translations for non-English service names. It will also cause trouble for other front desk staff who now have to make sense of the English translations of non-English service names made by their colleagues.
As such, I think that not allowing non-English service names will cause a great deal of inconvenience to the application's target users. Since the users can still continue to use the application, I think that a severity of Medium is appropriate.
It does not make sense that non-english vendor names are allowed when non-english service names are not allowed.
I consider this to be a medium feature flaw as a front desk user in a hotel functioning in say a chinese speaking city like Bei Jing would face huge inconveniences using your application.