Wikidata talk:Wikisource

Proposal[edit]

Discussions about points of the proposal

Main[edit]

There are three (and sometimes four with author pages) kind of pages in the main namespace:

text pages that contains a book chapter, a poem... Should them be linked to Wikidata items???

Only if they are considered stand-alone works or the whole book is missing. --Micru (talk) 18:48, 21 June 2013 (UTC)[reply]

Single poems should always be considered works, I think. About chapters, and parts of a poem, it would be useful to have them on Wikidata so that we can also have interlanguage links for them. Candalua (talk) 09:14, 12 July 2013 (UTC)[reply]

Yes, sometimes chapters do have interwiki links, for ex.: fr:ws:Le_Tour_du_monde_en_quatre-vingts_jours/Chapitre_1. So they could be relevant to include.

But the question it raises is really, how to make the difference between relevant and irrelevant pages, for automated creation? On fr.ws, in most cases page vs. sub-page should do the job, but it's not completely reliable. --LBE (talk) 07:34, 3 November 2013 (UTC)[reply]

table of content pages that are the entry points for texts. Should be linked with the edition items in Wikidata that has all the metadata about this edition of the text.

I agree. That is easy to do.--Micru (talk) 18:48, 21 June 2013 (UTC)[reply]

disambiguation pages that lists the different versions of the same work in Wikisource. Should be linked to the work items in Wikidata as there are a list of some/all edition of the given work.

It seems reasonable--Micru (talk) 18:48, 21 June 2013 (UTC).[reply]

Using disambiguation pages as interwiki for text pages breaks DoubleWiki extension or at least makes it useless. Ankry (talk) 23:59, 24 July 2013 (UTC)[reply]

AFAIK, disambiguation pages are not only for multiple editions of the same work, but sometimes also for works with identical titles (poems esp.). I can't get my hand on an example though. --LBE (talk) 07:34, 3 November 2013 (UTC)[reply]

At English WS there are three types of disambiguation in main namespace.

{{disambiguation}} template marks different works of the same name
{{versions}} template marks different versions/editions of the same work
{{translations}} marks the same source in another language with different translations

Also to note that enWS uses subpages, and these can be chapters of a work, or can be individual works that have been contained in another work. Examples of the latter can be biographical text about a person in a work, or say a Christmas Carol. Being subpages just indicates that there is an association with a work. — billinghurst sDrewth 12:59, 3 November 2013 (UTC)[reply]

Index[edit]

Metadata about a scan file and its proofreading. Should them be linked to Wikidata items???

Wait Denny said that a proposal for Commons is due in the next week(s). Let's wait and see how scan metadata fits into his proposal. If each file is going to have an "F" item, then at least a property "exportable as" (djvu, epub, html) could be considered.--Micru (talk) 18:48, 21 June 2013 (UTC)[reply]

Info As explained below, WS specfic metadata (correction state, epub, etc.) have nothing to do on Wikidata. Long term, there could be a wikibase instance driving each WS. So Index items should just be used as source for metadata on their "work" item, and not used as targer for links. --LBE (talk) 07:34, 3 November 2013 (UTC)[reply]

Anyway, an Index usually corresponds to an edition item, so it should be linked with that, at least. Candalua (talk) 09:08, 12 July 2013 (UTC)[reply]

Index pages will contain a specific work, as noted above, but there will usually be an associated Commons Category as well, since the source files and accompanying illustrations are preferentially housed at Commons. This point should be kept in mind in any decision about organizing data for Index pages. --EncycloPetey (talk) 02:14, 6 November 2013 (UTC)[reply]

We already have document file on Wikimedia Commons (P996) for linking to the file an edition is using as source, but how this file is classified that will depend on Commons once it can store structured data (next year).--Micru (talk) 12:48, 6 November 2013 (UTC)[reply]

You've misunderstood. I'm not talking about the source file; I'm talking about the Category where the source file and associated images from that edition are housed on Commons. A data type for the source file is irrelevant for associating a Commons Category with an Index page. --EncycloPetey (talk) 02:21, 8 November 2013 (UTC)[reply]

No, not needed, they are simply workspace for transcribers. — billinghurst sDrewth 11:15, 8 January 2014 (UTC)[reply]

Page[edit]

This namespace contains the proofreaded text of one scan page. Nearly no one of this pages use interlanguage links and contains metadata that would be relevant to be used on Wikidata. So, no need for Wikidata support.

I agree.--Micru (talk) 18:48, 21 June 2013 (UTC)[reply]

Sounds good. They aren't interwiki'd currently and I see no reason to change the status quo, unless it can be proven that similar pages exist on all projects. Ajraddatz (Talk) 05:25, 21 November 2013 (UTC)[reply]

There is a issue for Chinese Wikisource. For example, s:zh:世界人权宣言 have a interwiki link as "中文（台灣）‎", which is link to s:zh:世界人權宣言(Traditional Chinese translation for Universal Declaration of Human Rights), the source is [[zh-tw:世界人權宣言]], then s:zh:世界人權宣言 slso have a Simplified Chinese link [[zh-cn:世界人权宣言]] in the interwiki references. How to deal with these links when Wikidata support Chinese Wikisource? --Great Brightstar (talk) 13:07, 6 December 2013 (UTC)[reply]

Both docs are in the Main namespace, AFAICS, so this question does not belong to the Page space section. I'll move it to a dedicated topic below. --LBE (talk) 13:18, 6 December 2013 (UTC)[reply]

No, not needed, work space only. — billinghurst sDrewth 11:16, 8 January 2014 (UTC)[reply]

Author[edit]

To note that Author namespace can include {{disambiguation}} template. To also note that there can be subpages though this would be to allow breaking out of a large sub-collection of work(s).

Category[edit]

Same namespace and constraints as Wikipedia. Items, shared with Wikipedia, that store interlanguage links.

Categories like "Category:Authors-G" don't exist in WP. I would leave that for now and do a request for comments later on when the future about categories is cleared.--Micru (talk) 18:48, 21 June 2013 (UTC)[reply]

The category structure of the English Wikisource is deliberately set up to parallel the LoC system. It is frequently similar or identical in structure to the Wikipedia category structure, so that bit shouldn't be too difficult to manage. However, another point that should be kept in mind is that there will often be a closer category structure on Commons, because the source files for most works and their illustrations are stored on Commons. So, any category data should consider this point prior to implementation. --EncycloPetey (talk) 02:12, 6 November 2013 (UTC)[reply]

Specific points[edit]

OldWikisource[edit]

OldWikisource is a multilingual wiki that is used as incubator of new Wikisource projects. It should be handle by Wikidata. But, as the current linking interface rely on languages code, some change in the current Wikibase code will be needed to be able to add it in the "Wikisource" links section.

Maybe we should consider another name. The tag "oldwikisource" doesn't seem representative of the project.--Micru (talk) 18:48, 21 June 2013 (UTC)[reply]

The tag "oldwikisource" is used for interwiki links so I think this tag should be use in order to don't break habit of users. But we can also imagine some aliases. Tpt (talk) 18:55, 21 June 2013 (UTC)[reply]

The language code "mul" is appropriate here. It's the ISO 639-3 code for multiple languages and hence multilingual works. Some people already abbreviate oldwikisource to "mul.ws". I've thought that moving oldwikisource to mul makes sense (it would help with interwiki links if nothing else) but that seems like a lot of work for a small gain. More easily, mul could be created as an alias for oldwikisource, and used within wikidata to reference oldwikisource. - AdamBMorgan (talk) 18:19, 10 July 2013 (UTC)[reply]

I agree with Adam. Two years back I opened bug32189 in which, after some discussion, the idea of the alias "mul" came out and was regarded favourably by many, but still not implemented. Maybe we can try to revive the idea? Candalua (talk) 09:24, 11 July 2013 (UTC)[reply]

Mul it's OK (but not very evident for non-native speakers). But it's short enough, "oldwikisource" as tag it's too long. --Aubrey (talk) 06:48, 15 July 2013 (UTC)[reply]

I've updated the proposal to express that "mul" should be used as language code for oldwikisource. Tpt (talk) 13:59, 25 September 2013 (UTC)[reply]

That will cause problems on the English Wiktionary, where mul is used for terms that transcend language (what is locally termed "Translingual"). --EncycloPetey (talk) 02:23, 8 November 2013 (UTC)[reply]

What does this have to do with Wiktionary? This is about interlanguage links between Wikisource editions, which will have zero effect on Wiktionary... This, that and the other (talk) 07:01, 8 November 2013 (UTC)[reply]

So I infer that in a couple of weeks we'll have sitelinks to language-specific versions of Wikisource, but not to the multilingual Wikisource itself. What a pity! --Ricordi samoa 19:02, 1 January 2014 (UTC)[reply]

For Oldwikisource bug60069 has been opened by Tpt. Candalua (talk) 09:13, 15 January 2014 (UTC)[reply]

Interwiki[edit]

How will the current system of interlanguage links, aka interwiki, become? I think texts, in the various subdomains, should be linked together if they link to the same work item. So on each text we should have links to all other editions of that text, both in the same language and in other languages, providing also some additional info for distinguishing them, like the year of publication and the name of the translator. Is this feasible? Candalua (talk) 09:16, 11 July 2013 (UTC)[reply]

Yes it's feasible. The idea is that we will have in Wikidata an item for the work in itself and a specific items for every edition. We will add as "sitelink" the main page of the text to the related edition item. With a JavaScript code (or maybe with a specific extension) we will be able to get all editions of an item, and so, build from them a list in the sidebar (containing, of course, extra informations when needed). Tpt (talk) 14:03, 17 November 2013 (UTC)[reply]

Wikisource-specific data[edit]

Is it possible to use Wikidata to store some data which are specific to a Wikisource? Since years, on it.source we use LST in order to store data directly on the pages and then retrieve them from other pages, in a sort of "ante-litteram Wikidata" :D Most of this data will obviously end up in Wikidata, either in work items, edition items or author items. But some don't have any sense outside it.source, the most important being the quality level reached by a text (25%, 50%, 75%, 100%, that for us means respectively incomplete, complete but to be formatted, complete, validated). Can we use Wikidata to store this values? Candalua (talk) 09:37, 11 July 2013 (UTC)[reply]

I would say that we could have these data on a Wikibase installed in Wikisource, but not in Wikidata.

I'm not sure how we will handle the Wikisource interaction with Wikidata: I'm a bit puzzled by this new notion of creating wikibases for other projects (it's not a bad idea per se, I'm not sure what i think of it). But if we had a Wikibase for WS we could put the SAL there.

If we had a single Wikidata, though, I would not put these Wikisource specific data on that, because they are not really useful for others (and they always change). The only thing I can imagine as useful (for other project) is to know that a book has been validated by the community. --Aubrey (talk) 07:06, 15 July 2013 (UTC)[reply]

For quality levels metadata, I think they can be supported with badges as it'll be probably done for Wikipedia good and featured articles. Tpt (talk) 09:57, 29 July 2013 (UTC)[reply]

Don't forget that quality is language-dependent data. Infovarius (talk) 07:11, 9 January 2014 (UTC)[reply]

From what I understand, badges can be attached to a sitelink. So I guess every relevant page on every Wikisource will have its own quality badge. Candalua (talk) 09:29, 9 January 2014 (UTC)[reply]

Yes that is how it is going to work once badges are live. --Lydia Pintscher (WMDE) (talk) 10:53, 9 January 2014 (UTC)[reply]

Portals[edit]

What about portals? Should they be matched to Wikipedia articles, Wikipedia portals, or both? Regarding the latter, technical possibility must be taken into account.--Erasmo Barresi (talk) 19:24, 11 July 2013 (UTC)[reply]

What is the purpose of these pages? -- Lavallen (block) 14:48, 24 July 2013 (UTC)[reply]

On English Wikisource and a few others: mostly as a subject index, although some are smaller collections within a larger subject area. The English portals are classified by a loose implementation of the Library of Congress Classification System (which is in the public domain; Dewey is still under copyright). - AdamBMorgan (talk) 09:23, 25 July 2013 (UTC)[reply]

Some examples may help. Broad subject areas include such portals as wikisource:en:Portal:Acts of the Apostles, wikisource:en:Portal:Mammals and wikisource:en:Portal:Science fiction. Slightly narrower are portls like wikisource:en:Portal:Popular Science Monthly (for facsimiles of the periodical of the same name) and wikisource:en:Portal:Gerald R. Ford Presidential Library and Museum (for facsimiles of material from the museum of the same name). In other language subdomains, examples include wikisource:fr:Portail:Science-fiction and wikisource:it:Portale:Economia. German doesn't use a namespace but has similar pages in ns:0, indexed at wikisource:de:Thema. - AdamBMorgan (talk) 09:57, 25 July 2013 (UTC)[reply]

I think that Wikisource portals should be linked to Wikipedia portals because they are, as Wikipedia portals, entry point pages to the site content and not pages that store the site content (what the Wikipedia articles does). Tpt (talk) 10:04, 29 July 2013 (UTC)[reply]

Looks like we have similair pages on svws in ns-Project. -- Lavallen (block) 05:21, 30 July 2013 (UTC)[reply]

