Planning overhaul of author alternate names

[sbwhitt]

Mega-issue to overhaul the alternate names editor for author records. Eventually seeks to close:

• Better Editor for "Alternative Names" #8183
• Provide quick way to swap alias into the primary name #7846
• Translatable author names #7556

In addition to any new issues created during planning.

Describe the problem that you'd like solved

The current interface to manage an author record's alternate names needs to be updated. It's very hard to parse at the moment and prone to errors. Providing a more organized and intuitive editing interface will make it easier for editors to purge bad values and make sure that different languages are being represented.

The current alternate names input:

Values are unnecessarily grouped in one textbox and separated by semicolons.

Proposal & Constraints

1. Alternate names need to be separated into a list of different input fields, similar to the current autocomplete inputs (author section on work edit page for example).
   
2. An additional option to promote an alternate name to the author record's main title should be added alongside each value.
3. If available, the language of the alternate name should also be inputted alongside each value in order to track translations.
4. When viewing an author's page, the title should be translated into the user's current language if an alternate name of a matching language is available.

Proposed final solution markup:

Additional context

A new issue will need to be created to track step 3 if moving forward with that approach. Any community feedback is much appreciated as well as any more ideas about how to improve.

Stakeholders

@mekarpeles

[RayBB]

I don't have much of an opinion on design. However, soon (#710) we'll have access to the author's names in many languages as long as they have wikidata entries.
You can see a sample of how the data looks here https://www.wikidata.org/w/rest.php/wikibase/v0/entities/items/Q42

Edit: Also you might consider writing this component in Vue if it isn't already.

[sbwhitt]

I don't have much of an opinion on design. However, soon (#710) we'll have access to the author's names in many languages as long as they have wikidata entries. You can see a sample of how the data looks here https://www.wikidata.org/w/rest.php/wikibase/v0/entities/items/Q42

Edit: Also you might consider writing this component in Vue if it isn't already.

@RayBB
Sounds good. Thank you for the input. Tracking the language can probably be dropped for now then. If you want to update #7556 with that same info that would be helpful! As far as writing a new component in Vue; I would be fine doing that (and it honestly might be better to just write something from scratch), but I wasn't sure if we were continuing to create new Vue components. I can plan get that started for #8183.

[davidscotson]

One option for part 1 (adding a nicer interface for the current monoligual setup) would be to use a standard "tag" component like:

http://www.vue-tags-input.com/#/examples/validation

or

https://bootstrap-vue.org/docs/components/form-tags

(just randomly googled those, not specifically endorsing them) This format takes care of the ability to display multiple (possibly lots) of entries without becoming a long vertical list. You can easily add and remove entries, and they generally have basic validation built-in like, detecting duplicates with the option to customise it further. And are generally familiar to users, which is generally good for usability.

I believe there is already a tag-like interface somewhere in OpenLibrary, so possibly that could be re-used here.

[sbwhitt]

One option for part 1 (adding a nicer interface for the current monoligual setup) would be to use a standard "tag" component like:

http://www.vue-tags-input.com/#/examples/validation

or

https://bootstrap-vue.org/docs/components/form-tags

(just randomly googled those, not specifically endorsing them) This format takes care of the ability to display multiple (possibly lots) of entries without becoming a long vertical list. You can easily add and remove entries, and they generally have basic validation built-in like, detecting duplicates with the option to customise it further. And are generally familiar to users, which is generally good for usability.

I believe there is already a tag-like interface somewhere in OpenLibrary, so possibly that could be re-used here.

@davidscotson
Very cool, the tag system might be a good way to go. I'll definitely try that out as a I build out a new component. Thanks for the suggestion!

[davidscotson]

Whatever UI approach is used, it might be worth considering that the various Subject entry fields on Works follow the same pattern currently, i.e. multiple entries done as a delimited string on the front end, but stored seperately in the backend, but with comma seperators (and some auto-complete). A semi-consistent approach for these free-form text entries might be good.

[cdrini]

Speaking with @sbwhitt on call ; decided that it might be best to change the UI to use newlines instead of semicolons. That simplifies the project a ton and resolves the concern in #8183 .
Closing this issue since the project is now smaller in scope, and is covered by #8183 .