Wikisource:Requests for comment/Annotations and derivative works

From Wikisource
Jump to navigation Jump to search
←
Annotations and derivative works RfC

Discussion to establish the details of how the community wishes to host derivative works on Wikisource.

All users are free to add new topics or points for discussion. These should be added as second-level headers as with the existing points (or just click the "Add topic" link).

All users are free to comment on or discuss each and every point. Please comment on each point in the appropriate "Comment" section.

Overview[edit]

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 Wikisource: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[edit]

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)[reply]

Two more added. Jeepday (talk) 11:17, 24 March 2013 (UTC)[reply]
Two more added. Jeepday (talk) 22:25, 26 March 2013 (UTC)[reply]
One more added JeepdaySock (AKA, Jeepday) 15:12, 1 April 2013 (UTC)[reply]
One more added JeepdaySock (AKA, Jeepday) 10:56, 5 April 2013 (UTC)[reply]
Three more added Jeepday (talk) 11:43, 10 April 2013 (UTC)[reply]
Add Grandfather clause from, Foundations for all points. Jeepday (talk) 23:25, 15 April 2013 (UTC)[reply]
One point amended. - AdamBMorgan (talk) 19:13, 7 June 2013 (UTC)[reply]

Points for discussion[edit]

Foundations for all points[edit]

The following discussion is closed and will soon be archived:

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)[reply]

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)[reply]

  • 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)[reply]

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 w: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)[reply]
  • 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)[reply]
    Our differences in preference are represented by different philosophies of educational thought. The one I am following is described in the Wikipedia article w:Educational perennialism which responds somewhat to what you may object to in my position. ResScholar (talk) 07:24, 10 March 2013 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    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)[reply]
    "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 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 Wikisource: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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
First, I thought we agreed it was actually OK to transclude one index to many mainspace pages. That's part of what Wikisource: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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]

    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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 Wikisource:WWI#Scientific_research as it stands today? JeepdaySock (AKA, Jeepday) 15:07, 12 March 2013 (UTC)[reply]
    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)[reply]

Published derivatives[edit]

The following discussion is closed and will soon be archived:

No disagreement to date - AdamBMorgan (talk) 18:14, 20 March 2013 (UTC)[reply]

Should published annotated texts, translations etc be covered by Wikisource's policies/guidelines regarding derivative works (when it is decided here) or are these texts a separate case? Are published derivatives to be treated as any other pure text?

Comments
  • At face value, this seems like a no-brainer; Was it published? = It can be hosted, but I don't think this is that straight forward unless we make clear what exactly can be considered as "published". Of course, those works which are scanned from the formally published, printed word are easily included as acceptable but I draw the line at including blog-ish, originally researched and/or un-authoritative sources being included here. -- George Orwell III (talk) 00:31, 7 March 2013 (UTC)[reply]
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.

Annotations in general[edit]

The following discussion is closed and will soon be archived:

Consensus is that annotations in general are allowed in Wikisource. Jeepday (talk) 10:50, 24 March 2013 (UTC)[reply]

The different types of annotation will probably need to be discussed in more detail, separately under subsequent points. However, in a general sense, should Wikisource host annotations at all? If so, what other policies and guidelines should apply?

Comments
  • Yes. By no means should this action be required of editors; but at their individual discretion I believe it should be entirely permissible to link:
    • "unusual"[1] words (say using {{wg}}/{{WiktGrey}}/etc. or similar) to Wiktionary, if a suitable definition exists or is created. Hanging or unfulfilled redlinks are certainly of dubious value, and should not be encouraged.
    • (in works of a factual or semi-nonfictional nature) names of historical entities or places to a pre-existing (and obviously appropriate) Wikipedia entry.
  1. ↑ My working definition of "unfamiliar" here, refers to words with which the editor is either themself (or may reasonably expect another editor would be) unacquainted, upon initial edit.