The best option (from the Wikisourcer's point of view) would be linking a WS portal to both a WP article and a WP portal, so that the WS portals is linked from both. However, I do not think that the Wikidata team would be willing to make an exception to the rule. Without this option, there are only two possible situations.

Situation 1: Wikisource portal linked to Wikipedia portal		Situation 2: Wikisource portal linked to Wikipedia article
"chemistry" item	"Portal:Chemistry" item	"chemistry" item	"Portal:Chemistry" item
Wikipedia: "Chemistry" Wikiquote: "Chemistry" Wikibooks: "Subject:Chemistry" Wiktionary: "chemistry" Wikiversity: "School:Chemistry"	Wikipedia: "Portal:Chemistry" Wikisource: "Portal:Chemistry"	Wikipedia: "Chemistry" Wikisource: "Portal:Chemistry" Wikiquote: "Chemistry" Wikibooks: "Subject:Chemistry" Wiktionary: "chemistry" Wikiversity: "School:Chemistry"	Wikipedia: "Portal:Chemistry"

Situation 1 is strange. Most projects link between each other, but Wikisource is left out. In addition, the WS portal is only linked to Wikipedia. Apparently, the WP portal is advantaged because it has automatic linking to Wikisource; the other projects, however, still need to be linked from the WP portal manually.

In situation 2, Wikisource is linked to sister projects—not just Wikipedia. Apparently, the WP portal is disadvantaged because it does not have... (see comment to situation 1). The Wikidata item about the WP portal still has a function (interlanguage linking).

One might argue a WP article should not be linked to a WS portal because the two are different in nature—the former stores the site content itself, while the latter is a mere entry point to the content. However, that's just like what we are going to do by linking WS author pages to WP articles.

Also take into account that a lot of WS portals can be linked to a WP article but no WP portal. For example, see s:Portal:Gothic fiction.

My opinion is pretty obvious now—link Wikisource portals to Wikipedia articles. But I can change my mind if you show me an argument that has not come to my mind yet. If this thread fails to establish a clear consensus, then a Request for Comment can be opened.--Erasmo Barresi (talk) 10:18, 12 September 2013 (UTC)[reply]

However, that's just like what we are going to do by linking WS author pages to WP articles.: I don't agree with you. Author: pages are really about the author because they gives informations about it: he is birth in XXX, he has written xxxxx... and Portal: pages, that are list of works about the subject, aren't directly about the subject. I think also we should respect the "closest item rule": link pages, if it's possible, to the item with the closest subject: WS portal pages are closer to WP portals that are also list of links about a subject than to WP articles that are content about the subject. So, I really support that WP article should be linked to WS portal. Tpt (talk) 14:10, 25 September 2013 (UTC)[reply]

We have Portals in svws even if we do not have any Portal-namespace. They (and they are only a few) can be found in Project namespace. -- Lavallen (talk) 11:29, 8 January 2014 (UTC)[reply]

@Erasmo Barresi, Tpt: If I may revive this months-old discussion, I think I agree with Tpt; because s:en:Portal:Chemistry is organized as an entry point to the topic, it's more similar to w:en:Portal:Chemistry than it is to w:en:Chemistry. That said, the portal pages and regular pages should still be linked somehow. I think we need to create properties called "topic's main portal" and "portal's main topic" like we have for category pages. --Arctic.gnome (talk) 09:57, 15 January 2014 (UTC)[reply]

I didn't know of the "closest item rule" and I don't mind the suggested approach. A similar property proposal has already been formalized. I commented there.--Erasmo Barresi (talk) 13:32, 15 January 2014 (UTC)[reply]

I didn't notice this has been revived but I have a related question: Should we create new data items for Wikisource portals if Wikipedia has only an article and no portal (ie. if there is only one corresponding data item already)? For example, Portal:United States (en.ws), USA (de.ws), Estados Unidos de América (es.ws) and Portail:États-Unis (fr.ws) are all linked to Portal:United States (Q5365167), along with the Wikipedia portals. On the other hand, I created Portal:Albania (Q10815254) for Portal:Albania (en.ws) because Wikipedia has no equivalent yet. However, its German equivalent Albanien (de.ws) was already linked to Albania (Q222). I'm not sure when Wikinews will be integrated but they do have a Portal:Albania (en.wn), which will become part of this mess at that point. There is always a chance that one of the Wikipedias will create a matching portal in the future, in addition to their article. This comes up for several portals and I think working out some plan now will minimise problems in the future. The discussion here seems to tend towards linking to portals but the subject of creating items doesn't seem to be addressed yet. - AdamBMorgan (talk) 16:49, 29 January 2014 (UTC)[reply]

Sorry, it wasn't Albania but it did come up with one of the A— countries. The point stands, however. - AdamBMorgan (talk) 16:53, 29 January 2014 (UTC)[reply]

We can either create a new item or do nothing at all, but we cannot link the WS portal to the WP article. Otherwise, if we link some WS portals to WP portals and others to WP articles, this would really become a mess.--Erasmo Barresi (talk) 19:03, 18 February 2014 (UTC)[reply]

Agree, we are not supposed mix Potal-ns with main ns. It's possible that some projects like Wikinews and Wikiversity have material in their main namespace that fit WP- and WS-portals, but it does not look that way in WS. I guess it's also possible to mix Project-ns and Portal-ns. This since, projects who does not have any Portal-ns still may have portals in their Project-ns. -- Lavallen (talk) 19:41, 18 February 2014 (UTC)[reply]

Work, translations and interwikis[edit]

I think will be good idea to keep work and its translations as separate items. Of course, there should be properties like translations and translation of to link them. Both work and translations have shared metadata like source, creation date, publication date. Work has author property, translations - translator(s).

Each item will contain only one interwiki link. It’ll complicate interwikis fetching in clients, but will resolve problem with multiple interwikis on server side.

Problem with different translations of same title will be also solved with such data scheme.

Other benefit for poetry is possibility to keep first line of verse in each work and translation what is useful for disambiguation purposes.

EugeneZelenko (talk) 14:14, 24 July 2013 (UTC)[reply]

For Wikisource we will use edition items and when there are several editions/translations we will use work items to act as a central connecting hub of all translations and editions. The current GsoC projects are already working in that direction: Wikisource across projects.--Micru (talk) 15:36, 24 July 2013 (UTC)[reply]

de:Author[edit]

Is it impossible to convince dewikisource (and maybe some others) to create an Author-namespace? -- Lavallen (block) 14:42, 24 July 2013 (UTC)[reply]

Is it needed that de-ws uses Author:? I don't think it is a requirement, but I might be wrong.--Micru (talk) 15:36, 24 July 2013 (UTC)[reply]

No, but it would definitly make it easier for non-Wikisource-users here on Wikidata to understand the difference of different kinds of pages. It's possible that it would make it easier for the developers to, since ns-Author-pages and ns-0-pages will be treated in different ways. -- Lavallen (block) 18:27, 24 July 2013 (UTC)[reply]

author pages whether they are in a separate namespace or in the main name space, can have sitelinks in the corresponding wikidata page for that author. Having a separate namespace makes little difference. Filceolaire (talk) 20:11, 24 July 2013 (UTC)[reply]

While not necessary, I can see how it would be easier to operate with different classes of page if they were separated and identified by namespace (especially for a computer). Even human non-Wikisourcers are left trying to interpret individual pages, which is going to be awkward when trying to handle bulk jobs. If author pages are going to be catalogued on Wikidata, I would expect those projects with an Author namespace to be the first just because of this simplicity. - AdamBMorgan (talk) 10:25, 25 July 2013 (UTC)[reply]

Author pages of de Wikisource are all in the Autoren category, so, it's as easy to import de Author pages as en or fr author pages (I have already written a script). Tpt (talk) 14:14, 25 September 2013 (UTC)[reply]

Also, having a separate namespace breaks some things. I tried creating a list of all authors in the French and English wikisource with the Catscan tool, but it doesn't work, although it works fine for de.wikisource. --Herason Beattie (talk) 15:59, 23 November 2013 (UTC)[reply]

Herason Beattie, I have informed Magnus about the bug. What other bugs are preventing de-ws from using the Author namespace?--Micru (talk) 16:08, 23 November 2013 (UTC)[reply]

Thank you. If it helps: this is the query i used for de.wikisource which i couldn't find an equivalent for the French or English ws. Regarding your question, I can't speak for de.ws, but personally, I think having a separate namespace is just an unneccary complication. In de.ws every author (or person, if he/she isn't an author) page has the template {{Personendaten}}. This should imo be sufficient for computer-readability. Requiring on top of that the author-prefix is redundant. It just tells the bot/program (whichever) a second time that the page is a person page. Why? And it's a hassle for editors to cope with and accomodate. For example, right now auto-completion for authors doesn't work in en.ws, it works in fr.ws though. So, if i type Volt, "Voltaire" doesn't come up as a suggestion, but some hardly relevant article about a s:en:Voltairine De Cleyre. --Herason Beattie (talk) 16:39, 23 November 2013 (UTC)[reply]

All enWS namespaces work fine for autocompletion. For authors prepend with Author:Volt... or Author:Char.... For searches if you want to find someone you type Author: (add a space) Darwin it returns Darwins. There are pros and cons for separate namespaces be it author or other things, and that discussion does not belong here. — billinghurst sDrewth 14:13, 26 November 2013 (UTC)[reply]

Translation[edit]

I added a brief section to cover English Wikisource's new Translation namespace. This will almost certainly be identical to the Main namespace as far as Wikidata is concerned. I believe Hebrew Wikisource has a similar namespace but I'm not sure if it functions like their Mainspace. (I think other language subdomains may also have local-only namespaces like this.) - AdamBMorgan (talk) 15:41, 31 July 2013 (UTC)[reply]

Alemannisch (als)[edit]

Well, I think Alemannisch Wikisource has also a lot of editors, However it's a part of Alemannisch Wikipedia.
May be we'll ignore it?--Liuxinyu970226 (talk) 09:00, 28 October 2013 (UTC)[reply]

Does this wiki have separate pages for the text of a work and for information about the work? If yes then this could be a problem as only one of these pages can have a sitelink to the wikidata item about the work. Filceolaire (talk) 10:48, 3 November 2013 (UTC)[reply]

I'm not so sure it have to be a problem. The text page should link to the edition item, not to the main item about the work as far as I have understood.

An example: s:sv:Amtmannens döttrar should not link to Q4752339, but to an item about the Swedish edition from 1863. The text-items will therefor almost always have links to only one project ws-project and no wp-project at all. -- Lavallen (talk) 14:10, 4 November 2013 (UTC)[reply]

Bots on sv.wikisource[edit]

sv.wikisource is not within the range of the Global bots, and we normally do not give botflag to interwikibots. I have initiated a local discussion if we should do an exception for the Wikidata-migration. My proposal is that we do as we normally do: Let the bots run without botflag. Interwiki is not a big thing on Wikisource, they are mainly in the author-, category- and project-namespace, a limited number of pages. I will let you know what the conclusion will be. -- Lavallen (talk) 07:46, 3 November 2013 (UTC)[reply]

The conclusion of the short talk looks like any bot who wants to help with Wikidata-migration is free to do so. No botflag is required, as long as there is a userpage with basic information about the bot and it's owner. We do no expect any larger spamming of RC. -- Lavallen (talk) 17:57, 23 November 2013 (UTC)[reply]

Missing cases for main namespace[edit]

I think a couple more specific cases should be considered for the Main namespace

Dictionnary definitions: On fr.ws, we sometimes create one page per definition in a dictionnary (for ex. : fr:s:L’Encyclopédie/1re édition/Volume 1). Some contributors have started making pages linking to all definitions of a given term (again a good job for a WS wikibase backend btw). These pages should be considered specifically, since they should by linked to this term in Wikidata (and later to the Wiktionnaries).
- I think this should wait until the Wiktionary project is tackled.--Micru (talk) 12:51, 6 November 2013 (UTC)[reply]
Legal documents: Some WS (en esp.) have a repository of laws and court decisions. How to index them ? Maybe this should be linked to the creation of legal data repo in Wikidata? This probably falls within the relevancy criterias.

--LBE (talk) 07:52, 3 November 2013 (UTC)[reply]

There is not much of a difference with books, same system can be used with laws.--Micru (talk) 12:51, 6 November 2013 (UTC)[reply]

Translation namespace[edit]

Hi, Portuguese Wikisource is a some defunct subdomain right now but have also a namespace for pages in process of translation: Em Tradução (ns:108). 555 (talk) 04:36, 1 December 2013 (UTC)[reply]

Issues in Chinese wikisource[edit]

(Copied from Page space section above)

There is a issue for Chinese Wikisource. For example, s:zh:世界人权宣言 have a interwiki link as "中文（台灣）‎", which is link to s:zh:世界人權宣言(Traditional Chinese translation for Universal Declaration of Human Rights), the source is [[zh-tw:世界人權宣言]], then s:zh:世界人權宣言 slso have a Simplified Chinese link [[zh-cn:世界人权宣言]] in the interwiki references. How to deal with these links when Wikidata support Chinese Wikisource? --Great Brightstar (talk) 13:07, 6 December 2013 (UTC)[reply]

I don't read Chinese, but I think I understand the issue : the Chinese WS has 2 pages for some docs (here the Declaration of Human rights), one in Simplified (continental) Chinese, the other in traditional Chinese. Is that it?

AFAIK, this does not happen in Wikipedia, where there are actually 2 different instances, simplified & traditional.

I don't think there is a solution to that in Wikidata. One of the pages will have to support the interwiki links, the other will need to be singled out, and marked as derivative of the other. Or you have to create a zh-tw instance of WS, where these pages will be stored.

--LBE (talk) 13:26, 6 December 2013 (UTC)[reply]

Can you implement a disambiguation system that takes the interwiki link? Though I would still think that it would be better for you to choose one, and have a hat note to the other. — billinghurst sDrewth 13:07, 7 January 2014 (UTC)[reply]

Status?[edit]

What issues still need to be resolved, in order to be ready for deployment? --Rs chen 7754 19:57, 1 January 2014 (UTC)[reply]

From the dev-side we are ready to go. Not entirely sure if all bot and policy questions have been settled. --Lydia Pintscher (WMDE) (talk) 20:03, 1 January 2014 (UTC)[reply]

I have two questions: will there be a test.wikidata deployment? Also, say we have an item that links to both Wikisource and other sister projects. On Wikisource, what will display as the interwiki links? --Rs chen 7754 07:48, 2 January 2014 (UTC)[reply]

There will likely be a deployment on test, yes. Katie is looking into it. For the links: initially only the Wikisource links. If there is agreement that more should be shown we can do that but I want agreement on that and it will need some development. --Lydia Pintscher (WMDE) (talk) 11:27, 2 January 2014 (UTC)[reply]

@Lydia Pintscher (WMDE): which bot and which policy questions were you (want|need)ing addressed?

Not having watched closely the rollout processes of the previous w: rollouts, I was wondering how the process evolved to run matches with the s: <-> w: works so they end up on the same Q:.... page, as there is more likely to be more of those than xx:s: links. Looking at what comes out in a test environment would be most informative. Thanks for all of this. — billinghurst sDrewth 16:42, 2 January 2014 (UTC)[reply]

Mostly it'd be good to have figured out what bots do the migration of interwiki links and how they can find the appropriate Wikidata item if it exists (for example through inter-project links that exists in the wikitext). Also what the bot policies on the individual language editions are. Those are the main issues I can think of from previous deployments and it would be good to have this settled before deployment to be ready to go when the time comes. --Lydia Pintscher (WMDE) (talk) 16:46, 2 January 2014 (UTC)[reply]

Beyond what Tpt is doing, I would think that our Author: namespace is ripe and ready to go, so many identifiers in many of the template headers (WP, Commonscat, WD, VIAF). Main ns is actually a bit harder as we will have wp links in the header though they may not be a one to one relationship. I have a gut feel that many many works are not going to interlanguage links, and there are decisions on whether to just link the top of the root, or do we also do subpages (chapters); and my opinion is KISS and just do the top of the work, BUT where we have poetry and other compiled works it isn't so clean. :-/ Progress slowly would be my thoughts, do chunks, and enable output reports for review. The webs we weave! — billinghurst sDrewth 09:24, 3 January 2014 (UTC)[reply]

I know that for Wikivoyage User:Legoktm used the existing links. --Rs chen 7754 17:59, 2 January 2014 (UTC)[reply]

I've nearly finished to write a bot that uses the Author template of various Wikisources (en, fr, de...) to add links to existing items. I've also setup it to import VIAF and GND ids when available in order to help fight against duplication. Tpt (talk) 20:15, 2 January 2014 (UTC)[reply]

@Tpt: I assume this is read-only on Wikisource? --Rs chen 7754 04:55, 3 January 2014 (UTC)[reply]

I guess ns:Author is the simpliest namespace to edit. The local iw can be removed there without to much trouble. -- Lavallen (talk) 06:31, 3 January 2014 (UTC)[reply]

@Rschen7754: Yes. The remove operation is something that should be done with generic interwiki bots per local communities decision. +1 with Levallen. Tpt (talk) 16:37, 3 January 2014 (UTC)[reply]

Well on Wikipedia and Wikivoyage, we've gone ahead and removed the links with global bots, though we got local approval on wikis that required it. Are there currently interwiki bots running that need to be shut down before they start replacing removed links? --Rs chen 7754 17:17, 3 January 2014 (UTC)[reply]

CandalBot (master: Candalua) is the only active iw-bot on Wikisource I am aware of. And it has not edited outside it-source since Dec 3. -- Lavallen (talk) 19:11, 3 January 2014 (UTC)[reply]

According to m:Bot policy/Implementation only ca, el, fa, it, ko, no, pl, vi and zh are within the range of the global bots. That looks like a minority of the WS-projects. -- Lavallen (talk) 19:18, 3 January 2014 (UTC)[reply]

enWS is having the conversation about how to facilitate the bot operations at this time at s:en:WS:S, and we should have that resolved soon. The response is that they would like to see test runs, and that aligns with aspects of the plans above. — billinghurst sDrewth 16:02, 4 January 2014 (UTC)[reply]

Hello guys. CandalBot is currently still working (with very few edits) on interwiki links in Author: and Category: namespaces (not ns0). Please tell me if I should stop it and when. And please tell me what other bot work needs to be done, and how I can contribute (I don't closely follow Wikidata due to lack of time, so please be patient with me :-). Candalua (talk) 13:05, 5 January 2014 (UTC)[reply]

I do not think you have to stop. Au contraire! The better the iw-links are organised, the lesser work will we have with the transfer to Wikidata. Interwiki in ns:0 will stay local, so it's not affected.

I think it would be good if you could give us some of your experience. Are there any projects that are organised in a unexpected way? Are there trouble with running bots because of unusual botpolicys anywhere? It looks like in Wikisource a non-standard-botpolicy is more common than a standard policy. -- Lavallen (talk) 13:44, 5 January 2014 (UTC)[reply]

Ok then for now I continue! :) What do you mean, interwiki in ns0 will stay local? Not forever, I hope... sooner or later they should also go to Wikidata. Candalua (talk) 11:22, 6 January 2014 (UTC)[reply]

The texts in ns:0 will be treated as an edition of the work itself, not as the work itself. And since a English, a Dutch and a Swedish version of the same text are separate editions, they will have separate items. Therefor can we not add interwiki by the help of Phase 1 in ns:0. It's possible it can be solved later, but not in the same way as we solve interwiki in Wikipedia. -- Lavallen (talk) 11:47, 6 January 2014 (UTC)[reply]

Ok, got it! So it will be left for a future phase. Now I remember that previously in this page Tpt had already answered me about that. I hope a definitive solution will be implemented soon, because currently I had to stop my script for ns0 interwiki: it was running from Toolserver using a very old version of pywikipedia, and some work is required to port it to Labs (and I would like to avoid it if possible :-).

I also just discovered the reasons for CandalBot's recently low activity, apparently my script was crashing lot of times due to some of the recent MW software updates. Frankly I'm really getting tired... things are continuously getting broken and I cannot keep up. I will be really happy and thankful to all of you here, when the Wikidata solution will be fully functional and I can send CandalBot on retirement! :)

As per the second part of your question: oddities are indeed many, and surely I don't know all of them. One, as you know, is that only a minority of the subdomains has an Author namespace (and use it properly; for example there are pages like this); some have pages in ns0, others in Wikisource:... Then to me another nuisance was that some Author namespaces are not even recognised by pywikibot as the same namespace: because being custom namespaces, they were created with different numbers. Then I suspect there are also some "fake" namespaces, e.g. a prefix is used but the namespace doesn't exist for real. Then about bots policy, very few subdomains use global policy, so lot of people will probably bug you if you start doing lots of edits without a local flag, as they did to me even despite very few edits... Candalua (talk) 18:40, 6 January 2014 (UTC)[reply]

"<year> works" and "<year>" category types mismatch problem[edit]

On some wikisources, including en-wikisource, there are only categories named "<year> works", on other wikisources such as fr-wikisource they're simply named "<year>", for instance see s:Category:1880 works and s:fr:Catégorie:1880. The problem is they are linked in Wikisource but don't represent the same thing, "<year>" categories also including things like author births and deaths categories. So without modifying Wikisource categories, we can either link "<year> works" and "<year>" category types to their same-named categories on Wikidata (which means they will not be linked together on Wikisource), or link both types to one or the other category type on Wikidata (which means semantics will be wrong for one type). We can also create the "<year>" category types that contain the "<year> works" category types, on wikisources where they don't exist, or create "<year> works" category types and moving all pages there which is more work and introduces more changes to wikisources structure. -- Bjung (talk) 21:53, 2 January 2014 (UTC)[reply]

I think that some WS will need to be updated. I'd definitely advocate creating "<year> works" categories on the French WS. Yann (talk) 11:15, 7 January 2014 (UTC)[reply]

If push comes to shove, I can see that enWS could create an YYYY (plain) category and then link all the YYYY subsidiary categories, and move the required local interwiki there. It has never been discussed or requested, but I don't see it as a big issue. From looking at other interwikis it seems that "YYYY" only = fr/ca/ja/ee/pt/zh "YYYY works" = en/ko/vi/id/uk (note es/ru have both) — billinghurst sDrewth 12:56, 7 January 2014 (UTC)[reply]

I've seen this inconsistency a long ago. So I've created both types of categories in ru-wikisource. See difference in interwikis: s:ru:Категория:1880 год and s:ru:Категория:Литература 1880 года. Infovarius (talk) 08:24, 9 January 2014 (UTC)[reply]

So at deployment time, nothing has been fixed and everything has now been imported based on en-WS so we have the wrong semantics for fr/ca/ja/ee/pt/zh-WS, i.e. a "year" category is linked from a "year works" category. I'll ask to move them to the right entities, that's the right thing to do for now. -- Bjung (talk) 15:41, 15 January 2014 (UTC)[reply]

Great, I can't wait for those to be moved to their correct entities so they would connect to the icelandic year categories I have allready linked to their corresponding wikidata items. It's also worth mentioning that those icelandic year categories where not interwiki linked before.--Snaevar (talk) 23:46, 16 January 2014 (UTC)[reply]

Note that I have not yet asked for the move. I noticed that the century category links have been imported just the opposite (and correct IMO) way it has been done for year categories: it seems better to find Wikisource links --possibly slightly off-matching for some-- on the main period category entities than nothing at all. I also noticed internal confusion on fr-WS concerning category naming and usage, i.e. basically how the differences between "works of xxx", "works about xxx" and "events of xxx" categories are made; mix that with interwikis and it obviously becomes a mess, so changes to category naming and structure on fr-WS are needed anyway... -- Bjung (talk) 03:31, 2 February 2014 (UTC)[reply]

Several texts in one page[edit]

s:sv:Allena Gud i himmelrik has three Swedish version of a text in one page, and it's a frequent problem on svsource. Looks to me like this page needs four items, just like Bonnie and Clyde needs three. -- Lavallen (talk) 18:47, 4 January 2014 (UTC)[reply]

Notability, and other preparations for Wikisource deployment[edit]

I'm trying to resume the discussion started at Wikidata:Project chat#Wikisource WD:N. So far, there has been a proposal to modify our notability policy to allow all pages from Wikisource to have an item on Wikidata; however, concerns have been raised about this including pages in the Page: and Index: namespaces.

Overall, I remain concerned that we are not ready for the deployment of Wikisource on the 14th, and I am hoping to draw the community's attention to the necessary preparations. --Rs chen 7754 08:18, 7 January 2014 (UTC)[reply]

Index and Page-namespace are closly related to the File-namespace in Commons. And the File-namespace is not included yet. Therefor is there no hurry with those namespaces. -- Lavallen (talk) 09:15, 7 January 2014 (UTC)[reply]

Agree with Lavallen. Both those namespaces are working namespaces for transcription efforts, not presentation namespaces to Joe Public, and have no value in being in WD. To me the WD:N needs to more incorporate what the respective wikis express as their presentation namespaces (in the policy as the notability criteria), and that should be presented as a schedule to the policy. It is a lot easier to update a schedule as you add sister wikis, rather than generate a really complex set of notability. (this latter bit I will add to the originating conversation.
At enWS our presentation namespace are Main/Translation/Author/Portal, though I can live with Portal not migrating as it incomplete and can be a little random. — billinghurst sDrewth 09:46, 7 January 2014 (UTC)[reply]

Agree with billinghurst. If we can synchronize Main/Author, that is the core of the work. What we really need, too, is the interproject links, as it is would be fundamental to link a page of a book or a author on Wikipedia and that book or author in Wikisource. I will repeat this in a separate section. --Aubrey (talk) 10:13, 7 January 2014 (UTC)[reply]

As Lavallen said at the other page, the bigger and more complex issue is subpages, which are going to be more problematic …

enWS[edit]

The following is how enWS handles matters, and I do not know what the xxWS languages do …
Main ns

Works generally are only interlinked at the top/root level, and that works for most purposes. However …
A work that has chapters may be interlinked, at the chapter level, though more for side-by-side comparison, which to me is irrelevant to WD. (Skippable, and manageable by old-fashioned i/w, there are not thousands)

A work that is a compendium of work, eg. book of poetry. At enWS we encourage redirects from root to subpage level, so I am happy for us to follow the redirect and interwiki, the naming of the page is a little tricky.

Noting that there can be multiple versions of a work, and there will be a dominating {{versions}} template.

Translation ns

Root level only.

Author ns

Root level only
There are some other quirks in the system, but they are manually repairable IMNSHO. — billinghurst sDrewth 10:37, 7 January 2014 (UTC)

Subthought for subpages. As enWS uses header templates in its presentation namespaces, we could look to utilise these to help guide any bots. This is especially the case for some of the compendium works like Dictionary of National Biography which we probably don't want to do all those biographical components, and just do the works. We can probably also look to have some (standard?) configuration in templates that could be usable by people and bot to identify types of works. — billinghurst sDrewth 10:42, 7 January 2014 (UTC)[reply]

We do not need the subpages (or any page in ns:0) to Wikidata for the Interwiki, since interwiki will not be solved by Wikidata (today). The few pages who have interwiki in Chapter-level can still do that locally.

BUT, the subpages have templates, and as a preparation for Phase 2, it would therefor be nice to have the possibility to add properties for those pages. s:sv:Bibeln (Gustav Vasa)/S. Johannis Euangelium is for example "The Gospel of John", in contrast to the rest of the Gustav Wasa-bible. The page is proceeded by "Luke" and followed by "Acts". It would be nice to be able to add that information in WD.

In some cases the main page is an Anthology, where the subpages have different Authors, and therefor have different metadata. s:sv:Svenska medeltidens bibel-arbeten/Apocalipsis Sancti Iohannis apostoli is an example of that. -- Lavallen (talk) 10:55, 7 January 2014 (UTC)[reply]

We do provide links to Project: namespace on other wikis, so the "presentation" separation is not 100% foolproof. And I think that six days are not enough of a turnaround time to rethink our notability policy, though I agree that it is probably a good idea for the future.

That being said, maybe we should just amend the notability policy to allow Author: and main namespace in Wikisource to have items (in the event that there is no existing item already), ignore the issue of subpages for now, and get that going. What do people think about this? --Rs chen 7754 09:22, 8 January 2014 (UTC)[reply]

Sounds fair. I also think that pages in Translation-namespace can be treated as the Main namespace, since they have the same purpose. And Portal-namespace can be treated as the Project-namespace. This since that a project do not have a Portal-namespace, does not mean that they do not have a Portal. Interwiki between a Portal-ns and a Project-ns it therefor fully possible. -- Lavallen (talk) 09:48, 8 January 2014 (UTC)[reply]

So including Translation and Portal, if those exist. --Rs chen 7754 09:49, 8 January 2014 (UTC)[reply]

It seems that we have a consensus here, although (ashamedly) few people have participated in the discussion... are we good to go? Or do we need to start yet another discussion in a more prominent place? --Rs chen 7754 08:44, 9 January 2014 (UTC)[reply]

Interproject links[edit]

On several Wikipedias and sister projects, there is a Template sister project, like this or this. The linked a Wikipedia article to that authors Wikisource or Wikibook page, etc. Will they be taken into account in phase 1? --Aubrey (talk) 10:20, 7 January 2014 (UTC)[reply]

We have s:en:Template:Plain sister which is transcluded into all our namespace header templates which then points to all sisters. — billinghurst sDrewth 10:48, 7 January 2014 (UTC)[reply]

w:ru:Шаблон:Писатель has Викитека параметер for link to Wikisource author page. Same for w:be-x-old:Шаблён:Пісьменьнік (ВікіКрыніца) and probably for other Wikipedias. --EugeneZelenko (talk) 15:41, 7 January 2014 (UTC)[reply]

s:ru:Шаблон:Обавторе and s:ru:Шаблон:Отексте have ВИКИПЕДИЯ parameter for Wikipedia links. --EugeneZelenko (talk) 15:54, 7 January 2014 (UTC)[reply]

@Aubrey:. Yes, they will be used to import Wikisource links to existing Wikidata items and then will be changed to use Wikidata data. Tpt (talk) 16:09, 8 January 2014 (UTC)[reply]

I've opened my request for bot right. Please comment. Tpt (talk) 10:31, 11 January 2014 (UTC)[reply]

Issues in Russian Wikisource[edit]

1. For some old texts we have 2 variants: in original "before-reform" orthography (for now they are denoted by suffix "/ДО" in title, but the discussion is going) and in modern Russian "transliterated" orthography (without suffix in present).
2. If we have some russian text which has translations in other Wikisources we want to have all of the interwikis. Even if there are several translations into one language. For example, en and es interwikis in s:ru:Война и мир (Толстой) are correct unless they are between the work and its different translations. Also at s:ru:От Матфея святое благовествование there are several interwikis into en-wikisource (since some MediaWiki update only one is displayed), all are correct.
3. There is Template:Interwiki info which contains additives to interwiki-titles. How will it work after change to Wikidata-interwikis? --Infovarius (talk) 09:31, 9 January 2014 (UTC)[reply]

For 1 & 2, the standing decision seems to be to consider each WS document (in each language) as one "Edition" of the work, so each will have its own Wikidata item. So with Phase 1, there will be no direct support of interwiki links for documents through wikidata (AFAICU). There will be dev needed so that each WS document page can use WD to link "up" to the "Work" item, and "back down" to others "Editions" (that is, links to translations on other WS).

Unclear to me when/how this will come.

On the downside, it means WD phase 1 for WS will not replace explicit interwiki links at document level.

On the upside, it gives a direct answer to the issue of documents with multiple versions that many WS have (see above for simplified vs. traditional Chinese) : each can have its own "Edition" item.

Anyone, is this correct ?

Not sure I understand point 3.

--LBE (talk) 11:46, 9 January 2014 (UTC)[reply]

It is not possible to link to two pages on one wiki from a Wikidata item - I believe that there are a few smaller-language Wikipedias with that issue, and different orthography. --Rs chen 7754 12:09, 9 January 2014 (UTC)[reply]

Well, that's the point: there will be only one sitelink on each WD item created for WS documents, since the item represents the "Edition" of the work. But there can be several items created for a given "Work" in a given Wikisource : edition of a different year, language variant, with/without illustrations.

That also means there will be no interproject links either (to Wikipedia). WP usually links to the "Work" item, which fathers the "Edition" item.

That would definitely deserve a dedicated explanation on the main page ...

--LBE (talk) 13:53, 9 January 2014 (UTC)[reply]

About point 3: as explained here by LBE and by Tpt above, on each WS document we will have links to all other editions of it. Currently, Template:Interwiki_info provides some additional informations which help distinguish the editions (e.g. name of the translator, year of edition, publisher etc.); these are displayed next the interwiki links by some javascript. I think we can probably just discard these informations and remove the template; as I understand it, the solution described above which will be developed, will provide also this functionality. Candalua (talk) 14:51, 9 January 2014 (UTC)[reply]

There is additional issue in ru-wikisource, that need to be taken into account for future roadmap. There are several dictionaries in ru-wikisource (ЭСБЕ, РБС, ЕЭБЕ, МЭСБЕ, etc). They have page-per-item content structure (like s:ru:ЕЭБЕ/Москва, s:ru:ЭСБЕ/Москва, s:ru:МЭСБЕ/Москва).They need some kind of innerproject links, as well as links to and from ru-wikipedia (obviously, to w:ru:Москва). As far as I understand, current limitations (one wikisource page per wikidata item and no foreign key search without JavaScript) does not allow to implement such links using wikidata. I believe, the best solution will be to allow some wikisource projects to have several links from single wikidata item. It is okay for such links to have additional qualifiers and limitations (like prefix limitation), or may be to treat as some kind of fake wikimedia (sub)project from the wikidata point of view. I believe it shall not be properties -- because wikisource pages need to access the same item data from mw.wikibase structure, with all internal and external links, from all specified pages. -- Vlsergey (talk) 03:01, 10 January 2014 (UTC)[reply]

That's not necessary. Again, each WS document will have its own WD "Edition" item, even for alphabetical variants (to be marked with dedicated property, probably). There is a custom dev needed in order to use the parent "Work" item to retrieve the interwiki/interproject links. As written by Candalua above, the same system can easily be used to retrieve other "Editions" of the same "Work" on the current WS. They're all in the same Work <-> Edition items tree, t's only a matter of checking where the sitelinks go to. --LBE (talk) 08:36, 10 January 2014 (UTC)[reply]

With phase II (Properties) and some bugfixes, I think this will be solvable. But I think we need somebody who is skilled with programming modules or javascripts. -- Lavallen (talk) 10:05, 10 January 2014 (UTC)[reply]

enabled on test.wikidata.org[edit]

Hey :) Just wanted to let you know that Wikisource is now enabled on test.wikidata.org. Nothing spectacular but some people asked. You can add sitelinks to Wikisource. --Lydia Pintscher (WMDE) (talk) 20:25, 9 January 2014 (UTC)[reply]

Lovely, thx ... works for me — billinghurst sDrewth 23:40, 9 January 2014 (UTC)[reply]

@Lydia Pintscher (WMDE): Please see here. It doesn't work for me. —Justin (koavf)❤T☮C☺M☯ 23:59, 12 July 2016 (UTC)[reply]

THere is no support for mul yet. Only for all the other languages. --Lydia Pintscher (WMDE) (talk) 08:48, 13 July 2016 (UTC)[reply]

Translations[edit]

I would like to know how multiple translations of a work will be managed. Will there be a way to get interwikis on the page of each translation separately? While the idea of "disambig" pages for different versions may be a fair solution for incoming links (you want to see the translation of a work in a given language), it does not work at all for outcoming links (you want to compare the work with the original). Other issues of this idea are that:

It is especially bad given that Wikisource has gadgets for comparing translations with originals (like here), but this gadget does not work if it is linked to a disambig (like in this case). If links will now only lead to disambigs, matching works in different languages will be impossible
There will be problems with series (e.g. Shakespeare's Sonets): we will have a mess if some works were translated by only one author, and others have two or more translations into a given language (compare Sonnet 1 and Sonnet 2). If we create disambigs everywhere, we will have several "empty" ones with only one link. If we do not create disambigs everywhere, we will have a mixture of works with interwikis and of works where links were moved to disambigs, which will be far from obvious for readers

The only solution to it may be support of multiple interwikis per language (with probably one "main" — a disambig — and several secondary for individual translations). Will anything like that be implemented on Wikidata? Thanks — NickK (talk) 22:44, 14 January 2014 (UTC)[reply]

This issue has already been debated, read here and here. Candalua (talk) 22:51, 14 January 2014 (UTC)[reply]

All this was before Wikidata was implemented. Now Wikidata is live, and unfortunately I do not see any way to do it. This definitely needs some specific configuration, as a mission "retrieve all editions from work pages in all languages and link them to all edition pages" is impossible in the current implementation. More simply, I cannot see how the current implementation distinguishes works and editions — NickK (talk) 23:21, 14 January 2014 (UTC)[reply]

As I understand, this will not be done with regular interwikis: a custom solution will be developed once Phase 2 is live. I guess Tpt is the person who can better explain how this will work. Candalua (talk) 08:59, 15 January 2014 (UTC)[reply]

Poems[edit]

It says: "text pages that contains a book chapter, a poem... They should be linked to the related Wikidata items if, and only if, they are considered stand-alone works. So, a normal book chapter won't have its Wikidata item. "

So, where should separate poems (as stand-alone works) be linked to? To work items or edition items? --DixonD (talk) 23:03, 14 January 2014 (UTC)[reply]

They should be linked to edition items, like all other kinds of Wikisource texts. Only disambiguation pages should be linked to work items Candalua (talk) 23:12, 14 January 2014 (UTC)[reply]

I'm confused because almost all properties for edition items are like they are for printed editions (books, magazines etc) but not parts of them. --DixonD (talk) 06:41, 15 January 2014 (UTC)[reply]

Oh yes, I think we will have some item which will be part of the corresponding edition item? Am I right, guys? Candalua (talk) 08:46, 15 January 2014 (UTC)[reply]

Yes, that should be the same for articles from periodicals. There is a Task Force for that Wikidata:Periodicals task force, but at 1st glance, their model is less detaills that that of the Books TF. --LBE (talk) 09:14, 15 January 2014 (UTC)[reply]

But if we have two versions of the same poem which are parts of different collections (edition items), it means that we will lose connection between these poem versions. Isn't it right? --DixonD (talk) 15:53, 15 January 2014 (UTC)[reply]

Different versions on Wikisource[edit]

What should we do when Wikidata only has one item for a work but Wikisource has multiple versions of it with no master disambiguation page? For example, Wikisource has three versions of Constitution Act, 1867 (Q868884): the original 1867 act, the act as currently amended, and the amended version with annotations. Is there a rule of thumb explaining which should be linked to from Wikidata? --Arctic.gnome (talk) 02:05, 15 January 2014 (UTC)[reply]

All of them should be linked to Wikidata, but probably none of them should be directly linked to Q868884. They should all be treated as versions of Q868884. -- Lavallen (talk) 07:50, 15 January 2014 (UTC)[reply]

@Lavallen: Are you saying we should create three new Wikidata items about the Act whose only interwiki link is to the Wikisource pages and only property is "edition of -> Q868884"? --Arctic.gnome (talk) 09:07, 15 January 2014 (UTC)[reply]
I am not sure "edition of Q868884" will be the only property, but yes. Anything we can add to the templates in those pages are a potential property. -- Lavallen (talk) 11:10, 15 January 2014 (UTC)[reply]
Look at Help:Sources: for properties of a version, you can add the date of publicatio and the place of publication, the edition number, the language if this is a translation,...
- Okay, I think I did it right. Thanks. --Arctic.gnome (talk) 00:53, 16 January 2014 (UTC)[reply]

Close to blocking Dexbot[edit]

We talked about having an orderly and slow approach to the Wikidata import, and Ladsgroup has just set his bot to work without consultation. If someone cannot convince him to stop and quickly, I will take some measures to stop it. — billinghurst sDrewth 11:06, 15 January 2014 (UTC)[reply]

I have blocked it at enWS. It is flooding our recent changes, and we want to review edits and what is being done. There is no hurry. — billinghurst sDrewth 11:16, 15 January 2014 (UTC)[reply]

This was not correct. -- Lavallen (talk) 11:17, 15 January 2014 (UTC)[reply]

It's because the Author: page has also a link to the wrong article. It isn't an error of the bot but an error in en.wikisource. Tpt (talk) 12:19, 15 January 2014 (UTC)[reply]

I'm afraid it's not the only error. Pages are moved on Wikipedia, without the other projects noticing anything. The advantage of Wikidata will be that this can be solved automaticly! -- Lavallen (talk) 17:23, 15 January 2014 (UTC)[reply]

TptBot progress[edit]

Hi! I've began to run TptBot. You can see its progress here. Here is the list of the wikis already imported:

ca

de

en

es

fr

it

pl

pt

ru

sv

uk

Hi! Will you work on Ukrainian Wikisource as well? --DixonD (talk) 17:50, 15 January 2014 (UTC)[reply]

Maybe if someone help me because I don't read Cyrillic. The planned wikis are currently de, en, fr, es and it. Tpt (talk) 18:22, 15 January 2014 (UTC)[reply]

Unclear how to fix the interwiki conflicts you seem to encounter. Is the list somewhere? --LBE (talk) 11:09, 16 January 2014 (UTC)[reply]

Sorry, I planed to put a list interwiki conflict there but there was not so much for the currently imported wikis (ca, de, es, pl, sv and uk) I've fixed them between each import. I'm currently importing en and as there are far more conflicts I think I won't fix them all and so publish a list as soon as the importation is finished. Tpt (talk) 11:39, 16 January 2014 (UTC)[reply]

Checking the worklog, I noticed an error on list of Baltimore City College people (Q6563311). It came from a wrong interproject link on the EN.WS page. However, the item has instance of (P31) set to Wikimedia list article (Q13406463), instead of human (Q5). Is it recorded as a potential error in your conflict log ? --LBE (talk) 20:25, 16 January 2014 (UTC)[reply]

No, it isn't. I've just published a list of the not fixed yet logged errors here. Feel free to fix them and remove them from the list. Tpt (talk) 09:06, 17 January 2014 (UTC)[reply]

My bot has already removed links on French Wikisource and two other bots have done it on English and Italian Wikisources. I'm ready to import and/or remove links from some other Wikisources if requested. Tpt (talk) 20:41, 15 February 2014 (UTC)[reply]

Dexbot[edit]

Hi! I believe that the reaction against Dexbot bot of Amir Ladsgroup have been a little bit excessive. I understand that removing of sitelinks directly in Wikisources and creation of new items before having used all commons way to match Wikisource pages with Wikidata entries have made some people afraid but I believe that importation of sitelinks from Category, Author, Help, Template and Wikisource namespaces to existing Wikidata items won't be so harmful. So, I believe that we should apologize and ask him to continue the importation from Category, Help, Template and Wikisource namespaces as my bot is currently working on Author. What do you think about it? Tpt (talk) 17:35, 15 January 2014 (UTC)[reply]

If it helps, I apologize. But we are not late to any bus. We have time. My opinion is that it would help if Amir could set up a second bot (Dexbot2?), that is easier to follow than a contribution-list that mixes several kinds of tasks. My opinion is that it can be promoted directly without a complicated RfP-process. Unfortunatly I have fever (Q38933) today, so I cannot help as much as I have intended. -- Lavallen (talk) 18:20, 15 January 2014 (UTC)[reply]

Well, excessive, I don't know. We just asked him to stop his bot temporarily, since we had no indication that it was following the guidelines that we agreed upon here. He had not contributed to the discussions on this page, let alone volunteered his bot for help in the process. He did not explain clearly either what he had set it up to do. According to what he wrote this morning on the PC, for all I knew, maybe he was going to create items for every Page: and Book: and Main subpage. That's why I and others asked him to stop it for a few hours, and clarify.

Most of the arguments came from how he answered those requests.

But now (only 12 hours later), we probably have the answers we need. If DexBot can help with Categories, Help, Templates ... let's bring him back on board and thank him for this. As for the main namespace, we should probably move carefully, and on a per language basis. Things are very specific to Wikisource there. To be quite frank, I am not sure we should import items massively until we have the tooling to use Work-Edition bindings for interwiki, since none of the items which would be created would be usable for Phase 1.

--LBE (talk) 22:53, 15 January 2014 (UTC)[reply]

@Tpt:I blocked a bot for 24 hours that was flooding enWS recent changes when I was unable to get the bot owner to stop, and I had seen that others had tried. The bot was not following the expressly desired processes and was removing interwiki links and I believe that they were importing subpages of works, and the person considered that he could do as he wished. I don't see any for which an apology is warranted. I am happy for the person to participate within the boundaries that the WS community sets for the bots actions for our end. At the WD end, I would hope that the importation of subpages would cease. — billinghurst sDrewth 11:38, 16 January 2014 (UTC)[reply]

SamoaBot[edit]

...is running supervised on Wikidata (waiting for the approval of Task 42) and on some Wikisource editions (Catalan, Greek, Italian, Norwegian and Polish ones). --Ricordi samoa 23:03, 15 January 2014 (UTC)[reply]

I just supported --Aubrey (talk) 15:05, 16 January 2014 (UTC)[reply]

Ricordisamoa, how's the import going? I see most it.source works are still missing, correct? To make actual use of Wikidata (I'm thinking of book export for instance) it would be particularly important to import the basic work metadata like author, publisher, date, translator etc. The Italian Wikisource tries to provide Dublin Core metadata in the HTML, if that helps. --Nemo 15:25, 25 April 2014 (UTC)[reply]

Until now, I've deliberately avoided running the bot on work/edition/index/etc. pages, because of my little knowledge of the matter. If you think I should run it, please explain every detail. --Ricordi samoa 15:59, 25 April 2014 (UTC)[reply]

some people are moving ns0 interwiki to wikidata[edit]

Some people, evidently unaware of the work-edition relationship, are removing interwiki links from texts pages, and linking those pages to the work item. How should we act on that? Rollback and tell everyone to wait? Or what else? Candalua (talk) 18:29, 16 January 2014 (UTC)[reply]

Look if they follow the guideline before you restore! I have for example connected Q15629339 with Wikisource, and I think I have followed the edition-relationship. I have notified User:Romaine that it does not look like (s)he has followed it. - -Lavallen (talk) 18:33, 16 January 2014 (UTC)[reply]

Ok! Thanks for the extremely fast reply :) Candalua (talk) 18:45, 16 January 2014 (UTC)[reply]

