Wikisource:Requests for comment/Annotations and derivative works

__NEWSECTIONLINK__

=Overview= Consensus on the proposal made on Scriptorium is that, in theory, some kind of derivative works may be within the scope of Wikisource. This RfA is intended to work out the details: What derivatives are allowed? What are derivatives? How should they be presented? etc.

In the past there have been problems arriving at any consensus on annotations, which is why this unusually detailed page is here. Past discussions can be found at Wikisource talk:Annotations (especially from not wikipedia, not wikibooks onwards), Wikisource:Scriptorium (September 2011), as well as Annotations/types, Wikisource talk:Annotations/types and past short Scriptorium discussions that seem to go both ways.

At the same time, the objections to annotations also cover other derivative works on Wikisource. None of the policy regarding any of these works has ever been approved and there are some that don't even have proposed policy pages (or even proposed guidelines).

The three main types of derivative work currently hosted on Wikisource are the "CAT" trio:


 * 1) Comparisons - examples: Category:Comparative texts
 * 2) Annotations - examples: Category:Wikisource annotations (many wikilinked texts not included here)
 * 3) Translations - examples: Category:Wikisource translations

Of these annotations and translations are the most common. Other types of derivative works can include deannotation (stripping published annotations to reverse-engineer pure versions), grangerisation (adding illustrations), errata, and probably many more. As part of this, as found in past discussions, we also needs to determine what counts as an annotation and what does not.

(NB: For the purposes of this RfC, "pure" refers to the original, unaltered version of the text.)

Summary
The community appears to have reached consensus on the following points:
 * Professionally published annotated works are accepted per WS:What Wikisource includes. They are not covered by any annotation policy.
 * Comparison pages of any kind are not accepted on Wikisource. A technological equivalent, potentially using an adapted DoubleWiki extension, could be used if it can be developed.
 * The translation of single words or phrases counts as an annotation.
 * Annotations in general are allowed in Wikisource.
 * Wikilinks are annotations and are allowed in Wikisource. The creation of wikilinks is optional, where created they should be based on context, the type of work and the likely reader. There are a number of ways wikilinks could be miss-used (interpretative vs. non-interpretative) and a separate discussion will identify acceptable types of wikilinks.
 * Translations as original works of Wikisource contributors to be hosted in a new Translation name space. Formally published translations would be hosted in the main space with the appropriate licensing for that work.
 * Wikisource user translations are appropriate for Wikisource. They will be hosted in their own names space (per Special_namespace). There should only be a single translation to English per original language work. A scan supported original language work must be present on the appropriate language wiki, where the original language version is complete at least as far as the English translation. There was much conversation about language competence, but a clear definition and measure was not achieved. Lacking a clear guideline for language competence, the general expectation for accuracy of translation here, is the same as it is at any sister wiki work. Some discussion about requiring a formal or Semi-formal project for each translation, but a clear consensus on a requirement was not reached.
 * Ban on purely decorative illustrations regardless of context. Informative illustrations fall under the annotation rules and must relate directly the text in question.
 * Some types of annotation are specifically allowed or disallowed by Wikisource annotation policy. Other wiki projects have differing policies, Wikisource is under no obligation to host any type of annotation, based solely on the argument that it is out of scope for all other wiki projects.
 * Annotations where allowed, must meet the expectations of neutrality and verifiability. Interpretive annotations are never allowed.
 * Deannotation (stripping the annotation out of an published version) is allowed in very limited situations; 1. The work has never been published without annotations (or no originals are believed to exist). 2. The complete original version to be deannoated is hosted on Wikisource. 3. All annotations are removed, leaving only the unannotated work.
 * No community support for Derivative and/or Annotation Name Space. Translation namespace is discussed elsewhere.
 * Where previously existing & accepted works somehow no longer meet the new/current criteria for inclusion in moving forward - some degree of reasonable accommodation to keep & grandfather-in such works should be sought after first and foremost whenever possible.

If there is additional disagreement before the RfC is conclused, these points can simply be reopened. - AdamBMorgan (talk) 18:37, 20 March 2013 (UTC)
 * Two more added. Jeepday (talk) 11:17, 24 March 2013 (UTC)
 * Two more added. Jeepday (talk) 22:25, 26 March 2013 (UTC)
 * One more added JeepdaySock (AKA, Jeepday) 15:12, 1 April 2013 (UTC)
 * One more added JeepdaySock (AKA, Jeepday) 10:56, 5 April 2013 (UTC)
 * Three more added Jeepday (talk) 11:43, 10 April 2013 (UTC)
 * Add Grandfather clause from, Foundations for all points. Jeepday (talk) 23:25, 15 April 2013 (UTC)
 * One point amended. - AdamBMorgan (talk) 19:13, 7 June 2013 (UTC)

=Points for discussion=

