Last modified: 2014-09-15 15:31:38 UTC
- Add year "1400" in the UI - You will see "14. century" - Change auto-detected precision from century to year in "advanced adjustments" - You still see "14. century" - Click save - Date is saved as +00000001400-01-01T00:00:00Z precision 7 (century) https://www.wikidata.org/w/index.php?title=Q3907398&action=historysubmit&diff=119811305&oldid=119811153
The first problem should have been fixed for a while now. I can't reproduce it at wikidata.org. The auto-detection does not set "century" any more. "1400" is auto-detected as "year". Please try to clean your browser caches. I can reproduce the second problem. But I'm not sure if it's a bug we can fix. The problem is: The text field contains "14. century". What should happen if you set the precision to "year" but the text field still contains "14. century"? This is a mismatch. The current implementation takes the value of the text field more serious. Should the UI really touch what you typed when you change the precision? I'm afraid this will lead to all kinds of other problems. Current solution: Delete the value and type "1400" again. The precision will be set to "year". I will left this bug open because the current behavior really is a bit confusing and we should try to think of a solution. Suggestions welcome.
The user input was '1400'. The UI should keep that literal string in its memory and apply the precision changes to that string to obtain the derived value, until the user changes the input box.
(In reply to John Mark Vandenberg from comment #2) > The user input was '1400'. If you look at the two situations independently this is not how it works. The second situation is exactly like you typed "14. century". Try it: Type "14. century". The precision will be auto-detected as "century". This is correct, right? Now try to change the precision to "year". What do you expect? I'm thinking about the following change: When clicking "edit" the input field should not contain "14. century" but "1400" with the precision set to "century". Basically: Limit the precision of the editable value to "max. year". Unfortunately I'm not sure if this is an easy fix. It might need an additional API request. Additionally the precision selector should be expanded automatically when the precision is not "year".
I am going to close this as the first issue is fixed and I don't see us being able to solve the other one in the foreseeable future.