Bot owners also needs to be teached in this issue. Just cleared Q40185 with lots of additions by EmausBot (Emaus) (and cleared also some mistakes by me on Q1845 and Q60220). Lugusto (talk) 20:48, 16 January 2014 (UTC)[reply]

Editions of editions?[edit]

The bible can be found in many many editions.

The Swedish Charles XII Bible (Q5083751) is an example. It's an edition of the bible. But this edition of that bible can be found in several editions. A 1703-edition can be found here and a 1828-edition can be found here.

I guess we in these cases have to handle the 1828-version and the 1703-version as editions of Charles XII Bible (Q5083751). And that bible (Q5083751) have to be regarded as an edition of the "original" bible itself.

Or are there any other good solutions? -- Lavallen (talk) 10:00, 17 January 2014 (UTC)[reply]

Maybe we can just specify that "Charles XII Bible 1703" is an edition of the Bible, and "Charles XII Bible 1828" is an edition of the Bible and it's derived from "Charles XII Bible 1703"? Candalua (talk) 10:07, 17 January 2014 (UTC)[reply]

I wouldn't mind an edition of an edition. Lavallen solution seems kinda ok. The Bible is a work, with thousands ramifications. --Aubrey (talk) 10:56, 17 January 2014 (UTC)[reply]

But conceptually, "X is an edition of the Y edition" doesn't make much sense. And I guess it would make the interwiki system more complex, because instead of the regular edition -> work relationship, there would be an additional step, edition -> edition -> work". Plus, I think it would be more useful to have this information in a separate field, so we can use it in our templates to show that "the text of this edition is based on the text of that other edition". It could be useful not only for the Bible, but generally for every text which has been reprinted-reedited several times. Seeing Wikidata:Books task force, the property "based on" is currently provided for works, but not for editions. I think we should add it for editions too. Candalua (talk) 11:18, 17 January 2014 (UTC)[reply]