Foundations for all points
{{closed|This section covers early discussions of general expectations and a sub section about Deannotation. Other then a grandfather clause, all points seem to have made their way in to discussions and/or have been included in closure notes of related conversations. Jeepday (talk) 23:24, 15 April 2013 (UTC) |text= Regardless of the particulars of any of the points to follow that may or may come to fruition in the future, what are the minimum standards that should be enshrined as policy then met by contributors prior to the creation of those various types of works as eventually agreed upon by the community as yet to be fully described in the sections that follow?


 * Comments:
 * No matter the type of [derivative] work desired, the prerequisite for inclusion of that work be the full & faithful transcription of the work as near as possible to its published form first. Nothing should be presented as annotated (save those works utilizing the basic in-line wikilinking as a form of annotation) without the faithful completion of the transcription & proofreading of the work as published taking place prior to the creation of that annotated derivative. Nothing should be presented as a translation without the faithful completion of the transcription & proofreading of the work as published, and in the language that it was originally published in, taking place prior to the creation of that English language translation for the work.  In short, no derivatives of any flavor (save those works utilizing the basic in-line wikilinking as a form of annotation) can be hosted here on en.WS until its unaltered, faithfully transcribed & proofread parent also exists (preferably beforehand). Any user annotated/translated/other without such a base work being hosted somewhere in the Wiki-World, if not on en.WS itself, at the same time is of little added-value to the potential reader and of questionable fidelity at best in regards to the quality standards of Wikisource. -- George Orwell III (talk) 00:22, 7 March 2013 (UTC)
 * Utter agreement. Ashamed I did not express this point myself! MODCHK (talk) 00:33, 7 March 2013 (UTC)
 * Good wording George, keeping in mind that we have some existing translations that would not hit this bar, and I would be loath to delete existing works that didn’t meet a bar that had not been set at the time of creation. JeepdaySock (AKA, Jeepday) 11:47, 7 March 2013 (UTC)
 * I agree as well and I'm kicking myself that I didn't include it in the first place. - AdamBMorgan (talk) 20:37, 7 March 2013 (UTC)


 * In addressing concerns (such as the one voiced just above by Jeepday) over the possible outcome or outcomes borne from the discussion points that follow - where previously existing & accepted works somehow no longer meet the new/current criteria for inclusion in moving forward - some degree of reasonable accommodation to keep & grandfather-in such works should be sought after first and foremost whenever possible. -- George Orwell III (talk) 23:10, 7 March 2013 (UTC)


 * Support to George's wording.--Erasmo Barresi (talk) 20:07, 8 March 2013 (UTC)

Separate foundation principle with respect to deannotation

 * I don't understand why this should be such a bedrock principle. If a translated work is accompanied by pages and pages of commentary, that in itself testifies to the significance of the work, and its worthiness to being presented in and of itself.  If translators hesitated before the effort of translating such a significant work, it's natural that they would want to make it accessible as possible with translator annotations.  But it's the original text which is historically significant, not the commentary about it.  It's more important that we get significant primary sources on to the internet that are absent from the internet, than the faithful reproduction of the scans which contain them.  Otherwise you are using the very largeness of significance of the work against it!
 * What about the Mishnah, the Talmud, Virgil, the later Roman and Greek historians, Plotinus, Dante, Descartes? All historically significant, all possibly larded with commentary.  We need to make an exception for historically significant works, as is already supposed to be stated on the Wikipedia Wikisource article, that certain unpublished works (such as just-the-translation in and of itself) could be included in Wikisource if they are historically significant!  ResScholar (talk) 06:25, 8 March 2013 (UTC)


 * This comment is not to detract from the significance of your statement, but more to reflect that if they are that lauded as works, and with that sort of book age, I would much rather see a learned derivative version, than a Wikisource self-published version. — billinghurst  sDrewth  14:11, 8 March 2013 (UTC)
 * Our differences in preference are represented by different philosophies of educational thought. The one I am following is described in the Wikipedia article Educational perennialism which responds somewhat to what you may object to in my position. ResScholar (talk) 07:24, 10 March 2013 (UTC)
 * That is not to say that Educational perennialists object to introductions to these difficult works. A group of them made a large index to a lot of these classic works that you can still buy used and whose copyright expires in Australia and Canada in fourteen years.  ResScholar (talk) 07:40, 10 March 2013 (UTC)
 * Per "difficult", Hutchins (mentioned in the Wikipedia article) wrote in 1952: "If you will pick up any one of these books and start to read it, you will find it not nearly so formidable as you thought.  In one way the great books are the most difficult, and in another way the easiest, books for any of us to read.  They are the most difficult because they deal with the most difficult problems that men can face, and they deal with them in terms of the most complex ideas.  But, treating the most difficult subjects of human thought, the great books are the clearest and simplest expression of the best thinking that can be done on these subjects.  On the fundamental problems of mankind, there are no easier books to read."ResScholar (talk) 11:09, 10 March 2013 (UTC)
 * Respectfully, I don't believe there is any conflict between my stated and your position in response to it, but maybe there is some lack of clarity on a point or two that is still obstructing the possible harmony between the two points-of-view somehow. I don't believe anyone takes any issue with your desired goal(s) or questions the fact the works you've described as being anything other than positively meeting the hosting requirements (save those instances where copyright protections may still play a role in today's terms, of course). And I highly doubt anyone can (or would) question the integrity of your contributions to Wikisource nor fail to appreciate the value in retaining your continuing participation with it as we move forward at the same time. Plus your logic and rationale for wanting to present works of historical significance (but never formally published by 'a traditional' or 'the modern' perspectives) without the seemingly endless third party analysis or commentary added across the vast passage of time since the creation and recognition of those ever-enshrined core translations is not lost on anybody participating here either. So, as far as I can tell, the lingering issues, if any, seem to revolve around the means to your end - not the substance of it. Perhaps reviewing the work flow you're looking to follow (de-annotation?) with these works might shed some further light on any remaining sticking points? -- George Orwell III (talk) 11:23, 10 March 2013 (UTC)
 * Thank you for your consideration of my concerns and the compliments. I'm worried I'll run into another "Owen's Aristotle" in the cases I mentioned above with a lot of layers of notes.  What I would propose to do if that happens is clearly mark it as a de-annotated index page to avoid confusion with more faithful transcriptions from scans, and transcribe the original text to a proofread version. ResScholar (talk) 12:29, 10 March 2013 (UTC)
 * Ah-ha! Just as I suspected. We are already at least in ~90% agreement to what I would deem to be the most rational approach given the particulars comprising a specific [yet hypothetical; but still absolutely plausible] scenario. The only issue I take with your outline comes at the very end: ... and transcribe the original text to a proofread version. In my opinion, and maybe others can chime in here, one can absolutely ... transcribe the original [historically significant but never really considered to be formally published] text [minus all, or just 'some', of the since-added layer or layers of notes, analysis, commentary and similar, attributed to persons or parties other than the original author in the millennia that followed the point of generally recognized creation] to a proofread version [and a proofread state] - BUT - one absolutely should not do all of that again & exactly as now-expanded-upon within the bolded - plus - actually forward the status of the resulting transcriptions to 'Proofread - needs Validation' in the Page: namespace while the thumbnails being generated from the source file clearly still show all the previously stripped-out-in-transcription-only of layers of 3rd party added notes & stuff. One should, however, indicate the actual status or level of transcribed text quality only after the core text has been transcluded to the main namespace by using the older TextQuality template regime (also only in the main namespace).  Hopefully, the above will bring us even closer on this point now. If not - feel free to pick it apart. -- George Orwell III (talk) 15:56, 10 March 2013 (UTC)
 * As much as that is a reasonable compromise between our two positions, I still don't know why you're taking that position, especially if the final text would appear in a new kind of namespace. I would see two different clearly labeled indexes of the same scan with two different proofreading outcomes as fine—especially, as you mention later, because the outcomes wouldn't be related to any knowledge of the subject matter.  I would take up your compromise position, except for the fact that the colored bars that show text quality would be all red and would not match the three-quarters block right next to it.  If the bar could be eliminated I guess what you are proposing would be fine. ResScholar (talk) 07:15, 12 March 2013 (UTC)
 * "Why" I have come this position is largely due to keeping with what I would view as the well-established expectation of what the transcription of any source file under the normal Proof Reading process, which utilizes the Index: & Page: namespaces to help facilitate that aim, basically entails - the content in the left-hand user contributed section should match the content found in the thumbnails generated from the scans comprising a source in the right hand column as much as possible. Simply put - proactively stating the purposeful omission of content still found in the thumbnails of a scanned page does not near my understanding of as close as possible. It falls more under as much as needed to be frank about it. And to be just as blunt, your view to omit such obviously present yet deemed superfluous content, while quite reasonable for the goal of a derivative based end-product, should not preclude the possibility & availability for others to undertake the further transcription of the work with a just as worthy aim to fully and faithfully reproduce the work to match it as close as possible to it's formally published form (warts and all). In addition, this is the first I'm reading anything about "...two different clearly labeled indexes of the same scan..." in all that has transpired on this to date. The root of problem all along has been the single source file, the creation of a single Index: based on the filename of that single source-file and all the Pages: broken out from under that single Index:, all prefixed with the same pagename as the Index:'s in their designation, being used for more than a single purpose (de-annotation, translation, etc. in addition to "straight" Proofreading). Now if there was a way to create Two separate and unique Index: pages from one single source file, I'd much rather be for doing that than splitting hairs over this!!!
 * What about [//en.wikisource.org/w/index.php?title=Wikisource:Scriptorium&diff=prev&oldid=4237485 here], where I complain that "I was trying to point out that there could be a one-many relationship from scans to editions—also squelched." [by Adam when he wrote in Versions "Note that Wikisource should not have more than one copy of a specific edition."]? To clarify, my sense of "edition" means a de-annotated edition, a wikilinked edition, etc. while Adam's sense of "edition" meaning a "single distinguishable published version with a specific date or edition number".  I was wanting to assign one scan to two (or in rare cases more than two) outcomes appearing on Wikisource.  ResScholar (talk) 20:05, 12 March 2013 (UTC)
 * Still, it was the need for such clarity in the use of the term "edition" that begged the clarification by (then the consensus with) Adam's wording. You are not the originating author(s) nor are we the originating publisher(s) of the content in question so the use of edition in your sense is not in line with the understood meaning of the term for our purposes here on WS. Basically, "you" are referring to what "we" would term more like "a [user-generated] deannotated [never-before formally published] derivative of a [properly recognized as formally published] edition. It is also understood, for discussion's sake, that some core content (Socrates, Plato and similar super pre-printing press era works) cannot technically be viewed as being formally published at or around the time they were actually created - only subsequent, 3rd party, later reuse of that core content was ever formally published by today's standards. In addition, it is also realized that at some point one or more translations of historic content in this vein have come to be recognized as the definitive or leading translation(s) over any/the many others generated since creation. Since the likelihood of such straight and pure core translations ever being published as stand-alone works appear to be slim to none, some accommodation to reuse such core translations should not hinge upon the presence of additional 3rd party commentary, references or other supporting notations typically found along with these core's in later formally published works. The question on how best to fully proofread as published vs. how to partially proofread some of what was published under just one Index: page built from a single source file remains at the the forefront here. -- George Orwell III (talk) 01:50, 14 March 2013 (UTC)
 * And I also talked to you about my deannotated work being the foundation of an annotated work; how else would you do that but by copying the partially-complete text into a second index? We're mounting almost everything into an index these days, aren't we?
 * I'm not aware of any "second index" (more specifically - a second, derivative specific, proofreading enabling, Index: namespace page) playing a role in any of this; specifically, being created in addition to the first Index: with both pointing to same series of scans within the same single source file on Commons. The title given to the first Index: needs to match the File: name used when the source file is first uploaded to Commons; otherwise it won't recognize any of the single pages in the source file for pagelist assignment in the Index: template or for Page: namespace individual scan-page breakout. That said, I'm confused as ever on what exactly you meant by that "second index" or are referring to in practice by utilizing a "second index". -- George Orwell III (talk) 01:50, 14 March 2013 (UTC)
 * So shoot me, I thought it was possible to clone Index: pages. I apologize for the confusion.  Not to deny the comedy of errors I involved everybody in by that mistaken identity, what is the big deal about cloning scans that it needed to be included in Versions?  I issued a proposal in the Versions discussion with an equivalent effect to allow cloning of indexes, just before the discussion closed, and it was ignored, probably because it was not comprehensible to those who knew you couldn't clone indexes.  If I were to repropose, I'd say:  We could put an original scan on Commons, and have clones of the scan, labeled differently, and stored on Wikisource itself, to be used in special derivitive works.  I never meant to argue derivitive outcomes were to monopolize one single scan.  But I still think, properly labeled, multiple indexes, now considered as being taken from multiple scans, could have less than what appears on scan page and still do justice to the work if the criteria for removal was not related to the content but to the form of the work. ResScholar (talk) 08:31, 15 March 2013 (UTC)
 * Bang. Bang-Bang. That was for throwing a wrench in the works with your "index" terminology. And so, hopefully in conclusion, I would be agreeable to uploading a straight source file to Commons for normal transcription and proofreading purposes and uploading an identical second copy to WS with a derivative specific class as part of the file name to be used for the purposes of user generated derivatives. Of course all this minutia would be clearly noted on the relevant pages and/or namespaces for both the parent and child source files. THAT would be far better than trying to "share" one source file's Index: for more than just the typical full & faithful transcription that matches the original as close as originally published. -- George Orwell III (talk) 14:18, 16 March 2013 (UTC)
 * Stopping there, taking a step back - and largely just in theory - say we've uploaded a source file to the File: namespace (call it Perverted Pick-up Lines of Plato.djvu). The usual Index: and Page: namespace children are produced as a result of that upload and that is where a full and faithful transcription of the work is taking place. Would it be possible to create File:Perverted Pick-up Lines of Plato (deannotated).djvu as a redirect to File:Perverted Pick-up Lines of Plato.djvu and be able to create a second and separate Index: file (Index:Perverted Pick-up Lines of Plato (deannotated).djvu) independent of the first to handle only the kind of specialized derivative work we've been talking about around here? Would that work (if it works that is) any better for everyone/anyone than the (my) previous? -- George Orwell III (talk) 08:58, 12 March 2013 (UTC) Update: using a redirect does create a second Index: just fine but no thumbnails come through in the Page: namespace however -- George Orwell III (talk) 14:18, 16 March 2013 (UTC)


 * If the greatest problem all along was with "preclud[ing] the possibility & availability for others to undertake the further transcription of the work", we just misunderstood each other, and your solution is fine. But if you're going to insist the de-annotated thumbnails be red, I would still rather not see a red colored progress bar next to a proofread Text-quality indicator on the main namespace.  ResScholar (talk) 20:05, 12 March 2013 (UTC)


 * First, I thought we agreed it was actually OK to transclude one index to many mainspace pages. That's part of what Serial works is about, which came out of the Versions discussion (it is currently unfinished because I think I need to illustrate the point and I haven't had time).  Secondly, but related, I think I have misunderstood this thread.  I assumed that there would be one scan which would be proofread complete with annotations.  Then the whole thing could be transcluded to the mainspace as a pure version (again, with annotations) and also transcluded either to a new namespace or to a different page in the mainspace for a deannotated version.  This could be achieved, as mentioned below, by wrapping each annotation in a template that would detect the pagename and/or namespace and produce the appropriate text. - AdamBMorgan (talk) 21:51, 12 March 2013 (UTC)
 * Generally, I am of like mind on your second point but the apparent objection(s) to that here, I guessing, is based in something similar to being 'too onerous a requirement' to meet in the existing ProofReading regime. While the optimal approach to de-annotation might be the de-annotation of the content from appearing in the source file itself, doing that requires specialization currently not normally easily achieved around here for starters while also something unaccounted for by current policy since it deviates from primarily looking to host works as faithfully as possible to match it's published form. We are now left to entertain the possible reuse of a single source File: and Index: to achieve more than just that primary goal as a result. Having the full and faithful transcription completed along side its (de)annotated sibling derivatives seems like a rational threshold to be met (at least in my view) but ResidentScholar makes reasonable arguments against applying that threshold without some accommodation for deviations at the same time. I don't know if there will be a final consensus either way that goes beyond or entirely rejects just what the two (now three) of us have discussed (for the most part) so far, however. -- George Orwell III (talk) 02:19, 14 March 2013 (UTC)
 * My intention, even before the Organon was a subject for discussion as a typical, but hopefully rare, example, was to make understanding the two outcomes of two transcriptions as simple as possible. Looking back, I think I would have named the index (Index:O. F. Owen's Organon (Annotated)) so there was no misunderstanding throughout.  But even if you put both transcription versions on one index, one or the other or both transcriptions would have to be shown next to each scanned page, which would never match when the index page was accessed through page links from one and/or other of the outcomes (the transclusions), because there are notes throughout and not just chapter introductions.  This is a complication, leading to misunderstandings like the one above, which is why I prefer the simpler way.  George calls the deannotated transcription as presented "as much as needed".  While this is not a rousing seal of approval, I think I will have to be content with that.  ResScholar (talk) 00:19, 13 March 2013 (UTC)

}}
 * I want to stop here and mention an exception to the "only the original text" rule. I stated a while back on a user's page about wanting to wikify intratext references.  Sometimes these intratext references are found in the notes.  You had made the comment about including all the sidenotes or all the translation notes, with no picking and choosing.  I would want to define intratext references as a single class of notes.  I don't know if these kind of intratext references when the author says "earlier in my argument I said such-and-such", but the author doesn't say where they said it, will ever come up again in a translation, but I don't want to surprise anyone. ResScholar (talk) 12:29, 10 March 2013 (UTC)
 * The concern over this point and the initial wording as a result was more about preventing Users from selectively including or excluding bits and pieces from one or more "layers" of 3rd added content, such as the previously mentioned notes, analysis, commentary, etc., than anything else. Basically, the reasoning behind the suggested course of action was a.) first and foremost to avoid any odd, unforeseen final rendering or transclusion issues resulting from the 'nitpicking of notes'; and then b.) to minimize the temptation to champion or retard one existing 3rd party "voice" by selectively or systematically isolating or eliminating the other(s). Beyond that, I'm agreeable to letting common sense and user discretion dictate any needed deviations from my originally suggested threshold on this point - though imho any deviation from any standard at the same time should come with a User explanation somewhere - Talk Page, edit summary, Project page, notes field, whatever - as long as there is a time-stamp better indicating said deviation was forecasted around the time of editing and not forced in at some point much later or when questioned. Adding/amending the wording itself for possible caveats is also agreeable if my "opinion creep" is getting on anyone's nerves by now.  -- George Orwell III (talk) 15:56, 10 March 2013 (UTC)
 * No, I agree that rule requiring stating beforehand which notes you will be including (and to include all of the references or all of whatever layers) is best, if not essential to guiding potential collaborators. Just like on the Organon page, from the beginning I wrote "deannotated", meaning all of them removed.  I also made a time-stamped proposal to Harryjamespotter1980 how I'd like to add references later, or I might have put that somewhere on the index page too. ResScholar (talk) 07:15, 12 March 2013 (UTC)
 * I would transclude it in the "Derivative" namespace if that's where we're going with these. Otherwise I would mark it in mainspace as deannotated or unpublished in the title, however we like and never make it the primary version of the text so we can save a place for the complete version, if we need to do that too.  ResScholar (talk) 12:29, 10 March 2013 (UTC)
 * Much still seems to hinge on if the actual consensus to implement that new "Derivative" namespace materializes or not so it may not be wise to discuss the planning likely needed that far down the road. If the new namespace idea is dropped for example, I would further move to establish a new and distinct header background-color for whatever eventually makes up the derivative type-class so you still might not have to think about how and what to mark-up for each type just yet. -- George Orwell III (talk) 15:56, 10 March 2013 (UTC)
 * It doesn't necessarily need a namespace to do that from a technological point of view, although it would be easier. The existing annotations can be put inside a template with a reference to the page name.  Where that page name is true, it would not include the annotation (which makes the annotation default in all other transclusions).  Either the page name would have to be given in each instance, or a new template would need to be created for each work (possibly feeding into a meta-template), but it should work.  With the namespace, this would just be a quick namespace-detect function. - AdamBMorgan (talk) 19:27, 12 March 2013 (UTC)
 * I don’t have a problem with the creation of Derivative works, but I am not seeing any compelling arguments on why they should be at WS instead of WB. JeepdaySock (AKA, Jeepday) 10:50, 11 March 2013 (UTC)
 * I won't have a "problem" with them either, If all most of the do's & dont's are clearly established from this point on forward. In Resident Scholar's case here, the debate has been fairly narrowed down to what amounts to the De-Annotation type of derivative annotation and mostly deals with "extremely historical" works in nature (think Socrates or Plato here). WikiBooks has already voiced an opinion that such complete or partial de-annotations (where the User: is also not adding or substituting his or her own "new" annotations in place or along the existing ones) are not really considered hostable there. Personally, I consider the de-annotation variants to be "easier" to include here as a derivative work in spite of the the opposite of adding annotations taking place because the amount of expertise or knowledge of the subject matter needed is irrelevant to the ability of striking something out versus adding something completely "new" in. -- George Orwell III (talk) 00:08, 12 March 2013 (UTC)
 * So Derivative is limited to only that which is out of scope per b:Wikibooks:Annotated_texts and is really old/special. Is there anything in this group that would conflict with WWI as it stands today? JeepdaySock (AKA, Jeepday) 15:07, 12 March 2013 (UTC)
 * Spinning off from some points under Wikibooks: they only annotate as part of their educational scope. If we are to annotate, I think our annotations should focus on just reading and understanding the text as it is.  In part, this is covered by wikilinking difficult or unusual words.  However, it might be useful for a floating box on Wikisource to give some basic information without needing to go anywhere (eg. "Constantinople is Istanbul", with better wording, where it is relevant to the text) especially where it would have been common knowledge at time of writing but obscure now.  I believe some have added maps to the ancient works to show the locations of the obscure, ancient countries mentioned therein (I've done it once here, with an early modern work).  I'm not sure if that crosses a line or not.  Per this section's point, this should of source only be done in a declared and separate, annotated version of the work. About WS:WWI, I don't think any of this conflicts with that.  At least, nothing I've noticed so far. - AdamBMorgan (talk) 19:27, 12 March 2013 (UTC)

Published derivatives

 * This section has been closed as community consensus appears to have been reached. If you wish to add further comments, please do so and just remove the closed template.

Non-wikilink annotation types
{{closed|The method and type of annotation is not fixed by policy and remains a matter of individual users' judgement. - AdamBMorgan (talk) 19:52, 7 June 2013 (UTC) Different types on annotation, other than wikilinks, include: Adding footnotes with and {{tl|user annotation}}; pop-up notes with {{tl|tooltip}}; floating boxes such as {{tl|taxon}}, {{tl|place}} and {{tl|dated}}; adding maps; adding diagrams; etc.
 * text=

Are all possible annotations acceptable or just certain pre-approved types? Do any of these go too far? Are any forms of annotation allowed if the work is clearly identified as annotated?


 * Comments:
 * My preference is for user annotations to be separated from the work, for example by only allowing them in the notes section of the header. If you absolutely have to insert a user-generated annotation, it must be crystal clear that this is not part of the work. For an example of crystal clear, have a look at the contents page at A Voice from the Nile, and Other Poems. Hesperian 00:43, 7 March 2013 (UTC)
 * Please pardon, I found this example less than enlightening; how exactly does it demonstrate crystal-clear annotation? (Probably my error in reading!) MODCHK (talk) 01:09, 7 March 2013 (UTC)
 * It was necessary to link to a subpage that the contents page had omitted. Rather than falsify the original work by inserting the omitted item, we added this following box above the contents page.


 * I think the way we did it made it crystal clear that this was not part of the original work. It's in a box. The box is coloured like the header and footer. It states in explicit text that this was not part of the original contents page. Do you still find it unclear? If so then further effort is required. Hesperian 01:18, 7 March 2013 (UTC)


 * O.K. My dumb mistake.


 * But even admitting that, the matter pretty much admits that "crystal clear" is only in the eye of the beholder. We have to make annotations "really *****I mean ridiculously obvious**** to the subsequent reader. I hope the message is (dare I say it?) crystal clear. MODCHK (talk) 01:29, 7 March 2013 (UTC)


 * I looked at the example also and did not figure it out until I came back here to read farther. I even looked at the history to see if someone removed the crystal clear marker. JeepdaySock (AKA, Jeepday) 17:33, 7 March 2013 (UTC)


 * For my own part I've used tooltips to convey information from the facsimile that can't easily be represented in text, like that a particular piece of text was handwritten on a printed text or that it was inserted after the fact or that it is in a different hand. I think this is worthwhile, it is strictly adding information that wasn't originally there (i.e. a new written description of some phenomenon in the facsimile), but only to compensate for lost information (the phenomenon itself). Pretty much everything else in this head seems like it should be treated like annotations. Prosody (talk) 02:02, 7 March 2013 (UTC)


 * Tooltips and associated templates such as SIC are a nuisance when reading downloaded ePub texts on an eReader. There's a grey highlight behind the word, but there's no way of getting at the content of the tooltip. I'd rather not know that there was something I'm missing out on. What I'm really getting at here is who is our audience? It's not each other. Where and how will our audience read the works we're producing/making available? There's a good chance that it will be off-wiki. We've either got to provide everything they'll need (and notes in the header won't work either) or not worry about it. Beeswaxcandle (talk) 02:18, 7 March 2013 (UTC)
 * I couldn't possibly agree more with BWC here. A noticeable amount of "wiki-stuff" that ultimate renders like a Jackson Pollock painting under the more and more popular platforms and formats out there has been steadily increasing for many months now. Even that supplemental header field has lost its familiar greenish background color under simple mobile view - making a "clear" distinction between original & annotated completely hit or miss for example. Until these factors are addressed, I feel any discussion over the possibility of accepting these kinds of annotations as being premature. -- George Orwell III (talk) 03:04, 7 March 2013 (UTC)
 * I have addressed the issue of the mobile format blanking some of these display components and a lack of an evident guidance about how we might display works differently for the mobile format with the WMF Mobile team. To see if they are able to direct us or assist us with this aspect. Tomasz said that he will ping his team. — billinghurst  sDrewth  05:01, 8 March 2013 (UTC)
 * Hey. What specifically is breaking/not rendering? Do you think you could send a mail to mobile-l outlining the problem as I'm struggling to follow the thread without not knowing enough about the specifics of the wikisource project Jdlrobson (talk) 18:00, 8 March 2013 (UTC)
 * Surely WS inherits one of (what I had understood to be) HTML's basic tenets: "Don't code for the device." I find the ruling that the use of certain templates should be excluded based on an effect in a certain device rather unsettling. Unless every single alternate reader device fails under a given circumstance (is that true?); a more correct technical approach must be to examine weak or amenable-to-change points throughout the tool-chain (in something like this sequence): start at the device hardware, then any embedded EPUB emulation on said device; and only then the EPUB generation process; HTML(!) and HTML-generators (i.e. wikimedia itself). Items of last resort would be to fix the templates themselves. To me, it only makes sense after all of the other steps have been assessed as having failed to solve the issue to attack the issue via a change of manual validation rules. Frankly I would be happier with a quite mindless blanket ruling of "no annotations, at all, not ever" than this. MODCHK (talk) 21:28, 8 March 2013 (UTC)
 * I don't exactly understand how we got to the point where "mobile" is doing something other than what is generally best practice for mobile platforms - stripping the extraneous so it renders well on a tiny 2.5 inch by 5 inch touch screen. The point was to illustrate how the usage of pre-mobile based solutions (such as forcing a "green-field" by adding  or applying wikicode-compliant tooltips instead of HTML compliant tooltips) as means to differentiate or facilitate user-added annotations from/with their pure-text parents have become a less-than-optimal approach in today's terms. Yes... this "stripping of the extraneous" under mobile view appears to "break" the final rendering on mobile devices - if that rendering is compared to its normal-view parent's rendering - but that is because nobody thoughtfully [re]writes then tests things like templates or how they are typically used in the various namespaces (and I'm just as guilty as anyone else here btw) to make sure both views are producing similar effects. As far as '[not] coding for the sake of devices at the expense of the [HTML] standard', I couldn't agree more. The issues that can and do arise here are more due to the fact that the Wiki[media]code is not "pure" HTML but only a shell of the standard. This approach works great for the simplicity and ease in creating, amending and maintaining collaborative efforts such as the typical Wikipedia article - or even this RfC itself; not so much the case when the goal is to create set static pieces that are suppose to be mimicking as near as possible the form & layout of formally published, printed works. Personally, I'd much rather have back the main traditional HTML tags than always trying to squeeze the standard rendering and expected behavior out of the auto-handling of the same under the Wikicode to do this more efficiently (even if that purity was isolated to just the Page namespace) but I know that is a lost cause at this point. - George Orwell III (talk) 23:30, 8 March 2013 (UTC)


 * Perhaps the question needs to be posed (and I expect in any case would be quite out of scope for this current discussion) as to whether the current generation of eReaders should be considered standard-and-final; or merely indicative of future evolution. If in future years everything is pure-HTML-compliant enough to support for the wiki mix (whatever that will mean; especially by then!), current-day EPUB quirks may well be totally irrelevant. I don't see a lot of mileage in WS being overly influenced by some external party's compromises. MODCHK (talk) 00:46, 9 March 2013 (UTC)
 * I think emphasis on pure HTML misses the problem. If you have a tooltip with a subtle green shading, it doesn't matter how awesome your HTML interpreter is, neither the black and white Kindle Touch nor the screen reader can display that the way you ordered. Perhaps the Kindle can munge the tooltip into something handlable on a mouseless system, but the screen reader is forced basically to read it or not. Whatever you think about the future of the simple book reader, the screen reader will be necessary for certain users in the near future.--Prosfilaes (talk) 09:16, 21 March 2013 (UTC)


 * I take your point regarding limitations upon given hardware, and how frustrating certain aesthetic choices may be to render upon these devices, at their current level of development. However, by choosing to base wikisource upon the mediawiki engine, an implicit choice of HTML as the basic unit of specification has already been made (and on the whole I consider that is a fairly sound decision.) Surely it is more realistic to expect reader devices (and this incorporates toolchain behaviour in converting between formats) to better honour the standard next year; than it is to cripple current practices for fear of losing a few adherents tomorrow. Crystal ball gazing is admittedly an inexact science, but at least this much is reasonable, surely? "Subtle green shading"s may always be represented in a pinch by crude inverse video without loss of data. Isn't it all about the words? If we seriously countenance throwing out HTML, then maybe that involves losing wiki, and that would be rather too high a cost bearing in mind how much work the community has already invested. MODCHK (talk) 10:44, 21 March 2013 (UTC)


 * "an implicit choice of HTML as the basic unit of specification has already been made", - where? JeepdaySock (AKA, Jeepday) 10:54, 21 March 2013 (UTC)


 * Are you serious? You have got to be winding me up. Wikisource runs using the mediawiki engine, which spits out the HTML your browser is rendering for you to be reading this. Either an ereader interprets this in exactly the same fashion directly, or it relies on some kind of conversion process (which I termed the "toolchain" in the naïve expectation this was a commonly understood term. Am I wrong about that too?) which consumes HTML and spits out a format usable by the ereader, possibly in several steps or passes. Actual rendering decision compromises may be made along the way, so that the precise image finally presented may be visually quite different to that which a desktop browser may produce. This is unimportant just so long as the text of the original work survives the various processing paths.
 * My sincere apologies if this response is curt, as I am in a degree of shock that this matter needs any clarification at all. Please also look to my earlier comment about this matter pushing the envelope regarding being borderline out of scope for discussion here.
 * Maybe I simply misunderstand the point that is being made? MODCHK (talk) 16:59, 21 March 2013 (UTC)
 * No, its not "you". Its fairly clear there are several points of misunderstanding here and they're coming from more than just one side. The way I read it - Prosfilaes touched on the key overall point with regard to "pure" HTML and hardware devices and MODCHK just about agreed with him but went about it from another angle was all. In general, I think we are all on the same page and getting lost on symantics or wording. The point I wanted to get across is that we are overreliant on coding to specific functions or formatting via template rather than by definition via .css. While either path falls under "pure" HTML from a "technical" stand-point, the latter is the more "simple" pure HTML coding that can serve both desktop & mobile roles at once. If a standard browser is detected, one .css is in play. If a mobile device is detected, some other .css should be in play. Both .css should have the appropriate settings for a class name and that would normally be the end of the discussion. The problem we face, however, is rather than keeping templates and their coding as simple as possible, we tend to avoid utilizing or creating any pre-defined .css values for color, position, size, and similar settings by coding them right into the template or templates instead. So while our green shading is forced to transparent in mobile view, views fine under desktop view since headertemplate is already defined in our Common.css file - all thats needed is setting an additional shade of gray in the mobile .css file for the same headertemplate class definition and that particular issue would be easily resolved. That is not currently the way we've been approaching things. Its always 'code the crap out of the template' and forget about class definitions altogether; and that is primarily why I think staying HTML "pure" was always a given but keeping it HTML "simple & smart" is how need to think about these kind of functions in moving forward. I hope that clarifies the crux of the matter some. -- George Orwell III (talk) 21:50, 21 March 2013 (UTC)
 * Some of the chains are getting hard to follow. And some of it technical and in the middle of proposed scope discussion. I must admit without rereading this entire section, I am at a loss to say were we are with it. JeepdaySock (AKA, Jeepday) 10:34, 22 March 2013 (UTC)
 * "At their current level of development" is part of the reason I mentioned screen readers; they won't magically get better. Also, the physical size of the Kindle is useful and by design, and no technical wizardry is going to change that. Rendering a green background as inverse works until you have a blue background--and it will be always unclear to the machine whether you intended it to be emphasized that strongly. It's more than just having the right words; readers of ebooks run into headers and footnotes stuck into the wrong place way too often, and tables can disintegrate into a right mess. Using CSS instead of hardcoded HTML will help, some, but I don't think you can magically get a quality Kindle book or audio book if all you're staring at and thinking about is a 20" 16x9 monitor. You say "Actual rendering decision compromises may be made along the way, so that the precise image finally presented may be visually quite different to that which a desktop browser may produce." That's extremely biased for supposedly device-neutral HTML. If you write an speech full of allusions to English literature, you don't get to blame the speaker who had to give it to a Japanese audience. The Kindle and speech readers are not inferior PCs; they're their own devices, with their own needs. HTML is supposed to be device-neutral; if we're writing in such a way that it's not coming out right on ebook readers, then it's our fault. We can expect handling of HTML to improve, but they're still going to be 6.5 in. x 4.5 in., not huge mouse-driven machines with 20+ in. 16x9 monitors.--Prosfilaes (talk) 02:04, 22 March 2013 (UTC)


 * One common thing is works that have a separate collection of plates (for example, at the end or in the middle of the book, or journal). Often it would be nice to place them in the text where they are mentioned. This I assume is an "annotation" since it is not present there in the original text. Thoughts on this? MarkLSteadman (talk) 06:58, 7 March 2013 (UTC)
 * Mark, for those works where I have found it important, I have made the changes, especially in a case where the positioning put the work into the next chapter. I did this by typesetting the images twice &lt;includeonly> where I wanted them, and &lt;noinclude> for the Page ns: display.  In cases like these, I put an &lt;!-- html comment --> in the footer to explain what I have done.  The author always intended for the image to by the words, it is the typographer/publisher who has moved them. I am unpure! — billinghurst  sDrewth  11:42, 7 March 2013 (UTC)

I am just trying to pull together bits that relate to non-printing, not that it is my knowledge area of MW I will see what may be around at MobileFrontend, Mobile default for sister projects and Wikimedia Mobile engineering, though I would think that if have specific requirements in this area that a bugzilla and coordination with the mobile team would see this sort of thing managed — billinghurst  sDrewth  11:42, 7 March 2013 (UTC)
 * mw:Manual:FAQ
 * there is some sort of "printonly" styling, so bits can be in Mediawiki:common.css and bits like @media screen, handheld, projection and from a glance around I think that Front-End Coding Standards has relevance.
 * It has complexity, and is confusing for a numnum like me. A partial explanation has been given ...  mobile is different from media-queried desktop site that it reformats page HTML (in addition to a separate skin) {{smaller|(hope that means something to someone)}}. — billinghurst  sDrewth  12:31, 7 March 2013 (UTC)


 * Including my support for exclude unless ’crystal clear’, and admitting I have no idea what ’crystal clear’ might be. JeepdaySock (AKA, Jeepday) 17:35, 7 March 2013 (UTC)


 * I would like to know if the opinions stated so far still apply if something like an "Annotation:" namespace is used to host these works? - AdamBMorgan (talk) 20:56, 7 March 2013 (UTC)
 * How would "Annotation:" namespace be different from Wikibooks? JeepdaySock (AKA, Jeepday) 11:30, 8 March 2013 (UTC)
 * It could create a third option. Pure texts in the Wikisource mainspace, Wikisource-compliant annotated texts in the Annotation namespace and Wikibooks-compliant annotated texts in the Wikibooks main namespace. From other points, Wikisource annotation might tend more towards reader comprehension rather than Wikibooks' educational focus. For example, something might have been obvious to a comtemporary reader that is now obscure to a modern reader; or possibly aimed at younger readers. - AdamBMorgan (talk) 18:28, 8 March 2013 (UTC)


 * Does Field Notes of Junius Henderson/Notebook 1 count as crystal clear? That uses {{tl|taxon}} and related templates for annotation.  The writers of that page did ask on Scriptorium first (Scientists, personal notes and Wikisource) and the result was mentioned in the journal ZooKeys.  I would not want to infringe on that project too much (or pull the rug out from under them). - AdamBMorgan (talk) 20:54, 7 March 2013 (UTC)
 * Just to reply to my own point: I think this approach does count as crystal clear and should be valid. Having thought about it some more, I think this might be a way forward for annotation.  These annotations are all in floating boxes to the side, which I think can reasonably be assumed to be recognised as not part of work itself.  Possibly we could change the box background to header-green for consistency.  The use of templates also provides a litle more control over the types of annotations allowed. - AdamBMorgan (talk) 18:28, 8 March 2013 (UTC)
 * I'd much rather we fix the existing "plain old" side-note approach once and for all than mess around with adding something just like it but is somewhat less flexible. Done right, it could solve multiple issues; default view would be 'as published' but a toggle easily flips that on or off regardless of the annotations being part of the original as published or if they are user-generated post-published additions; the same ability would apply for desired print-modes; class designations insure "neat" rendering in both normal & mobile views; and possibly much much more. We'll never exhaust those possibilities because "fixing" side-notes requires "fixing" dynamic layouts first and nobody seems to know how to do that. As an aside, using colors, icons or pop-ups as a marker that normally would let the reader know that something is or is not part of the "pure text" works fine in normal view but the same does not apply to mobile view (this mindset is killing us on today's most popular platforms and devices imo). -- George Orwell III (talk) 00:08, 9 March 2013 (UTC)
 * Some combination of the proposal by Adam and George immediately above, would seem likely to meet the crystal clear marker. Jeepday (talk) 02:23, 9 March 2013 (UTC)
 * Fixing dynamic layouts might have to wait for some unspecified time in the future. Personally, it is beyond my ability to do anything and will probably need some specialised tech help from somewhere (probably a passing volunteer as I'm not sure the Foundation does stuff like this—maybe a future grant could pay for it).  I'm tempted to start Wikisource:Requested functions to complement Requested texts.  I should also point out that the Wikisource roadmap includes thoughts on overlaying annotations on a text, like layers of an onion or a sheet of acetate, that can be toggled on and off.  It's just an outline of wants and thoughts but someone somewhere may be trying to implement it (one of the pending IEG proposals is based on this roadmap; future ones might do so too). In any case, I don't think it should hold up the annotation policy.  It would be a nice improvement but not essential (we already have sidenotes after all). - AdamBMorgan (talk) 18:51, 12 March 2013 (UTC)

Notes field and Navigation annotations
Adding this section as it is a specific means that we add componentry to a work that could be viewed as annotation. To this point their addition has been non-controversial, and this seems an appropriate time and place to ensure that it is considered.

In some works there is specific parts that can be added to Notes fields that is an annotation. Be it see such an article, or to not a reply to a work, or further research in another work, even another edition/translation/...

Similarly in some works we add navigation aids, eg. something like CompactTOCalpha, or equivalents, used in a work's index pages, eg. Picturesque New Zealand/Index. More recently I know that I have been adding such to the notes field, rather than in the body of the work. So if these are non-controversial, then it would be useful that we cover that in the documentation. — billinghurst  sDrewth  01:13, 12 March 2013 (UTC)


 * Not sure I completely followed everything, but I think what you are saying is that every allowed annotation (as approved in other discussions) would be required to be in:
 * The Header or Footer
 * The notes section of the page.
 * Excepting wikilinks which may be in the body, or anyplace on the page.

-- Annotations: ? Annotated texts might display a box with a fixed position on the screen containing a "Show Wikisource annotations" link. This is in addition to the "crystal clear" rule.--Erasmo Barresi (talk) 13:00, 12 March 2013 (UTC)
 * Is it technically possible? JeepdaySock (AKA, Jeepday) 14:53, 12 March 2013 (UTC)


 * I am pretty sure that it is. Though, it may be very difficult to achieve from both the technical and the maintenance points of view. Possibly using user annotation for plain text and  for boxes is better. But I threw in an idea...--Erasmo Barresi (talk) 18:27, 12 March 2013 (UTC)
 * I think this might connect with the dynamic layout point mentioned above. In theory that, or something similar, could be used to switch annotations on and off.  As I recall, the was once a ſuggeſtion to use ſomething ſimilar to toggle long-s ſymbols on and off but it cauſed problems.  A technological solution would be nice but I'm not sure if it is practical at the moment, we don't really have the resources. - AdamBMorgan (talk) 18:51, 12 March 2013 (UTC)


 * On French Wikisource we have both: we have a gadget Afficher les notes and a gadget Convertir les caractères anciens (mainly the long s). They are gadgets now but we would completely agree to create buttons such as the ones described by Erasmo. --Zyephyrus (talk) 20:18, 12 March 2013 (UTC)


 * What happens when you export the book? Does it export with or without the annotations depending on your selection? Jeepday (talk) 23:30, 12 March 2013 (UTC)


 * It always exports with annotations, I suppose. Possibly collapsed tables would be better as they are easier to manage. Annotations would be always exported with this option, too.--Erasmo Barresi (talk) 06:40, 13 March 2013 (UTC)

Final shot
I propose to adopt the following rule. In the main namespace and the Translation: namespace, the only allowed annotations, in addition to wikilinks, are:

1. the relevant header template, maintenance tags, and copyright tag (the latter only applies to the main namespace)

2. tables based on the following scheme, with  in the main namespace and   in the Translation: namespace

3. references with user annotation

--Erasmo Barresi (talk) 21:22, 13 March 2013 (UTC)


 * 0. I think an Annotation namespace still makes some sense (in addition to the proposed Translation namespace). If we have annotated works in the mainspace, they need to be clearly labelled as such and separate from the pure version of the text.
 * 1. We should make it clear, in any resulting policy, that these templates are not annotations and therefore annotation policy does not apply to them.
 * 2. I don't think tables are necessary. I'm still leaning to floating   based boxes (although a table could be similar, I suppose).  I need to check what "headertemplate" actually means before commenting on that.  If just the green colour then OK.
 * 3. As stated, I'm personally leaning towards floating boxes. I don't think footnotes have the required "crystal clear separation" element. - AdamBMorgan (talk) 22:26, 13 March 2013 (UTC)


 * Not sure we can wrap everything up with 3 simple rules. I was thinking close each segment separately, some like wikilinks & translations will need to go into addition fine tuning in separate discussions. Some conversations had only couple of quick easy comments, and they can be closed individually. As this page was only created on March 5, 2013 I would say waiting until at least March 19 before closing any of them would be best. JeepdaySock (AKA, Jeepday) 14:54, 15 March 2013 (UTC)


 * Jeepday, this is only for closing the segment, not the entire RfC.
 * 0. How many people would look to the annotations if they are in a different place? Would wikilinks and navigation annotations be included in the pure version of the text?
 * 2. Tables are an easy way to display collapsible content. The "headertemplate" class gives the green color, 5 pixels of bottom margin, and a 100% width (but this can be changed).
 * 3. We may modify the user annotation template to get a colored background for the footnote and thus achieve the "crystal clear" separation.--Erasmo Barresi (talk) 06:37, 16 March 2013 (UTC)

Specific, templated annotation proposal
I think there is (possibly) the beginning of some agreement on allowable annotation: very specific types of annotation could be allowed if clearly separate from the body of the text and within the scope/ethos of Wikisource rather than Wikibooks. Floating boxes, like taxon and similar in appearance to the old Wikipedia sister links, should achieve this. An added benefit of using templates to make annotations is that they can be controlled, tracked and, if necesary, easily deleted en masse by bot. As for scope, I thnk "enhanced readability" and "embedded data" work for Wikisource (as explained below).

Examples of this type of annotation could include:


 * taxon, place and dated. These templates already exist and are used in the main namespace. For example: ; ; and . These were created by Gaurav. When he suggested them on Wikisource talk:Annotations (followed up at User talk:Gaurav), he said    This seems like a worthwhile use of Wikisource, it uses our ProofreadPage extension and is not really within the scope of Wikibooks (making educational resources).  It has also been mentioned in a few places like ZooKeys and the Wikimedia Research Newsletter blog.
 * Micro-translation. We have decided (at time of writing) that any translation of foreign language words and phrases count as an annotation.  It would be within Wikisource's scope to support the reading of its texts.  In this case, enabling people who are not fluent in the other language to understand what it says (without using a separate website or dictionary, and without requiring the user to know how to do that); ie. enhancing the readability of the text.  In some cases wikilinks could be used, especially with single words or phrases notable enough to have a Wikipedia article.  In other cases, or all of them for consistency, this micro-translation could be achieved with a template similar to those shown above.
 * Modern terminology. I mentioned this is a different section and it follows the same "enhanced readability" idea.  Readers may not be familiar with archaic terminology (for example, defunct placenames such as "Constantinople" or "Gaul").  Again, if not wikilinked, a template could provide this information.  The template could also clearly explain the type of modern term (Constantinople is now Istanbul, Gaul is an ancient county approximately equivalent to France, etc) without necessarily following the link.
 * Contemporary references. Related to the above, if a text makes an indirect but unambiguous reference to an event or piece of pop. culture that would have been obvious to a contemporary reader, but not necessarily to the average modern reader, it would be helpful to provide some information.  In this case, wikilinks may not be appropriate; a direct "SALT" could be wikilinked but the rules that seem to be forming elsewhere in this RfC are going against wikilinking non-direct terms (and it may not be obvious where to put the link).  Coming back to taxon et al, it could be useful to see patterns of references in works (In which case, it could be combined with an in-line wikilink in some cases). For example, I've recently been proofreading some memoranda of conversations from the 1970s, where this sort of reference and allusion seems to be common.

The annotations could be placed in a clear "Annotation:" namespace to further emphasise that these are not pure texts. Is this an acceptable, or at least more acceptable, approach to annotation? - AdamBMorgan (talk) 19:59, 20 March 2013 (UTC)


 * I don't think they should be put in their own namespace. Microannotations are most likely to get created and used if they're in the copy of the work that's used, not in a separate work.--Prosfilaes (talk) 22:36, 20 March 2013 (UTC)


 * Using box template forms for annotations would visually and structurally intrude into a number of works, especially in cases where the box cuts into formatted poetry. It also physically separates the information contained in the annotation from the location where it is mentioned, and thus requires a reader to determine (a) what is that box doing there? and (b) where is the referent in the text?  I don't like this idea at all, and there are a number of locations where they would pile up in large numbers. --EncycloPetey (talk) 05:01, 1 April 2013 (UTC)

New plan
As we cannot agree on a fixed type of annotation, I suggest we allow whichever scheme seems appropriate to the work in question with just three conditions: So, for example, a work may be called "The Annotated Foo", with a linking template to "Foo" and be annotated with footnotes, templates or whatever else is possible as suggested above. Other agreements (such as literal information only) still apply. - AdamBMorgan (talk) 22:55, 14 April 2013 (UTC)
 * 1) The page title must make clear that this is a user-annotated work.
 * 2) A template like similar to be placed just above the header template, pointing to the pure version.
 * 3) Each annotation should be clearly separated from the body of the text. (eg. Footnotes with user annotation, floating templates, or something similar.)
 * A couple more rules/conditions, that seem appropriate given conversations on translations and seem implied here as well.


 * 1) A pure version must be completed prior to an annotated version
 * 2) w:WP:NPOV & w:WP:V must be met, all annotations should be denotative (literal/factual) and not connotative (suggestive/interpretative).
 * 3) Only a single annotation version may be created (in keeping with NPOV and V only one is needed).
 * 4) Wikilinks are the only annotation types exclude from these rules (they will be discussed under a different rule).
 * I have found this discussion particularly difficult to follow. So if anyone feels I have missed the boat on these, do not hesitate to call it out. Jeepday (talk) 22:59, 15 April 2013 (UTC)
 * All OK to me (although, to expand on your 2nd point, all annotations should be denotative (literal) and not connotative (suggestion). - AdamBMorgan (talk) 09:23, 16 April 2013 (UTC)
 * Added per your suggestion, there are multiple words with similar intent ’factual or interpretative’ where most widely used in discussions. I suspect the most appropriate word(s) will arise in discussions on piped and direct wikilinks. JeepdaySock (AKA, Jeepday) 10:30, 16 April 2013 (UTC)

}}
 * Instead of permitting any way of marking works as annotated, we could set the standard on adding  to the page name (that is, Text/Annotated, Text/Chapter 1/Annotated, etc.). The link to the unannotated version would be just the automatic basepage link.
 * We might want to prohibit annotations that cannot be printed or downloaded, such as tooltips.--Erasmo Barresi (talk) 15:39, 29 April 2013 (UTC)