MODCHK (talk) 22:25, 6 March 2013 (UTC)[reply]
  • Overarching policy should be that annotations (other than internal wikilinks) must be clearly and completely separated from the text. Integration should be forbidden. The reader's experience of annotations should not be one of reading an annotated work; it should be one of reading an original work with a CliffsNotes to refer to if needed. We're not changing the original work in any way; we are simply making available a body of distinct annotations that the reader may access if they wish. Hesperian 01:10, 7 March 2013 (UTC)[reply]
  • What Hesp says AND when printed (exported) the default should be to have an unadulterated copy of the work, with any annotations being separated from the work, maybe pseudo-appendicised, if that is possible. — billinghurst sDrewth 10:20, 7 March 2013 (UTC)[reply]
  • Most annotations fall into the scope of other projects like b:Wikibooks:WIW#Wikibooks_includes_annotated_texts, for the most part I am of the opinion "don’t scribble in Library books". I understand that there may be good rationale for including some, and am open to considering limited annotations. JeepdaySock (AKA, Jeepday) 12:00, 7 March 2013 (UTC)[reply]
    BUT if we have the work here but only proofread (not validated) yet transcluded, one then has to copy and paste a less than fully verified edition. If it is done locally it can be validated and transcluded. The argument needs to take into account the practical and reasonable constraints. Under this proposal all texts would have to be reproduced at enWB without special tools. Now that may be the decision, but that needs to be part of the conversation. — billinghurst sDrewth 14:18, 8 March 2013 (UTC)[reply]
    Working to annotate an unvalidated book is like, trying to butter the bread before it is finished baking. Sure you can do it but, you are likely to get burned and it would better to just wait before trying it. Jeepday (talk) 02:15, 9 March 2013 (UTC)[reply]
  • Surely it is more of a compromise. A validation made to early risks becoming foolish in the context of later work; one made much later risks never being made at all. Surely the best path is to make the annotation, and (perhaps others may) remove it if it ever ceases to he helpful. (This also raises another concern of mine: are annotations solely intended to be oriented toward the final product [whatever that may be]; or should they be considered aids to the validation process itself, and thus of less import later on?) MODCHK (talk) 02:55, 9 March 2013 (UTC)[reply]
  • I am assuming/implying this only applies to off WS works, we are leaning towards including some specific annotations here, which would be part of the baking process. Jeepday (talk) 02:17, 9 March 2013 (UTC)[reply]
    There are many works that sit unvalidated but proofread for many years. Either way, it is still taking and replicating a text that already sits in one wiki. — billinghurst sDrewth 09:45, 10 March 2013 (UTC)[reply]
    In my brief attempt at annotating a text, I was adding them as I proofread. I would assume the same is true for others, or at least potential others. It will probably be necessary to annotate on Wikibooks from unvalidated text and maybe try to copy in the validated version when that becomes available (although that would be complicated; you couldn't just copy and paste as that would delete all of the existing annotations). I would expect a user to want to go straight from proofreading to annotation and not want to wait for someone to do the validation. A fringe possibility (that I only mention for completeness) is working on Wikisource and exporting to Wikibooks when it is finished, but that is less desirable as it would leave an out-of-scope work on this project for months or years.—unsigned comment by AdamBMorgan (talk) .

Wikilinks as annotations[edit]

The following discussion is closed and will soon be archived:

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. Jeepday (talk) 11:13, 24 March 2013 (UTC)[reply]

It has been suggested that any wikilink within the body of the text counts as an annotation because the text is no longer pure. The choice of wikilink may also be dependent on a particular user's opinions of what needs to be wikilinked and the destination page. Wikilinks within Wikisource (ie. to other works or author pages) could possibly be treated differently to wikilink to external pages (such as Wiktionary and Wikipedia, although the interwiki map allows wikilink to multiple sites, including Project Gutenberg and Google). It may prove difficult to enforce a ban on wikilinks, should one be decided ono(?) by consensus, because new users are likely to expect wikilinks on a wikiproject.

Should wikilinks be treated as annotations or allowed in all texts? Does it matter what the target of the wikilink is?

Comments
  • Provided the link target makes sense in the context it is employed; and does not affect the text of the work (minor highlighting of the link aside) I perceive no real conflict. MODCHK (talk) 22:29, 6 March 2013 (UTC)[reply]
  • Wikisource wikilinks — wikilinks that link author names to our author pages, and wikilinks that link work titles to our hosted works — are our value proposition. They are what makes us different from other transcription projects. If we didn't use them, we may as well be Project Gutenberg. They should be encouraged in all works. With some hesitation, I would extend that to all internal wikilinks e.g. links to Portal: pages. However, links to sister projects such as Wikipedia and Wiktionary should be treated as annotations, and discouraged in the body of original texts. Hesperian 00:38, 7 March 2013 (UTC)[reply]
There is a downside to redlinking works (and sometimes authors) within a text, and that is due to the possibility that if the redlinked work or author page is ever created, a different titling might be used, and the redlink could stay redlinked possibly forever. Perhaps encourage editors to create an author page upon redlinking an author in a text... Don't know what the solution would be with a redlinked text that might be titled slightly differently in the future, however... Londonjackbooks (talk) 03:08, 9 March 2013 (UTC)[reply]
True, there is always the risk. But when it happens it pretty easy to combine them. I know that billinghurst has found and corrected some Author pages, that I have created where they already exist. In some cases it is just stupid search errors that missed finding the existing page. In others (like Popes) it is naming convention issue where a redirect from one to other is appropriate. Internal red links and crosswiki red links have different issues. In part because crosswiki red links are not red. Jeepday (talk) 09:04, 9 March 2013 (UTC)[reply]
  • Generally agree with the previous POV's except that I see little difference between wikilinking to the various goodies found in our internal Wikisource namespaces and those found within external sister Wikis such as Wikipedia or Wiktionary; I would find those acceptable as well.

    Of course, over wikilinking is more frequently the problem I find rather than lost or under-wikilinking. At any rate, I find wikilinking acceptable as long as they are limited to common-sense standards of being useful, value-adding and/or targeted while en mass or as-many-as-possible wikilinking quickly turns into a case of diminishing returns. -- George Orwell III (talk) 01:23, 7 March 2013 (UTC)[reply]

  • Linking direct references (e.g. references to other pages or sections of a work, citation of another work, conceivably link to Author namespace for citation of an author's oeuvre) okay. Everything else treated as annotations. I recall an interesting argument regarding the effect of wikilinks on Flight 93 Cockpit Transcript in a previous round of discussion on wikilinks, to the effect that linking the basmala and takbir WP articles emphasizes and exoticizes them. They're alterations to a work and can affect its reading. Prosody (talk) 01:54, 7 March 2013 (UTC)[reply]
    You raise an excellent (and overlooked) point concerning wikilinks - the piped wikilink vs. a straight wikilink. My previous support was based primarily on "straight" wikilinking ( [[w:Flight 93|Flight 93]] ) where the titled target is the same, or nearly the same, as the displayed (& as published) text is and not the kind Prosody mentions where the titled target is technically not the same as the published text ( [[w:takbir|Allah is greatest]] ). While the latter seems like one in the same in its ultimate meaning I agree these are alterations to the original that can & do affect readability. They are not the flavor of wikilinking I am in support of. Maybe we need to further clarify any inclusions/exclusions based on very specific examples of a wikilink while moving forward? -- George Orwell III (talk) 02:25, 7 March 2013 (UTC)[reply]
    GOIII, Flight 93 is a direct link, non-interpretative, whereas the second example of link is interpretative, not solely a wikilink. For the second type, IMO such an interpretative link would need something citable, which is all getting into danger territory. If the link can be disputed, then it is my opinion is an interpretative annotation, and probably doesn't belong here. We have examples of this interpretative linking in The Fight at Dame Europa's School, and the more recent additions which have been reverted. — billinghurst sDrewth 10:03, 7 March 2013 (UTC)[reply]
    Billinghurst, you managed to illustrate the nuance I was originally aiming for far better than I did. To be absolutely clear on this point - I completely concur with your assessment based on that excellent description between the types of wikilinkage in question. As a result, my previous re: the link syntax involved (straight vs. piped) should be superseded with the better differentiation using the interpretative vs. non-interpretative model in moving forward from here. -- George Orwell III (talk) 21:46, 7 March 2013 (UTC)[reply]
  • For me context is key. If an author has been mentioned in this chapter or section already, then there's no need to link to them again. If it's a work of fiction that would normally be read through in sequence, then multiple linking to works we hold (or may hold one day) is pointless. However, as I said in May 2012 in response to a question on WS:AN:

    There's no right or wrong answer to how much to link. It depends on what the target audience is of both the original work and of our representation. For example, in Tracts for the Times I'm linking the Bible references as I assume that the reader won't have their Bible open beside them while they read. But in Index:A Critical and Exegetical Commentary on Judges.djvu, which is a Bible commentary, I'm not linking the references because the work will be used with an open Bible. In other examples, when I'm working on a Stratemeyer Syndicate book I'll link to Wiktionary for words that are now little-known because the audience will be younger readers, but I don't do the same in Charles Dickens as the target audience is adults. In scholarly or scientific works such as The Mediaeval Mind or Manual of the New Zealand Flora there is more linking happening because that is how academics will use the works. Lastly, in A Dictionary of Music and Musicians there is a lot of linking between entries and to the DNB00, which enhances the usefulness of a Dictionary.

    Beeswaxcandle (talk) 02:08, 7 March 2013 (UTC)[reply]
  • I tick off numbers of the above points, and agree that we do have a difference between fiction and non-fiction works; and do put in the occasional link to wiktionary for truly archaic words. I think that we have to start with BWC's point about expected knowledge level, and the context. Internal links in body (author and book title), in header (portal, related_author, notes). Sister links, predominantly links are in header, but where they significantly add value, then sister links to WP/Wikt, never WQ,WN,WV in body. A big IF … if we are getting significant number of links to a subject matter, then we should consider whether a portal page should be created locally, and linked to it. In main ns, NOTHING should link to WS: or Help: nss., and pretty well the same for completed works, then pretty much the same for Page: and Index nss (source link and marginal page links apart). I see that this is probably going to be where we generate the bulk of our guidance, and it should be guidance based on principles (which is presumably what we are developing). — billinghurst sDrewth 10:33, 7 March 2013 (UTC)[reply]
  • Seems there are a lot of different classes of wiki links, some (author page) has near full support, while others (cross wiki non-identical) are less acceptable. I would suggest either a list of the types, or tabling this particular area for a phase 2 discussion. JeepdaySock (AKA, Jeepday) 17:27, 7 March 2013 (UTC)[reply]
I agree with you, Jeepday. A list of acceptable links should be set up. It will certainly include Wikisource works and author pages; it might also include Wikipedia articles about non-authors, places, and historical events, Wiktionary definitions of uncommon words, and Wikispecies taxonomy pages.--Erasmo Barresi (talk) 20:07, 8 March 2013 (UTC)[reply]
I created a work in progress list at Wikisource_talk:Requests_for_comment/Annotations_and_derivative_works#WikiLinks, it has been quite there for a couple days. Unless there is an overwhelming desire to address it now, I suggest we wait until farther into the process, and address as a separate discussions. Feel free to add to the list if I have missed anything. JeepdaySock (AKA, Jeepday) 10:45, 11 March 2013 (UTC)[reply]
  • I have a story about how wikilinks got to be included on the pages of original works (or at least mine). In June 2005 I started a wikilinked version of A Portrait and called it "Portrait, A (linked)". A little later I described it and put a link of it in the notes of the non-linked "A Portrait", wanting to do everything right. Then, in January 2006, Zhaladshar deleted the original "A Portrait" and took "Portrait, A (linked)" and renamed it, putting it in the old "A Portrait" location!
Ever since I would put wikilinks on the original works page. Maybe I was right in the first place, or Wikisource has finally grown large enough for my original way of doing things to be appropriate (through a Derivitive namespace). ResScholar (talk) 01:00, 13 March 2013 (UTC)[reply]

Non-wikilink annotation types[edit]

The following discussion is closed and will soon be archived:

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)[reply]

Different types on annotation, other than wikilinks, include: Adding footnotes with <ref> and {{user annotation}}; pop-up notes with {{tooltip}}; floating boxes such as {{taxon}}, {{place}} and {{dated}}; adding maps; adding diagrams; etc.

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)[reply]
    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)[reply]
    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.