Yes, but in this case, the edition (the Swedish translation from 18th century) is also a work, not only an editon. It is only in relation to the original it is an edition.

And, yes, it makes it more difficult to solve the interwiki-problem, but it's not unsolvable.

On the other hand, svwp has 12 different translations of the bible + 2 comments of the bible. I do not know how many enws has, but I think they have more than that. We already have a serious interwikiproblem here. -- Lavallen (talk) 11:25, 17 January 2014 (UTC)[reply]

I'm confused: can an item be an instance of 2 things at the same time? Or am I missing something in your proposal? And, is it correct to consider a work something which is in fact a translation (although probably most Bible translations can also be considered adaptations, since most translators actually tried to make the text "fit" to their religious theories)?

As for the huge number of interwikis in some pages, I think it can be managed; we can just organize all the interwikis by language, and for long lists we can show by default only the top-level links, like: "Swedish editions - Click to expand the list", so that users can easily navigate through the "interwiki tree" even with hundreds of them, expanding and collapsing the list at will. Candalua (talk) 11:58, 17 January 2014 (UTC)[reply]

"Can an item be an instance of 2 things at the same time?" - Good question! That is maybe the key question.

A translation is a work, definitily! Especially when you have to translate from such an alien language as Hebrew to Swedish. And we in Swedish as of the 16th, 17th and 18th century did not have any words for some of the animals and plants in the Bible. I do not think any translator have the intension to "adapt" the texts to their religious theories, but de facto, it always more or less obvious that way it looks. One of the Swedish translators have for example avoided the word "Priest" in all of his bible, since his opinion was that the Priests as they look today was never intended. My opinion is that he was right, but it is most likely the wrong way show it.

