Translation Proposal
Document Actions
Submitted by
brentmh.
on 2005-05-19 19:13.
Since Max brought up translations in a previous blog entry I've been meaning to write up my proposal on the subject.
Legally, a translation is a derivative work. This is affirmed in the text of the creative commons license. So the only legal requirement is that the translation retain attribution for the original author. Everything else is pretty much up to us. The goal is to design a system that works well for all concerned parties. In particular, we must meet the needs of:
- Readers
- Translators
- Original Authors
I propose the following design:
- Multiple translations allowed
- in keeping with our philosophy o open contribution, we should allow anyone to publish a translation of a module into a given language. This is very similar to the way we allow anyone to publish a module on a particular topic.
- Ratings
- to aid readers in selecting a translation if there are muliple available we should have a mechanism for readers to rate translations. This should be separate from any system for rating the content and should assess only the quality of the translation. In the future we could have a "trusted translator" status for translators whose ratings are above a specific level.
- Separate modules
- our system models each individual work as a module and since translations are legally derivative works it makes some sense to keep this model. This allows each translation to have all of the features of an individual module: This also easily supports multiple translations.
- Special derived copies
- again, since translations are legally derivative works it makes some sense to make use of our existing system for storing that information. What is needed is an additional flag to identify a derivative as a translation.
- Translations derive from a specific version
- translations will be created from a particular version of a module so they should identify that. Then the version of the translation can advance independently of the version of the original so corrections and improvements can be made. This is already how derived copies work.
- Translations can be reparented
- when the original module is later revised, translators shouldn't have to create a whole new translation module just so it can derived from the new version. I propose that revisions of translations can be reparented to a later version of the original. Translators should be notified when revising a translation that the original module has changed and asked whether or not to reparent.
- Show availability
- It should be very clear to readers when translations are available for a particular module. I think the clearest possible way is to have a portlet that lists available translations. If there are many of them, perhaps a link to a page listing the translations. When listing translations for readers, each translation should also list the translator and rating. Also, if there is not a translation available for the current version, the page should lists translations of previous versions which may be better than nothing.
- Encourage translation
- When viewing a module there should be a link for potential translators that provides clear information on the steps required to contribute a translation. If the reader is logged in, there should be a button to begin a translation in the user's workspace.
- Reuse media
- When possible, translations should reuse media from the original (unless it too needs translation). When a new translation is started the system should rewrite the media tags to point at the original module's files.
Let me illustrate with the following scenario:
- Doug Jones publishes a module in English on DSP that receives an ID of m15000. He makes several revisions until the module stands at version 1.5.
- Patrick Frantz's group makes a translation of m15000 into Chinese. This new module has an ID of m15001 and a version of 1.1.
- Patrick's group makes some changes to the translation until it reaches version 1.3.
- Doug adds a new section to m15000 and publishes the revision as version 1.6. He then adds a figure and publishes it as version 1.7.
- Patrick's group checks out m15001 to update the translation to include Doug's recent changes. They reparent m15001 to point at version 1.7 of m15000 and add the new translated material. They then publish m15001 as 1.4
m15001 translates m15000 1.1 1.5 1.2 1.5 1.3 1.5 None 1.6 1.4 1.7
In other words, m15001/1.1-1.3 are translations of m15000/1.5. m15000/1.6 does not have a translation, and m15000/1.7 is translated by m15001/1.4
Unresolved questions:
- Roles
- what role(s) should the original author have on the translation? Some people have said that the original author should stay the author on the new work and the translator should be the maintainer. Thoughts? Who holds the copyright on the translation?
- Metadata
- the module title should probably be translated, but what about keywords? abstract?
Re: Translation Proposal
Posted by
reedstrm
at
2005-05-23 10:05
Re: original author's role: I don't think we should try to support the traditional model of translations of works. Tight control of translations is one of the things you give up with the CC "derivatives" license clause. However, I think the oroginal author _should_ have some additional powers. How about "recommended derivates" on the original module? This would apply to _all_ derivatives, not just translations.
Re: Translation Proposal
Posted by
cbearden
at
2005-05-23 16:57
Most, maybe even all of this sounds right to me.
Under the rubric "Show Availability", I wonder about also
(a) perhaps having a little "Translation Available" icon appear next to a module title in search results;
(b) displaying an auto-generated list of links to translations in the "Supplemental Links" section of a module.
From your comments in "Reuse media", it's clear that the behavior in deriving translations will be different from deriving same-language copies, in that deriving a translation will not cause the media files in the original module to be copied into the translation. Or would the author deriving a translation copy be presented with the choice: either rewrite links to point to the original media files, or copy media files over to the translation module?
It would probably be too complicated (and confusing to the user) to create special acquisition magic, such that by default media files in the translation module are used, but for those which are not present in the translation module, the same-named files from the original module are displayed.
Under the rubric "Show Availability", I wonder about also
(a) perhaps having a little "Translation Available" icon appear next to a module title in search results;
(b) displaying an auto-generated list of links to translations in the "Supplemental Links" section of a module.
From your comments in "Reuse media", it's clear that the behavior in deriving translations will be different from deriving same-language copies, in that deriving a translation will not cause the media files in the original module to be copied into the translation. Or would the author deriving a translation copy be presented with the choice: either rewrite links to point to the original media files, or copy media files over to the translation module?
It would probably be too complicated (and confusing to the user) to create special acquisition magic, such that by default media files in the translation module are used, but for those which are not present in the translation module, the same-named files from the original module are displayed.
Re: Translation Proposal
Posted by
mhusband
at
2005-05-23 17:22
Regarding the reparenting of an existing translation, will we provide a tool for comparing the original parent to the new parent and generate a change file? This would be very useful to the translator. It would enable them to reuse the majority of their original translation and just make changes where the original and the new parent modules differ. The current change tool creates a change file of the differences between the version of a module in the author's work area and the last published version. It does not allow you to pick which versions of the original or new module you want to compare.
Re: Re: Translation Proposal
Posted by
reedstrm
at
2005-05-24 09:31
This was my next topic to comment on: how much technical support for "reparenting" do we need to be able to do? There are a number of "translation assist" frameworks out there. At minimum, finding the diffs just in the original (parent) line would be most useful: a textual diff of the transaltion vs. the original isn't going to be very useful.
That is, If I author a translation parented vs. version 1.4 of a module, and that module revs., I need to see diffs between 1.4 and 1.5, not between my version 1.1 and 1.5 of the parent. But as I edit, diffing the translation side-by-side with the parent diff: that would be cool.
That is, If I author a translation parented vs. version 1.4 of a module, and that module revs., I need to see diffs between 1.4 and 1.5, not between my version 1.1 and 1.5 of the parent. But as I edit, diffing the translation side-by-side with the parent diff: that would be cool.
Re: Translation Proposal
Posted by
reedstrm
at
2005-05-24 09:47
I've been thinking more re: authors and attribution on derived works (after discussion after the meeting yesterday.)
I think there are a couple principles at war, here.
1. Nothing should be published under my name without my direct consent.
2. I should get appropriate credit for my work.
Regarding the first, this is the thing potential authors always brought up as the boogyman when we describe the "anyone can edit" feature of CNX: "Other people can change whatI put up?" We always said "No", but that's not true right now - I can derive Brent's module, say and completely change it, and he's an author. I can even remove myself as author, so he's the only one.
But the second is important, as well. If Matusma Toyoda wants to do a translation of say, Macbeth into Japanese, there's a big difference in expectation if it's "Macbeth" by William Shakespeare, translationed by Matusma Toyoda, or "Macbeth" by Matusma Toyoda, based on a work by William Shakespeare. I'd expect the later to be a rework of the story, not a direct translation.
If I derive a copy of Brent's module, just to fix all the typos, yes, he should be author. But I don't think we can let him automatically become an author. That's the price of getting the credit: you have to at least once approve the collaboration.
But, but, but: not all forks are that tightly coupled. If I want to rework Brent's module dramatically, I need to be able to make a "based on" type derivative, without him being able to block me.
Implementation wise, I think this might all be covered by having a derivative optionally create a collaboration request with the original author. This would even be removeable, without the parent author's consent. As an extra "plagarism" check, perhaps we could also check the size of the diff, and if it's not very large, and the original author is not present on the new suggest to the "new" author that this might be a in appropriate fork ...
I think there are a couple principles at war, here.
1. Nothing should be published under my name without my direct consent.
2. I should get appropriate credit for my work.
Regarding the first, this is the thing potential authors always brought up as the boogyman when we describe the "anyone can edit" feature of CNX: "Other people can change whatI put up?" We always said "No", but that's not true right now - I can derive Brent's module, say and completely change it, and he's an author. I can even remove myself as author, so he's the only one.
But the second is important, as well. If Matusma Toyoda wants to do a translation of say, Macbeth into Japanese, there's a big difference in expectation if it's "Macbeth" by William Shakespeare, translationed by Matusma Toyoda, or "Macbeth" by Matusma Toyoda, based on a work by William Shakespeare. I'd expect the later to be a rework of the story, not a direct translation.
If I derive a copy of Brent's module, just to fix all the typos, yes, he should be author. But I don't think we can let him automatically become an author. That's the price of getting the credit: you have to at least once approve the collaboration.
But, but, but: not all forks are that tightly coupled. If I want to rework Brent's module dramatically, I need to be able to make a "based on" type derivative, without him being able to block me.
Implementation wise, I think this might all be covered by having a derivative optionally create a collaboration request with the original author. This would even be removeable, without the parent author's consent. As an extra "plagarism" check, perhaps we could also check the size of the diff, and if it's not very large, and the original author is not present on the new suggest to the "new" author that this might be a in appropriate fork ...