Not listed on the contents page: PAGE
James Thomson by Bertram Dobell
 vii
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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 class="headertemplate" 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)[reply]

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • "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)[reply]
  • 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)[reply]
    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 <includeonly> where I wanted them, and <noinclude> for the Page ns: display. In cases like these, I put an <!-- 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)[reply]

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 mw:MobileFrontend, mw:Mobile default for sister projects and mw: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)[reply]

  • 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) (hope that means something to someone). — billinghurst sDrewth 12:31, 7 March 2013 (UTC)[reply]
How would "Annotation:" namespace be different from Wikibooks? JeepdaySock (AKA, Jeepday) 11:30, 8 March 2013 (UTC)[reply]
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)[reply]
  • Does Field Notes of Junius Henderson/Notebook 1 count as crystal clear? That uses {{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)[reply]
    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)[reply]
    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)[reply]

    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)[reply]
    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)[reply]

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)[reply]

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:
  1. The Header or Footer
  2. The notes section of the page. [1]
  3. Excepting wikilinks which may be in the body, or anyplace on the page.

Annotations:

  1. ↑ Like a reference only different
JeepdaySock (AKA, Jeepday) 14:52, 12 March 2013 (UTC)[reply]
I don't think anything in the header has ever been contentious, so I support making that explicit in whatever policy text results from this RfC. Anything obviously connected to the header by proximity (which includes templates like {{similar}}) is probably OK too as long as no one mistakes it for part of the body of the work. I wouldn't add <references/> to the header but it is a possibility if others are OK with it. - AdamBMorgan (talk) 18:51, 12 March 2013 (UTC)[reply]
I was thinking the <references/> would go at the bottom of the page with any published references. Probably as <annotations/> and using <ann></ann> instead of <ref></ref>. Jeepday (talk) 23:36, 12 March 2013 (UTC)[reply]

Button to show annotations

What about marking all annotations—except links and the {{header}} template—with id="annotation"? 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)[reply]

Is it technically possible? JeepdaySock (AKA, Jeepday) 14:53, 12 March 2013 (UTC)[reply]
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 class="headertemplate" for boxes is better. But I threw in an idea...--Erasmo Barresi (talk) 18:27, 12 March 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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 class="headertemplate" in the main namespace and class="TO_BE_DEFINED" in the Translation: namespace 

{| class="<NAMESPACE-SPECIFIC CLASS> collapsible collapsed" {{ts|<CSS ATTRIBUTES>}}
! <TITLE>
|-
| <CONTENT>
|}

3. references with {{user annotation}}

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

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 <div> 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)[reply]
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)[reply]
Jeepday, this is only for closing the #Non-wikilink annotation types 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)[reply]

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: Rattus rattus Rattus rattus; Ashburn, Virginia Ashburn, Virginia; and 2013-03-20 March 20, 2013. These were created by Gaurav. When he suggested them on Wikisource talk:Annotations#A new annotation project (followed up at User talk:Gaurav#From Wikisource talk:Annotations), he said "We've started playing around with annotating our content - if we can index which species Henderson observed, and when and where he observed them, it would let biologists today use historical data to look for patterns of species movement in the last century. So far, I've created three very rough, very experimental templates to play around with: {{Taxon}}, {{Place}} and {{Dated}}. All three create a box outside the flow of the document, with links to relevant resources (all three link to the Commons; Place additionally links to OpenStreetMap and Taxon additionally links to WikiSpecies)." 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)[reply]

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)[reply]
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)[reply]

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:

  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.)

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)[reply]

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)[reply]
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)[reply]
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)[reply]
  • Instead of permitting any way of marking works as annotated, we could set the standard on adding /Annotated 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 {{tooltip}}s.--Erasmo Barresi (talk) 15:39, 29 April 2013 (UTC)[reply]

Annotation content[edit]

The following discussion is closed and will soon be archived:

Annotations where allowed, must meet the expectations of neutrality and verifiability. Interpretive annotations are never allowed. Jeepday (talk) 11:20, 10 April 2013 (UTC)[reply]

What information can an annotation provide? Should it be literal fact or is some element of interpretation or analysis allowed?

Some common forms of annotation include: wikilinks to wiktionary (for unusual words) or wikipedia (to explain the concept via an article or biography), full names of people where only a short version (eg. just surname) is used, maps of locations, explanations of terminology, and identifying literary or historical references made in the text.

As an example of a non-literal annotation currently on Wikisource, The Annotated "Privateersman" includes the annotations: "This may be a nationalistic gibe at the French, or just an observation about sailors in general." and "Why? He said previously he was so disgusted with privateering he would have stopped if he could. Possibly he was unsure of the planters sincerity or ability to provide protection." Both move further than simple information.

Comments
  • At the end of the day, this is why some of us oppose annotations at all: because it is so hard to draw a line between acceptable and unacceptable. If a line must be drawn, I think that we should do so by adopting Wikipedia's pillars of neutrality and verifiability. Hesperian 00:45, 7 March 2013 (UTC)[reply]
  • Ditto Commentary and analysis don't belong here unless they have been published in accordance with our core policy. Adaption of WP's pillars of neutrality and verifiability comes with the responsibility to present multiple views, assessments, positions & the like in order to reach that desired neutrality plus there is no guarantee of actual truthiness via the path(s) to verifiability as well. Accomplishing this is well beyond Wikisource's mission and scope. Expansion to include these type of annotations in my view is just not possible forget about plain old desirable or useful. -- George Orwell III (talk) 04:04, 7 March 2013 (UTC)[reply]
  • As I mentioned above, anything that relates to interpretative is on the outside. If someone really want to add comment, they can be directed to utilise the edition parameter, and add a note on the talk page. — billinghurst sDrewth 12:34, 7 March 2013 (UTC)[reply]


Question 1
Would the addition of supporting illustrations (with or without captions) count as "annotations"? If so, then we have a fourth class of annotations to consider. --EncycloPetey (talk) 14:29, 20 March 2013 (UTC)[reply]
If you mean, for example, the Hogarth image in The History of Tom Jones, a Foundling/Book I#Chapter xi. (as you mention below under Allowable illustrations), then I would say that was non-interpretive, NPOV and easily verifiable. As such, if illustrations-as-annotations are allowed, it should be OK under the terms of the discussion here. - AdamBMorgan (talk) 22:01, 1 April 2013 (UTC)[reply]

Comparisons[edit]

The following discussion is closed and will soon be archived:

No disagreement to date - AdamBMorgan (talk) 18:17, 20 March 2013 (UTC)[reply]

Comparison pages show different versions of the same text, either in parallel or in series. This can be the whole text or select lines from a text. Comparison pages date back to the early days of Wikisource (and possibly Project Sourceberg) as a means of giving Wikisource a unique selling point among other digital libraries. If these pages are accepted, should they provide analysis or only present information for the reader to interpret (the latter is standard at the moment)? Could this be replaced with a modified version of the DoubleWiki extension?