And yes, interwiki is probably solvable. -- Lavallen (talk) 12:24, 17 January 2014 (UTC)[reply]

I'd like to quote Hesperian's post on the English Wikisource scriptorium: "What we need is a generic 'is a derivative work of' relation, to handle the situation where: an old German fairy tale is written down by various authors. One of those stories goes through various revisions over the life of the author. One of those revisions is translated into English multiple times. Once of those translations is revised multiple times over the life of the translator. One of those revisions is abridged, and that abridgement is published multiple times. We probably can't expect to capture the fact that a publication is a publication of an abridgement of a revision of a translation of a revision of a version of a work. But we do need to capture these dependencies somehow. If everything is declared to be either 'work' or 'edition' (but not both), how are we to handle the above? Declare all those editions to be editions of the original fairy tale, and lose all that semantic detail? That would be terrible."--Erasmo Barresi (talk) 15:25, 17 January 2014 (UTC)[reply]

This discussion is becoming more and more intriguing! :D Thanks Erasmo. That, in a way, is also my point, although me and Hesperian reached it by very different roads :D I think we need, and we can have, both of these two things:

we need a direct link between edition and work, so that it's fast and easy to reach every other edition (and by the way, we should have only works and editions, not more kinds of items; or things will really become too difficult to understand and use); and:
we need a way to represent all the evolution of a text: A is derived from B, B is abridged from C, C is a revision of D... this can be done with one or more properties, depending on the level of details that we want to obtain.

Candalua (talk) 16:52, 17 January 2014 (UTC)[reply]

To make the example of Karl XII's bible more complex. It's often regarded as a revision of a translation from early 17th century: Gustaf Adolfs Bible. And Gustaf Adolfs Bible is regarded as a revision of Gustaf Wasa bible from 1526 (NT) and 1541 (OT). And Gustaf Wasa bible is regarded as a translation of one of the Martin Luther bibles in German. And the Martin Luther bible is... etc

If all of this really is true is another question. I would say that the translators of 16th century did not have the skill to create a translation from latin/Greece/Hebrew. They only know German and some phrases in latin. And the 17th and 18th century did not have the courage to say anything than it was a revision. Doing otherwise would have been regarded as steps away from Luther, a blasphemy.

-- Lavallen (talk) 17:34, 17 January 2014 (UTC)[reply]

Wikisource categories link suggestion[edit]

Bot specialists could be interested in helping with Wikidata:Bot requests#Wikisource categories link suggestion. --EugeneZelenko (talk) 15:03, 18 January 2014 (UTC)[reply]

Bot assistance requests[edit]

I added couple of request which should help to improve authors coverage in Wikidata:

EugeneZelenko (talk) 15:22, 20 January 2014 (UTC)[reply]

I was hoping WikiDataQuery could help for this kind of reports, but I asked Magnus, and he said the queries of sitelinks is currently broken. Hopefully, he'll be able to fix it soon. --LBE (talk) 20:14, 20 January 2014 (UTC)[reply]

Technical questions[edit]

Hi,

A few questions on the next steps:

Is there a planned date to deploy phase 2 for Wikisource? AFAIK, it is activated only for the Wikipedias so far.
Is phase 2 necessary to use the interprojects links out of the Wikidata item (like links to Wikipedia, in an "Other projects" template)?
Is phase 2 necessary to get this Work-Edition binding tool that we need to actually have interwiki links in the main namespace?
About this binding tool, is it correct to assume it's going to sit on the Wikisource side, with no dependency to Wikidata development?