Comparisons

 * This section has been closed as community consensus appears to have been reached. If you wish to add further comments, please do so and just remove the closed template.


 * So we're banning stuff like To*** Kern and Catullus 52? I'm not really upset about it, but it does seem moderately convenient for students.--Prosfilaes (talk) 02:18, 22 March 2013 (UTC)
 * Those might fall more under translation, although it's worth confirming what the community thinks about this before going ahead with anything. At the moment, the position on translation is that there needs to be an equivalent original on the appropriate Wikisource (this is true in both of these cases).  Whether we can have a copy of the original alongside the translation is up for debate. - AdamBMorgan (talk) 21:55, 1 April 2013 (UTC)

Translations
{{closed| Wikisource user translations are appropriate for Wikisource. The will be hosted in their own names space (per Special_namespace). There should only be a single translation to English per original language work. A scan supported original language work must be present the appropriate language wiki, where the original language version is complete at least as far as English Translation. There was much conversation about language competence, but a clear definition and measure was not achieved. Lacking a clear guideline for language competence, the general expectation for accuracy of translation here, is the same as it is at any sister wiki work. Some discussion about requiring a formal or Semi-formal project for each translation, but a clear consensus on a requirement was not reached. JeepdaySock (AKA, Jeepday) 15:08, 1 April 2013 (UTC) |text= User translations are foreign-language works translated into English by Wikisource users. User translations are currently indicated by "Wikisource" as the translator in the header template.

Should Wikisource host user translations? If so, what policies and guidelines should apply? (NB: The proposed policy Translations has been proposed without approval since 2006.)

If allowed on Wikisource, should user translations be identified in any other way that at present? Translation can involve some interpretation on the translator's part, are future users allowed to change an existing translation and/or will Wikisource accept multiple translations of the same work? If multiple, should there be a maximum? Given the interpretation involved, how will we ensure that the translation is neutral and without added bias? Are other forms of English valid for translation, ie. translating into Old English or, conversely, one of the "Simple English" systems for young or non-native readers?


 * Comments:
 * I think we should only permit user-generated translations where no public-domain published translation exists. At present we are hosting bits and pieces of a user-generated translation of the Bible and I think that is absurd. Hesperian 00:50, 7 March 2013 (UTC)
 * (The above comment shouldn't be regarded as opposition to a proposal of banning of user-generated translations altogether. Hesperian 02:30, 9 March 2013 (UTC))
 * Generally concur. There are some cases where the only public-domain translations are bowdlerized, inaccurate, or incomplete, I think those are compelling reasons to allow a user-generated translation. Prosody (talk) 01:38, 7 March 2013 (UTC)
 * Happy with that. A counter-example: Of the 19 English-language translations of Madame Bovary — the 'Everest of translation' — only one is in the public domain, and it is widely regarded as the worst of them. I would not regard this is a justification for us to attempt our own. We'd only be making fools of ourselves. Hesperian 04:29, 7 March 2013 (UTC)


 * I think the Bible translation is its own problem; it's certainly out there on the redundancy of the translations. As counter-examples, I would think that a work whose only English translation was Caxton would be easy to justify for a new translation. Another example is Cookery and Dining in Imperial Rome, a notorious translation of Apicius whose faults are well-enough known that producing a better translation shouldn't be too much of a challenge.--Prosfilaes (talk) 09:23, 7 March 2013 (UTC)
 * The other issue with the bible is the impossibility of creating a neutral translation. Google "bible translation controversy" and enter a parallel universe where people will fight to the death over whether or not 1 John 5:7 is the word of God, and whether presbuteros translates as priest or elder. Hesperian 13:03, 7 March 2013 (UTC)
 * (P.S. the Wikipedia article on the 1 John 5:7 controversy is 210Kb long.) Hesperian 13:12, 7 March 2013 (UTC)
 * Part of the problem here is that we don't know the whether those who are contributing these translations are actually qualified to make translations. We also end up being used as a self-publishing venue for people wanting to get their translation into the public arena (recent Romanian -> English translations of short stories and and Hindi -> English translations of poems come to mind). The other problem is the verifiability issue that GOIII raises near the top of the page. We're valiantly working towards obtaining scans for our works, but there's this set of works that we can't do this with. Beeswaxcandle (talk) 02:37, 7 March 2013 (UTC)
 * Some of the work I'm happiest with is the translation of Pinglopiketoj and the editing on Rat on a tray. I don't claim that either of them are great art, but I do claim that they make accessible something to the English readers that might not otherwise be available, and it's something where we're not just a better Project Gutenberg, or a copy of some legal site, like so much of our material falls into.--Prosfilaes (talk) 09:23, 7 March 2013 (UTC)


 * Yes to hosting them, BUT I want them hosted in their own namespace, or a namespace that is not main. They need to be identified as different, and always an element of unverified.  Some are/were doing side by side translation against scans, and I think that should be our future standard as that can them lead to verifiable process. We can grandfather previous translations and set new stds for anything into the future. — billinghurst  sDrewth  12:44, 7 March 2013 (UTC)


 * After debating this over and over again in my mind for considerably more than just a hour or so, I have formed the opinion that in moving forward, user created translations should no longer be part of Wikisource. Even given the benefit of doubt by assuming "good faith" by all who contribute and the like, there is just no measurable way to verify the accuracy of such translations. Existing works should be grandfathered in somehow (if possible). -- George Orwell III (talk) 22:09, 7 March 2013 (UTC)
 * In the greater Wikimedia world, we exist alongside Wikipedia and Wikibooks, neither of whom have as tight a rules in main space as is being proposed for translations. In the body of Wikimedia projects, you're pushing that there be no space for English language translations because already the strictest of the Wikimedia projects wants to be even stricter. We're part of a project that started with an encyclopedia built by amateurs; I think removing a space for English translation of works in the name of measurable verifiability is a little extreme.--Prosfilaes (talk) 00:10, 8 March 2013 (UTC)
 * I said no such thing. The authorized or unauthorized (and the many variants of either class) of an English translation of a work first formally published in a language other than English is always a welcomed addition to the Wikisource library.... and if that work is already being hosted in its original language by one of the other Wikisource sister domains - all the better. Scans of such works are best; linkage to credible, well-established third party sites should be provided at worst. Now what I did say was that I don't think we should be including user-generated, never-before-seen, first-time, translations of non-English works to English, be they properly sourced elsewhere, hosted here or none of the above. Merely executing a perceived ability to translate something here on en.WS does not necessarily establish as fact that such a contributor is actually qualified to make such a translation does it? How would we / could we hypothetically verify such contributions? -- George Orwell III (talk) 03:37, 8 March 2013 (UTC)
 * {{comment}} Prosfilaes statements pushes my opinion to that there needs to be somewhere in the wiki world to host these, even though I share GO3's reasons of the interpretative natures of the translations/works. I am uncertain where they should belong, but we have the tools available to make them easier, and to allow multiple people to bang away on them, and they will sit in the original language in a language sister. This combination of reasons says to me that we should allow them, but differentiate them in that interpretative aspect, hence why I put forward the aspect of a separate namespace (be it solely Translation: or Derivative: depending on other discussions). — billinghurst  sDrewth  04:37, 8 March 2013 (UTC)
 * I've always understood user-generated translations to be validatible by second user familiar with the language—that's how you insure the accuracy! Otherwise it remains only in "proofread" status.  ResScholar (talk) 05:26, 8 March 2013 (UTC)
 * I don't know what your editing interface has but on mine the radio buttons once used to achieve this before the consensus for source-file backed works was reached are long gone here. And if I recall correctly, the proofreading percentages once used in textinfo templates were phased out of standard practice at some point as well. -- George Orwell III (talk) 05:51, 8 March 2013 (UTC)
 * We have a large inheritance of classic works (many from proofread sources) with the text-quality mark still attached acquired back in the days when works were added on the basis of their perceived significance and not merely on the availability of a scanned original. We could re-use (and are using) those marks for translated works whether translated works are in their own namespace or not.  ResScholar (talk) 09:06, 10 March 2013 (UTC)
 * Yes, I've gleamed as much long before any of this started - approx. 27,000 pages still utilize the {{tl|TextQuality}} template; how many of those (if any at all) are somehow still intertwined with the usage of the {{tl|Textinfo}} template used primarily on mainspace Talk: pages or are strictly used on mainspace translation related pages - I cannot say. But I'm under the impression this whole radio-button/template approach was phased out of policy & practice when the radio buttons in edit mode where turned off for all mainspace works & not just those pages with a 'source' tab and the colored PR status bar (i.e. transclusions from the Page: namespace). I believe I argued against that at the time this universal "phase-out" or whatever it was called was being floated way back when (& hopefully done with just such a rationale for the possible future [re]use of the approach as you are presenting now). If this is all still clearly part of our guidelines, practices or policies somewhere then I see no reason not to re-use it for that possible "secondary" new namespace being floated in another section. But, if its been stripped out like I think it was, I'd think formally proposing its reintroduction would be in order before we go any further here. -- George Orwell III (talk) 12:23, 10 March 2013 (UTC)
 * Hosting the translations are not the problem - the means and methods being applied for translating are. User 1 creates a translation; User 2 comes along weeks after User 1 is pretty much gone from en.WS and modifies User 1's work; User 3 comes along months after User 2's changes and makes even more changes. User 2 then happens upon User 3's changes and reverts them; User 4 then arrives to re-translate the entire work - thanks to what they've determined to be a poor translation from the day it was created. User 1 happens upon the re-write by User 4 and an edit war erupts...... And so on and on and on. How exactly would such a scenario benefit the other potential readers out there again? What would a work in such a perpetual state of flux - going from one's interpretation to another's over the course of several months if not years - say about the rest of the works hosted on this site to the unfamiliar visitor exactly?  and how is it that I can display most of the default English skin [//en.wikisource.org/w/index.php?title=Tracts_for_the_Times&uselang=fr so easily in French from here] but not the text-box content? Is it because we choose to ignore real language translation development and it's standards for this red-headed stepchild of translating instead? (Just asking). -- George Orwell III (talk) 05:42, 8 March 2013 (UTC)
 * I put my own username on my translations. I agree they shouldn't be in flux like that with multiple wikipedia-like wiki-edits.  ResScholar (talk) 07:01, 8 March 2013 (UTC)
 * Tsk... I would consider you the exception, not the rule in my hypothetical. What I'm speaking to are works attributed to date much like by Catullus, translated by Wikisource in particular. I'm glad the hypothetical point on possible perpetual flux is not lost on you but at the same time the only equitable solution for 4 different users with 4 different interpretations over the same supposed translation of  a single non-English work would be to have all of them individually attributed as separate translators in 4 separate and distinct derivative works. Nobody wants that do they? Its that lack of an objective way to verify the credibility and fidelity of such derivative works that I cannot reconcile in moving forward. - George Orwell III (talk) 07:36, 8 March 2013 (UTC)
 * How exactly would having the translation of a work benefit the readers? Are you seriously asking how having content available in English is useful to the reader?
 * Are you seriously trying to twist my 4 contributor hypothetical into such an implausible simplification as that to honestly think it was the actual point I was really trying to convey? -- George Orwell III (talk) 09:23, 8 March 2013 (UTC)
 * It's not twisting anything. You're using your hypothetical as a way to argue that we should not have translations. My point is that even your hypothetical does not justify the intended actions.--Prosfilaes (talk) 13:16, 9 March 2013 (UTC)
 * You can display the default skin in English because some person went in and translated the default English skin, just like you don't want to let someone do for the text box content. It's not done by computer. What do you mean "real language translation development"? Computer translation will not in the near future be better then tolerable even in the simple cases.-- Prosfilaes (talk) 08:17, 8 March 2013 (UTC)
 * I thought it displayed in English because that's the domain we're in and happens to be my default - but what I was alluding to is the 'why the skin can be translated on the fly to French while never leaving the English domain'. A more sincere interaction could have led us to the possible standardization of a new practice to always set the language attribute whenever & wherever possible in such cases. My mistake. -- George Orwell III (talk) 09:23, 8 March 2013 (UTC)
 * I know what you said; I don't know why in the greater context you would interpret my statement as indicating that I thought you wanted all translations, previously published or not, deleted.
 * Because judging by the previous conversations I've had with you, the lack of clarity and specificity on my part always seemed to lead to further & further pointless, if not outright antagonistic, responses by you. My apologies if this instance was to be any different. -- George Orwell III (talk) 09:23, 8 March 2013 (UTC)
 * If you're curious about the theory of verifying material like this, there's a project called Wikipedia you might want to look at. It's been around for more then a decade. We would be doing a disservice to the Wikimedia Foundation we're a part of by dropping English language translation on the floor because we're too pure to accept editing disagreements like every other Wikimedia project.--Prosfilaes (talk) 08:17, 8 March 2013 (UTC)
 * Just as the numerous points of view (and the like) within any given mainspace article is expected to be supported by references to reliable and verifiable sources on Wikipedia by standard, I don't see how asking for the same standards of verifiability and reliability here is some sort of disservice. If the answer to my asking falls short of some sort of unambiguous and objective standard, as I believe is currently the case, then all that has transpired is that I've suggested is that we no longer entertain any further new creations of this type of derivative work and strive to grandfather in the previously existing ones. If anyone can arrive at any better rationale solution - I'm all ears (I can do without the condesending tone however). -- George Orwell III (talk) 09:23, 8 March 2013 (UTC)
 * There has never been requirements that specific wording be backed up by references on Wikipedia. You're saying that Wikipedia can have The Good Soldier Švejk whose structure on the article, paragraph and sentence level is not derivative of any other work, but a translation that follows the original on the chapter, paragraph, and usually even sentence level would somehow need reliable and verifiable sources beyond the original.--Prosfilaes (talk) 13:16, 9 March 2013 (UTC)
 * That's still not reflective of the general point that I'm trying to make here. And you're still parsing things I've said that were meant only to illustrate the nuances of that point in hopes you'd absorb the overall gist of my position rather than arguments to be taken literally (so after this - I give up w/you). We don't know the translator is actually fluent enough in both parent & derivative languages to be qualified to make such translations. I'd like to be able to have some standard or mechanism that could verify that fluency. Well obviously achieving that as measurable standard is wrought with issues & hurdles. Therefore, I don't think we should stop doing this in moving forward or at least until something checkable or measurable is put into place. In short, a contributor should not be able to create an account, claim to be making a translation, not provide scans & proofread in the original language, and "finish" that derivative here without some way of verifying the quality and integrity of his or her work. Its crazy to think we're just suppose to put that translation right next to something faithfully transcribed and validated, backed by scan, in the mainspace without question. So in closing, I'd rather not entertain standardless derivatives of the translation type anymore - if they get isolated to their own "secondary" mainspace instead - I can live with that. -- George Orwell III (talk) 15:03, 9 March 2013 (UTC)
 * I think we are all pretty much on board that new translations have to have scans of the original language text. Jeepday (talk) 16:07, 9 March 2013 (UTC)
 * Yes, I think having the scans and translation-via-proofreading is the best way to do this. The translations will be crowdsourced. We will just have to accept that Wikisource translators are no more experts than any other Wikimedians.  The policy could state that they are living documents that other users could revise the translation in the future, just to make it clear.  Edit wars are a risk with this, and any other derivation, but they should be manageable and contained. If it happens, we will just have to borrow guidelines from a sister project. - AdamBMorgan (talk) 18:30, 9 March 2013 (UTC)
 * ... and the practice should be clear as that stated policy. Special: namespace or not - translations and any other derivatives decided upon here should not share the same header [background color] as the current mainspace works do regardless of sharing the Page: namespace for hosting and transcribing/translating those source files or not. It should be made just as clear that the color-coded status for pure texts in the Page: namespace are pure reflections of a work's current state of proofreading proper while the same color-coding status for translations (or any other derivative that may somehow wind up in that namespace) are not guaranteed to be accurate reflections of the state of translating but are subjective determinations based on 2 or more contributors that are only believed to be qualified to make such translations and assign such color-coding statuses. In general, the lower the chances a user-generated derivative can be mistaken-for or benefit-from the accrued reputation of the faithful representation and unambiguous standards of pure-text hosted works, the better. And if we're all "on board" with the future accommodation of lending the Page: namespace out beyond it's current role in pure-text transcriptions to help facilitate user-generated derivative works (such as user-generated translations or projects), I believe these new tweaks to standing policies & practices should be [re]affirmed as foundation principles and clearly outlined beforehand as well. In other words, if we are going formally "stick a fork" into the outlined rules, roles & responsibilities for contributors to accommodate whatever it is that comes out of this RfC at its close, that "fork" better be made clear enough prior to implementation that the paths of future development, manipulation or evolution still allows for the possibility of severability (if there is ever comes a need or the ability to remove the "fork", it can be easily done so that one "tine" does not adversely affect the others). -- George Orwell III (talk) 21:53, 9 March 2013 (UTC)
 * Your "let's verify the fluency of the translator" is in gross violation of the principles that founded this set of projects. And I take offense at the continuing attempts to stigmatize one of the more valuable aspects of Wikisource, one of the few that other projects aren't doing better or more comprehensively.--Prosfilaes (talk) 23:05, 9 March 2013 (UTC)
 * I sincerely regret that the conclusions that you've reached here to date are still so negative but I still firmly believe the reasoning behind the concerns we've debated in this section so far have been recognized by others as valid ones. They might not agree with my conclusion to stop the practice of hosting user created translations entirely but that does not equate to invalidation of those concerns (just as it does not affirm the opposition to my conclusion as being an invalid concern either). Nevertheless, a consensus somewhere in between the two extremes will eventually be reached. You can either remain offended, focus on the messenger rather than the message or opine about earlier eras now long, long gone - or - you can [continue to] positively contribute to the development of that consensus as we move WS forward as a community. I hope its the latter. -- George Orwell III (talk) 01:45, 10 March 2013 (UTC)
 * You have done your best to personally antagonize me. "Because judging by the previous conversations I've had with you" is your line, not mine, and you have repeatedly avoid discussion of the issues I've brought up. Changes are not always for the better and don't always last: the statues of Marx and Lenin have mostly fallen, and US Prohibition lasted not long over a decade. You can describe my conclusions, that permitting translation is maximally consistent with our role in the WMF and something we provide to the net of unique usefulness, as negative, but I believe that represents your own biases more than anything else.--Prosfilaes (talk) 09:55, 10 March 2013 (UTC)


 * "If anyone can arrive at any better rationale solution - I'm all ears." At the risk of jumping further into something that I'm not a part of (but taking this comment as a bit of an invitation), I'd just like to point out a resolution of the above problem that works in our experience at Hebrew Wikisource. In essence our experience agrees with both Prosfilaes and George Orwell III. It works like this: Whenever there is a reader generated edition or translation whose guidelines are complex (this is a small minority but it concerns some very important works), what we do is dedicate a special page to the editing guidelines for that work in the "Wikisource" namespace. On that page the community develops agreed upon editing guidelines that are both useful and solid, based on verifiable sources (such as available editions and scholarship about the work), very much like you would find in a in a good referenced Wikipedia article. Only here the ultimate goal is not the article itself, but rather the book that is to be edited. In our experience this has nearly always worked very well and with little if any controversy. Plus it utilizes the strengths of the wiki environment to the maximum in a prudent manner. Have a good weekend, Dovi (talk) 11:27, 8 March 2013 (UTC)


 * I like the suggestion by Dovi. I don’t have a problem with Translations being on Wikisource.  I would imagine they would always be a work in progress. They should clearly state they are wikisource translations (as they currently do), I also agree that new translations must have scans of the original document, and that all translations must show that address a deficiency in public domain translations (to English) of the work.  This could be quantified by requiring at least one more committed editor then there are public domain works available.  So if there are no translations, one editor is sufficient, if there are 20 translations then 21 editors need to actively be part of the project and in agreement with the "editing guidelines" of the work. JeepdaySock (AKA, Jeepday) 12:01, 8 March 2013 (UTC)
 * Note that my suggestions; does not specifically exclude works on new translations of the Bible, but does set a threshold that precludes casual attempts. Nor does it attempt to alter the multiple editor validation process. JeepdaySock (AKA, Jeepday) 12:01, 8 March 2013 (UTC)
 * The concept of mandating a translation of a work into a WikiProject sits fine with me. We know that WikiProjects have worked well for this sort of documentation process and for doing the work more consistently. It isn't foolproof, but it will assist. — billinghurst  sDrewth  14:33, 8 March 2013 (UTC)
 * Would a new WikiProject be required for each new translated work? That would be OK for larger efforts but it may be too much for smaller works (for example: articles, academic papers, short stories, poems etc).  Would it work to have one WikiProject to cover all translations of small works?  Otherwise I support (1) the general WikiProject concept, (2) the Translation: namespace, and the requirements for (3) scans and (4) a pure version on another Wikisource. - AdamBMorgan (talk) 18:23, 9 March 2013 (UTC)
 * I don't see the point of requiring a WikiProject at all - it does little in the way of alleviating the various concerns or resolving any of the unanswered questions being identified as a result of prior discussions here in this section and/or some of other sections. For contributors who wish to establish as much credibility & fidelity for their translation contributions as possible, a WikiProject can only help. If the potential reader opts to delve into some aspect of- or questions over- the translated content, having a Project already in place would be far more efficient & hands-off than having them resort to looking for answers from the community at large in Scriptorium. So (1) I'm not against the concept of having WikiProjects set up in conjunction with each translation effort or efforts (large or small), absolutely think the added policy should be to recommend a WikiProject be created in conjunction with a translation effort; explaining that creating one aids in establishing the appearance and/or degree of credibility & fidelity of the translation in the absence of the normal objective verifiability the PR extension typically provides under the Page: namespace, - but - I don't think creating an accompanying Project should be a stated requirement  unless  the consensus is that failure to meet that requirement absolutely results in a deletion or deletions per established practice(s). I'd much rather waste time restoring deleted stuff if and when compliance to that requirement is later met than have to drag out another possible series of discussions in Proposed Deletions for something that is allegedly as clear cut as 'failure to meet a requirement' normally would be. Otherwise, I'm 100% with Adam on his points (2), (3) & (4) just above. -- George Orwell III (talk) 02:45, 10 March 2013 (UTC)
 * Compliance difficulties: As a translator, I would have difficulties fully complying with one of George's proposed requirements.  The book I translated from is 360 pages long with scores of figures, but I only translated the preface and the first four chapters, which is 60 pages.  Also I started a translation, and now the preface and first section of the first chapter are done, but on French Wikisource the whole first chapter is available, but not the rest of the book.  I think a complete proofreading of the original work in its original language may be a too onerous requirement for the translator to comply with, while proofreading up to the chapter being translated may be more suitable for translators taking it one step at a time.  ResScholar (talk) 08:47, 10 March 2013 (UTC)
 * I would be OK with that. As long as the translated text has a pure/original text somewhere on Wikisource.  So, "translated chapter 1" needs a matching "original chapter 1".  Conversely, if "original chapter 2" does not exist yet then "translated chapter 2" cannot be created.  Potentially, a Wikisourcer could alternate between the two: proofreading an original chapter, then translating it, then proofreadinmg the next chapter, and so on. - AdamBMorgan (talk) 22:49, 13 March 2013 (UTC)

Dual language competent
Separate from the policy and technical discussion above, I think all can agree that hosting google translations would be out of scope. So some level of competence in both languages would seem to be a basic standard expectation of those doing the translation. I don’t think we can have any "Perfect" rule for setting a guideline on competence, but we do have multiple language wikis (and we are leaning towards requiring that the original language work first be hosted on the original language wiki), so I propose we set some level of measure based on edits in any family of both the cross wiki languages (i.e. Some level on English Wikipedia, and some level on Spanish Wikibook, would be ok without reguard to previous edits on either English or Spanish Wikisource, for Spanish to English Translation). JeepdaySock (AKA, Jeepday) 11:03, 14 March 2013 (UTC)
 * I agree in spirit but I wouldn't make it such a formal requirement. A perfectly competent person could have other reasons for not editing at another project.  Also, I have a very basic grasp of German but I think I might be able to translate some works as long as I had access to a German-English dictionary, and some scope for trial-and-error.  I think checking cross-wiki edits could be part of the process of confirming any suspicions of a user entering machine-translations (that is, after the fact rather than before hand).
 * NB: I would be OK with Google translations as the first stage of a translation project, equivalent to "Not proofread" (red), and the guideline that work of this quality should not be transcluded to the mainspace. Any machine-translated works pasted direcctly into the mainspace should be grounds for deletion, on top of not being backed by scans. (We might also steal and adapt a few more maintenance templates from Wikipedia to cover this). - AdamBMorgan (talk) 14:27, 14 March 2013 (UTC)


 * Adam's position for a requirement. This nonsense with adding unverifiable translations while attributing them to some unaccountable, blanket-Wikisource, team-translator tag rather than to the actual translating User:, skipping out on any OTRS requirements in the process, has to end before we inherit any more sub-standard works under the previous scheme guiding the inclusion of translations today. And if a work isn't transcribed past Chapter so-and-so on the original language WS domain - So What? If one is supposedly soooooo fluent in both languages to be translating works into English here, what exactly is stopping them from furthering the proofreading process in the Parent language over there? I say 'horse-feathers' to the whole idea of continuing the inclusion of translations in general but if that view ends up being in the minority, I'd much rather endorse new requirements than keep the old ways on this. Instead, I'd like to see some sense of verifiability through some metric of set requirements put in place once and for all here. Even requiring the contributor here to have at least reached auto-patrolled status over there would be a small step in the right direction for cris' sakes. Let's find an acceptable threshold together and put it in writing asap. -- George Orwell III (talk) 15:05, 16 March 2013 (UTC)
 * "while attributing them to some unaccountable, blanket-Wikisource, team-translator tag rather than to the actual translating User:"; Presumably translations would be a collaborative process like any other wikiwork unless it was previously published so I am not seeing how it could be attributed to "to the actual translating User", which just gave me a flash of insight into a related on going discussion. Jeepday (talk) 10:00, 17 March 2013 (UTC)
 * A Collaboration and/or a collaborative process that is specifically geared to best-result in the competent translation of some measure of preexisting content from it's originating language to some other target language, does not automatically equate to an establishment of "true" joint-authorship as it "normally" does in Wikipedia's case. Without legitimate joint-authorship, the entire group-project / collaborative-effort premise starts to fall apart as the supporting lynch-pin behind By clicking the “Save Page” button, you are agreeing to....  as some sort of blanket indemnifying waiver or protection for the subsequent contributions made after the initial ones attributed to the author who actually first added some/all of the translated content no longer applies. Blanket attribution to 'Translation Project' or 'Wikisource' as a means to circumvent actual collaboration (hashing out different interpretations before creation so the end product is static) is exposed for the farce its always been as soon as content is no longer stable nor static (attacking one unproven, unverifiable and allegedly group agreed upon interpretation by replacing it with another just as unproven, unverifiable and obviously only single-minded interpretation is not a sign of common intent, effort or aims reached through group consensus). Ba-lo-ney. You just can't have all the elements needed to make translations work as group project all at the same time. Each interpretation should have there own translation; not infringe upon a part or parts of someone else's. -- George Orwell III (talk) 13:49, 17 March 2013 (UTC)
 * "Each interpretation should have there own translation" Are there any existing example on the wikis of one person (or specific group) having ownership of an original work? Jeepday (talk)
 * That's not the point and we're focused just on translations here on Wikisource. What makes a formally published translation of some pre-existing public domain work any different than a "WikiBunch" collaborative translation of some pre-existing public domain work? Answer: Not much, its all about the license the translator or translators winds up using. In the first case - we typically have a dual license applied to the work; a single PD or CC license for the original work & another single PD or CC license for the translation. Its the same in the case of translations by collaborative effort, but the group of contributors must be qualified as joint-authors rather than a single author before they can waive copyright protections - but they have never qualified as joint-authors. Its nearly always a first translating author followed by a bunch of contributors taking issue with the first's interpretation and translation... and THAT is not a collaboration. A collaboration would also be static because these differences would be hashed out before final posting - something that also rarely happens if ever. -- George Orwell III (talk) 22:48, 19 March 2013 (UTC)
 * LOL, yeah it kind of is the point, your saying Wikisource should not have translations; but if they do, they should host them as non-collaborative works. Which is in complete opposition of pretty much every tenant of Wikisource and the entire wikifamily. JeepdaySock (AKA, Jeepday) 10:37, 20 March 2013 (UTC)
 * You've twisted having proper attribution and applying proper licensing into being for non-collaboration. That is not what was being laid before you. These original derivatives should have a license matching their attribution because they both rely on an original work that was formally published. Of course whatever or however they come into being will be the sum of a group effort but, again, that is not the same as correctly attributed joint-authorship being properly waived collaboration. The reason I'm against translations overall is because there is no way to measure the contributor's fluency in both languages - the point of this section. But as long as we're discussing requirements, I thought it best to fix this oversight (again I assumed too much all at once on my part). If you want to cite 'Wikisource' as the translator, then by all means we must have a translation project set up for each work (large or small) prior to the creation of the translation. If the person setting up the project allows for others to make "corrections" to the original translation, the question of joint-authorship & attribution are then no longer paramount. The flip side of setting up translation Projects ahead of page creation would be proper attribution to the joint-author(s). If you don't want to do either, then each interpretation should have it's own seperate translation. -- George Orwell III (talk) 13:36, 20 March 2013 (UTC)
 * This message is a little clearer about your concerns. I am completely on board with identifying the original work and author, I think we are firm on that. I am still not seeing though how each person involved in a translation needs to be physically identified in place of a "Translated by Wikisource" statement. Every edit on any of the wikifamily sites is released through the same license, and terms of use which pretty much says, once you posted it you loose all control of what happens to it, AND "You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license". I hear you saying each contributor translator needs to be clearly identified (paraphrase), but I am not seeing how anything beyond what is captured in the edit history is required and, As I understand your proposal is for A single individual, or specifically named (in a project) group to be identified prominently on the translation(paraphrase). And this is counter to my understanding of policy here and across foundation. The picture you are drawing in my mind of your requirement, is that Wikisource, becomes the home for single author ownership of original translations, that can be freely modified (due to CC release) anyplace EXCEPT Wikisource.  So either I am completely not getting your message, OR I would request the you point to what ever you think it is that requires this higher level of ownership, and how it could be supported within the policy of Wikisource and the Foundation. JeepdaySock (AKA, Jeepday) 15:00, 20 March 2013 (UTC)
 * Look, I'm not going to go 50 rounds with you over this here (I'm already guilty of going far beyond what was actually asked in other sections). I'll gladly further the nuances in play here anywhere else you see fit but as far as the point on having some standards measuring a contributors dual language competence -- I'm in full support of it. As for the other point(s) raised and still left open to discussion in this section -- you may want to start by pondering what is the point behind the asking User:Khesapeake for OTRS to support an acceptable license for his English language translations of Romanian poetry clearly in the PD in that parent language when by your logic all he needed to do was just click "save" or maybe just attribute his work to some undefined project title instead of his User: name to avoid proper attribution/copyright questions? -- George Orwell III (talk) 20:01, 20 March 2013 (UTC)
 * This is not a 50 round fight, you tossed out a proposed requirement for translation attribution, that is different. I was a exploring how/if it could work.  At this point I would say it can’t work. It was an interesting idea, but no one else is supporting it, and while I can see how could help to increase the quality of translations, it does not seem feasible currently. JeepdaySock (AKA, Jeepday) 10:44, 22 March 2013 (UTC)
 * I object to any translation rules that make us holy-then-thou with respect to Wikipedia. If it's good enough for writing an encyclopedia, it's good enough for making a translation.--Prosfilaes (talk) 02:20, 20 March 2013 (UTC)

}}
 * Of those voicing an opinion there is a consensus of some expectation of cross language competence. I have thought but don’t have the idea completely worked out; would it be technically possible to identify in the proposed translation name space, the original work language and provide the release notice in both English and the original language?
 * "By clicking the “Save Page” button, you are agreeing to the Terms of Use and the Privacy Policy, and you irrevocably agree to release your contribution under the CC-BY-SA 3.0 License and the GFDL. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license. "
 * I'm not sure if or how the MediaWiki page or template would be able to detect the language. I have been thinking about possibilities for the new header template, eg. translation header, which would, for various reasons, include the language as a parameter.  That could potentially display something.  The next problem is that each version of this statement for each language would need to be stored on English Wikisource in some way (probably as a template). Unless a combined document exists somewhere, someone is going to have to go around collecting each version of the statement from other projects. - AdamBMorgan (talk) 14:17, 22 March 2013 (UTC)
 * Yeah I was thinking of somehow capturing the original language from user input also (maybe a list or drop down). But I was hoping we could harvest the message automatically somehow. The terms of use, would be easy enough as it is a URL with the language indicator on the end. My concern is that someone without exposure to any other wikifamily and not having English as a first language may not understand what it really means to post their work here.  If we don’t have a requirement of some level of wiki experience in both (or at least one language) I am not comfortable that we have informed consent to the CC-BY-SA and GFDL release. Having heard the arguments against dual language wiki experience, I can see how that might not be feasible. So looking for something, to say we have done our best… Without a single or dual language wiki experience requirement we can not prevent something like "English As She Is Spoke" from being created (and that is ok, it is the wikiway), but we should have at least some confidence that user has been given an opportunity to understand what it means when they post a translation here. JeepdaySock (AKA, Jeepday) 14:58, 22 March 2013 (UTC)
 * I think it's possible for a template to detect if the page is being edited (although I'd have to check on that). If so, it can include an ambox between the header and the body, with the speedy delete style type borrowed from ombox (rose background, exclamation mark etc) and the appropriate message.  If anything, it will be more obvious than normal.  The foundation's terms of service only appear to be in a handful of languages but it's a start.  Every project will have a localised version of MediaWiki:Wikimedia-copyrightwarning, so it won't be difficult collecting them; it might just take some time to do.  A maintenance category could be used to track translations without versions of the text, to alert us to any gaps.  NB: For the record, the other reasons to include the language code in the header are: for the interwiki link (so we can track if this is present or not with a category), to highlight that link as the original (which we only do sometimes at the moment), automatic categorisation (eg. Category:Works originally in Latin or Category:Wikisource translations of works in Thai), and possibly to include it in the header (ie. "translated from the [LANGUAGE] by Wikisource"). - AdamBMorgan (talk) 17:58, 22 March 2013 (UTC)
 * Additonally, maybe it would be possible with Lua to have a message controlled by a drop down list in the edit-notice for the Translation: namespace. I can't think of a way to do it with a standard template and I still haven't grokked Lua but there's a chance it could work.  We would still need to collect the messages, of course. - AdamBMorgan (talk) 18:01, 22 March 2013 (UTC)
 * I just randomally checked Wikimedia-copyrightwarning, we should be able to bring them in automaticelly, Changing the language code in http://en.wikisource.org/wiki/MediaWiki:Wikimedia-copyrightwarning brings you to the correct place, at first blush mk:MediaWiki:Wikimedia-copyrightwarning and simular works, so it should not be to hard automatically populate the message, if we have a language code. JeepdaySock (AKA, Jeepday) 19:18, 22 March 2013 (UTC)