Should Wikisource host Comparison pages? If so, what policies and guidelines should apply?

Comments
  • The only way I see the comparison of different versions of the same texts being "allowed" to exist is if the comparison(s) being made is user selected and initiated on the fly. Creating a static page containing some kind of comparison between version or versions forces the subjective selection(s) made by the page's creator upon the potential reader without the reader's input and typically without any tangible supporting authority to make that determination on his or her own. For example, maybe the page creator felt the 2 versions he or she statically presented are the most enlightening or intuitive (in their opinion) but that perception may or may not be the most widely accepted view nor the most useful, reader-desired one. The ability of what to compare should be entirely left up to the reader; only the ability to easily do so (i.e. some variant of DoubleWiki) should be Wikisource's responsibility. If we can't do that, we shouldn't make (force) comparisons at all. -- George Orwell III (talk) 00:53, 7 March 2013 (UTC)[reply]
  • Our current comparison pages (e.g. Bible/Psalms/1/1) are ugly and other sites who specialise in such things do it better (e.g. here). Additionally, we don't have that many multiple editions of works (other than the Bibles) that would necessitate the work to adapt DoubleWiki for this purpose. Beeswaxcandle (talk) 02:29, 7 March 2013 (UTC)[reply]
  • There are some of Aesop's tales that have been done by the comparative fashion, and when I split them I was reverted. There are potentially numbers of works that could be falling into this space and they are mostly translated works. My point of view is that "no more comparative" works to be added, and that we look to have comparisons undertaken by a tool, be it through an extension, or through a toolserver tool. This is an enhancement that could come at anytime into the future. — billinghurst sDrewth 12:39, 7 March 2013 (UTC)[reply]
  • I'm not sure if BirgitteSB is around at the moment, so I'm going to add a copy of a comment she made regarding these pages when discussing the Versions guideline - AdamBMorgan (talk) 20:45, 7 March 2013 (UTC)[reply]

They were done as proofs of concepts back when Wikisource was perceived as offering no value or a negative value to the larger realm of free content. That Wikisource could never do anything except duplicate the work being done at PG or other free content projects.

Danny (a former admin) and I, feeling some pressure from those viewpoints, presented at Wikimainia about (among other things) the technical roadblocks Wikisource was facing that prevented us from doing things that seemed of obvious value within a digital format which no one else was doing. Sanbeg, who heard our presentation, spoke to us further and went on to code LST in order to remove these roadblocks. We developed those pages shortly afterward to both test and showcase the robustness of LST. If Proofread Page had been in use then the pages would be transcluded from scanned text in the Page: namespace. A straightforward reading of the proposal would seem to forbid such presentations.--BirgitteSB 21:14, 1 January 2013 (UTC)

 Comment I believe that this approach preceded our use of transclusion from the Page namespace as a tool, which adds elements of complexity. I do not know where it stands beside the development of mw:extension:DoubleWiki. ~~
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)[reply]
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)[reply]

Translations[edit]

The following discussion is closed and will soon be archived:

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)[reply]

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 Wikisource: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)[reply]
    (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))[reply]
    • 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)[reply]
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)[reply]
    • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      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)[reply]

       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)[reply]
      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)[reply]
      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)[reply]
      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)[reply]
      Yes, I've gleamed as much long before any of this started - approx. 27,000 pages still utilize the {{TextQuality}} template; how many of those (if any at all) are somehow still intertwined with the usage of the {{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)[reply]
      • 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 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)[reply]

        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)[reply]
        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)[reply]

        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)[reply]
        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)[reply]
        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)[reply]
        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)[reply]
        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)[reply]
        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)[reply]
        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)[reply]
        There has never been requirements that specific wording be backed up by references on Wikipedia. You're saying that Wikipedia can have w: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)[reply]
        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)[reply]

        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)[reply]
        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)[reply]
        ... 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)[reply]

        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)[reply]
        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)[reply]

        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)[reply]
  • "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)[reply]
  • 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)[reply]
    • 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)[reply]
      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)[reply]
      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)[reply]
      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)[reply]

  • 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)[reply]
    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)[reply]

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)[reply]

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)[reply]
  •  Support 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)[reply]

  • "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)[reply]
  • 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)[reply]
  • "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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

  • 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)[reply]
  • 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)[reply]
  • 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? —unsigned comment by JeepdaySock (talk) 11:06, 22 March 2013.
    "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)[reply]
    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 wmf: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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

Comment on translations[edit]

The following discussion is closed and will soon be archived:

This is a potential problem but one we may have to deal with on a case-by-case basis. - AdamBMorgan (talk) 17:45, 12 July 2013 (UTC)[reply]

Regarding translations by WS users: It's not always possible to have a "scan supported original language work on the appropriate language wiki", because the copyright requirements are different. For instance, PD-1923 here vs. PD-70 on other projects etc. --D.H (talk) 15:40, 10 April 2013 (UTC)[reply]

The requirement for having the original language work freely available was seen as nonnegotiable, there being no other obvious way meet to w:WP:V and w:WP:N. In cases where the original language wiki cannot host the work oldwikisource may be an option. Works outside of these options can be discussed on a case by case bases at Wikisource:Possible copyright violations or Wikisource:Scriptorium. JeepdaySock (AKA, Jeepday) 15:07, 12 April 2013 (UTC)[reply]
  • I agree that texts should generally be transcribed in both languages, which I have actually done several times, for instance: German de:Index:AbrahamMinkowski1.djvu, English translation: Index:AbrahamMinkowski1.djvu.
  • I'm only talking about texts which cannot be hosted on the specific language Wiki due to different copyright requirements. An example: The Theory of the Rigid Electron in the Kinematics of the Principle of Relativity. It's not allowed on de-WS per PD-70, but it is allowed on en-WS per PD-1923. So only for this special cases I would rather suggest that we require scans of the original works here, be we don't require them to be transcribed in the original language, when it's not allowed to put them on the specific language WS. (Oldwikisource as an alternative seems problematic to me, since it could be misused as a competition to the official language WS.) --D.H (talk) 16:09, 12 April 2013 (UTC)[reply]
  • PS, regarding rules in general, see Help:Beginner's guide to reliability: "Texts without scans should still be proofread. This is harder than using Wikisource's proofreading system but still possible." In other words: There is not even a strict requirement to have scans of English language works, so how can there be such a strict requirement for translations? So if we change our rules, we should change them everywhere. --D.H (talk) 16:09, 12 April 2013 (UTC)[reply]