Thanks for your insights.

--LBE (talk) 22:56, 20 January 2014 (UTC)[reply]

@LBE:

It is deployed on Wikivoyage too; about Wikisource, please follow User talk:Lydia Pintscher (WMDE)#Wikisource Phase 2;
Interwiki links are automatically shown in view mode, but handling them via a template (as well as handling claims, sources, etc.) would require the mw.wikibase Scribunto library to be available (it will be with Phase 2);
and 4: dunno. --Ricordi samoa 23:48, 20 January 2014 (UTC)[reply]

2/ was about interproject links, not interwiki, but i assume the depency to a WB lib is the same. --LBE (talk) 07:23, 21 January 2014 (UTC)[reply]

@LBE: they're all sitelinks here on Wikidata. You have to wait Phase 2 to access them. --Ricordi samoa 13:30, 21 January 2014 (UTC)[reply]

There is also a bug that have to be solved. I do not remember it's number, but it prevents us from using properties in other items than the directly linked item. -- Lavallen (talk) 14:01, 21 January 2014 (UTC)[reply]

Another question is if a javascript solution to solve interwiki between "editions" require Phase 2, or if it can be done without it. -- Lavallen (talk) 08:22, 21 January 2014 (UTC)[reply]

@Lavallen: It can be done without it. Tpt (talk) 09:33, 21 January 2014 (UTC)[reply]

Date for data access[edit]

Hey :)

Thanks to everyone who helped make the language link access for Wikisource so smooth. Let's get them data access as well now. We are currently planning this for February 25th.

Cheers --Lydia Pintscher (WMDE) (talk) 13:52, 27 January 2014 (UTC)[reply]

@Lydia Pintscher (WMDE): Do you have any prediction of how far away a solution of bugzilla:47930 is? Three weeks, three months or three years?

It's not a big deal to me, but I can see some frustration that Wikidata has not (yet) been a solution for interwiki between editions. If we then have to wait long for 47930, then we maybe should look for other solutions until it is solved. -- Lavallen (talk) 14:34, 27 January 2014 (UTC)[reply]

I will need to talk to Daniel and Katie about how complicated it is to fix. I'll do that when they're back from travel. --Lydia Pintscher (WMDE) (talk) 15:45, 27 January 2014 (UTC)[reply]

Translations by the community[edit]

Some of the texts on Wikisource are translated by users or a group of users. How are we supposed to treat such cases? On svws, we have a category: s:sv:Kategori:Wikisource-översättningar for such texts. How are other projects showing this and how should we use translator (P655) in such cases? I came to one case here where it's possible that the text is credited a specific User (User:Nysalor@fiwikisource), but since my and Google translates Finnish isn't very good, I'm not sure yet. Do we have to create an item for User:Nysalor (if he is the author, I'm not sure yet) and other Users and do we have to set up an item for unspecified/anonymous community authors? -- Lavallen (talk) 09:10, 29 January 2014 (UTC)[reply]

I have now confirmed from the userpage of User:Nysalor that he is the Author of the Finnish translation of this text. -- Lavallen (talk) 11:35, 29 January 2014 (UTC)[reply]

I believe the item shall be created, but the label of the item can be discussed on per-case basis. For example, we can have so far item with label "Nysalor (fr-wiki user)", but rename it later to, for example, "John Doe", as soon as (and only if) the real name will be revealed by himself. For IP-addresses "Anonymous Author" item can be created and supported. Basically I have no problems with Q-items for users, and they can be also used for interwiki links. -- Vlsergey (talk) 15:23, 29 January 2014 (UTC)[reply]

For groups of users the situation shall be the same as for group of authors. -- Vlsergey (talk) 15:24, 29 January 2014 (UTC)[reply]

The user call himself "Matti Järvinen" in the text. -- Lavallen (talk) 15:28, 29 January 2014 (UTC)[reply]

WikiData Query now handling Wikisource[edit]

Great news !

Let me quote Magnus:

it finally seems to work. Try this for all books that have a link to en.wikisource. You can get all the items not linking to en.wikisource using nolink instead of link, but it's awfully slow (minutes!) for the moment.

So consistency reports become easy to do, even for those who can't code. I'll propose a few when I have time. --LBE (talk) 08:55, 8 February 2014 (UTC)[reply]

What wikidata for wikisource item?[edit]

About Main namespace linking to Wikidata items, fourth type () I read:

"text pages that contains a book chapter, a poem... They should be linked to the related Wikidata items if, and only if, they are considered stand-alone works. So, a normal book chapter won't have its Wikidata item".

My question: What item? Work item or edition item? I'd like the first one, and IMHO I'd like to generalyze it so that in any "book" (even when it contains one wotk only) a relationship between both edition and work could be set. But - in such "one-work-only" books, where can be set the link to related work item?

Consider that any book, even if containing one work only, has something different inside from the work it contains (i.e. frontespice, introduction, index of topics...) --Alex brollo (talk) 08:11, 27 March 2014 (UTC)[reply]

I have here sometimes discovered that some works have been published as a "stand alone"-work in English, Swedish etc, but in one or maybe two projects, they are considered only as a chapter in a larger work. I think I found such a case in some of Darwins books at the French Wikisource. It was included inside what looked like a collection of texts from different authors. That "chapter", I connected to a "edition-item" here. And that edition-item, I connected to a work-item.

My opinion is that all "chapters" also should be connected to Wikidata. A page on sv.wikisource should be deleted or merged, if it wasn't considered to be able to "stand alone", even if it only contained a chapter or a short poem.

A chapter-item can have properties like "instance of" chapter, "part of" edition, "followed by" next chapter and "proceeded by" previous chapter. If the chapter have different authors/translators, than the editions item, it can have such properties too.

The problem is that it does not look like Wikidata is prepared for Wikisource yet. It's to focused on Interwiki and Wikipedia. -- Lavallen (talk) 08:50, 27 March 2014 (UTC)[reply]

IMHO, Index and Page namespaces are largely underestimated, since - far from being "proofreading tools" - they are the true digitalized edition of the book. On the contrary, main space transclusion is much more linked to digital version of the work - and introduces always large amounts of "original contribution" in formatting. If/when a TEI structure would been applied to wikisource books, this would be evident - paging of text being one of basic TEI structures of book contents. I know that this is a personal idea, I discussed it some time ago into enwikisource village pump with no result, but I feel that the whole matter should be evaluated again. --Alex brollo (talk) 10:30, 27 March 2014 (UTC)[reply]

I think we have agreed to add Index-namespace here as soon as we have agreed on how to do it. They are often (but not always) connected to a single file on Commons, and maybe the index-page and the file-page should share item, but your idea is another option. -- Lavallen (talk) 11:17, 27 March 2014 (UTC)[reply]

In a naive way, completely unaware of this page & this talk, I tried a possible solution here: here I created a work item Ritratto delle più nobili et famose città d'Italia and an edition item Ritratto delle più nobili et famose città d'Italia (Venezia, 1575); then I linked the former to ns0 version into itwikisource, the latter to its Index: page into itwikisource, I cross-linked them with edition/edition of properties, I report this idea into itsource village pump... and I've been redirected here by Candalua. :-) --Alex brollo (talk) 17:06, 27 March 2014 (UTC)[reply]

Showcase items[edit]

I will be good idea to have showcase items for work, collection of works, etc.

I'm also interesting in metadata examples which describe work. I'm aware about characters, narrative set in properties, but I'd like to know how to describe approximate time frame narrated in work (for example, war, revolution, natural disaster, etc); topic or problem raised in work (social issues, politics, travel notes describing particular place, etc); etc.

Which property should be used for date when work was created?

EugeneZelenko (talk) 02:01, 14 April 2014 (UTC)[reply]

Properties for reflection connections with works/persons[edit]

I think will be good idea to add properties which will allow to refer to quoted and critiqued works.

Some texts mention persons (but not characters of work) like writers, artists, etc. So property for reflection such connections may be useful.

EugeneZelenko (talk) 15:05, 13 May 2014 (UTC)[reply]

Separated works, akin to subpages[edit]

Just dropping this note into place as I identified an item that I am about to discuss, and this is more as information and background, not with any expectation of answers. It has a relationship to the discussion about subpages of works.

Winch, Nathaniel John (Q15987212) is an item that relates to a page at Wikisource. The article is one of many at enWS from the Dictionary of National Biography. It is one of the early biographical dictionary works undertaken, and has some artefact issues about its presentation at enWS, things that have been grandfathered, and would not be undertaken in that way now. If done now the article would be a subpage of the overarching work (even though there are 63 vols, and many thousands of articles). Now it will seem that one or more of these article bio^s have been added as items, and I am not certain that it is fully appropriate, though not certain that it is entirely inappropriate.

So at some point, we will need to address articles that are part of biographical dictionaries, some at root, some as subpages; whether we link the people to the article(s), as a specific linked item, or as sources. — billinghurst sDrewth 08:54, 26 June 2014 (UTC)[reply]

billinghurst, that would be more suitable for a "Wikidata for textual content" (similar to "Wikidata for media info"). I would prefer to avoid this kind of items for the time being and wait to see what happens with Commons. Once we see how that is working we can decide to propose a similar way for Wikisource, or perhaps just rely on Wikidata. --Micru (talk) 09:03, 26 June 2014 (UTC)[reply]

I would have avoided these completely, it is amazing what we stumble upon. It crossed my mind to nominate it for deletion, then thought it made a reasonable discussion point, hence the above. We should definitely be discouraging further of these at this point in time, and had even wondered whether we could build an abuse filter to prevent their addition (until there is a resolution). — billinghurst sDrewth 10:41, 26 June 2014 (UTC)[reply]

Some time ago i raised at discussion on forum regarding links from encyclopedias stored in wikisource to wikipedia articles: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2014/06#Wikisources_encyclopedias_links . There were no objections (neither help though) about the scheme where each encyclopedia item (i.e. subpage text in wikisource) is assotiated with wikidata item and linked from wikipedia article item. On the next week i plan to finish the bot and import quite number of such links into wikidata. Personally i don't quite understand the issue with "textual content problem", since it can be treated the same way as any other wikipedia article or source reference. Also those wikisource items have properties like "author", "volume", "main topic", etc., that should be stored along with item (not as qualifiers for text content link). Links to discussions and arguments would be appreciated. -- Vlsergey (talk) 12:01, 26 June 2014 (UTC)[reply]

Vlsergey, sDrewth: I am really neutral about this, it might be good for encyclopedic pages, the only thing that worries me is that the data might not grow "organically", that is, without proper community support and without creating consensus. Some questions:

Should this been discussed in a broader context, like the wikisource mailing list? That might help raise awareness and support for your development.
How does this fit with the (in development) Book Manager? Perhaps it is good to discuss with the student how to integrate wikidata in her project?
Are there lua templates to use the data? How can users modify them?
Shouldn't we have a standard solution for all book parts instead of several solutions? If we could appraise how many chapters we have, maybe there would be less fears of using wikidata in those cases too.

--Micru (talk) 14:08, 26 June 2014 (UTC)[reply]

@Vlsergey: I would prefer that we didn't import these articles at this time. 1) I don't think that WD or WS are ready for these, and especially where an encyclopaedic work is incomplete; 2) We are still to work out subpages from WS -> WD, and these are predominantly subpages; 3) They aren't urgent, 4) They won't be interwiki'd. Some of these what is the value of having these subpages in WD? If are using references, the work itself, with the page should be cited, not a sub component. This is especially the case when there are multiple editions of some of these reference works; each would be pertinent to import? I am yet to see the point. — billinghurst sDrewth 15:07, 27 June 2014 (UTC)[reply]

@billinghurst: 1. What exactly in wikidata is not ready? from my point of view it has everything it need to support required functionality. Regarding wikisource i'm talking about Russian one, and we need those links to link articles in ru-wiki with appropriate articles in ru-wikisource. 2. We don't have technical problem here -- those pages are technically not subpages from engine point of view. 3. Well, this is plan of my work, tell me the reason not to do it. It's not like i'm asking for help here or asking for technical support. I will create lua module by myself, javascript to update from wikisource by myself, import bot by myself. Nothing is urgent, but why not now? 4. If you read the discussion i linked, they will be linked from other elements. This is the goal to reach. It is not about links from different languages to ruwikisource, but from one project (ruwiki) to other (wikisource) and back. And there is only one edition for each work to be imported at this point. Again, i'm not talking about importing all wikisource subpages, but only from 3-5 dictionaries and enciclopedias presented in ru-wikisource. -- Vlsergey (talk) 15:51, 27 June 2014 (UTC)[reply]

Updating Wikidata:Wikisource[edit]

