Spurious spaces and dates added when editing CK

When you edit existing data in a CK field, a space is sometimes added at the end of the field. Also, if there's a date in the entry, the year appears in the edit box in brackets. E.g. if the field contains 'fred' and you edit then save it, it will contain 'fred '. If the field contains '2010-06-10' it will display as '2010-06-10 {2010}', and when you edit it, the edit box will contain '2010-06-10 {2010}'. If you save that, the field will display '2010-06-10 {2010} {2010}'.

Previous mentions:
Spurious space added when editing CK
« invariant editing » : restoring any CK information without changes should not alter it
normalization: ignore « leading / trailing spaces » « spaces / whitespace » in « Common Knowle

Fixed. Thanks.

There seems to be a new problem with the date one.

I double clicked on a birthday "1974-05-26 [1974]" and saved, and the whole thing was turned into a single link, instead of having the bracketed bit be a metadata link.
Clicking on it took me here: http://www.librarything.com/commonknowledge/search.php?q=1974-05-26%20%20snuppys... 91;1974]&f=8&exact=1

Where did you do it?

Author page. http://www.librarything.com/author/amanokozue

And now it's showing the 1974 doubled in the brackets. When I doubled-clicked and saved to see if it would add the bracketed year again, it turned the whole string into a link, but didn't show the new brackets. Going back to the page, it's there now.

I'm not sure where the fix was applied, but I've gone through a selection of random works and authors, and much of the time if I double-click to edit a CK field, there's a space at the end.

Here's another example: http://www.librarything.com/author/porterandrew has spaces at the end of Nationality, Places of residence, and Occupations. In Education it shows up before the (. Some values have two spaces. (Date of birth is a good example of the other bug where the year in brackets gets added as you go into edit mode.)

In all cases, if you hover over the CK entry the search link doesn't include the space.

It's hard to tell if the space is in the data, but ignored when creating the search link, or if it's not in the data but is added in the process of going into edit mode.

The fact that some values have two spaces makes me think that at least one space is saved in the data, and possibly one is added when going into edit mode.

Is is a problem? Honestly, I don't know. I know that in the past, I have seen searches that include the space, and sometimes two, but I haven't seen them recently.

Is it confusing? Definitely, for people who are careful with data.

Hi! http://www.librarything.com/topic/94962 linked to this bug. I verified http://www.librarything.com/work/9959501/commonknowledge today and the event "Aktion Brandt" shows "two" trailing spaces. The issue is not to correct this particular CK manualy, the question is if it is possible to run a script deleting all multiple spaces as well. I assume that neither single leading space nor multiple leading spaces should be preserved.

Note: The event "Aktion T4 (Euthanasia)" one line above will show "two" spaces between "Aktion T4" and "(Euthanasia)". I assume that such multiple spaces at an arbitrary position should be replaced with a single space.

corrected typos

note: I did not do this intentionaly:
place starting with a space . I realized it later. I used "copy and paste" but a leading space was in the scrapbook. If users are not aware of this behaviour such cases are very difficult to detect because the browser link rendering or whatever piece of software involved makes some "optimization".

I assume that there are no cases where leading spaces are meaningfull. Supreasing leading space would be a precaution action.

As I mentioned in the other thread -- cleanup of existing data, or removing spaces when users enter them, should be suggested in Recommend Site Improvements - since those things aren't actually bugs (but they would be great improvements).

This thread is about the case where LibraryThing itself adds a space when you edit a field.

>9 r.orrison:: Sorry! opened as requested http://www.librarything.com/topic/100105

Hm. Buggy data added because of a bug isn't a bug? I'm not sure I agree. I guess it depends how much of a problem the buggy data is.

Well, the problem with the search including the spaces seems to have been fixed, except for when the spaces are added between the search content and metadata content, which is what I thought the primary problem was. But it's still strange that spaces get added.

>8 gangleri: Neither did I >8 gangleri: intentionaly nor did I add intentionaly multiple spaces in CK series names at Series: ZZZZ - test - author picture available from wikipedia intentionaly.

One needs special attention to see that there are two "+" characters before the word "author" in the url. At any later point in LT GUI the browsers will display only one SPACE. This is not a bug in LT itself but it is a "source of erros". LT should prevent this just by replacing multiple spaces with a single space in the middle of (any) objects.

2010-10-21: Neither the errors (having a leading space, multiple spaces etc.) not the fixes can be seen at work CK history pages.

Please take a look at the "dormant author url" mullerjosepheacutemile CK author history.

I added there in four "Date of birth" lines:
1911 + SPACE + (testcase)
1911 + SPACE + SPACE
1911 + SPACE
1911

When I edit CK agin I can see:
1911 + SPACE + SPACE + (testcase)
1911 + SPACE + SPACE + SPACE
1911 + SPACE + SPACE
1911 + SPACE

I suspect that whaterver postprocessing creating the additional date links, piped links etc. is adding this extra space.
Please note that no space is added after the original post in the fields: "Relationships" and "Disambiguation notice".

The trailing SPACE in the "Canonical name" field was not present during initial save.

I am using Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 on Ubuntu 7.10, Gutsy Gibbon, October 2007

>14 gangleri: It seems that there are different types of postprocessing involved:
a) at "Relationships" is trying to identify the requested author url and if found a link is generated;
b) at "Disambiguation notice" a link validation is made; I noticed there that arbitrary links are not allowed ( see http://www.librarything.com/topic/82714#1731820 )
finaly c) many other fields: depending on syntax additional links are generated.

I guess that the algorithm makes basically the followings:
c1) preserves the entered field; maybe only a part of it
c2) adds a SPACE
c3) verifies if some links should be generated, some conversion should be made etc.
c4) if the answer to c3) is YES it does what it should

What about changing the order: c1) c3) c2) c4) ?

some notes:
¹: I could not find a full description on the syntax, the usage of "|" OR "·"
²: The JavaScript result is not identical with a page reload. I used to reload the page to be safe about all changes.

Note: Joseph-Émile Muller (1911–1999)'s CK (author CK history) has:
d) in the "Canonical name" field: a SPACE added after the original post
e) two SPACEs between the original posts and the appended squares with the link

Where comes the second SPACE from? One would be sufficient.

P.S. What actions take place if clicking on the edit icon?

Another reported problem, probably because of this: http://www.librarything.com/topic/102983

As noted by BarkingMatt in the other thread, one side-effect of this is that it creates two different links that don't lead to the same data. In his example, clicking on the "Animator(space)" one takes you to a different set of results than just "Animator". This makes the bug much worse than what you might at first suspect.

Assigning to CH.

Ah, already was :)

I'm pretty sure that I fixed the cause of this but I'll check it out. Of course that didn't fix any of the existing entries that may have had spaces in them already. Again, checking on that.