This is a potential problem, which will need to be discussed, but I think it can be resolved. We could do as you suggest, and perhaps include a warning note somewhere. On the the other hand, some may want to just avoid all translations that fall into this category.
If we track all translations on a process or project page (a watered down version of a suggestion above), that might be a useful place to include exceptions and meta information such as this. I'm thinking of something like Wikipedia's assorted suggestion and deletion systems (Did You Know, for example), where each item starts with a template on its own subpage and gets displayed on a main page or an archive page by transclusion. That could both include this information, allow for discussion and provide some oversight on the whole process.
The stricter requirements are partly due to translations being original and comparitively unverifiable works. There is an element of interpretation involved with translation, which was a concern above, which limits the reliability of the project (and the neutral point of view, in Wikipedian terms). There were some additional restrictions suggested, so this is actually less strict than some Wikisorcers would prefer.
(Ironically for your example, I think German Wikisource is the only one to absolutely require scans at the moment. It is possible en.ws will move in that direction too but probably not in the near future.) - AdamBMorgan (talk) 17:38, 12 April 2013 (UTC)[reply]
I posted a question at oldwikisource:Wikisource:Scriptorium#Copyright_Issues_by_Language to see if might "be an appropriate language wiki for works that are PD in the US but not in the country/language of origin". JeepdaySock (AKA, Jeepday) 14:41, 17 April 2013 (UTC)[reply]
In principle it is possible on oldwikisource (see here and older discussion), also Wikilivres would be an option. Even though I initially liked this idea some years ago, it would lead to competition with other WS projects, so I won't put texts on Wikilivres or oldwikisource anymore. Maybe we could include and transcribe them here as the first version, and then replace the text with the translation, and link to the original version? --D.H (talk) 15:01, 17 April 2013 (UTC)[reply]
I've responded on mul.ws. The works should be there if the issue is copyright. They technically cannot be at Wikilivres as that project has a rule against works that can be in the WS domain. However, I'm not sure why a scan based transcription at the original language is non-negotiable - why not simply set up the scans as an index here and note on the index page that they are set up for translation? Yes, it should be transcribed at the original language too but where that's an issue - as it often is with de.ws due to many rules beyond copyright - just set it up here - that would meet the intent if not the wording of the requirement.--Doug.(talk • contribs) 03:53, 27 April 2013 (UTC)[reply]
Trying to squeeze caveats such as the above into the policy's wording weakens & defeats the entire purpose of setting a policy in the first place. That 'ever-floating gray area' is exactly what "we" are trying to address by introducing these proposed changes.

The proposed policy requiring a "scan supported original language work on the appropriate language wiki", is simple and to the point. Contributors who are fluent [enough] in both languages should not have a problem with meeting this new requirement. Any issues preventing a scan-backed transcription at the parent language Wiki -- or any other deviation from the primary policy requirements -- should be introduced, discussed and validated in a timely manner by the community either way. Of course nuances such as D.H's copyright-expiration-to-host-country example would appear to warrant an exception to the requirement without much debate being needed. Low quality scans or poor embedded text layers at the parent Wiki is not an excuse to feign a transcription project there just to enable a translation project here however.

At any rate, whatever the specific issue might be - just bring it up and we will go from there. -- George Orwell III (talk) 09:55, 27 April 2013 (UTC)[reply]

Translated phrases[edit]

The following discussion is closed and will soon be archived:

No disagreement to date - AdamBMorgan (talk) 18:19, 20 March 2013 (UTC)[reply]