Hi all, I'm reaching out because I'm currently looking at cleaning up and updating the Wikidata documentation for sister projects. I'd like to help and/or support efforts to improve Wikidata:Wikisource so the page more fully reflects the fact that Wikidata has been deployed for Wikisource (IMO currently the page reads as though deployment is still just in the proposal phase). It'd be great to include content on how Wikdiata supports Wikisource (and vice versa) and why people should care and contribute. I'd also like to mirror some of the documentation on Wikisource at s:Wikisource:Wikidata that not only describes Wikidata-Wikisource interactions but directs contributors to tasks and maintenance activities. Unless anyone objects, beginning next week I'll start making some changes and moving some content around (likely I'll set up a couple of sub-pages). If you have any suggestions or recommendations for content that is missing but should be added, please comment and let me know! Thanks -Thepwnco (talk) 20:56, 19 July 2014 (UTC)[reply]

Page(s) updated as part of documentation overhaul[edit]

Hi all,

as discussed above, I've gone ahead and updated the Wikidata:Wikisource page. I realize these are substantial changes—but I did try and keep the original proposal/discussion completely intact (as you will see, it is now a subpage at Wikidata:Wikisource/Development). If you have suggestions or concerns please leave them here—you can, of course, edit/revert my changes but I hope this documentation will prove useful for the Wikisource community, help sustain contributions to Wikidata, and encourage further collaboration. There are a few issues I would like feedback on, including the following:

I removed the sister projects template from the top of the page in order to add navigation and better brand the page for the Wikisource community - I don't think this template is particularly useful as it is still linked to from the Wikidata:Sister_projects portal. What do others think?
Should discussion on proposals/further development for integration of Wikidata & Wikisource be now directed to the talk page of Wikidata:Wikisource/Development? Or should they continue to take place on Wikidata:Wikisource? Should there be a note explicitly stating where to leave development/deployment-related discussions or does it not matter that much?
Is the bugzilla link important? Should it go to Wikidata:Wikisource/Development? What about the 'in a nutshell' notice?

Thanks in advance. -Thepwnco (talk) 23:55, 24 July 2014 (UTC)[reply]

Wow, the page looks now so much better! I would recommend to put some visible link to the Wikidata:WikiProject Books, because Wikisourcerors might be very interested on it (if there is already a link sorry that I didn't see it!)--Micru (talk) 15:09, 25 July 2014 (UTC)[reply]

thanks for the feedback! You are correct - the link to WikProject Books was lost in the content reshuffle. I've now added it to Resources. -Thepwnco (talk) 20:44, 25 July 2014 (UTC)[reply]

Badge feature[edit]

With the new badge functionality imminent for the wikis, I was wondering whether we should be looking to firstly discuss what each of the wikisources is doing in this space, and then coordinating getting suggestions to the WD team.

For instance, (initial thoughts) I could see that English Wikisource could have an interest in the badging feature for:

Featured works
Proofread of the month works (or other competition works)

— billinghurst sDrewth 13:56, 17 August 2014 (UTC)[reply]

mul: interwiki now exists[edit]

Tracked in Phabricator
Task T54971

It quietly happened in the mediawiki release last week (git #f0d86f92 - Add additional interwiki links as requested in various bugs (bug 16962, bug 21915)) that the mul: interwiki has appeared for the wikisources to be able to point to wikisource.org. What is it that we now need to do to enable the mul: interwiki to be used in Wikidata? — billinghurst sDrewth 03:46, 29 September 2014 (UTC)[reply]

@billinghurst: Notified the dev team.--Micru (talk) 21:20, 17 October 2014 (UTC)[reply]

Index pages and text quality[edit]

Right now it is posible to create an item to represent a Wikisource text, and also use the property document file on Wikimedia Commons (P996) to link with the file used as basis, but we don't have any qualifier to indicate which Index page correspond to that scan file. I was wondering if we could use a monolingual text property (Wikisource index page) for that purpose and generate the links based on the language chosen (see example with the sandbox property: Iliad (Q17559055)).

The other question is about text quality. We have different quality indicators:

for a single page
for the whole scan file
for a text (specially those without scan file)

Should we create a new property to be used as indicator of text quality? I think we have too many different options to be used as a badge.--Micru (talk) 21:26, 17 October 2014 (UTC)[reply]

I agree, there is a difficulty for Index page - moreover, for bilingual books, there may be 2 index-pages, one on each language project :)

the problem with quality indicators is that, if the same in Index/Page context, due to the use of "Proofreadpage index template", they may be different from a language to another on mainspace. --Hsarrazin (talk) 08:49, 18 October 2014 (UTC)[reply]

For this book there are even five index pages in different language subdomains. Ankry (talk) 20:05, 18 October 2014 (UTC)[reply]

D - I knew some 3-languages books, but 5 !! and I even think it's 6 (de ; en; eo ; fr; pl; ru) : only esperanto can achieve it… most are 2-languages I think, text+translation ;) --Hsarrazin (talk) 10:25, 19 October 2014 (UTC)[reply]

@Ankry, Hsarrazin: In that case we could use the monolingual datatype for the proofread progress too. Check again Iliad (Q17559055), I have added the same Index page in 3 different languages and proofread levels for 2 languages (the meaning of the codes should be agreed). The question is to know if that might work with MediaWiki:Gadget-AuthorityControl.js, with each monolingual string pointing to a different Wikisource depending on the language. Pinging @Bene*, Legoktm, Hoo man:, they might know...

The other option could be to create a third item for the Index page which would be linked using "manifestation of", but that seems a bit overkill for most books that only exist in one language and only have one edition.--Micru (talk) 22:23, 18 October 2014 (UTC)[reply]

well, putting all the infos in the same property (or qualifier), without separating the values seems a bit messy to me… what about a "Quality level of ws text" property, with possible qualifier "language" ? - and yes, creating an items for the sole purpose of linking to language indexpages seems really too much :)

I used the same property because it is the only monolingual sandbox property there is, but yes, the idea would be to use two distinct properties. Qualify with language is also a nice idea.--Micru (talk) 10:43, 19 October 2014 (UTC)[reply]

what do R and E stand for ? maybe numbers would be clearer ?

If we can use items, even better.--Micru (talk) 10:43, 19 October 2014 (UTC)[reply]

I don't understand what you mean about "Gadget-AuthorityControl" ? there is no common point between wikisource and AC, or is there ?

The Gadget-AuthorityControl is what is used in Wikidata to generate links to external sites. Normally when you enter a property that uses a string, it can be converted into a URL by that gadget... when it works... because lately has not been working and people just see strings when they should see urls.--Micru (talk) 10:43, 19 October 2014 (UTC)[reply]

moreover, I'm not really certain we should mix our wikisource home-cooking in the "Claims" part of items in wikidata… :/

for now, I would be more satisfied with a visual badge, similar to these ones on the wikisource links :) - and maybe time to think… --Hsarrazin (talk) 10:25, 19 October 2014 (UTC)[reply]

If you add badges, how many badges do you want to create? There are many revision levels, plus if a text is exportable as Epub or not.--Micru (talk) 10:43, 19 October 2014 (UTC)[reply]

Oh, and one thought that just occurred after closing, and seeing that Q17559055 is only the Catalan edition (from the labels)… why bother about es and eo links on it ? --Hsarrazin (talk) 10:29, 19 October 2014 (UTC)[reply]

Q17559055 was just a demostration in case it existed in 3 different language wikisources, not the way it should be as it only exist in one language...

Perhaps we should begin adding just the links to the Index: pages and think later about how to represent quality. One step after the other ;)--Micru (talk) 10:43, 19 October 2014 (UTC)[reply]

Proposed badges for text quality[edit]

If we start just signaling text quality as sitelink badges, some possible options could be:

Text being edited
Text complete
Text and sections exportable as Epub
Proofread by one user
Proofread by several users
Problematic text
Community translation

Note that this only refers to the quality of the whole text, not to the quality signaled by ProofreadPage which operates at page level. For now it is better not to include the status of the whole Index, as it is complicated to manage (see conversation above).

Additionally I proposed a property to link with the Index page, Wikidata:Property_proposal/Sister_projects#Wikisource, comments and support would be appreciated.--Micru (talk) 12:03, 19 October 2014 (UTC)[reply]

@Micru: I am not sure why you are wishing to represent this at Wikidata. To me, it is something that sits within the WSes as internal data. About the only one that I like above is "community translation" as it reflects the source of a new work that is not achievable by existing meta data, and that has relevance to the broader world. If you needed further information, it may just be complete or incomplete for other transition works. Maybe how you see the value, and how it would work would be of assistance here. — billinghurst sDrewth 01:06, 20 October 2014 (UTC)[reply]

@billinghurst: Excellent point. As I see it with Wikidata we are opening Wikisource for reuse, so we might want to convey as much information as possible through Wikidata to these potential users that might read our texts without even seeing the traditional Wikisource interface. This mockup shows a possible way of presenting works on wikipedia by an author, it is just a possibility, but it suggests that it might not be enough to just create an item for the work, it is also important to convey to the user somehow what to expect when following the link. Is it a complete and usable text or just a stub? Perhaps the "good" and "featured" badge can be used to mean "proofread" and "validated" respectively that way we would reduce considerably the number of badges, and just create a new one for "community translation". --Micru (talk) 07:36, 20 October 2014 (UTC)[reply]

I still don't see that the stages of a two-step validation process are notable, with the validation process being peculiar to WSes. I also have a personal opinion that works shouldn't be listed at WD until they have reached the proofread status, in that they are a finished product, and if that line holds, it indicates my opinion to the remainder of the criteria. [Other things falling into that non-listing zone are the Index: ns pages which along with Page: ns are workspace items.] A community translation is specific in that it won't have a translator, so it becomes its own "edition". Re Epub: every work should be exportable as epub is my point of view, and it is that way at enWS. — billinghurst sDrewth 10:09, 20 October 2014 (UTC)[reply]

On ca-ws we have many works that have not been proofread completely which might be useful to list on WD in a way that they can be told apart from the finished ones. Also by having the indication that the proofreading is not finished, it is possible to invite users to participate. On en-ws there are also many texts that are not complete but might be useful to have represented as items, like s:en:"I'll_Fight". Would you leave them out?--Micru (talk) 10:35, 20 October 2014 (UTC)[reply]

My personal view: Yes, I would leave them out until completed through one proofread (where transcluded works). That may not be my community's view.

I see WD as the structured, not a browsing tool. If we can demonstrate how or where the structured data for this may be extracted to do other things, then maybe I can be convinced otherwise. In the proposed process, I am seeing that it is manual maintenance, and to be linked to something else it needs a broader proposal, a consensus of the communities about stages, and a bot to do it. — billinghurst sDrewth 01:04, 21 October 2014 (UTC)[reply]

Poem[edit]

We use Property:P31 as Q5185279 for a poem. But do we have/use any sub types for poem? As on Gu wikisource there many specific poems for example some are sung during marriages only and some in mornings only. So what to do with such specific works? How do I use "instance of" with these? Please advise.--Vyom25 (talk) 11:59, 2 February 2015 (UTC)[reply]

Look at http://tools.wmflabs.org/wikidata-todo/tree.html?q=5185279&rp=279 and see the current possible P31 values to use. You can also create a new item for a specific poem subtype and use it with P31. Michiel1972 (talk) 12:07, 2 February 2015 (UTC)[reply]

Thanks for the advise. I will try to use existing subtypes as much as possible and will create new ones if necessary.--Vyom25 (talk) 12:54, 2 February 2015 (UTC)[reply]

DNB[edit]

Please see Wikidata:WikiProject DNB --- Jura 06:07, 27 March 2015 (UTC)[reply]

wikisource mass import[edit]

Are you aware that mass import of wikisource items without any claims have been done recently ? I just discovered it, and it's really, really not nice to clean up :/ --Hsarrazin (talk) 13:43, 28 March 2015 (UTC)[reply]

Interwiki and Notability[edit]

I am currently making some progress in how to handle interwiki on Wikisource. See for example s:sv:Bibeln (Karl XII). The module making this interwiki possible can be found here. I am not good in Lua and self learned as a programmer, so there can be a lot of bugs in the code. But as you can see, it's fully possible to create an automaticly updated interwiki between all versions of the same texts, even if the items does not include more than one sitelink per item. It's done by letting the module running first up by the help of edition or translation of (P629) and thereafter down by the help of has edition or translation (P747). The Lua-code itself, does not fix all of this. It needs support from MediaWiki:Common.js. The code also allows interwiki with the four WS-projects who are embedded in Wikipedia. (als, bar, frr, pfl)

Next step includes allowing links between chapters in the books on Wikisource. Interwiki wasn't very common here earlier, and it will most likely remain that way. But we have a lot of textsamples from Bible (Q1845) and interwiki between different versions of Gospel of John (Q36766) is, I guess, desired. You maybe think "the Gospel of John" is not a chapter. And, No, maybe it isn't. But when you look at it as a part of the Bible, it can be regarded as a chapter. Some projects even have textpages about "chapter 6 in the Gospel of John", and then that page has to be regarded as chapter of the Gospel. I think enws even have some pages about single verses in the Bible, but I think they are alone there.

To be able to add interwiki between chapters, we have to connect those pages to Wikidata. WD:N tells "The status of subpages of mainspace pages (for example, individual chapters) is undetermined". I would say that statement is outdated. I would say it is determined today, and that by criteria 3 structural need. What kind of statements should such items have? instance of (P31): chapter (Q1980247) together with a new property "Chapter of": "Main page of the WS-edition"? If the chapter has another Author than the main page of the WS-edition, statements describing that can be added to the page. follows (P155) and followed by (P156) could also be added, I guess. Observe that the order of the chapters are not always the same in all editions of a book.