Translated phrases

 * This section has been closed as community consensus appears to have been reached. If you wish to add further comments, please do so and just remove the closed template.

Errata
{{closed|Inconclusive but certainly not banned. The annotation policy may apply. If not, further discussion on Scriptorium may be necessary. - AdamBMorgan (talk) 17:45, 12 July 2013 (UTC) Another form of derivative work are versions with all later errata incorporated into the text. Whether the errata is official or user generated makes a difference but even with official errata, the result would no longer be pure, hence a derivative text.
 * text=

Should Wikisource host works like this? If so, what policies and guidelines should apply?

Agreed. We are on the same page. MODCHK (talk) 00:18, 7 March 2013 (UTC)
 * Comments:
 * How might the errata be proven? This is dangerous territory, and I feel well beyond the scope of Wikisource. MODCHK (talk) 22:32, 6 March 2013 (UTC)
 * It was mentioned on Scriptorium. I think the idea may have been to merge errata from a separate errata page or a later publication back into the work itself.  Of course, there might be a risk of this encouraging users to "fix" works which could cause problems. - AdamBMorgan (talk) 22:54, 6 March 2013 (UTC)
 * Oops. Rather condescending. I did not by any means intend that. MODCHK (talk) 00:21, 7 March 2013 (UTC)


 * Errata are annotations, and should be governed by whatever rules we apply to annotations in general. As stated above, my view is that separation of annotations from the original work is critical; e.g. put them in the notes section of the header. An example of this applied to errata can be seen at History of botany (1530–1860)/Book 1/Chapter 4. Hesperian 01:02, 7 March 2013 (UTC)
 * If the annotations are contextually added inline and using &lt;ref> tags, then they &lt;references> component needs to be AFTER the reference, so putting that into the header is problematic. — billinghurst  sDrewth  13:05, 7 March 2013 (UTC)
 * I just want to mention that for mathematically heavy texts with errata in equations, it is quite possible for the errata to be very extensive. This can be due to the length of the equation involved or the number following from repeated use, but also the nature of mathematics. For example, here a single erratum reworks many lines. MarkLSteadman (talk) 06:49, 7 March 2013 (UTC)

I strongly believe that there is the need for some sort of errata. Reference books that we have show variations in spellings, or wrong data, some of which can be corrected in later editions. Where there is errata, and it can be demonstrated, I believe that this falls within {{tl|user annotation}}. An example for me is Author:James Hingston Tuckey, early author for Australia. The biographical works call him James Kingston Tuckey and through my observations and research I can demonstrate where and when in history that this has occurred. It isn't covered in the research material for this otherwise obscure author. I have a note at Tuckey, James Kingston (DNB00) and A Compendium of Irish Biography/Tuckey, James Kingston about various aspects. {{smaller|[And one day I will publish my research so that it can be credited into enWP, but for now we are the holders of my research gems.{{wink}}}} — billinghurst  sDrewth  10:20, 7 March 2013 (UTC)


 * As mentioned above, errata are important, we shouldn't deny that works have errors, among the types we have are
 * Some are self-corrected by the publication, eg. an errata in the the work itself {{smaller|(The Dictionary of Australasian Biography)}}; or
 * by the publication of the errata in a separate set of volumes {{smaller|(Dictionary of National Biography)}}; or
 * by a later edition {{smaller|(DNB <-> ODNB)}}; or
 * by research; or
 * by discovery of a hoax, etc. at a time after publication
 * So this becomes an area where we need to look to manage by guidance, as some of the issues can be quite problematic, and there are a range of solutions available to have these errata. We have talked about the representation of an unblemished text, and that is a necessity. — billinghurst  sDrewth  13:02, 7 March 2013 (UTC)
 * To me at least, an erratum is like a correction in a newspaper. If it is not published by the author or the publisher as a correction or an erratum, it is not an erratum or a correction. There might be additional errors in the text, and maybe they should be annotated, but that should be considered a class of annotations above, and not under the errata here. There are in principle complications (like a newspaper publishing an April Fool's Day correction, or a journal retracting the paper of a scientist which the scientist still thinks is valid) but errata are not just people saying, hey here is an error, they are published, acknowledge corrections to errors. MarkLSteadman (talk) 17:08, 7 March 2013 (UTC)

Drawing this point to the top.
 * What is errata?
 * Editor / publisher generated? (official to the text).
 * Identified / published by other parties; and may or may not have been published (separate to the text)

It probably needs a later discussion. There was a discussion within WikiProject DNB {{smaller|(not directly linked)}} about the means used to display errata, and in the end they have been done inline with the original article. — billinghurst  sDrewth  04:02, 8 March 2013 (UTC)
 * Adding some examples of what has been done onsite.
 * DNB — pages visible via {{tl|DNB errata}}
 * DAB — example page {{DAB lkpl|Thomas, Robert}}


 * Agreeing that Errata = Annotation. Presumably any corrections that we would at all consider would be in published works that meet our requirements for hosting.  If the difference is sufficient enough to note, then it presumably sufficient for the entire other work to be hosted per Versions. In which case I would support a minor annotation that would reference the correction in another hosted work (red links allowed). JeepdaySock (AKA, Jeepday) 16:18, 8 March 2013 (UTC)


 * I'm not quite sure I follow. If by "other work" you mean the corrections for work X, than sure it is presumebley they could be hosted as an independent work "errata for work X" and then note it on the page of work X. But then, it would not count as another version of the work X, it would be a separate "work," hosted because it has it's own independent merit. If by "other work" you men a corrected version of work X, i.e. with the errata applied to X, it would make sense to host it as a new version of X, but then you have the problem that there would not necessarily be a published version of that work and any case it would be outside the scope of annotation as it would be a new version (just as a new edition would fall under the version policy rather than here.) Also, it would require redoing the entire work to fix a few corrections.
 * I would also like to point out that having to go back and forth between the corrections and the original work is suboptimal and I think it is absolutely silly to have a work, have a list of corrections printed with the work, and then to say that I all I can do is put a note at the top and say, this work has corrections but I can't tell you what they are, you have to go to another page to see them. If the corrections have to live in a tooltip / sidenote / box / whatever is decided on as an appropriate way to handle them, that is ok, but the corrected text should be as near the the errant text as is deemed feasible. I might live with them at the end as we handle footnotes, but to have a marker that leads to a "footnote" that is just a link that says, click here to see the corrections is, as I said above, silly. MarkLSteadman (talk) 23:32, 9 March 2013 (UTC)
 * I am assuming that the source for corrections to Book1 are in Book2, two distinct works. Both of which would need to be PD, and both original works. So host them both, don’t try and fix Book1, by making changes to it that are not published until Book2.
 * In the worst case, if there is some terrible blunder in Book1 (i.e. Pluto is described as a Planet), that is corrected in Book2, then some kind of small addition (Crystal Clear) is added to Book1, point to correction in Book2, possibly with some short description of the terribleness. Jeepday (talk) 00:32, 10 March 2013 (UTC)
 * I see three possible relationships mentioned so far between Book1 and Book2. 1) Book2 is a later version (e.g. a later printing/edition) of Book1, where the terrible sentence has been rewritten. 2) Book2 is a later book in the same series as Book1 (for example, a later journal) which contains a note such as, "In Book1 we said planet we should have said dwarf planet, we regret the error."  3) Book2 is a completely different book, but it shows that Book1 is wrong, for example the work where Pluto is officially defined as a dwarf planet. Whatever we decide on, should cover all of them. My inclination would be to leave the original sentences in case 3, but document the error (as you mentioned), but use the revised sentence and document the original sentence in case 2. For case 1, if we are hosting the revised edition in its entirety, it seems that some nonintrusive marker that means check out the revised version would be sufficient, since if you want to read the corrected version, you can. MarkLSteadman (talk) 10:53, 10 March 2013 (UTC)
 * For the most part I think you are reflecting the building consensus as I see it, but I get a little lost when you are talking about replacing a sentence. Generally we keep  incorrect spelling (i.e. {{tl|SIC}}) the same approach would seem appropriate for other errors as well. JeepdaySock (AKA, Jeepday) 10:39, 11 March 2013 (UTC)


 * • In the hypothetical's 3rd scenario, where Book1 states or infers Pluto as officially, generally or even anecdotally as being recognized or classified as something other than what Book2 has over the same point(s), doesn't necessarily make Book1 "wrong" at all - especially if scenario 2 (the editorial oversight) is not behind the difference. At best, Book1 can be considered 'outdated' or as 'since being superseded' but not so much as being outright erroneous or baseless when being viewed by more than the POV of just in today's terms. Now there might be some agreement in clearing that point up for the sake of today's potential reader as being a beneficial or value-adding effort in some sense to whatever degree here on WS, but I don't see how that translates to something that Wikisource is tasked and/or equipped to currently address as well as some sort of justification for inclusion of these kind of additions without considering that it may detract from the reading experience of some other slice of our potential viewers rather than enhance it both at once. Continuing on down the previous hypothetical trail - There was an era Pluto was the 9th planet, case closed. And let's say.... people focused on researching an era somehow need to incorporate/disseminate aspects of Pluto as framed by that era (not Pluto itself in particular in other words); would they find such annotated diversions, may they be 'up close' or 'quite a ways away', very useful? Not in my opinion. -- George Orwell III (talk) 05:21, 12 March 2013 (UTC)


 * • I agree with this completely. I've been proofreading nineteenth century physics texts, and I would be completely against placing a correction on every idea that turns out not to be quite true, such as "caloric" or conflicts with later developments, such as relatively or atomic or nuclear physics. It might be conceivable for someone to work through a nineteenth century text, marking these various errors but that to me is more in the general commentary / annotation realm. That said the hypothetical could be about a recent astronomy work published under a valid license (for example in an open access journal) where it might be appropriate to mark the error. MarkLSteadman (talk) 07:36, 12 March 2013 (UTC)


 * Putting my head on the block here. There is a fourth errata scenario in which the work is published as several volumes and the last volume has an extensive appendix full of addenda and corrigenda to the main text. An prime example of this is Index:A Dictionary of Music and Musicians Vol 4.djvu in which there are 304 pages of this Appendix and it covers articles across all four volumes of the work. I have been adding the corrigenda to the articles as I proofread them. For an example, see the end of the second paragraph of Page:A Dictionary of Music and Musicians vol 1.djvu/708, where the original text as printed in Vol. 1 remains and a note of the amendment is inserted in []. I acknowledge that doing this borderline within the above discussions, but due to the way this work will be presented articles will not have their own headers and therefore will not have notes fields. I decided about 3 years ago that this was the most pragmatic approach to this work. The alternative was to insert "errata anchors" that readers would have to click to get the amendments (which I have only just thought of now). Beeswaxcandle (talk) 06:49, 12 March 2013 (UTC)


 * I would prefer that for scenario 2 and 4, i.e. Editor / publisher / author corrections to: 1) Host the correction on WS, 2) fix the error i.e replace the wrong information in the main text with the correct version, and 3) mark it so that a) it is clear a correction was applied and b) allow the user to see the original text. Especially for books published with errata lists at time of publication, it is technology (the need to remake the printing plates, the demands of traditional printing schedules etc.) that prevented them being fixed, and would it best match the desires of the author and publisher. To me the difference between this and the {{tl|SIC}} is that the publisher is asking us to fix the error, and that should certainly matter. Any non-publisher corrections, should leave the sentence as is, and put the corrected version behind the tooltip in the sidenote / footnote etc. MarkLSteadman (talk) 07:36, 12 March 2013 (UTC)


 * Rather then changing the text from it’s originally published version, I like the suggestion Requests_for_comment/Annotations_and_derivative_works for these annotations. Seems like you would get the best of both worlds that way. You are reading it as it was published and you can easily see the "revised version". Somebody with the technical know how, might even make it so the note could pop-up as a tool tip on mouse over. JeepdaySock (AKA, Jeepday) 10:57, 12 March 2013 (UTC)

