[chaley]

Originally Posted by arspr

Any hint about the & feature?

I have reread the pertinent posts, and I now think I understand what you mean by "the & feature".

To summarize, you want a column that contains names of people, mimicking the author column, including separate sort values. Such a column would be used for editors, translators, friends, and what-have-you, and would have several characteristics:

1. It would be 'multiple', possibly containing more than one name.
2. It would be separated by &, not comma. Commas would not be significant.
3. Completion would use author-like rules, including the tweaks.
4. It would sort using author_sort rules, including the tweaks.
5. It would display using author rules, including the tweaks.
6. The author_sort value can be set independently of the name.

Of these, the first 5 are probably doable because none of the 5 radically break existing database and code 'rules'. The last one, the separate column for the sort value, would require changing the database, which is more problematic.

My thought is that such a column would be similar to a tags-like custom column (already multiple), but with the behavior indicated by lines 2-5. The required changes touch a large number of bits of code, but as I said above, probably doable.

It is worth noting that such a column would create a new pool of names. This matters if a person is both an editor and an author. The standard searches would be role-based (author, editor, ???). A grouped search term could be made to amalgamate all the fields together for searching, but that isn't a perfect solution. For example, renaming the person in one role would not rename the same person in another role.

The question: Is this work worth doing without the separate column and given the role-based behavior?