An overlap between translation and annotation. Some works include non-english words or sentences (for example, a Latin quotation). If especially common, phrases can be wikilinked to Wikipedia. Otherwise, a translation could be provided by a form of annotation (eg. a footnote or tooltip) or in brackets within the text (1911 Encyclopædia Britannica/Franklin, Benjamin includes such an in-line translation in one of the published footnotes. See also: Category:Texts needing translations.

Should this be allowed? Does this count as an annotation?

Comments
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.

Tracking and identifying derivatives[edit]

The following discussion is closed and will soon be archived:

Pending other decisions - AdamBMorgan (talk) 18:20, 20 March 2013 (UTC)[reply]

Should derivative works have special templates to mark them out or tracking categories to collect them all (adding a new namespace is a separate point as it is more extreme)? Should parameters be added to header templates to support this or should be have new header templates? Should page names refer to the derivation (eg. "Foo (annotated)" or "The Annotated Foo")?

Comments
  • (comment) this is stylistic decision, not whether we should or shouldn't, I think that question is premature — billinghurst sDrewth 12:49, 7 March 2013 (UTC)[reply]
    • This is somewhat connected to the namespace option: marking annotated works as different in some way. These are slightly easier to implement (or lower impact) although I do personally prefer the namespace(s) approach to really make it clear that these works are separate. Even if we don't use the namespace option, I think a special header is out; other comments note that this won't be seen on other platforms like e-readers, so it won't always fulfil its purpose. - AdamBMorgan (talk) 20:36, 7 March 2013 (UTC)[reply]

Special namespace[edit]

The following discussion is closed and will soon be archived:

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 Jeepday (talk) 22:23, 26 March 2013 (UTC)[reply]

See also the newer Derivative and/or Annotation Name Space section below.

Hebrew Wikisource stores their derivative works in a specific namespace, although they are currently the only ones to do so. It has been suggested that this approach may work on English Wikisource. Potentially the new namespace could be called something like "Derivative:". (Technically, multiple namespaces can be created if necessary.) This is not difficult to do but it is more extreme than other options.

Should we do this? If so, what should go into this namespace (ie. should it contain translations as well as annotations etc)?

Comments
  • A clarification of the status in the Hebrew Wikisource: (a) The Hebrew namespace is called "ביאור", which is literally "commentary". (b) Self-made derivative works that are not commentary on existing works are usually hosted in the main space. For example, a user created an index of terms for קדמות היהודים - נגד אפיון (a PD Hebrew translation of Against Apion by Josephus Flavius), and after discussion the index was placed in main-space, at the end of the original work, and not in the "ביאור" namespace. Inkbug (talk) 17:38, 7 March 2013 (UTC)[reply]
  • To further clarify Inkbug's point: The dedicated namespace at Hebrew Wikisource is mainly used for user-generated annotations, which are sometimes very serious commentaries on classical works. But user-generated translations of foreign works into Hebrew are in the main namespace (and we have some very good ones, such as short stories by Chekhov from Russian to Hebrew by User:Amire80, who has also made some very fine contributions here in English). Plus, as Inkbug correctly pointed out, published public-domain works to which user-generated technical apparatus is added (of the sort that any good publisher might add, such as indices or parenthetical source references) are in the main namespace. This is a result of seeing our contribution as re-publishers of public domain works, and as such that we should aim towards the highest possible quality edition that our wiki medium allows for, even if that goes beyond simple transcription. I hope having clarified what we do at he.wikisource will be useful to the discussion here. Overall I think that the namespace idea is an extremely valuable one, but even if it is adopted it obviously doesn't have to be used the same way on every wiki. Perhaps in English, given the huge emphasis here on precise transcription, it would make sense to put all "derivative" works there. Finally, I'll add that I'm very gratified the discussion is taking place here (even though I won't be taking much part in it since I'm no longer active here, unless people have further questions), and I wish the en.wikisource community great success! Dovi (talk) 19:49, 7 March 2013 (UTC)[reply]
Does Hebrew Wikisource have a Wikibooks sister? JeepdaySock (AKA, Jeepday) 15:47, 8 March 2013 (UTC)[reply]
Yes. The front page says it is for making "free textbooks and manuals", and that seems to be what most of the works there are like. Inkbug (talk) 17:57, 9 March 2013 (UTC)[reply]
  • One last point for thought: Why is this option described as "extreme"? It is actually rather simple and easy to implement. Dovi (talk) 20:00, 7 March 2013 (UTC)[reply]
    "More extreme" is a relative term. Compared to just labelling everything, one of the other options, it is extreme. It is something that would require outside work, rather than something any editor could do. I did say it wasn't difficult. - AdamBMorgan (talk) 20:30, 7 March 2013 (UTC)[reply]
  • The use of one or more namespaces is my preferred approach to handling derivative works. It would make clear the distinction between the reliability of pure texts in the mainspace and these other useful, but slightly less reliable, texts. It would also make management easier from a technology point of view. For example, following the Foundations for all points point, we could automatically detect the presence of a page with the same name in a different namespace and categorise accordingly (for annotations, at least; this wouldn't work for translations from other Wikisources). - AdamBMorgan (talk) 21:02, 7 March 2013 (UTC)[reply]
  • If the final consensus is to continue hosting all/some of the various types of derivative works mentioned in this RfC, I guess I'd much rather see them placed into their own namespace or namespaces too than continue to see them co-mingled among the non-derivative works currently hosted in the mainspace. And I'd hope their respective headers would not be one in the same either - a new header background-color for the new namespace(s) would seem to be in order here. -- George Orwell III (talk) 13:42, 8 March 2013 (UTC)[reply]

Wikibooks and scope[edit]

The following discussion is closed and will soon be archived:

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. JeepdaySock (AKA, Jeepday) 10:55, 5 April 2013 (UTC)[reply]

Wikibooks' scope includes annotations as well as, potentially, other derivative versions of works. Should all derivative works be exported to Wikibooks instead? If we do allow certain derivative texts on Wikisource, at what point will they be out of our scope and in Wikibook's bailiwick. What would the tipping point be? One suggestion is denotation versus connotation (literal vs. implied), with the latter being a matter for Wikibooks. Other potential factors that could affect any tipping point are the scale or detail of any derivation and adding additional sections (for example, adding a dramatis personae to a work of fiction). Bear in mind that Wikibooks defines its own scope and, for various resons, may not accept works that Wikisource rejects.

This may require some co-ordination with Wikibooks, depending on how this discussion develops.

Comments
  • The line should be drawn where separation of annotations becomes problematic. Our rule should be, if you need to add a single annotation then do it in the notes section of the header, so that there is no confusion. If you want to add lots of annotations and it isn't practical to put them all in the notes section, but rather you need to intersperse them throughout the text for the benefit of the reader, then at that point you should head on over to Wikibooks. Hesperian 00:55, 7 March 2013 (UTC)[reply]
  • As a note, we should probably try to agree any change(s) with Wikibooks. Otherwise there is a risk that works could fail to met the requirements of either project. I think scale of annotation might be a potential problem. I expect light annotation won't necessarily meet their expectations of an annotated text. - AdamBMorgan (talk) 21:35, 7 March 2013 (UTC)[reply]
    I agree that this is an area where we should engage in a discussion with enWB, and it may require negotiated positions and changes from both parties, so that the scope allows this seemingly desired function to be available. — billinghurst sDrewth 04:48, 8 March 2013 (UTC)[reply]
  • Annotations at English Wikibooks are intended to be interwoven within the primary text as study aids useful in an educational/classroom-like environment. My impression of Wikisource is that the aim of the project is to preserve works for future generations. I suggest to that end, the aim of annotations at English Wiiksource be to aid people in understanding any history and culture that may be of significant influence in the source text. If Wikisource decides to allow interwoven annotations too, I think an untouched copy of the original text should be preserved on Wikisource as well. FWIW I came here in response to Wikisource discussion about annotated texts. --darklama (talk) 14:07, 8 March 2013 (UTC)[reply]
  • As this entire discussion matures, any change from published (including wikilinking) is evolving as the description of an Annotation from the WS perspective. Given that, any annotation not specifically approved, would be inappropriate for WS. Wikibooks allows and encourages annotations to a much broader scope then WS. Neither WB nor WS is under obligation to accept any specific type of annotations. JeepdaySock (AKA, Jeepday) 15:57, 8 March 2013 (UTC)[reply]
    There is no need to worry if there is place for a specific type of annotation, the main question "is it correct for the project?", is all we need to answer. The wikiworld does not have an obligation to provide a space for any annotation someone might want to document. JeepdaySock (AKA, Jeepday) 16:00, 8 March 2013 (UTC)[reply]
    I agree no project is obligated to provide a space for any annotation someone might want to document. Wikibooks and Wikisource may not be the only projects to accept annotations either. For example, I think Wikiversity would consider annotations based on primary/original research done by it's contributors to be appropriate for the project. I think a good way to answer the question, "is it correct for Wikisource", is to consider Wikisource's scope and what does Wikisource intend to achieve with annotations that is appropriate for the project? English Wikibooks already has an answer to what is intended to be achieved with annotations, which considers the scope of Wikibooks. The result is Wikibooks has a general answer to what annotations are appropriate for the project. --darklama (talk) 17:11, 8 March 2013 (UTC)[reply]

Deannotations[edit]

The following discussion is closed and will soon be archived:

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. Jeepday (talk) 11:30, 10 April 2013 (UTC)[reply]

In other words, stripping the annotation out of an published version of a text in order to get a reverse-engineered version of the pure text alone. This is modification of a published text and so it counts as a derivative work even though it is the opposite of annotation. Should Wikisource support this activity and host such texts? If so, should they be identified in some way as a deriviative text (ie. with a template, category and/or namespace) or treated as a pure text?

Comments
  • Not here. Wikibooks can host corrupted works if they wish. Hesperian 00:56, 7 March 2013 (UTC)[reply]
    • If all you've done is remove the annotations from a published work, my feeling is that Wikibooks contributors would still see that result as a source text and push for inclusion at Wikisource. So it'd be preferable to find a solution for hosting such a derivative (corrupted or otherwise) here. Adrignola (talk) 02:17, 7 March 2013 (UTC)[reply]
  • As long as the Foundations Principle of providing the as-published, annotated, faithfully transcribed & proofread work is being hosted in addition to the "stripped down" derivative version, I see no reason why this particular type of reverse-engineered version would be unacceptable for hosting.

    The nuance being the opposite of- or contrary to- the user generated addition of annotations based on some preconceived yet completely subjective idea of being enough of an authority on the subject matter to confidently add material as that 3rd party contributor may see fit, the complete removal of all such 3rd party additions does not require any given contributor to be a so-called expert on the subject matter at all. Even if somebody believes they are to be considered an authority on any given subject matter - enabled only by some construct of self-logic cooked-up in their own little absurd fantasy world & little else - the amount of expertise needed to remove an existing annotation is quite the opposite to the generation of a completely new, never-before-seen annotation based on somehow being convinced one is actually qualified enough to do so.

    The only caveat here being the complete removal of all the annotations and not just selectively some of them. Either all the reference notes go or they all stay; either all the sidenotes go or they all stay and so on etc. -- George Orwell III (talk) 02:00, 7 March 2013 (UTC)[reply]

  • This should only be done if there is no urtext available. And by "available" I mean that it has never been published as the text alone without annotations or other critical apparatus. If the work ever has been published as an urtext then it needs to be found and scanned or we wait for one of the holding libraries to get around to scanning it. Beeswaxcandle (talk) 02:43, 7 March 2013 (UTC)[reply]
    Point taken. I did not think the premise here was anything else but the assumption that no such "de-annotated" version of a particular work was ever formally published at any time prior to the creation of our "stripped-down" derivative. -- George Orwell III (talk) 03:48, 7 March 2013 (UTC)[reply]
  • Wikisource was conceived to hold primary sources. If we look at the commentary on Adam's Venn diagram on the Wikipedia w:Wikisource article, it states: "The requirement for prior publication can also be waived in a small number of cases if the work is a source document of notable historical importance." My deannotation of Aristotle's Organon is not a prior published work, but it is a source document of notable historical importance. Most copies of the Talmud have layers of commentary, up to five or six layers. Are we saying Wikisource can't host a certain translation of the Talmud until we've engineered a way to display all six layers? ResScholar (talk) 06:50, 7 March 2013 (UTC)[reply]
  • Would we classify reproduced poems that are extracted from other works as deannotated? I am presuming not, but again this is where we will need attention to detail in our definitions, or examples. Anyway I remember doing such with some poems that were reproduced in full within the body of a work about Sussex where they were included in the main work. The poems were just #LST transcluded and appear in main ns as the poem by original author, and if required would be disambiguated as versions. — billinghurst sDrewth 14:37, 8 March 2013 (UTC)[reply]
  • We have partially accepted some level of Deannotations, per Wikisource:WWI#Advertising Advertisements that are part of a larger publication are acceptable. But per Help:Beginner's_guide_to_proofreading#Optional such as adverts, do not need to be proofread or included in the main version. Together these make it personal choice to include or not include, part of the published work. JeepdaySock (AKA, Jeepday) 16:09, 8 March 2013 (UTC)[reply]
  • Could it not be possible for an edition of a public domain work to have annotations by a modern editor, which could be removed in order to present the best possible edition while satisfying copyright law? Of course, if other changes were made to the text were made by the editor which made it a copyrightable derivative, we'd have problems, but I do believe there are some cases where the text itself is not copyrightable by the editor. I'm also thinking of editions where a foreword or other apparatus is prepended/appended to a public domain work. I do know of at least one work here where images have been removed for copyright concerns. --Jfhutson (talk) 18:03, 8 March 2013 (UTC)[reply]
    • You'd have to mark out all the editor's notes with a black felt tip pen for the scans. Fortunately we can usually find an earlier fully uncopyrighted public domain scan. ResScholar (talk) 07:55, 10 March 2013 (UTC)[reply]
      • There are many cases of older, popular works where all of the accessible public domain texts are corrupted due to many printings and modernizations, but an edition of an authoritative edition has been reprinted with some kind of apparatus that can be easily blanked. Perhaps in the case of notes within such a text the deannotation would not be worth the effort, but for shorter works perhaps it would. Anyway, such a deannotation does not seem outside the scope and purpose of wikisource. --Jfhutson (talk) 00:45, 13 March 2013 (UTC)[reply]

Grangerisation[edit]

The following discussion is closed and will soon be archived:

Ban on all added illustrations regardless of context, unless a falling into a specific scenario as outlined in the annotation rules (currently none) Jeepday (talk) 22:06, 26 March 2013 (UTC)[reply]

Illustrating texts with images that were not in the original (see grangerise on Wiktionary). This is rare at the moment but it does happen. Wikisource even has a maintenance tag that could be read as supporting it, {{illustrate}}. This mostly covers decorative illustrations, rather than maps or diagrams which would come under annotation. There is a similar practice of using images of book covers, title pages or similar to illustrate some pages; should this be covered as well?

Comments
  • Would this include images of artwork or buildings when a book mentions them? I assume it would be context dependent (for example, yes in a novel, no in an art history book). MarkLSteadman (talk) 23:39, 9 March 2013 (UTC)[reply]
    I think, from consensus so far, this would either be:
    1. A blanket ban on all added illustrations regardless of context.
    2. Counted as an annotation and included or banned under whatever policy we decide for annotations.
    I was going to close this a having reached consensus but I will leave it open for now as this point may need to be addressed. - AdamBMorgan (talk) 18:23, 20 March 2013 (UTC)[reply]

Errata[edit]

The following discussion is closed and will soon be archived:

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)[reply]

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.

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

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)[reply]
    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)[reply]