A real life error correction example to chew on: "In 1872 No. 7 Savile {{sic}} Row, Burlington Gardens—the house in which Sheridan died in 1816 {{sic}}—was occupied by Phileas Fogg, Esq." Those sics were added by A Bibliography of Jules Verne's English translations, as the French reads "En l’année 1872, la maison portant le numéro 7 de Saville-row, Burlington gardens— maison dans laquelle sheridan mourut en 1814—, était habitée par Phileas Fogg, esq., l’un des membres les plus singuliers et les plus remarqués du Reform-Club de Londres, bien qu’il semblât prendre à tâche de ne rien faire qui pût attirer l’attention." The interesting thing to me is that both those changes are motivated by reality; there is a Savile Row in London, and Richard Brinsley Sheridan did die in Savile Row in 1816. There's space here for interesting and useful annotations without going too far, I think.--Prosfilaes (talk) 09:32, 21 March 2013 (UTC)

Scan Correction
Does Errata/Annotation include scan corrections where two identical (or near enough per community discussion) DJVU files are combined to overcome technical or physical limitations of available works,
 * I would say no. The two scans should be of the same book/journal/whatever, not necessarily the same physical object but the same edition, per Versions.  Only the digital file has been changed, the actual text will remain the same (and by text I mean the words and letters not the ink on the paper). - AdamBMorgan (talk) 18:34, 8 March 2013 (UTC)

}}

