Proposal for reordering and creating a new translation relationship

[ApeKattQuest_MonkeyPython]

Proposal for reordering and creating a new translation relationship.

Summary:

Currently a translation work looks like this

That is:

 $originalauthor  wrote  $work
 $translationauthor  translated  $work

This proposal will replace that with the following:

 $originalauthor  wrote the original language-work of  $work
 $translationauthor  translated  $work

Problem:
Right now we cannot easily distinguish between works an author has written and works that are based on a work an author has written (including translations).
This leads to several problems:

• We cannot display these relationships separately in the interface (e.g. tabs)
• Semantically, these are actually separate (but adjacent) concepts, but we are serving them to the end user programmatically and visually as if they are the same (api, databases, future users)
• Adding this data is confusing for users (and it’s been annoying the stylemonkey (aka apekattquest-monkeypython (me)) for aaaages)

Proposed solution:

We already have the “provided story for” relationship:
https://bookbrainz.org/relationship-types/author-work

$author  provided story for  $work
(Indicates an Author wrote the original story that a Work is based on.)

This is for a link between an author and a work based on a work of theirs: adaptations, comics, abridged works, and so on.

However in our work we’ve found that having a separate relationship specifically for translations would make sense.

So, I propose creating this, sub-relationship:

 $author  wrote the original language work of  $work

And one of the suggested reverse phrases:

 $work  was originally written by  $author
 $work  was written in the original language by  $author

Now, the second wording is a bit clunkier, but so far, it’s the clearest way we’ve come up with that states plainly how this is different from the other relationships - the first can still be more easily confused with “provided story for”.
If you’ve got a better suggestion, we’d love to hear it!

Justification:

Doing this will fix and clarify many problems:

• api (fetching translations is hard without this, because the alternative is to fetch a lot more data which is inefficient)
• logically and semantically correct (an author has (usually) not literally written the words of the translated work)
• database (it will be much easier to order this data into corresponding tabs in the new tab view, if the data in the database has this underlining structure that defines them differently)
• easier for users (it should be clearer for users (especially once we update the docs) how to enter the data if we have semantically correct terms for “links between the original-work author and translated-work”)

[blackteadarkmatter]

I understand your point about how original and translated works are not distinguishable now, even though it was the translator that wrote the words of the translation, which does result in a confusing list in the interface. But I have two issues with your proposal:

1. “Wrote” seems the appropriate relationship for the author. That is how these works are presented and how we talk about them. I don’t think it should be a different relationship.
2. I think this confuses faithful translations with adaptations by comparing with the “provided original story” relationship.

What I would suggest is a “translated work” attribute for the work. It can just be a checkbox in the work form. This way you always identify translated works and originals. We can also have an “original” attribute in the “wrote” relationship, but I wonder if it isn’t unnecessary, if we can already set the work as a translation.

[UltimateRiff]

I think a checkbox (or in MusicBrainz terms, a relationship attribute) could be an ideal solution for this. additionally, it might be possible to detect the presence of a Translator relationship and automagically set that attribute? unless there’s cases where we don’t want that

[mr_monkey]

That is interesting, I’ve been wondering about this option myself.
Where would you put this relationship attribute?
I don’t mean on the page but rather in the data; we currently have three relationships, how would you suggest modifying them?
[author] wrote [translated work]
[translator author] translated [translated work]
[original work] is a translation of [translated work]

[jwillikers]

Having added many translated works, I’m all for this. Being able to list original works by an author is critical. I’ve had original works that use the provided story for relationship, and this relationship relates to translated editions as well, though it is completely distinct from the author of the original work in the original language.

I prefer $work was originally written by $author as it seems distinct enough from provided story for. The second form might be slightly confusing for edge-cases, such as works written in multiple languages.

[ApeKattQuest_MonkeyPython]

In MusicBrainz we actually do have a [translated] attribute for the work-work relationship: Relationship type / Other version - MusicBrainz
And I agree, that that would absolutely be ideal.

We do not, however (𝑦𝑒𝑡) have relationship attributes, including date ranges or free-text fields. (taking a gander at the relationship table on MusicBrainz is very inspiring (and overwhelming ) Relationship types - MusicBrainz )

That being said, it’s unknown when we will be able to develop relationship-attributes on BookBrainz - we have limited developer time and resources (even our lead dev, @[~mr_monkey], cannot utilize all his time to just BookBrainz, but also works as a lead dev on ListenBrainz)

Additionally, adding relationship-attributes will require quite a lot of work and rewriting old code, even if the work was started Right Now it would take quite a bit of time and effort.

However, this change, can be done, like, Today by myself, which will let us differentiate these concepts asap.

Later down the line, hopefully, we can bake in the relationship into a writer-one with attributes!

[mr_monkey]

Thanks for the feedback everyone!
@ApeKattQuest_MonkeyPython and I had more discussions on the topic.

We agree that a relationship attribute on the Author-Work relationship would be the ideal way to enter this information, as was suggested here.
On a technical level, it would also be sufficient to differentiate translated work when we load an author page, without needing to fetch each work additionally (the {original} attribute is attached to the Author-Work relationship, which we have access to, rather than the work).

We do currently already have some limited relationship attributes, but they are kind of hidden and apply only to ordering series items.
It will require some amount of development to properly add relationship attributes in the website UI and the server code, but it is much less work than we originally feared.

As a consequence we want to update the proposal

• add this “original” (or “original language”) relationship attribute, instead of adding a new relationship
• update the relationship editor in the edit page to support relationship attributes (see mockup)
• update the entity display pages to show these relationship attributes
• (at a later date) on author pages, use this attribute to separate translated works in another tab

This will also pave the way for adding more relationship attributes in the future.

As a quick mockup, in the UI this is what we are looking at:

One aspect we are still discussing is the wording, and your input would be precious.
Wedging {original language} into the “Author wrote Work” sentence, as pictured in the mockup above, is not as clear as rewording the whole thing, but it is easy to implement without introducing more issues. Would that be acceptable?
Other easy-to-implement options include “Author {originally} wrote Work”, which we find ambiguous, and “Author wrote Work {original language}”.

Your opinions on all this are welcome.

Edit: more mockups of the entity page relationships UI, with a couple of options:
On the translated work page:

On the author page: