openhab
German Umlaut are alphanumeric characters
The problem
Expected behavior
"Ü" is an alphanumetic character
Steps to reproduce
- Create new location using German Umlauts
Your environment
Browser console
Browser network traffic
Additional information
I could imagine that this is intended behaviour. I don't know if the backend supports it and I avoid it at all cost because it will cause issues at some point especially when you have another app that is consuming the api. Umlaute are the source of a lot of trouble
These are LABELS. Their only purpose it to be displayed AS-IS in the UI. They are never identifiers.
@MarcusWolschon
What @niwla23 says is AFAIK correct. Working with Umlauten always causes trouble and therefore is now allowed for the Item name even though Umlaute might be alphanumeric.
And the Item‘s name is in fact the identifier for the Item that is used in the backend, the APIs and everyhwhere. The name is NOT the label, for label you have an extra field called label and that field accepts anything (even kyrillic I think).
@ghys I guess we can close this issue here.
@ghys So adjust the error message because it's factually wrong and misleading.
The error message is wrong, misleading, frustrating users who are doing exactly what it says and it would be trivial to change that single string resource.
If is is so trivial to change that single string resource, why don‘t you contribute yourself? Just search for the given string in this repo, change it and open a PR.
Forked. WTF? You guys are using hardcoded, untranslated strings in your source code?
You have your pull request.
@MarcusWolschon Pinging other devs/maintainers and commanding them like above:
So adjust the error message because it's factually wrong and misleading.
… won’t make you any friends in this community.
Don‘t forget that we all develop openHAB as a hobby - no one is working for openHAB or earns money from developing it. TBH I don’t need to work with people that behave like you did in my spare time.
And some explanation why
WTF?
… are we using untranslated, hard-coded strings:
I guess @ghys who wrote the UI put a higher priority in having a working UI than in localising everything of from the beginning. And localisation is still missing for parts of the UI, because no one worked on it yet - most devs still have higher priority in fixing bugs and adding new features the community requests than in localising stuff (which is nice-to-have, but real functionality is much nicer).
Given your reaction to a proposal for an alternative fix presented in a factual manner and to donated code I can see why you are lacking volunteers.
Remember, it takes an outside volunteed serveral times longer with fork, clone, looking up the correct syntax in an unfamilar programming language, commit, push, PR,... down to deleting the clone and forked repository later on a sunday night then a single line commit by a project developer familar with the code.
I do not think the error is misleading. Alphanumeric usually refers to a-z,A-Z,0-9. If you have a value that can take umlaute, it can probably take everything, so you would call it a (unicode) string. What would you want the error message to be?
As you can see by the very existance of this issue, your understanding of the meaning of "Alphanumeric" may or may not be usual but is not universal. Thus it can be misleading and frustrating for people who share a different interpretation. Most likely native speakers of languages with a different set of letters in a latin-based alphabet and of different alphabets altogether. "Usual" is not enough of a criteria for a good user experience under the precondition that the user has just entered a name that does not match this rule.
The pull request above, as requested by Florian, already contains the proposed new error message (and introduces a separated message for the case of empty inputs).
Good night. I'll have a look again in a few days to delete the fork of this project, I had to create.