Hi @zorae,

I want to work on this issue. It is a useful improvement to streamline data entry and prevent formatting errors. I'll review potential edge cases where leading/trailing spaces might be necessary and ensure the implementation excludes those fields.

Please let me know if this feature has any additional details or preferences!

Thanks @QuangPhung15!
I’ve been pondering if spaces should a) be stripped immediately upon deselecting a field, or b) only upon saving changes.

a) has the advantage that it gives librarians immediate feedback so they know they don‘t have to manually remove spaces. But I foresee that this could be annoying for multi-line fields like bio or work description where a librarian might start writing something, add a space or line break at the end and deselect the field before coming back to continue writing.

Option a) would have to be implemented client-side, while b) could be either client- or server-side.

Would it also be possible to substitute multiple space characters to only one, something like: s/\S+/ /g?

@zorae can we please be enumerative of the exact fields you believe this should be applied to? Even if we start with only a few, that is more likely to make forward progress than requiring folks who don't have librarian context / experience from having to figure out what fields we might be talking about. Thank you!

Also, as @scottbarnes mentioned to me in a passing, there may be edge cases, like author, where there are things like ", Sr." or other prefixes that end up complicating these rules.

@mekarpeles Some fields I would find particularly useful are author name, bio, date of birth, date of death, edition title, work title, and work description.

@scottbarnes Can you clarify what the issue would be with the “, Sr.” suffix? It ends with a period, so I don’t see how a rule that strips out whitespace at the end of a field would affect it.

I apologize, I think I misheard this when the issue came up as including the stripping of periods.

@zorae the first option seems far better to be since it would immediately make the librarians aware of this new update.

However, I do not feel that any of this should need server-side processing.

If there is a clear consensus about this, then I would like to begin working on this rightaway since it seems simple enough to implement by adding the relevant eventHandlers for edit.html.

Let's try with this happening upon de-selection of the relevant fields that @zorae enumerated. I went ahead and assigned this to you, @Spaarsh.

@scottbarnes I have added the relevant JS and these are the results:
For editing an existing edition:

For adding a new edition:

For adding a new book:

@Spaarsh looks great! does this handle only normal spaces, or also other whitespace characters like tabs?

@zorae yes! I have used the JavaScript method trim() and the official document defines whitespaces here and it includes tabs as well. It also removes line-terminators such as /n.