Agreed. We are on the same page. MODCHK (talk) 00:18, 7 March 2013 (UTC)[reply]

Oops. Rather condescending. I did not by any means intend that. MODCHK (talk) 00:21, 7 March 2013 (UTC)[reply]
  • 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)[reply]
    If the annotations are contextually added inline and using <ref> tags, then they <references> component needs to be AFTER the reference, so putting that into the header is problematic. — billinghurst sDrewth 13:05, 7 March 2013 (UTC)[reply]
    • 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)[reply]

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 {{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. [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)[reply]

  • As mentioned above, errata are important, we shouldn't deny that works have errors, among the types we have are
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)[reply]
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)[reply]

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 Wikisource:WikiProject DNB (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)[reply]

Adding some examples of what has been done onsite.
  • 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 Wikisource: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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. {{SIC}}) the same approach would seem appropriate for other errors as well. JeepdaySock (AKA, Jeepday) 10:39, 11 March 2013 (UTC)[reply]
• 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)[reply]
• 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)[reply]
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)[reply]
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 {{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)[reply]
Rather then changing the text from it’s originally published version, I like the suggestion Wikisource:Requests_for_comment/Annotations_and_derivative_works#Notes_field_and_Navigation_annotations 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)[reply]

A real life error correction example to chew on: "In 1872 No. 7 Savile Row, Burlington Gardens—the house in which Sheridan died in 1816 —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)[reply]

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 Wikisource: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)[reply]

Validation of Annotations[edit]

The following discussion is closed and will soon be archived:

Inconclusive. Further discussion may be necessary at either Wikisource:Annotation or Scriptorium. - AdamBMorgan (talk) 17:45, 12 July 2013 (UTC)[reply]

We are on track to formally approve some types of annotations, but we have not addressed accuracy of them. At Wikipedia the Core Polices cover the standard expectations Verifiability, Neutrality and Originality. Originality is mostly covered by WS:WWI, but as a library we have not had need to addressed Verifiability or Neutrality, these be concerns with Annotations. JeepdaySock (AKA, Jeepday) 11:00, 11 March 2013 (UTC)[reply]

  • The above is my overriding concern for the more complex, user generated types of annotated derivative works in my deciding whether or not to support the inclusion of them. Things like in-line, non-interpretive WikiLinking, dealing with proper Errata, and even as far as De-Annotations go, all seem "right" to me for inclusion under WikiSource's scope as well as it's mission, but ask us to enter the realm of contributor added never-before-seen-or-published annotations and I think we've gone too far.

    Currently, to the best of my knowledge, the amount of viewing traffic that comes through here (never mind the amount that actually contributes) is far too low for approaching and insuring what Wikipedia's success in the areas of Neutrality and Verifiability has always counted on and has abundantly received for some time now --> a consistently large enough cross sample of potential readers who serve the Wikipedia project both as 1.) the scale of balancing that is effortlessly created when a good number of dispersed views and opinions are all participating in tandem that becomes the mechanism used to measure & insure the principles of neutrality are indeed being faithfully followed; as well as 2.) the auxiliary "police force" that patrols their respective beats (or favorites) to a well enough degree and on consistent enough schedule that any "crime" committed deemed contrary to the principles of verifiability has its "suspects" arrested (reverted, locked), prosecuted (talk page discussed, escalated) and either acquitted (consensus to include, page protection) or sentenced (consensus to exclude, user blocked/warned) all in a objective and timely manner by a wide enough swath of participants.

    If my belief on WS traffic is a shared one - we are currently just not visited in the numbers needed to be sufficiently well versed enough across the likely pool of points-of-view, perspectives and similar that typically arise in such cases to objectively and fairly judge a question of neutrality. Nor are we visited in enough numbers to accurately and efficiently weed out every acceptable citation and source given from the inappropriate ones with any due diligence, within in a reasonable amount of time and in a manner where more than just the same handful of regulars are always ultimately making the decisions to keep or delete them. It does WikiSource's reputation no good to host a user generated, annotated derivate for months and months before someone else discovers it, identifies some issue with it and reveals some previously unseen buried bias or proves an existing pattern of citation slight-of-hand for example.

    In conclusion, I'm against hosting user-generated, complex and/or interpretive, annotated derivatives - allegedly supported by external, 3rd party sourcing - primarily for the reasons I've outlined above. There are a few more reasons I feel the way I do, however, which are basically already existing points of contention presented as subsets to the two core WP principles being mentioned here (search for 'truth in verifiability' on WP for example). Any other class-type and certain types of non-WikiLinking that wouldn't typically rely on "principled things", that I feel we would be doing an injustice to if we tried to standardize them here on WS, are also acceptable to host in my book. -- George Orwell III (talk) 02:10, 12 March 2013 (UTC)[reply]

Insofar as I have read, I would have to agree with George Orwell III's position on interpretive user-generated annotations per the points given in his second paragraph. But right now, this is slightly beyond my level of understanding. Thank you. Božidar 15:34, 19 March 2013 (UTC)[reply]
I agree with the points made above as well, but they don't address the original point raised in this thread: What policies do we want to have for annotations? No, we don't want to host highly derivative works at this time (if ever), but now that there is consensus that we are going to have some kinds of annotations, the question remains as to what policies will we apply towards them. --EncycloPetey (talk) 20:54, 1 April 2013 (UTC)[reply]