Implementation
Request was made to Administrators' noticeboard about the implementation aspects of a Translation: ns, and I addressed some questions there for the bugzilla, which I will progress in the next few days.

There are some implementation points that the community will need to discuss.


 * Will we continue to utilise the Index: and Page: ns for side-by-side translations of our works? It keeps the workspace away from the immediate public eye
 * Yes this example Appears to meet my understanding of the community consensus perfectly. JeepdaySock (AKA, Jeepday) 10:53, 6 June 2013 (UTC)
 * I think we should translate in Page & Index (using them as a general workspace). This has already been done in a few cases and it is probably a lot more work to get Proofread Page working on an entirely new set of namespaces than it is to just use what we have. - AdamBMorgan (talk) 10:56, 6 June 2013 (UTC)
 * Will we then transclude these works into the Translation: ns? It does transclude and I cannot see technical reasons why this won't work, but am not a code fine detail person git
 * Yes, if there is no problem, that should be the solution. (ps your link is 404 error) 10:53, 6 June 2013 (UTC)
 * I don't expect any problems but, likewise, I'm not familiar enough with the code to actually know. - AdamBMorgan (talk) 10:56, 6 June 2013 (UTC)
 * Are we going to use header or implement a derivative; even consideration of the colour. Clearly
 * Don’t see why not, if we need to make adjustments it would be easy enough to upgrade headers in Translation name space by bot later. JeepdaySock (AKA, Jeepday) 10:53, 6 June 2013 (UTC)
 * I have actually started sketching out a translation header. It doesn't do much and it is not fully featured at present but it's there.  I started a brief list of features to be included on the talk page.  I chose yellow as a placeholder colour just because it was available (currently we have red-ish=author, orange-ish=process, green=main & blue=portal; that left yellow and purple as the unassigned colours of the rainbow). - AdamBMorgan (talk) 10:56, 6 June 2013 (UTC)
 * I did not like yellow very much and changed it to green—it's different from the header green, which is closer to blue. I also made other little changes. Later on a better set of parameters could be developed, including override_author, editor, and override_editor. I think all Wikisource translations should be categorized like other works, i.e., by type, genre/subject, year, and original language. I added an automatic categorization by original language in the template, and a system to automatically categorize by year could be enabled, too (like Template:Header/year). I am not sure about whether we should use copyright tags in the Translation namespace.--Erasmo Barresi (talk) 09:35, 25 June 2013 (UTC)
 * Well I did not like your green one bit so it is back to the off-yellow now. It was far too close to the header green. -- George Orwell III (talk) 07:46, 26 June 2013 (UTC)
 * What will we need to replicate in Mediawiki:common.css and Mediawiki:common.js that matches main ns.
 * I've added the aforementioned placeholder-yellow already. - AdamBMorgan (talk) 10:56, 6 June 2013 (UTC)
 * NB: I reverted my Mediawiki edits, mostly because I was using a slightly damaged monitor at work and couldn't see the normal header colours (making me think I had broken something) but also because it will be easier to modify and play with style options in the template and then move them to Mediawiki when they are done. - AdamBMorgan (talk) 18:55, 7 June 2013 (UTC)
 * Cross wiki namespace redirects are currently forbidden under our rules, do we or how do we point from main ns: to Translation: ns? some effect on how we move the works.
 * On Wikisource talk:Translations I proposed using Dated soft redirect for existing works, if we include Translation name space as a default search inclusion, this should cause the least issues. JeepdaySock (AKA, Jeepday) 10:53, 6 June 2013 (UTC)
 * I'm not sure about this. Hard redirects would be the most invisible for casual users (who probably aren't going to care about the distinctions between namespaces).  It goes against the current practice but we could make an exception for this.  Alternatively, we could use translations, a variant of disambiguation pages.  That would fit current practice but it means loading and reading an entirely redundant intermediary page (assuming just one translation) which will probably be annoying for many readers. - AdamBMorgan (talk) 10:56, 6 June 2013 (UTC)
 * A soft redirect of some kind could work (although the same issues apply as with ). However, I do not think we should use dated soft redirects.  Many links to our translated content are on blogs, forums, reddit etc, which are hard-to-impossible to change now.  There should be something at our end of these links, especially when the content is still on Wikisource. Deleting the pages entirely invalidates at lot of work, outreach and enthusiasm for our project. - AdamBMorgan (talk) 18:55, 7 June 2013 (UTC)
 * What about using the article ID No. ( wgArticleId / MediaWiki:pageinfo-article-id ) ? That way, we'd still be leaving one namespace for another ( cross-namespace redirect ) but neither namespace designation needs to be present or given in the link text. Click the following & observe...
 * [//en.wikisource.org/?curid=1193406 https://en.wikisource.org/?curid=1193406]
 * [//en.wikisource.org/?curid=1193406&match=es https://en.wikisource.org/?curid=1193406&match=es]
 * I'm pretty sure that can be templatized/Lua'd somehow to work inline, cross wiki and so on. -- George Orwell III (talk) 08:46, 26 June 2013 (UTC)

I am sure that there other minutiæ, however, that is all that springs to mind at the moment. — billinghurst  sDrewth  10:28, 6 June 2013 (UTC)

50007 — billinghurst  sDrewth  06:49, 22 June 2013 (UTC)
 * ✅ Namespaces Translation: (ns:114) and Translation_talk: (ns:115) have been created [//en.wikisource.org/w/api.php?action=query&meta=siteinfo&siprop=general|namespaces|namespacealiases] for us with thanks to . 114 and 115 were chosen as they were free across the Wikisources ns:, and as part of the request there is now a comment asking that they be reserved. Also note that ukWS has also requested the similar namespaces and setups.  We should be right to start moving works.  I would suggest that we do a few, ensure, after a couple of days, that they are being indexed, and then move the remainder.  I would suggest that substituted dated soft redirects are put in place of the other documents.  We are also need to go through our general documentation. — billinghurst  sDrewth  15:19, 5 July 2013 (UTC)


 * Related to this is the on-going discussion to have Translations made into policy. The section concerning the namespace for original translations will need to be updated, and there is an active discussion about some portions of the page. --EncycloPetey (talk) 21:46, 5 July 2013 (UTC)