| Raymond | |
| Apr 29 2020, 9:37 AM |
| F36969418: whitespace.png | |
| Apr 29 2023, 2:04 PM |
| F35020195: Screenshot from 2022-03-22 18-30-15.png | |
| Mar 22 2022, 5:30 PM |
| F31786421: grafik.png | |
| Apr 29 2020, 9:37 AM |
Trim text input before saving
Steps to reproduce:
In this example a leading space in front of "Swiss Ruby"
Possible solution:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T251380 Trim text input before saving on Structured Data on Commons string input | |||
| Resolved | Manuel | T47925 [Task] Apply normalization to string values in statements | |||
| Resolved | daniel | T104873 [Task] wbparsevalue should support StringValues, instead of relying on UnknownValue | |||
| Resolved | daniel | T104874 Implement standalone StringValueParser |
Yes, ran into this too on Wikidata this week. The stripping could happen on the front end javascript or in the backend API. Not sure where other clean up is currently happening. AFAIK this only applies to string datatypes so I'll update the task a bit.
Any chance that this could be fixed in the near future? It's really annoying to run into the misleading error "wrong input". As I am an experienced user I know what to do (trim by hand) but other people with less experience would give up :-(
Putting it on my list to discuss with Adam next week.
Open question from my side: how do we deal with statements where the value is supposed to be only a whitespace? (I'm thinking of the Item for the whitespace character for example.)
Those can't be added right now, so nothing would change there. For items about characters, I would suggest always using the P4213 (Unicode code point) value instead (especially if you're using SPARQL - T233204).
Isn't this ticket for Commons though, not Wikidata? There's already T47925 and T250695 for Wikidata, although it seems to be working fine for me there, e.g. I can no longer reproduce T261071.
Hi @Lucas_Werkmeister_WMDE, we now have built in Unicode normalization of string values already, right? So if we solved this task, it would automatically solve T47925 and others. In your opinion, could we just enable automated trimming in the parser? The case would be that we do not allow purely whitespace values in the UI, as I see no reason not move away from the working status quo. This seems like an obvious thing that we should do, but maybe I have missed something,
I think the parse API already trims strings? Example: https://www.wikidata.org/w/api.php?action=wbparsevalue&datatype=string&values=%20abc%20def%20&format=json&formatversion=2
Thank you! I have made the ticket more specific to SDC now, as this seems solved already for Wikibase.
Came here to report this useless message only to find out the problem was already reported 3 years ago...
What's the point in showing me the "bad" input when the whitespace that's not allowed will never be visible? And what's the point in showing me this error message instead of just trimming the whitespace like any normal form would?
All it has done is discourage me from editing SDC: I didn't want to start again, so I didn't add the statement and I'm not going to do the other statements I was planning to add either.