Derivative and/or Annotation Name Space[edit]

The following discussion is closed and will soon be archived:

No community support for Derivative and/or Annotation Name Space. Translation namespace is discussed elsewhere. Jeepday (talk) 11:38, 10 April 2013 (UTC)[reply]

There have been several discussions here about creating Derivative and/or Annotation name spaces. Those conversations have been somewhat fractured, so here is the formal proposal to create one or both. Should a separate name spaces for Derivative and/or Annotations be created? If Yes, separate rules for those/that name(s) space would be required, and discussed in secondary discussion. In any case, the discussions above would serve to help define the rules.

  • Comment: Just to be clear, per the talk page, this does not include the potential Translation namespace. - AdamBMorgan (talk) 18:43, 20 March 2013 (UTC)[reply]
  • Derivative would be a more open term but that might be a problem in itself. The general flow of this discussion appears to be on limiting derivative works and framing any additions as annotations. As such, one additional namespace called "Annotation" would seem best. The only exception to that is the deannotation concept. That would fit better under "Derivative", and there would probably not be enough of them to justify a namespace of its own, but it could work under the Annotation title with just a little explanation. I don't think we would need both Derivative and Annotation namespaces. I do think there is a case for some annotation and deannotation but that has yet to be decided. - AdamBMorgan (talk) 18:50, 20 March 2013 (UTC)[reply]

Allowable illustrations[edit]

The following discussion is closed and will soon be archived:

Some informative illustrations may be added as long as they follow all the rules that apply to other forms of annotation (eg. must be clearly distinct from the text, etc.) - AdamBMorgan (talk) 19:08, 7 June 2013 (UTC)[reply]

If we're going to "ban" added illustrations (which I feel is a mistake), then we at least need to set a few examples or reasons why we don't allow them, and we also need at least a couple of positive guidelines for instances in which they are allowed.

I propose we make a start with the latter, and can provide specific examples from a work I had been adding. In The History of Tom Jones, a Foundling, the author Henry Fielding frequently make reference to prints by William Hogarth . These prints were in circulation at the time, but are not generally known to modern readers. Their inclusion therefore facilitates the reader's understanding of the text. You may see this in the following locations:

In some of these cases, the print in question is specifically named, portions described, and the reader advised to refer to the print for illustrative purposes. In other cases, the inspiration drawn from Hogarth's prints is more subtle, but the sheer number of times that a Hogarth print exists at all that matches a specific moment in Tom Jones must be more than coincidence.

Additionally, specific works of art are brought to the reader's attention, such as in Book IV, Chapter ii, where the reader is asked, "perhaps thou hast seen the statue of the Venus de Medicis"? This is not the well-known Venus de Milo, but a now lesser-known sculpture.

Finally, a few cultural items relevant to a fuller understanding of the story have been illustrated, although this has only rarely been done, as in:

So, here are three particular sorts of situations in a work of fiction where illustrations might be included. I hope we can all agree that the first of these situations, in which a work of art is specifically referred to by the author with relevance to understanding or illustrating some point, is certainly allowable. The second situation, is which a work of art is specifically mentioned in passing, but which is not generally known to a modern reader, might also be allowable. The only points on which some debate might be had involve the third situation, where items of culturally historic significance are illustrated for further understanding. These issues are (a) are such images allowable, and under what conditions? and (b) what sort of strictures should be placed on captions? The particualr links included above may be instructive in forming or refining opinions. --EncycloPetey (talk) 17:01, 1 April 2013 (UTC)[reply]

I was hoping for some movement on acceptable annotation before commenting here but, lacking that, I will say that this is another form of annotation and will fall under whatever restrictions we apply to such. We appear to have agreed on the general principle of allowing annotations but not on the practical details of what, when or how. This may have to wait until we clarify the annotation policy a it more. - AdamBMorgan (talk) 17:42, 12 April 2013 (UTC)[reply]
But that's exactly what this thread is trying to do. The current summary at the top of this page says "Ban on all added illustrations regardless of context, unless a falling into a specific scenario as outlined in the annotation rules". So, this issue is a specific and separate part of the annotation rules, because (contrary to what you've said) illustrations will not be treated like other annotations. If this is incorrect, then the summary at the top of this page must be corrected. In any event, this set of examples was put forward in the hope of generating some feedback on acceptable annotations with concrete examples. --EncycloPetey (talk) 01:25, 13 April 2013 (UTC)[reply]
Personally, I am OK with all three categories you propose; they meet my personal (but not project-consensus) opinion that annotations be used to aid the reader's comprehension of the text. However, following on from the discussions above, they will probably all need to be explicitly identifiable as annotations (a term I am going to use to cover all small additions for the time being). The work itself will also need to be identified as an annotated work to distinguish it from the real thing. The most likely way to do the former is to use a template with a clear header above the image and probably a coloured background (header-template green, for example) just to clearly separate it from the text. As the annotation namespace does not seem to be supported, having the word "Annotated" somewhere in the header will answer the second condition. I am not sure if both will need to apply, as nothing else has been really agreed on annotation, but I think it is likely. I am sure that this will not be allowed in the "pure" text (so the existing History of Tom Jones will need to be duplicated, with no images in the main version). - AdamBMorgan (talk) 22:38, 14 April 2013 (UTC)[reply]
Oh, I agree about having some sort of basic "unadulterated source version" around. And at some point the issue will arise as to which annotations (links, images, etc.) can be included in that basic version, and which can appear only in an "annotated" version. My only concern with this particular thread is to get people to think about and to discuss concretely the use of illustrations as annotations. FYI: I had some assistance in (finally) tracking down copies of all parts of the original edition of Tom Jones, and hope to spend part of my summer vacation getting that all set up on IA and here. --EncycloPetey (talk) 03:23, 16 April 2013 (UTC)[reply]


A similar situation arises in the opening chapter of Jane Eyre, in which Jane contemplates the illustrations in a copy of Thomas Bewick's A History of British Birds:

"The two ships becalmed on a torpid sea, I believed to be marine phantoms. The fiend pinning down the thief's pack behind him, I passed over quickly: it was an object of terror. So was the black horned thing seated aloof on a rock, surveying a distant crowd surrounding a gallows."

I would be comfortable providing such illustrations for reference, so long as they are clearly indicated as being distinct from the text. The practice I espoused above — of wrapping annotations in boxes with the same background colour as the header and footer, with in addition a textual assertion that these are not part of the text — would suffice for me. The way that Hogarth's illustrations are currently being presented in Tom Jones is not acceptable in my view. Hesperian 10:56, 21 April 2013 (UTC)[reply]

Implementation[edit]

Request was made to Wikisource: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
  • 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)
  • Are we going to use {{header}} or implement a derivative; even consideration of the colour. Clearly translator = Wikisource
    • 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)[reply]
      • 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)[reply]
        • 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)[reply]
        • 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)[reply]
  • 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)[reply]
      • 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)[reply]
  • 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)[reply]
      • 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)[reply]
        • A soft redirect of some kind could work (although the same issues apply as with {{translations}}). 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)[reply]
          • 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...

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)[reply]


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)[reply]

Bugzilla:50007 — billinghurst sDrewth 06:49, 22 June 2013 (UTC)[reply]

Done Namespaces Translation: (ns:114) and Translation_talk: (ns:115) have been created [1] for us with thanks to Odder (talk • contribs). 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 redirect}}s 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)[reply]
Related to this is the on-going discussion to have Wikisource: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)[reply]
Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Requests_for_comment/Annotations_and_derivative_works&oldid=13656369"