To be able to add interwiki in the same way as I have done in svws, we also need mother-items for the chapter-items, to be able to create P629 and P747-statements. (When there is a "structural need" for them of course.) For example, we need a mother-item for the "Gospel of John in American Standard Version" and fortunatly, Gospel of John (Q36766) I think can be used for that purpose. There is often non-symmetries here, and that is a good reason to have only one sitelink in every item also here. Observe that not all "chapters" on Wikisource can be found in subpages. Some books are organised in other ways. And some chapters do not have a main page for the book. For example, we have some Swedish 15th century handwritten translations of the bible. Those texts have never been part of a larger book, so there is no "Main page" for these text, but they are still organised in subpages.

My proposal:

We should include also chapters to books on Wikisource to WD:N, even when they can be found in subpages
We should create a new property "chapter of", the need of a property in the other direction, is not obvious to me.

This is not a proposal that we should bot-import every subpage on Wikisource today. It has been so poorly done this far, that I do not trust our bots to do that today. It's enough if it's done by hand. -- Innocent bystander (talk) 14:33, 21 June 2015 (UTC)[reply]

What naming conventions will it have? Will it be "Text name / Chapter 2" / ("chapter of Text name"), or "Chapter 2" + ("chapter of Text name") or "Chapter name" + ("chapter of Text name") ?

Some workaround will be to specify entityId of parent element in text itself at Wikidata. Thus chapter entity won't be required. Better solution will be to ask developers for some "entityId-by-page-title" function, thus be able to extract links from parent page without child page wikidata item. -- Vlsergey (talk) 16:15, 21 June 2015 (UTC)[reply]
Naming conventions, I guess you mean for the WD-labels? To be honest, I do not know. I cannot see that we have any good naming convention for Wikisource-items today, not even for the main pages. Labels like "Title of the book (author/language)" is often used. Using brackets is a little against the normal conventions for labels, but I cannot see that it is a big problem. Having the label "The Bible" for every item connected to has edition or translation (P747) in Bible (Q1845) would look akward, and impossible to work with.

An "entityId-by-page-title" would be nice, we recently talked about it at WD:DEV. But every subpage on Wikisource is not a chapter in a book, and not all book chapters are in subpages, so it will not solve everything. And I cannot see that neither gives us interwiki to "The Bible (Charles XII)/Gospel of John" or the chapters of The Wonderful Adventures of Nils (Q726254). In Q726254, not every chapter in the Swedish version have a corresponding page in Danish or vice versa. Chapter 3 in Swedish is number 1 in Danish. -- Innocent bystander (talk) 16:47, 21 June 2015 (UTC)[reply]

Links to pages on the multilingual Wikisource[edit]

There are eight (8) pages in Ladino on the multilingual Wikisource. (See s:mul:Main Page/Ladino and s:mul:Category:Ladino. Is there a way to link these pages in through Wikidata?

I'd have a similar question about Ladino Wiktionary and Ladino Wikibooks, which are both on the Incubator.

Thanks. StevenJ81 (talk) 15:08, 13 August 2015 (UTC)[reply]

No, sitelinks to multilingual Wikisource and Incubator cannot be added, yet. -- Innocent bystander (talk) 15:40, 13 August 2015 (UTC)[reply]

Thanks. StevenJ81 (talk) 15:45, 13 August 2015 (UTC)[reply]

Links to pages on the multilingual Wikisource 2020s followup[edit]

I oppose what Innocent bystander said, it seems possible, though not easy and tricky, to add such sitelinks, by using a browser that supports HTML5, drag-drop the gray "edit sitelinks" on the left, copy-paste the title to the label name field to create a dummy item contains what you've linked. and finally merge it to the correct item. --User:Liuxinyu970226 (talk) 14:42, 13 October 2020 (UTC)[reply]

@Liuxinyu970226: Could you give an example of a page you edited in this way so that I can look at the history and see how it was done? It's a little hard to understand with just words. Arlo Barnes (talk) 13:24, 6 December 2021 (UTC)[reply]

I think we don't need to discuss this site anymore, since the interface now just supported the mul.wikisource. Adding Incubator interwiki links, however, still needs to do so. Liuxinyu970226 (talk) 13:29, 6 December 2021 (UTC)[reply]

Is the example given correct?[edit]

The example given on this page is the item linking the English Wikisource page for The Curse of Minerva to the French Wikisource page La Malédiction de Minerve, a translation of the former by Benjamin Laroche (Q2896130). Shouldn't the French page have a separate item, formatted as a translation, with translator information and such? If so, when should different language Wikisource pages be linked? Only when they have versions translated by Wikisource? This page probably requires additional information. --Yair rand (talk) 22:09, 28 January 2016 (UTC)[reply]

@Yair rand: Yes it definitely should be 2 different items ! More, it should be 3 : one for the work, one for the edition in English, one for the edition-translation in French.

The only obvious cases for an item linking to different Wikisources is templates, disambig pages and some general pages (like Portal:France (Q3247097)).

VIGNERON (talk) 14:19, 13 June 2016 (UTC)[reply]

Words as entity, morphology and lexical information from wiktionary[edit]

What about flood wikidata with subj? I need this data in RDF form an think about try get it through wikidata.

I mean register entites like "milk" a "word", a noun, lang English, and link it to entity "milky", a word, an adjective, as a base of them, an to word "milk" as a verb, and so on.

In languages like Russian much more morphological forms of words, and it is described in special tabled templates (see, for example, Declension section of молоко which can be imported like info boxes from Wikipedia.

What do you think?

--Nashev (talk) 09:07, 18 May 2016 (UTC)[reply]

Hi @Nashev:, I think this has been a very long and unfinished discussion for the folks of Wikidata:Wiktionary. I don't think a real solution has been accepted yet. Aubrey (talk) 09:14, 28 May 2016 (UTC)[reply]

Thanks! --Nashev (talk) 10:52, 1 June 2016 (UTC)[reply]

List of editions[edit]

There is a now a list at Wikidata:Wikisource/Lists/language editions. I added items for the languages lacking them.
--- Jura 13:33, 14 June 2016 (UTC)[reply]

Publisher[edit]

Maybe I'm mistaken, but it seems that publisher (P123) accepts only items: this for Wikisource is not good, as ancient texts do not have proper publishers often, not in the modern sense. Definitely, we couldn't define an item for them all. What can we do? Aubrey (talk) 20:49, 15 June 2016 (UTC)[reply]

@Aubrey: Why couldn't we define an item for them all? --Yair rand (talk) 20:51, 15 June 2016 (UTC)[reply]

Hi Yair rand: I'm not an expert of ancient book cataloging (it's a discipline on it's own), but my fear is that we wouldn't know, very often, if we are talking about the same publisher, because it's often written differently, or because it is not a publisher but a mere printer... I kinda agree with you that, if this is a problem in general, maybe for Wikisource tiny numbers is not, maybe we can sort these problems out. Or we can use a property printer... Aubrey (talk) 07:44, 16 June 2016 (UTC)[reply]

Badges: proposing a WS badge for digital documents[edit]

Tracked in Phabricator
Task T153186
Resolved

At the moment we have badges that can be applied for problematic/not proofread/proofread/validated which works well for our old works from scan, but do not work for digital only documents/works. I would like to propose that we request an "digital" badge for these works. If that is an acceptable proposal, we would need to put in a phabricator request, set some rules and identify a preferred colour. — billinghurst sDrewth 10:33, 5 December 2016 (UTC)[reply]

I support this idea, because it would be helpful for my project, which will deal with importing fulltexts from open access publications to Wikisource.--TIB-NOA (talk) 12:53, 8 December 2016 (UTC)[reply]

Comment I have created a phabricator ticket to have a fifth badge for the Wikisources. — billinghurst sDrewth 10:17, 14 December 2016 (UTC)[reply]

This has been coded and going through the code review. The detail reflected back is

called "digitaldocuments"
will be a silver icon in the badges, and will show as a silver circle in other projects interwikis

Presumably will go to the wild in the next week or so. — billinghurst sDrewth 11:04, 30 December 2016 (UTC)[reply]

Rolled out and available. — billinghurst sDrewth 11:50, 4 January 2017 (UTC)[reply]

Fixing significant issue of links to works, and merging of editions to works[edit]

I am tidying up from a well-meaning though problematic series of editing. A user has been adding Wikisource editions (multi-languages) to the works, and in certain cases moving them from editions, merging editions and works, etc. I have left the requisite messages for the editor, and to administrators. There are hundreds of edits, and it is painful to revert so many well-meant edits.

In reflection my biggest concern is that this has been going on for weeks, and no one has sufficiently noticed to mention it to the editor & & & that the system is unable to suitably identify this sort of misapplication. About the only sort of approach that I can see is watching for the addition of wikisource interwiki links to "literary works", "books", etc. as a flag for review. [Noting that enWS will link a disambiguating 'versions' page to a literary book.

Also noting that it is only works that have editions that have this sort of issue. Historic records/documents and the like (court cases, etc.) will only have the one version of the document and would link to the same place as the WP article. — billinghurst sDrewth 10:37, 6 December 2016 (UTC)[reply]

I gave up long time ago. This especially since my knowledge of non-scandinavian languages are very limited. Setting up a good edition-item could prevent users from merging, but when the pages are in languages I do not read or they contains almost no meta-data at all, it is a hopeless work. Preventing people from using Wikidata MAINLY and ONLY for interwiki is hard even on Wikipedia. These "games" that introduces a lot of strange merges doesn't make it easier. -- Innocent bystander (talk) 11:16, 6 December 2016 (UTC)[reply]

This is not adequate, but I can't really blame people for doing that. We should have a system which handle interwiki links to works with sublevel editions, i.e. adding an edition linked to WS should create an interwiki link to Wikipedia for the corresponding work. Regards, Yann (talk) 15:35, 20 December 2016 (UTC)[reply]

@Yann, billinghurst, Innocent bystander:

Tpt (talk • contribs • logs) is now working on an integrated system that would automate this linking between work items and editions. Don't know exactly when it will be available and working... --Hsarrazin (talk) 14:40, 3 May 2018 (UTC)[reply]

Proper differentiation between generic written work and specific publication of it[edit]

I often run into confusing items for a book, poem or other written work with statements which can only be true for specific editions, like translator (P655), editor (P98), publisher (P123), or illustrator (P110). I guess it is a merge of the Book item with specific edition item, and we should split them, or at least remove problematic statements. Any guidance on how to differentiate such items? --Jarekt (talk) 13:54, 18 March 2019 (UTC)[reply]

If you run across a data item that represents both a written work and also a specific edition of that work, then yes that data item should be split. It is worth noting, however, that sometimes translator (P655), editor (P98), and illustrator (P110) are relevant to written works also, as the creative output of such people is a work in and of itself that can have multiple editions. Beleg Tâl (talk) 23:17, 18 March 2019 (UTC)[reply]

Connecting Wikisource related pages on Commons to Wikidata[edit]

Cross-posting with Wikidata talk:WikiProject Books:

Commons has 779 thousand pages calling Book infobox template, mostly used by files used by Wikisource projects. We have over 2 thousand templates in c:Category:Book templates, which are mostly used for books that store each page in a separate file and great many PDF and DjVu files storing multiple pages. Very few of those books, are connected to Wikidata in any way: few sitelinks from Wikidata book items to Commons categories and very few Book templates with "wikidata" parameters linking them to Wikidata. Lately, I was working on rewriting Book template to use Lua code c:Module:Artwork, already used by Artwork and Photograph templates. The new code will be able to utilize data from Wikidata if "wikidata" parameter is provided to the template. I am not done testing it yet, but the new version can be accessed through Book/sandbox if anybody wants to try it. Also it would be great if there was some way to add "wikidata" parameters to Book templates and individual book files, as most wikisource entries are already connected. --Jarekt (talk) 20:28, 6 May 2019 (UTC)[reply]

proposal for a specific property for Author's writing language[edit]

Please come and discuss Wikidata:Property proposal/langue d'écriture for authors... Thanks for your help on this. --Hsarrazin (talk) 22:06, 6 May 2019 (UTC)[reply]

statement with scanned djvu/pdf: page for thumbnail[edit]

Please see Wikidata:Contact_the_development_team#Page_for_thumbnail. --- Jura 17:42, 10 December 2019 (UTC)[reply]

Greek WS: Monotonic and polytonic[edit]

Hello Wikidata users. I am an admin in the Greek WS and I want to work on the integration between Wikidata and Wikisource. Greek language is currently using the monotonic system of intonation, but that's not the same for the older texts (those we use to transcribe in WS), when the polytonic system was in use. The Greek WS community has decided to use the monotonic system in the page titles for convenience reasons as not many people use polytonic keyboards in their computers. But we refer to the original title of the work, in polytonic, in the headers. For example you can see the different writings on this page el:s:Δεν είνε... (polytonic system: Δὲν εἶνε...). So what about Wikidata? Should we use the original polytonic title of the work? That would be very useful if we wanted to use the data from WD for our WS headers. Thanks in advance!--Texniths (talk) 15:31, 19 July 2021 (UTC)[reply]

Not a language, so these are more thoughts than opinion. I always think, why not both in this space, so to me it is how do you achieve both nicely, especially as we often need to think and differentiate with both search and display. So which do you want as the primary? Use primary in label and secondary in aliases. title (P1476) has a language setting; is there a different language setting between polytonic and monotonic? If yes, then set each and set the primary as the preferred, and set the secondary as normal. Also look at the allowed qualifiers for P1476 and see how you can qualify each. — billinghurst sDrewth 00:38, 20 July 2021 (UTC)[reply]