Wikidata:Properties for deletion/Archive/2019

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Quais du polar writer ID (P5666)

This section was archived on a request by: --Pasleim (talk) 13:39, 1 January 2019 (UTC)

candidacy in election (P3602)

This section was archived on a request by: --Pasleim (talk) 13:39, 1 January 2019 (UTC)

Property:P5733

This section was archived on a request by: --Pasleim (talk) 13:39, 1 January 2019 (UTC)

Property:P3113

This section was archived on a request by: --Pasleim (talk) 13:39, 1 January 2019 (UTC)

Property:P3183

This section was archived on a request by: --Pasleim (talk) 13:10, 8 January 2019 (UTC)

Soundex (P3878)

This section was archived on a request by: --Pasleim (talk) 13:09, 8 January 2019 (UTC)

language of work or name (P407) and original language of film or TV show (P364)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus to merge, excluding usage on "television series" and "films" items. The property should be relabeled to reflect the tighter scope. ·addshore· ^{talk to me!} 11:36, 14 January 2019 (UTC)

---

Migration

Given that both properties have some external usage, how should the migration proceed? Should we create a timetable? (Announcing in WD:Status updates/Next is essential.) Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)

1. announce the migration in WD:Status updates/Next
2. copy over all values of "original language" to "language of work or name" but don't yet delete the "original language" statements
3. fix all templates
4. remove all "original language" statements and delete property

I can help with all steps including fixing the templates on other projects --Pasleim (talk) 20:44, 16 May 2017 (UTC)

Agree with this steps. Just to avoid error: we keep Property:P364 and delete Property:P407, correct? --ValterVB (talk) 16:50, 17 May 2017 (UTC)

@ValterVB: Nope, the opposite (discussed in the section above). Matěj Suchánek (talk) 14:40, 20 May 2017 (UTC)

@Pasleim: Your proposition will create multiple opposing statements in the same item: what happens if one item about an edition has one statement original language of film or TV show (P364) and one statement language of work or name (P407) ? With your scenario, you will just create 2 statements for language of work or name (P407) and one will be wrong. You can't separate the conversion and the deletion process

1. announce the migration in WD:Status updates/Next
2. launch the migration with the following analysis:

   if in one item the property "original language" is used:

   • convert it into "language of work or name" if no existing statement using "language of work or name" is found in the item
   • delete it otherwise

No need of fixing templates to perform that action. Templates can be fixed later without any lost if the correct work/edition model was used in WD. If someone created the edition item without the work item, no template fixing will solve the data lost because you will need to create the work item first. So the problem is not template fixing but incorrect data modeling in WD. Snipre (talk) 20:13, 28 May 2017 (UTC)

@Matěj Suchánek, Pasleim, ValterVB: Do you think we can proceed now for property merge ? Snipre (talk) 20:13, 28 May 2017 (UTC)

Your approach looks good to me, I think we are mostly ready. Matěj Suchánek (talk) 07:48, 2 June 2017 (UTC)

I added "(DEPRECATED)" mark to original language of film or TV show (P364) just now. --Liuxinyu970226 (talk) 04:39, 13 June 2017 (UTC)

• It seems the situation on books is a thoroughly confused and no basic statistics on it's status are available. See Wikidata talk:WikiProject Books. Before doing an merges, one should ensure an action plan is available to clean this up. Otherwise the merger just confuses the situation further. It appears that the scheme suggested at Wikidata:WikiProject Books can't be implemented in practice and a new approach may be needed, possibly with enhanced Wikibase features for relevant Wikidata items.
  --- Jura 10:50, 8 July 2017 (UTC)
  • If missing statistics are indeed bothering you, here you have it:
    • Items with P364 OR P407 statements: 1.337.876
    • Items with P364 AND P407 statements: 13.674
      • Items with identical P364 and P407 values: 12.171
        • biggest classes: album (Q482994): 3558, film (Q11424): 1922, periodical (Q1002697): 1842, book (Q571): 1087, creative work (Q17537576): 1006, media (Q340169): 534
      • Items with conflicting P364 and P407 values: 1.503
        • biggest classes: poem (Q5185279): 256, translation (Q7553): 243, book (Q571): 209, film (Q11424): 186, version, edition or translation (Q3331189): 155, literary work (Q7725634): 66, musical work (Q2188189): 46, game (Q11410): 43, work of art (Q838948): 36

    --Pasleim (talk) 17:32, 8 July 2017 (UTC)

  • The problem is not the number of items as such, but the relevancy of the language statement to the group of items. For films, things are clear, but might get messed up if you merge. For books, I don't think we have a clear vision what we want and how we get there. Merely stating some have P364 or P407, some sort of identifier about a random edition and sitelinks to a Wikipedia article about the work will make us loose information.
    --- Jura 17:45, 8 July 2017 (UTC)
• For books, the problem may be that many items for editions don't have an item for the work. For all values with "original language of work" (P364) such items would need to be created.
  --- Jura 14:49, 9 July 2017 (UTC)

  Jura convinced me that the situation around books should get more attention. I found many cases of items containing data about both work and the edition. (Well, they mostly seem to represent editions, eg. they have translator (P655) but they also contain data about the original work, eg. original language of film or TV show (P364) or instance of (P31). Perhaps a bot could help here.)

  Nevertheless, the property should be marked as deprecated, so that we have additional means of preventing arbitrary new usages. Matěj Suchánek (talk) 11:30, 10 July 2017 (UTC)

  I'm fine with doing this for books (as it's already done), but if we mark it as such for any item, people may start introducing incorrect data for other items. For books, I think a plan should be worked out how to split these items if people are actually interested in using the model proposed at its WikiProject. An alternative solution may be to develop a property datatype that could more easily hold information for various ISBN.
  --- Jura 05:44, 13 July 2017 (UTC)

> various ISBN

ISBN doesn't exist in 300BCE.

This would take far more time than current properties with multiple items and not necessary better than current 629+747+language 05:21, 24 July 2017 (UTC)

• So how do we handle collected translations, where there is an original language, but NOT an original work? In particular it is common for translators to publish the surviving plays of Pautus as a collection, or the surviving fragments of Cratinus, but these items never had an original "work" to come from. The modern translation(s) are collected as a volume that is a translation, but not of any particular work. --EncycloPetey (talk) 00:23, 23 July 2017 (UTC)

Use properties that don't assume any works: P2439 (P2439) 04:01, 24 July 2017 (UTC)

• It looks like we still lack a status and a clear plan for books. This is really problematic as it has a negative impact on other fields.
  --- Jura 07:12, 23 July 2017 (UTC)

  From my own experience, the biggest problems I run into involve dealing with translations of works, and dealing with collected works. Most of the decisions and properties have been made assuming (incorrectly) that (a) there will always be an "original work" from which a translation/edition will come, (b) that translations never have intermediary translations. They also fail to account for (c) editions of translations (a book that is a translation or contains translations, which book is then printed in editions), and (d) collections of works, which may exist in editions, and whose components are themselves translations and/or editions. --EncycloPetey (talk) 20:12, 23 July 2017 (UTC)

that's why several users voted to keep only most generic property (P2439 (P2439))

a, b - remove 364 (and possibly 407)

c - not relevant here, use edition or translation of (P629) and has edition or translation (P747)

d - use P629 and P747 and P2439 in any possible combination.

@EncycloPetey: any single example when many items with P629 and P747 and P2439 not able to represent information? d1g (talk) 04:21, 24 July 2017 (UTC)

I think the biggest challenge we face here is the casual dismissal of issues without meaningful discussion. D1gggg, I have to say I don't have much confidence in your suggestions, because it's clear from other edits that you don't know much about library data or the Wikidata properties you're using. You've added entirely the wrong property on more than one occasion, have altered project pages without consensus, and fail to sign your posts frequently. This shows unfamiliarity with the system. So, I will need to hear from more people with greater experience. Your responses above also show that you either do not understand the issues involved, or have not thought about the consequences. How will the data represent the "original language" in a situation like "c", which you claim is "not relevant here"? If we have editions of translations of works, that whatever system is retrieving the data to get the original language, it will have to know somehow to climb more than one step back to get that data. --EncycloPetey (talk) 14:17, 24 July 2017 (UTC)

@EncycloPetey: The proposed system isn't a problem for translated editions:

1) "there will always be an "original work" from which a translation/edition will come". The model used for book is FRBR which is quite widely used. If we decide to use this system, we have to create the corresponding structure so if for one item about a translation we don't have to create one item which will be the work one. But for that we have start the migration in order to avoid people to continue to use the wrong model.

2) The current system with 2 language properties doens't help you to model the case you mentioned:

• A is a transaltion edition in French of B
• B is a transaltion edition in German of C
• C is the first edition in the original language English

What is the original langauge for A ? German or English ?

That's why the current system is wrong, because it collects data from different items in one item instead of keeping data separetely in the correct items and to use link between items to extract the data you need.

We miss probably a property for items about translated editions which allow to identify which is the edition (in the original lnaguage or not) used as reference for the translation but this problem is not relevant for our present languages problem as the original langague property doesn't help you to solve the problem of intermediary translations.

For the two last points you mentioned there is a need for additional properties but at the end having 2 languages properties don't help you to solve the problem you mention. I think your points should be discuss with the project Wikidata:WikiProject Books but not here in that discussion unless you can show how 2 languages properties can help to solve the problems you mentioned. Snipre (talk) 18:44, 24 July 2017 (UTC)

@Snipre: I don't think you've understood some of the issues I raised:

1) There will NOT always be an "original work". And there is a real problem using translation/edition interchangeably. These two problems create most of the issues I have dealing with translations. Perhaps I need an actual example:

A is the "edition" item for the 4th edition of Swanwick's "Tragedies of Sophocles".

B is the "translation" data item for Swanwick's "Tragedies of Sophocles".

But B is a translation of C, D, E, F, G, H, & J, which are all separate data items for the "works" by Sophocles in the original ancient Greek.

So, is B a "work" because it has multiple editions? Or is it an "edition" because it is a translation of another author's works? And to return to the issue at hand: C, D, E, F, G, H, & J were are all originally written in ancient Greek, but as works they have no language at all. Only specific editions will be written or published in a particular language; even the first edition published or written. And any bot or tool that pulls data from this structure (by the current proposal) would run into difficulties, since, A and B are in English, and if A is an "edition" of B, how will it be indicated that English is not the original language when the data is extracted? We have a three-tiered hierarchy in these situations, but our model assumes that the hierarchy always has only two levels. --EncycloPetey (talk) 19:09, 24 July 2017 (UTC)

@EncycloPetey: What's "translation" data ? I think you are not able to describe your problem. Is it book, an eletronic file, a scroll or different parts of a scroll or even different parts from different scrolls ? Data doesn't mean any thing at that level. Snipre (talk) 19:19, 24 July 2017 (UTC)

@Snipre: You misunderstood. I did not say "translation data", I said "translation data item": A data item for the translation. The translation is a translation/work, and has four editions. Works are never physical objects, only specific editions of works have physical forms. The work itself can appear in any form: printed, electronic text file, audio recording, or performance. So it makes no sense to ask whether the translation is a book, file, scroll, etc. This is the fundamental problem in dealing with books that I keep trying to point out. Our labelling is fuzzy concerning the distinction between works, translation, editions, etc. --EncycloPetey (talk) 14:51, 25 July 2017 (UTC)

@EncycloPetey: So again what is B ? What is C ? Books ? Scroll ?

Then a book can't be a translation of several other books: it can contain translated parts from other books/documents but in that case, if the translated book is composed of several translations coming from different document, it is a new work compared to those documents, because the choice of the translations is a creative choice. I don't see any difficulty to treat your case, what is missing in your case is a link to other documents as inspired by (P941), based on (P144) or after a work by (P1877). A compilation of works is a new work. Snipre (talk) 20:12, 2 August 2017 (UTC)

@Snipre: RE: So again what is B ? What is C ? Books ? Scroll ? I say again: C is a work; it is not an instance of that work, but a work itself. It is not a scroll, nor a book, nor anything physical. To ask whether it is a book or scroll, etc. it to completely fail to understand what a work is. Only the editions of works can be a book, scroll, performance, etc. B is a translation of C, and this is where we run into specifics of the problem. If a translation is treated as an edition, then it must have specific edition data such as a year of publication, but if translations are treated like works, then the translation can exist in multiple editions (as it often does), but in that case it is not a book, scroll, etc. as works have no physical form. This is in fact why translations are troublesome to enter. If I have a translation that exists in different editions as a book, as a chapter, as the right-hand pages of a book, or as an audio file, then the data item for the translation cannot be specified to exist in any particular form. So, again, B is not a book or scroll or anything you could hold or point to; it is a translation. Likewise, C is not a physical object, but is the original work. I am sorry that you cannot understand the difficulty. --EncycloPetey (talk) 20:37, 4 August 2017 (UTC)

@EncycloPetey: The main problem is you don't used usual WD terminology with your "edition data item" or "work data item". We just use work item or edition item. In WD, an item is a collection of data, so when you say "edition data item", this gives something like "a collection of data about data of an edition". If you use your own definitions then don't be surprised to be not understandable.

And finally your problem is you don't do any difference between a book which is a translation of a work and a book which contains a translation of a work. In the second case the book contains more than the translation of the work so it can be considered only as translation of that work but is something different so you need another property to link the book to the different works it contains typically "has part". This solves the problem of antologies or other collections you mentioned in the first time.

Still stays the question of a new edition of a previous translation. In that case just take the FRBR model and consider that the edition definition corresponds to the manifestation definition of the FRBR model and we don't use the expression level of that model.

So example:

A is a work, B is the 1st edition in the original language, C is a translation of the 1st edition

In a logical scheme C is not a translaion of the work, but a translation of an edition in the original language. In your system you should create an additional item D which is the work of the translation and represents this system with:

D is a translation of A, C is a translation of B, B is an edition of A and C is an edition of D. And then you need a aditional property to link C and A. But this latter link is what most of people working with WD want to have.

This creates more complexity for a minimal added value. So in WD, if you have W is a work, X is the 1st edition of W in the original language, Y is a translation of X and Z is a reedition of Y, then X, Y, Z and edition of W and to create the link between X, Y, Z you need new properties like "translated from" (Y translated from X) and "reedition of" (Z is a reedition of Y).

In WD we choose to keep the system simple and to avoid to create to many abstract items like the ones you mentioned (translation defined as work).

So is the WD system clear for you ? Snipre (talk) 23:32, 7 August 2017 (UTC)

@Snipre: I'm sorry that you still don't understand. You're giving examples that have no application for the works I have to deal with. In your example, you say that "B (or X) is the 1st edition in the original language", but there lies one of the problems with the translations of classical literature: there is no 1st edition available anywhere. What we have are dozens of edited editions in the original language that have been reconstructed from medieval or Renaissance manuscripts, where these various editions and manuscripts all differ from each other. Sometimes, a translator will rely on a particular original language edition, but most often they will not. So there is no means of tying most translations to any specific edition printed in the original language. With that link in the chain broken, your entire proposal falls apart at the very first link. So, no the WD system is neither clear nor usable as you have described it, and that is why I have raised the issue of dealing with translations. --EncycloPetey (talk) 00:24, 8 August 2017 (UTC)

@EncycloPetey: I understood your problem: WD community doesn't model the data in order to fit your problem because your translation problem is not relevant for the community objectives. Do you understand that there are different ways to model data and you choose the one which fit the objectives you want to reach ? WD model currently doesn't take care about the sequence of the translations or if a translation was based on two or three originals which were partially recovered. ONCE AGAIN, WD doesn't care about the relations between the different editions or translations. perhaps later we will try to do solve the problem you mentioned and we will create new properties to be able to create that relations.

You don't understand that WD is a top level ontology and not a specialized ontology: we are not describing only books but animals, planets and comics. We want to reach a certain level of details but without having to deal with a heavy model with data relevant only to specialists.

Saying that "the WD system is neither clear nor usable as you have described it" just indicates you don't know the purposes of WD concerning bibliographical data: citation. So we choose an appropriate model for that. If you want to be useful for this community try to understand what are the objectives of WD, which are perhaps not the same like yours. And if you really want to propose a new model which is able to solve the problem you mentioned, don't spent time here: go to Wikidata:WikiProject Books, propose your model there and convince people to use it. Currently I am trying to apply the model described on that page and which was accepted by a relative majority of the WD community, so if you don't like it please go there and try to change it there. You will save your time and the time of other contributors. Snipre (talk) 01:19, 8 August 2017 (UTC)

{@Snipre: No, you didn't understand my problem, and as I pointed out, the model you propose above demonstrates strongly that you do not understand. Claiming that you understood all along, and claiming that I am the one who does not is simply avoiding the discussion by moving the goalposts and does not advance the discussion.

Right now, there is no model for translations at Wikidata:WikiProject Books which is part of the reason I have my problem and am trying to get it addressed and solved. But each time I state the problem, people (such as yourself) first claim there is no problem, then claim that the problem is easily solved, and finally admit that the problem exists and is not easily solved, but then claim instead that it is not important after all. Look back through your own comments above, and this same pattern of response occurs. If you cannot see a solution, that is fine, but please do not simply dismiss the issue on false pretense. --EncycloPetey (talk) 02:28, 8 August 2017 (UTC)

Danish works

Looks like @Fnielsen: is still focusing on adding original language of film or TV show (P364) even duplicate language of work or name (P407) values, I don't know what's wrong within Danish that is not OK to lose original language of film or TV show (P364). --Liuxinyu970226 (talk) 23:57, 26 July 2017 (UTC)

How would we describe Digte (Q23009890) (regardless of whether it is a work or a version, edition or translation (Q3331189)) without both original language of film or TV show (P364) and language of work or name (P407)? — Finn Årup Nielsen (fnielsen) (talk) 07:44, 27 July 2017 (UTC)

Should I copy suggestions from Snipre that is archived above? --Liuxinyu970226 (talk) 08:22, 27 July 2017 (UTC)

@Fnielsen: IMHO, I have an idea that describe that thing that without original language of film or TV show (P364) but with language of work or name (P407), and perhaps no splitting needed:

1. Allowing loop-back value of edition or translation of (P629) (i.e. adding Digte (Q23009890)edition or translation of (P629)Digte (Q23009890)) (note that country (P17) is such allowed in sovereign states items), with qualifiers:

a. (may only available after description re-designing, or maybe new datatype needed) start point (P1427)Danish (Q9035)

b. (ditto, :p) terminus (P559)English (Q1860)

c. Wikidata usage instructions (P2559)This work item cannot be splitted, as it has English contents that are in conjunction with original Danish contents, and per the will of author those contents are just included in one work

2. language of work or name (P407)Danish (Q9035) PRIORITY: Preferred rank

3. language of work or name (P407)English (Q1860) PRIORITY: Normal rank

I wish you to understand this alternate. --Liuxinyu970226 (talk) 02:04, 28 July 2017 (UTC)

We need to make sure that we don't loose any information. Until a clear plan is available, the best approach is to continue as of now, as said: no large scale changes should be made before.
--- Jura 07:08, 28 July 2017 (UTC)

@Snipre: It still needs your suggestion to resolve problems here. --Liuxinyu970226 (talk) 14:17, 4 August 2017 (UTC)

I added to Digte (Q23009890) all works it compromises by using has part(s) (P527). This allows now to exactly determine which parts of the collection have original language Danish and which parts are translations from English. --Pasleim (talk) 23:06, 4 August 2017 (UTC)

@Liuxinyu970226: Pasleim solved partially the problem: the final step is to delete the original language statements which just means nothing in that case. The English versions of the poem were translated from Danish or from Jutlandic dialect but not from Danish AND Jutlandic dialect. I am quite confident to think that in reality the original version of the poems is in Jutlandic dialect which were translated in Danish. But the current data structure doesn't provide any corretc information about the relation and just add confusion because we mix data: we mix data about the book with data about the poems. Each time you go further into the details you have to create item and not adding more and more informations in the general items. Just take the example of a village: you don't add data about the village in the country item where the village is located in. If the original language is different for each poem, the current statment current statement Original language = Danish/Jutlandic dialect is wrong because it is imprecise. That's why you shouldn't not mix data: the book is in English/Danish/Jutlandic dialect, that's a fact. Then for the original language we have to create an new item for the document which was used as original text or at least to provide the correct process: the poems author wrote them in one language and then translated them in another language, so be accurate and provide the correct sequence. And if you don't know the correct sequence don't write wrong information. Snipre (talk) 00:32, 8 August 2017 (UTC)

@Snipre: That approach only works when there is only one document which was used as original text, and when we know exactly which document that is. For translations of whole books written in the modern era, that is usually possible, but it is not possible for most older texts where all the available source texts were used, or where the "original" is either not identified or never existed in written form. Even for a well known work like Shakespeare's Romeo and Juliet, there is no single source text used for modern editions or translations. All modern English editions of the play are amalgamations of several early texts, and translators seldom identify which edition(s) they worked from. --EncycloPetey (talk) 01:13, 8 August 2017 (UTC)

@EncycloPetey: "That approach only works...when we know exactly which document that is." If you don't know exactly, don't write unsourced information. If an Italian translation of an older Greek document is not known has being translated from the original Greek document in Greek, don't write that the original version form of the Italian translation is Greek, because the translation was perhaps done from Latin. WD doesn't deal with some hypothetical possibilities but with facts. So if you don't know what was the original version used for a transaltion, don't add wrong information. Snipre (talk) 01:42, 8 August 2017 (UTC)

@Jura1: Unfortunately, we still have some editors making major changes to many entries, such as User:Pasleim. --EncycloPetey (talk) 23:42, 6 August 2017 (UTC)

@EncycloPetey: I'm cleaning up items which mix work with edition/translation. You can not abuse this discussion here to stop the whole Wikidata:WikiProject Books. --Pasleim (talk) 00:03, 7 August 2017 (UTC)

@Pasleim: The resolution of the problems of edition / translation are part of the ongoing discussion. No resolution has been adopted by consensus in the discussion. --EncycloPetey (talk) 00:07, 7 August 2017 (UTC)

The topic of this discussion is not if work items should be separated from edition/translation or how to discriminate an edition from a translation but how to merge original language of film or TV show (P364) into language of work or name (P407). As pointed out above by User:Matěj Suchánek, the problem are items constaining data both about work and edition/translation. A way has to be found how to separate these items. My constructive answer to this problem was to separate them manually... --Pasleim (talk) 01:22, 7 August 2017 (UTC)

The topic of discussion is the removal / merger of a property associated with books. Refusing to discuss points pertaining to that discussion and removal / merger is not helpful. --EncycloPetey (talk) 02:58, 7 August 2017 (UTC)

The topic of this discussion is the application of the model proposed on that page, so if you want to discuss again the model itself go there. Snipre (talk) 01:29, 8 August 2017 (UTC)

No model is identified for translations at the location you have indicated, only models for "editions" that are used as sources. Wikisource data housed here for translations does not fall into that category, yet we are trying to house a wealth of translation data here. One cannot apply a model that does not exist. --EncycloPetey (talk) 02:32, 8 August 2017 (UTC)

Have you seen Help:Sources#Books? Matěj Suchánek (talk) 08:56, 8 August 2017 (UTC)

@Matěj Suchánek: Yes, but it does not provide the help needed for the large category of items in which I usually work, nor does it provide a useful example for translations or editions of translations. --EncycloPetey (talk) 02:06, 9 August 2017 (UTC)

@EncycloPetey: Note that your undo actions are happened twice or three times, please do not violate 3RR, thx. --Liuxinyu970226 (talk) 03:45, 9 August 2017 (UTC)

@Liuxinyu970226: Please note that WD has no 3RR policy. In fact, several MW projects have no such rule. You are thinking of Wikipedia. --EncycloPetey (talk) 14:05, 9 August 2017 (UTC)

@EncycloPetey: So you can legally do a lot of edit war (Q764327) because you just want to keep one property? --Liuxinyu970226 (talk) 02:23, 10 August 2017 (UTC)

@Liuxinyu970226: Making comments ascribing invented motives and goals to other people will not solve anything, and can damage the community. Please do not make such comments. What property do you think I want to keep? It seems you haven't read any of the above discussion, have you? The issue at hand is that, for some kinds of "books" and especially for their translations, we have no clearly defined model to work from, and so are trying to determine how best to proceed. Discussion above has indicated that no large-scale action be taken yet, because we're still deciding what action to take. Despite the ongoing discussion, and stated desire to hold off on enacting change, some editors are going ahead and making large-scale changes on their own without waiting for the discussion to conclude. But I am instead waiting to enact changes, and am trying to get this discussion to resolve some of the long-standing issues tied into this property. If you read all of the other discussion I've posted here, then that is what you'll find is going on. --EncycloPetey (talk) 03:18, 10 August 2017 (UTC)

@EncycloPetey:

What property do you think I want to keep?

original language of film or TV show (P364)

It seems you haven't read any of the above discussion, have you?

I read the entire PFD page carefully, that's the reason that I assume that you're edit-waring, as your edit comments like "consensus was to merge but NOT make changes yet" no longer make sense for me to still AGF

Discussion above has indicated that no large-scale action be taken yet, because we're still deciding what action to take.

There's already consensus to drop P364 even for that Danish user, your "aganist" is too late.

If you read all of the other discussion I've posted here, then that is what you'll find is going on.

By watching out the Special:CentralAuth/EncycloPetey, the 2 wikis that you are mostly editing are English Wiktionary and Wikisource, so can we concentrate on what's wrong within both English projects if one day we unfortunatelly deleted original language of film or TV show (P364), instead of discussing some random "large-scale changes" which you even did? --Liuxinyu970226 (talk) 03:39, 10 August 2017 (UTC)

@Liuxinyu970226: We are getting way off topic, so I'll be brief: You're wrong on almost every point or assumption you state above, including which projects I've edited mostly. (I've edited heavily on wikispecies, for example, but that project doesn't seem to appear in the data when I follow the link.) So, instead of trying to pick apart other editors, let's stick to discussing the issue at hand, please? --EncycloPetey (talk) 03:50, 10 August 2017 (UTC)

Let me clarify some things concerning "Digte 1906" Digte (Q23009890) as there seems to be some misunderstandings. I really like that particular book as a test bed for Wikidata modeling as this collection of poems is quite complex to model in any database: Some poems were originally written in Danish and first appeared in a novel and as such appear in the Digte 1906. Two poems where written in the Danish dialect "Jutlandic" they were first published in a novel that was part of a triology, the three parts of the triology were collected to one novel which was termed "Kongens Fald" (in Wikidata, we have a work item The Fall of the King (Q1758876) and some edition items Q27655001 Kongens Fald, 1901 edition (Q34605018) and a edition with translation Kungens fall, 1906 (Q34607398)). This work contains body text in Danish, two poems in German, a bit of Latin text (if I recall correctly) as well as the two Jutlandic dialect poems. The two dialect poems are also published in the "Digte 1906" (perhaps with slight variation). The two dialect poems were put to music by Carl Nielsen and published in "Strofiske Sange Strofische Gesänge", a publication that contained the text in both Danish (including Jutlandic) and German (I believe a scanned copy is available somewhere on the Internet, but I cannot find it). Other poems in "Digte 1906" are translations from English to Danish. It is the three Whitman poems that Johannes V. Jensen translated. What further complicates matter is that "Digte 1906" which was actually called "Digte" was later extended a bit, then later extended yet again, extended and edited. The latest version was quite different for the 1906 version. Whether these new publications are new works or just new editions I really haven't come to any decision about. Through the 1900s the Digte 1906 gained a status of a classic so that the original "Digte 1906" where published as a new edition without the additions from the earlier versions! I do not think that "Digte 1906" has been translated in its entirety, but some individual poems exist in various translations. Sorry for this long and complicated explanation, but I invite interested Wikidata modellers to consider the works of Johannes V. Jensen, because the bibliography is so complicated, e.g., newspaper articles were turned into a poem and published in "Digte 1906", body text in a novel was turned (typoset) into a poem, etc. — Finn Årup Nielsen (fnielsen) (talk) 10:15, 8 August 2017 (UTC)

Thanks for this clarifications. My proposal how to deal with this case:

• Digte (Q23009890) only contains texts in Danish and Jutlandig. So those should be the only values of language of work or name (P407). No other language statements or qualifiers should be added.
• Since Digte 1906 is a collection of works, use has part(s) (P527) to link to all poems resp. translated poems it contains.
• Create for each translated poem an own item as well as for each original poem. On the item about the translated poem use language of work or name (P407) to indicate the language of the translation; on the item about the orignal poem use language of work or name (P407) to indicate the original language. The translated poem can be linked with the original poem with edition or translation of (P629).
• published in (P1433) is used to show in which works a poem was published. This property can have many values. No distinction is made between the work in which the poem was first published and subsequent works.
• If a poem was put to music, create an own item for the song and use based on (P144) to link the song with the poem.
• If a work gets slightly extended, one has to decide if it's just a new edition or if it's a new work. No hard rule is applicable here. For a new edition, use edition or translation of (P629) to link to the original version. If you decide it is a new work, you can use instead based on (P144). --Pasleim (talk) 14:14, 8 August 2017 (UTC)

But what should be done if a translated poem has multiple editions? I'm seeking clarification regarding you point above:

• "Create for each translated poem an own item as well as for each original poem. On the item about the translated poem use language of work or name (P407) to indicate the language of the translation; on the item about the orignal poem use language of work or name (P407) to indicate the original language. The translated poem can be linked with the original poem with edition or translation of (P629)."

Are we going to use edition or translation of (P629) on the translation and then edition or translation of (P629) again on the edition of the translation, so that we have an "edition or translation of an edition or translation"? And for each item in such a situation, what should be used for instance of (P31)? Current practice in this regard leaves much to be desired. And with regard to the issue of "original language", it means that we end up with a situation in which the "original" language is not one tier above the edition, but two steps back. And I have situations analogous to Digte in which I fear we would have three steps. How will those who are making use of the data going to know the "original" language when the information may be one, two, or three data items away instead of a consistent number? Without a specific property to identify the original language, what can we do to clarify that information for users of WD? --EncycloPetey (talk) 03:28, 10 August 2017 (UTC)

@EncycloPetey: Your comments here gave me those panoramas: We must discuss Park Geun-hye (Q138048) in conjunction with Kim Jong-un (Q56226) when talking about his policy (Q1156854) (really?), we must discuss John Cena (Q44437) in conjunction with Roman Reigns (Q275971) (2nd really?), we must discuss your heart in conjunction with automated external defibrillator (Q787407) (biggest REALLY?) mass edits can be happened in any conditions, and are those hurting you and you must "undo, revert, restore..."? e.g. Zhuyifei1999 made a large scale of recommendations to tool maintainers of our new Wikimedia Toolforge (Q36500248), so in your logic those recommendations must also be reverted? Anything is already big-rock-defined here. No more harassments to my Echo notifications, thx. --Liuxinyu970226 (talk) 15:05, 14 August 2017 (UTC)

@Liuxinyu970226: I do not understand how your examples or discussion pertains to the topic being discussed. Your response does not address or solve any issue under consideration, and only distracts from the core problem. I ask again to the community: How will those who are making use of the data know the "original" language when the information is not on the data item, and that information may be one, two, or three data items away (instead of a consistent number), and has no property or qualifier to identify the original language? Without a specific marker to identify the original language, what can we do to clarify that information for users of WD? --EncycloPetey (talk) 16:52, 14 August 2017 (UTC)

If you have a chain of 4 works/editions, how would you do it with the current system? We only have properties "language of work", "language of original work" but no property "language of original work of original work" and "language of original work of original work of original work". --Pasleim (talk) 17:54, 14 August 2017 (UTC)

Movies (or possibly Japanese animes)

Some users had questions about films and their dubbed versions. Will the FRBR system apply to them? Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)

This discussion is related to a more global concept than the FRBR system: data duplication have to be avoided and data have to be saved in the more related item. These principles are important for bots, queries and automatic data extraction like the one for infoboxes in order to have general rules allowing codes reusability. We shouldn't not have a special way to store data for book and another for movies. WD is one database and we have to have general rules independent of the topics. Snipre (talk) 19:53, 13 May 2017 (UTC)

• I demonstrated the FRBR system for movies on Via col vento (Q29478369) and Via col vento (Q29478260). Till now, no member of the WikiProject Movie could show me how to express the data I added to this items without the FRBR system. I understand this as a silent agreement to the FRBR system. --Pasleim (talk) 20:44, 16 May 2017 (UTC)

If items are made for dubbing, this is the way suggested by WikiProject Movies. Please see the previous discussion on WikiProject Movies about this and the subsequent discussion at Wikidata:Bot_requests#Merge_of_.7B.7Bp.7C407.7D.7D_with_.7B.7Bp.7C364.7D.7D. This does not solve all other language issues for movies.

Further, you might have noticed at Wikidata talk:WikiProject Books, that the project didn't manage to implement the suggested scheme there either. Maybe it's either not suitable for Wikidata or users can't apply it. Maybe an action plan for WikiProject Books is needed before doing any merges on books as well. --- Jura 10:44, 8 July 2017 (UTC)

Sorry, but I can't still see any problem. This series of edits and this discussion implies to me that there is a consensus regarding items for dubbed edition items. Please explain in detail to me as a non-involved person where you see problem. Matěj Suchánek (talk) 16:06, 9 July 2017 (UTC)

We don't create such items in general. It seems that even the person who first sought help on how to create one isn't actually interested, or, at least, isn't able to create any. I don't have any real explanation for this inability. Maybe you can help us? Is this a specific contribution pattern that should be investigated?
In general, the core of the information on films is held on the main item. This includes the original language and one or several other languages. In general, there can be several dubbings and subtitlings of films in one language, but they still share core elements of the film. Similarly, there is now the possibility to link several items about posters and scripts of the film.
The idea seems to have been to adopt a solution that is proposed for books, but it appears it isn't working there either, so maybe it's better to consider the outcome of this as potentially desirable for textual work, but currently lacking a practical migration plan. If you see one for books, I'd be interested.
--- Jura 17:07, 9 July 2017 (UTC)

We – who? Me either?

the person who first sought help – @Suruena: could you comment?

the core of the information on films is held on the main item – we aren't going to delete it, are we?

there can be several dubbings and subtitlings of films in one language – imagine having all of them stored in a single item...

it isn't working there either – where not?

Finally, do you have an example of item which would suffer from a significant (if any) data loss during the migration? Anyway, it sounds to me that you don't like the whole work-edition distinction, which was, however, approved in 2013. Matěj Suchánek (talk) 17:48, 9 July 2017 (UTC)

I think any item that currently has its original work language determined will suffer. Maybe the migration plan for books can help sort this out, but looking at what Wikidata:WikiProject Books does and how they implemented it, it's just .. maybe you should read what active participants there write about it. In any case, you are actually deleting information, if there is no clear plan where the same information will be held afterwards.
--- Jura 18:03, 9 July 2017 (UTC)

@Jura1: Can you give me a movie example which splitting is not possible? --Liuxinyu970226 (talk) 02:19, 10 July 2017 (UTC)

Looking only at items that use P31=film, there are currently about 200,000 of these with information about 470,000 different language versions. Some maybe up to 60 different ones. Obviously, we could created 270,000 new items, but these wouldn't be easy to maintain nor use by Wikipedia with the current tools. The confusion we currently have for books may spread further.
--- Jura 05:44, 13 July 2017 (UTC)

Could you please give a source for your numbers? So far I was assuming there are 189,000 movies with language information [2] holding information about 203,000 different language versions [3]. Those 11,000 items holding information about multiple languages [4] are typical movies produced in multiple languages e.g. Monty Python and the Holy Grail (Q25043). However, those do not suffer from the migration. --Pasleim (talk) 06:35, 13 July 2017 (UTC)

I may found an example that not suitable for splitting: Detective Conan (Q185143) (

Konggaru Starry K. Erne Mogilevich Santer AldNon^Ucallinme? Thibaut120094 Shikeishu C933103 Sight Contamination -Zest Vulphere Sakretsu Jean-Frédéric Tris T7 ^{TT me}
Wallacegromit1 Jeanjung212 Bagas Chrisara ミラP CrystallineLeMonde
Nicereddy Shisma (talk) MatrosMonk Bwk24 Mickn RPI2026F1 Yirba Eniehack Wiccio IntensionalLogican

Notified participants of WikiProject Anime and Manga for more help on it)

To the best of my knowledge, most of non-Japanese articles that linked by this item, are describing both Japanese and their dub works (*not only describing dubs in their own language, but also other lingua franca), so is it fairy to split it to 60 items? While it's technically possible, there will mostly have opposite voice from at least ja, ko and zhwiki as P407 value would be polluted. --Liuxinyu970226 (talk) 22:57, 14 July 2017 (UTC)

The statements on Q185143#P674 have up to four voice actor (P725) qualifier. How can you tell if that are voice actors of the original work or of a dubbing? How do you plan to add publisher, publishing date, original network, website and translator of the dubbings? With qualifiers some of the data could be stored. But qualifiers on qualifiers do not exist so you will never be able to add all information if you don't split the item. A Wikipedia article describing both the original and the dub work can stay on the current item. --Pasleim (talk) 20:15, 17 July 2017 (UTC)

Hello, Spanish Wikipedia user here. I'm not sure about the politics on different Wikipedias, I think the only thing I know is that in the English Wikipedia you use to translate the main article name to it's translation, in the case of Japanese animes and mangas (Blue Exorcist, The Qwaser of Stigmata, Attack on Titan, Future Diary, ...) but anything else. Talking about Wikipedia in Spanish, I'm truly not concerned about everything, because, for example, we keep the original Japanese titles on manga and anime articles, and in character names too, but there are cases in which, for some reason, the original name is replaced by a translated one (who the heck is Elsa Scarlet?), and that is defended by many users, some of them also participants of WikiProject Anime and Manga. I don't know if there will be a poll for using original names, but if so I'll be so happy, I've succeeded deleting that article for my memory, but every time I see things like Elsa Scarlet I got a mindblow and my body gets possessed. Ok, enough jokes, coming back to reality, there's also a lot of politics on Spanish Wikipedia concerning translations and original titles, for example, we use to keep the original name in its foreign language in movies, but for some reason we translate the title of books, so it's very confusing. --Erne Mogilevich (talk) 19:40, 20 July 2017 (UTC)

 Comment Still I don't see serious difference between movies and books. We possibly need widget to create "prepare 30 editions please" and to fill "voice actor" "translator" details. This difficulty isn't unique to movies, but for popular books too (or anything somehow global). d1g (talk) 01:20, 23 July 2017 (UTC)  Comment In contrast to this, films and books without separation in 30 item would be cluttered with qualifiers:

• "applies to country"
• "applies to language"

Which is way worse than to use separate items with direct statements. d1g (talk) 01:22, 23 July 2017 (UTC)

• The current solution for films works, includes information about 500,000 language versions and can accommodate additional elements (as illustrated with dubbings, film posters etc.). Unfortunately, we still don't have a plan for books (see section above). We should probably just close the section about movies and, if ever a solution is found for books, rename the property to limit it to films.
  --- Jura 07:12, 23 July 2017 (UTC)

 Oppose, see what Snipe said carefully " in order to have general rules allowing codes reusability. We shouldn't not have a special way to store data for book and another for movies. WD is one database and we have to have general rules independent of the topics".

Language of creative works applies to many concepts, far beyond "books and/or movies"

It would be unproductive to create sets of specific properties for every of domain to perform same tasks.

@Jura1: please provide an example how movie would be different from book? Why separate items would be wrong for movies? This question was raised several times, please address it. d1g (talk) 04:08, 24 July 2017 (UTC)

The current solution for films works, but the one for books doesn't.

Maybe you can provide a set of working samples for books. This was raised several times, but we haven't seen any actual work, plan or status.

You mention elsewhere that we should follow some other website that would only have one for films, but they actually have three and they explicitly don't try to use their scheme. I don't quite see how the current approach doesn't allow you to map the properties to these three. If there are specific queries you have problems with, try Wikidata:Request a query.
--- Jura 07:08, 28 July 2017 (UTC)

@Jura1:

1. The current solution for films works

   under which signal system? NTSC (Q185796)? PAL (Q105973)? SECAM (Q223765)? digital video recorder (Q865042)? Network Video Recorder (Q426040)? ...

2. but we haven't seen any actual work, plan or status.

   Huh? There's no entity books in your neighborhood?

3. but they actually have three and they explicitly don't try to use their scheme

   This could be intractable as I expanded this section to include ACG stuffs, but then your answer of "How can you tell if that are voice actors of the original work or of a dubbing?" from Pasleim is still missing, which could give me this daydream: the Marvel has actors from Cameroon from Tonga from Saint Helena... and they use Catalan use Faronese use Pitkern use Guarani... so they (the Marvel staffs) can re-use actors for all dubs of Captain America (Q190679) in all languages even some have ≤10,000 native users.

--Liuxinyu970226 (talk) 12:35, 28 July 2017 (UTC)

Also @Jura1: if you keep vote is having the reason of N/A (Q21686005), then my answer is that I suggest to merge this item to uncoded language (Q22283016) (ISO 639-3 mis). --Liuxinyu970226 (talk) 00:29, 8 August 2017 (UTC)

Specific movie example

How about considering A Fistful of Dollars (Q76479) as an example? The cast spoke Italian, German, and English, but the movie was filmed entirely without sound. The sound was dubbed on later. The movie was released in Italy first (in Italian), then in Germany, Spain, and other European countries, but did not have a US release until several years later. The US delay resulted from copyright issues because the Italian film was an adaptation of the Japanese samurai film Yojimbo (Q20475). So, what was the "original language" here? Do we need to have separate data items for every different language dub? Or how do we indicate that the movie exists in multiple language dubs? And do any of the languages get precedence or priority over others? --EncycloPetey (talk) 17:06, 14 August 2017 (UTC)

Every different language dub can get its own item, see Wikidata talk:WikiProject Movies/Archive 1#Dubbings. A list of properties you can use with dubbings you find on Wikidata:WikiProject Movies/Properties#Synchronisation. --Pasleim (talk) 17:51, 14 August 2017 (UTC)

• Tricky question, still I think the current set of properties works generally fine for films. Maybe we could replace "work" with "film" in the label, once written works are sorted out. This would avoid creating additional properties, just to match some "schema".
  --- Jura 17:56, 14 August 2017 (UTC)

This still leaves the question of whether the main data item will have a language value. In this example, should the item for the work have no language at all, since every version of the movie was a dub? And if it has no language, then how do we mark the data item to keep editors from adding specific languages to the work instead of the data items for the individual dubs? --EncycloPetey (talk) 00:09, 15 August 2017 (UTC)

For Le Bal (Q1637024), I came to the conclusion that an item with "no dialogue" might be the most suitable one. Maybe a similar one could be made for Q76479.
--- Jura 06:41, 15 August 2017 (UTC)

...except that every released copy has dialogue. The problem is more general than just the one movie, since it is not always possible to pick out an "original" or "first" release of a film or publication. Even then, the "first" edition of any work is an edition and will be on a separate data item from the work itself. So, should we omit language properties from every work? and put them only on the editions / dubs? --EncycloPetey (talk) 13:44, 15 August 2017 (UTC)

I don't think you can use the same item as on Q1637024, but it should be possible make an item that describes it. As you mention, not all are straigthforward, but with the current two properties, I think we should be able to describe films. This without creating additional ones, just follow schema.org. How is the situation for books evolving?
--- Jura 07:37, 17 August 2017 (UTC)

@Jura1: The two language properties schema.org uses for movies are http://schema.org/inLanguage and https://schema.org/subtitleLanguage. So is your suggestion to turn language of work or name (P407) into subtitleLanguage or what do you mean by "just follow schema.org"? --Pasleim (talk) 08:39, 17 August 2017 (UTC)

@Jura1: Please either elaborate what you meant with "just follow schema.org" or cross your statement out. --Pasleim (talk) 21:21, 25 August 2017 (UTC)

@EncycloPetey: Instead of omitting the language property for A Fistful of Dollars (Q76479), I would use the special value novalue since it's also an information that the movie was filmed without sound. --Pasleim (talk) 08:39, 17 August 2017 (UTC)

Moving forward and alternative proposal

@Jura1, Matěj Suchánek, Snipre, Liuxinyu970226, EncycloPetey, Fnielsen: Consensus was reached to merge original language of film or TV show (P364) and language of work or name (P407) and decision was made that original language of film or TV show (P364) will be deleted. Many subsequent discussions were held. However, some objections were raised without providing any concrete arguments ("movies need to language properties"), in some other discussions problems were brought up which will not be new with merging but already exist now, e.g. how to deal with translations that have intermediary translations. The only unresolved problem is how to deal with items containing data about both work and edition. Based on that I would like to propose the following procedure for merging:

• move P364 statement to P407 if no P407 statement is on the item
• delete P364 statement if it is equal to the P407 statement
• if a book item has P364 and P407 statements but their values differ, check manually if the items contains data about both work and edition and if necessary create new items to follow the guidelines on Wikidata:WikiProject Books.

The last step does not have to be considered for movies since no movie item has conflicting P364 and P407 values [5]. Before merging starts, it will be announced on WD:Status updates/Next and after merging, help will be provided to Wikipedia and sister projects to adapt their templates. --Pasleim (talk) 20:34, 26 September 2017 (UTC)

As before, this proposal doesn't deal with the problem of books that are/contain translations for which no "original" work item can exist. G. M. Cookson's Four Plays of Aeschylus Four Plays of Aeschylus (Q26710829) is not a work, it is a translation (which Wikidata combines with edition). But no original "work" item of those four plays ever existed. So we have no possibility of indicating derivation.

Also as before, no provision exists for parallel texts, where both an edition of a work and a translation of a work are included in the same volume.

This doesn't look so much like an alternative proposal as merely a restatement of the same proposal with more specific details. --EncycloPetey (talk) 22:04, 26 September 2017 (UTC)

This propsal does deal with these problems. It states that such items will be checked manually and edited according to the guidelines on Wikidata:WikiProject Books. In previous proposals this manual part was missing and it was suggested to do everyting programmatically. --Pasleim (talk) 22:30, 26 September 2017 (UTC)

Fine for me. Just a last question: what's about the label of language of work or name (P407) ? No need of solving that question now but I think that changing "language of a work or name" to "language" will simplify the problem. Snipre (talk) 22:50, 26 September 2017 (UTC)

@Pasleim: No, this proposal doesn't deal with those problems, and your last claim is not what the proposal says. The "new" proposal only makes provision for creating new items to follow the guidelines on Wikidata:WikiProject Books. It does not deal with existing items. Further, WikiProject Books does not currently have guidelines in place to deal with either of the situations I have described. Hand-waving and passing the buck are not solutions. I see no concrete solution that has yet been proposed for cases such as those I have raised, nor for similar situations. --EncycloPetey (talk) 00:00, 27 September 2017 (UTC)

@EncycloPetey: Wikidata:WikiProject Books provides principle and not a solution for every special case. Instead of claiming that nobody is giving the solution you need please try to show by applying the principle of work/edition that this system is not able to answer the cases you raised.

And I already provided some solutions for at least the first of your case: a compilation of original texts or translated texts is de facto a work. Four Plays of Aeschylus (Q26710829) is an edition and an additional item for work has to be created even if only one edition of this book exists. The item defined as work of Four Plays of Aeschylus (Q26710829) is a work composed of 4 other works and the characteristic allowing to consider the compilation of the 4 texts as work is the choice of selecting the 4 texts and to create a new text composed of 4 others.

Then for the second case, I don't see a problem: as you mentioned, wikidata considers translation and edition in the same manner. So in your case what prevent you to define the item containing an original text and its translation as an edition/translation with two languages, the original language and the translation language ? It would be a problem if WD was considering edition and translation as different types of documents (but even in that case we could create a new class) but this not the case.

The only problem we have to solve is to be able to link the different translations/editions by additional properties in order to provide more informations in case of translations about what was the original text (not the work but the edition) used as source for the translation. Snipre (talk) 01:01, 27 September 2017 (UTC)

I'm sorry, but what? You are not using the standard terminology, I assume, because what you are saying makes no sense. Specifically, you are not using "work" in any sense that I understand it to mean. How can a "work" that consists of translations, consist of other works? Translations are never works; they are editions by Wikidata standards. So you are effectively stating that a work can consist of editions, which makes no logical sense.

With regard to the second situation, we are considering the original text and the translation to be co-equal, which cannot ever be the case. The original text has an author (and possibly an editor), but the translation has a translator. One of the languages is that of the original text, while the other language is that of the translation text. We are talking about throwing all that information together without any means for the user to disentangle it.

One point in all this is that we should be treating editions and translations as separate types of documents, and many of the difficulties of dealing with translations derive from our failure to distinguish between them. But that is another discussion.

But back to the original issue in the first case: If a translator publishes a single translation on its own, that's clearly a translation/edition by our current standards. You are suggesting that if a translator publishes two translations together which were not originally published together in the combination in the original language, then it's a work. And if a translator publishes three translations together, it's also a work, unless those three form a trilogy in the original language and we have a data item for that, in which case it's a translation/edition. And I suppose then that if a poem or short story collection is translated in full, then the translated volume is an edition that consists of edition/translations. But if the translator plays editor and includes only three-quarters of the original stories, then the volume is now a work that consists of works, or perhaps edition/translations? Would this same logic apply to translations of parts of works? Because that is incredibly common. All the Japanese translations of Tom Brown's School Days (each done independently) omit huge sections of text and whole chapters. Nearly all English translations of Euclid's Elements of Geometry omit several of the original 13 books, and some include all "15" with apocrypha. The Christian Bible does not have regular contents in its various translations, since there are differing views of what constitutes canon, apocrypha, pseudepigrapha, etc. Does each translation that includes a differing set of books constitute a different "work" then? The logic of your reasoning escapes me. --EncycloPetey (talk) 02:42, 27 September 2017 (UTC)

@EncycloPetey: Just be constructive once because until now you just critize everything without proposing something:

First what is your work definition ? Because I provide an explanation about why I consider an book composed of existing texts or translations is a work: the selection of texts is a work. What is your problem with that definition ? When somebody says "I want to publish the best texts of an author", if sombody cuts a original text, he is performing a creation. Even if the choice is based on obvious criteria. It seems you have a very limited vision of what is creation, so please just give your definition of work first.

Then about case, you lose nothing as you always have the the work item to identify the original data and to infer then the corresponding case:

* work item:

** language: X

** author: XX

* edition item:

** language: X, Y

** author: XX

** translator: ZZ

What kind of information is lost ? And by the way, what is your solution to model this case in WD ? Snipre (talk) 02:16, 1 October 2017 (UTC)

If selecting texts is a creation, and the result is a work, then why isn't translation also a creation, resulting in a work? Your definition doesn't explain that. --EncycloPetey (talk) 02:36, 1 October 2017 (UTC)

@EncycloPetey: Translations could be considered as work, this is a choice we can do, the question is to know if we need to add more complexy and for which gain. I just created a first list of cases and I can describe quite complex cases for translated texts without need of work definition for translations. So if we don't need to have work for translation, no need to add it. We are creating a model and the purpose of a model is not the reach the perfection but to be useful for the application we want to use.

And by the way you didn't provide any definition from your side. Do you want to be constructive or do you want to stay at the objections level ? Snipre (talk) 13:24, 1 October 2017 (UTC)

edition or translation of (P629): somevalue, qualifier language of work or name (P407)? And I don't understand this: P364 has been "language of original work". But you also state: ... for which no "original" work item can exist. So usage of P364 looks wrong, doesn't it? Matěj Suchánek (talk) 07:30, 27 September 2017 (UTC)

No original work in that form exists, but there is a translation because the components have original works from which they are translated. That is, the four plays were originally in ancient Greek, and the translations are in English, or French, or whatever, but there is not a "work" that consists of those four plays published in the original language used as the translation source, rather the individual plays are works that were all translated. So the original language was Greek, but the published language is English, and by all standards presented in the proposal, we would simply mark the translations as "English" with no indication whatsoever that they were ever written in any language but English, and with no indication whatsoever that they are translations rther than works originating in English. That is positively misleading the users. --EncycloPetey (talk) 12:58, 27 September 2017 (UTC)

On Four Plays of Aeschylus (Q26710829) you state that it is an English [6] work [7] having multiple parts [8]. On the parts items you state that these are English translations [9]. You also provide for each translation a link to the original work item [10]. On the original work items you state that these are works [11] in Ancient Greek [12]. Now we will use P407 instead of P364 in the last linked edit. What is here misleading the users? --Pasleim (talk) 13:55, 27 September 2017 (UTC)

Your links do not support what you claim. Where did I say that Four Plays of Aeschylus (Q26710829) was a "work"? If you feel we must do this incrementally, with diffs and details going over every word, then let's start there. Where did I say it was a "work"? --EncycloPetey (talk) 01:15, 28 September 2017 (UTC)

In September 2016 when you added that instance of (P31)=book (Q571), book (Q571) was a direct subclass of work (Q386724). Today, book (Q571) is a subclass of intellectual work (Q15621286) which is subclass of work (Q386724). Since subclass of (P279) is a transitive property, stating that Four Plays of Aeschylus is a instance of a book, it is implicitly also an instance of a work. --Pasleim (talk) 05:45, 28 September 2017 (UTC)

But, since this data item is for the copy at Wikisource, is that a correct value to use for "instance"? I used "book" because I could not find a more suitable value to use, but surely a particular copy cannot be a "work". (Please stay with me, and don't get sidetracked.) --EncycloPetey (talk) 13:54, 28 September 2017 (UTC)

I'm not an expert on Wikisource and there are would be project pages with more knowledgeable users on Wikisource linking. But the question is whether s:en:Four Plays of Aeschylus (Cookson) describes the work by Cookson or a particular copy of the work. If it describes the work the item is fine, if it describes a particular copy we need two items. One item for the work, i.e. the compilation of the four translations, and one item for the copy. --Pasleim (talk) 21:25, 28 September 2017 (UTC)

No, there are no project pages with more information, and that's part of the problem. This issue has never been worked through to its logical conclusion, nor has it ever been written up. Please don't waver on this discussion now.

But as for the four English translations by Cookson: aren't they also "works" that will have multiple editions? Couldn't Cookson's translation of The Suppliants appear in more than one published edition? And so, in addition to having two data items for Cookson's book Four Plays (one for the book as a "work", and one for the edition housed at Wikisource), wouldn't we also have to have two data items for each of the four translations of plays included in the volume (one for the translation as a "work", and one for the specific edition of that translation that was published)? --EncycloPetey (talk) 02:20, 29 September 2017 (UTC)

A translation is a translation and not a work. This does not exclude that a translation can not appear in more than one edition. Each edition gets its own item.

Imagine I told you a translations are also works, would it change something on how we should delete P364? --Pasleim (talk) 09:13, 29 September 2017 (UTC)

You're getting sidetracked here; please stay with me. Each publication of a work housed at Wikisource necessitates that each publication has a different data item. We are treating editions and translations as the same thing, yes? And Cookson's translation of Prometheus Unbound is a translation, yes, but there are multiple editions of that translation because it has been published by different editors in different volumes. We can't re-use the same data item every time the Cookson translation appears in another volume, so the translation must have multiple editions. We therefore must have a master data item indicating the information about the translation as a "work", and then data items for each edition of the translation. --EncycloPetey (talk) 15:53, 30 September 2017 (UTC)

I almost agree with you, I just don't call the translation a "work" but maybe it would be easier if I do so. If a translation gets published by different editors then we need indeed an item for the translation and items for each edition. --Pasleim (talk) 18:26, 30 September 2017 (UTC)

I agree that the terminology is inadequate for describing this situation. But continuing: What happens then when a translation has two (or more) different textual revisions, each of which has been published in more than one location? We have this issue with Browning's translation of Prometheus Bound and Shelley's translation of Cyclops' for example. As far as I can tell, we would have a data item for the original play, one for the translation as a "work", one data item for each "revision" of that translation as a "work", and one data item for each "edition" of each revision of that translation. --EncycloPetey (talk) 19:31, 30 September 2017 (UTC)

Yes that is the idea. Sounds fairly complicated but it is the only way to give proper attribution to each editor and to show each publication date and place. And if Wikisource hosts multiple edition of a work/translation/revision there are even software restrictions which forces us to follow this data model. --Pasleim (talk) 20:03, 30 September 2017 (UTC)

Complicated, but we're not quite done yet, though we can soon move on to the next step in the discussion. Before we go there, I must also point out that many translators translate using a specific edition of the original text, such as the Dindorf edition of a Greek text. So we can have an edition of a revision of a translation of an edition of a Greek publication of a work. The actual Wikisource edition must then have six data items in place, all of which are suitably interlinked. And someone seeking the original language would have to blindly navigate through six layers of data items to find what that original language was of the translated work. --EncycloPetey (talk) 20:44, 30 September 2017 (UTC)

It is not a blind navigation. We have edition or translation of (P629) to link to the next upper layer and instance of (P31) to tell the type of the layer. --Pasleim (talk) 00:48, 1 October 2017 (UTC)

It is blind. In the situation we've constructed, there are six layers of "edition/translation of" to sift through, but in the end, a person would have to follow a link into "has part/part of" and follow it back to find the original language, since the "work" in question would be marked as "English" for its language, since the book as a whole was not composed originally in Greek. A user would have to poke around every possible link or "edition/translation of" and "has part" or "part of" and might find the original language somewhere within a maze of interconnected data items. If they stopped too soon, or didn't know ahead of time which direction to follow for the links, they would mistakenly end up with the wrong language. --EncycloPetey (talk) 01:11, 1 October 2017 (UTC)

Well if we go from a particular edition up to the work, there should never be more than one edition or translation of (P629) claim and if an item uses "has part/part of" it is possible that multiple original languages exist. If you have usability concerns, you should consider that seen over all books cases like Four Plays of Aeschylus (Q26710829) are rather rare. Moreover, the target audience of Wikidata are not users visiting wikidata.org but Wikipedia/Wikisource which include data from Wikidata and external pages retrieving data through the API or query service. For those, the current situation means that they have to poke around every possible statement and might find the original language somewhere within a maze of unstructured data. The original language can be found sometimes as qualifier on language of work or name (P407), sometimes as qualifier on original language of film or TV show (P364), sometimes as qualifier on edition or translation of (P629), sometimes as an own statement, or sometimes one has to follow the edition or translation of (P629) link. On the original work item, sometimes original language of film or TV show (P364) is used, sometimes language of work or name (P407), sometimes both. If there is a translation of a translation of a work, P364 is anyway illdefined. If we could do the migration, we could write a function for the Lua module on Wikipedia to retrieve the original language and external pages could add a while-loop to their code and we would finally have a distinct data structure that works in all situations. --Pasleim (talk) 02:39, 1 October 2017 (UTC)

@Pasleim, EncycloPetey: I created a lis of cases here and I was trying to model the cases acording to the work/edition principle. I didn't find big issue until now, but we have to provide a more detailed example for some cases. The main problem is never the language but work definition so I think all the discussion above is out of the box concerning the issue of merging 2 properties about languages. I proposed to EncycloPetey to provide a defined case where the merge of the mentioned properties is a real problem. For the general discussion about the work/edition model, better discuss about that in the talk page of Wikibooks project.

@EncycloPetey: I propose you to generate some cases based on what you mentioned like I did in my cases list and then we can discuss based on a generic case (and not on a real case where you are the only one knowing the details) the solution.

@Pasleim: You mentioned that translations should have work items. If I agree in the absolute vision of a perfect classification, I ask you: where do you find an advantage of this more complex system compared to the one where translations are considered as edition ? The best will be to model the cases from my list with the addition of work for translations and see what are the results. Snipre (talk) 13:42, 1 October 2017 (UTC)

@Snipre: I commented on the talk page of your list as the answer is irrelevant for the migration discussion here. --Pasleim (talk) 14:08, 1 October 2017 (UTC)

@Pasleim: RE: "seen over all books cases like Four Plays of Aeschylus (Q26710829) are rather rare". Actually they aren't. If you like I can show you how almost any translated book becomes just as complicated. For example, The Time Machine: An Invention (Q627333) by H. G. Wells (Q42511) has no single authoritative edition to be the standard. Rather, there is the serialized version of the novel, and at least two book formats for the novel with significantly differing text and even different chapter numbers. That's just the major English editions. When one of these gets translated, we have to identify whcih English edition was the one translated, because it's not always one particular translation. The choice of edition affects the number of chapters, and this is hugely important for Wikisource, where editors like to be able to place the translated text side-by-side with the "original". To do this requires a data item for each chapter, both in the original language and in the translation, which means there must be data items for each chapter as part of the "work" and data items for each chapter of the "edition" and data items for each chapter of the "translation". And if the translation has gone through multiple editions (it usually has), then we end up with the same morass of data items that we had for the Greek plays.

Whether you consider Oliver Twist by Charles Dickens or L'Homme qui rit by Victor Hugo, you get the same complexity of hundreds of interconnected data items. Most of these works were serialized to begin with, later collecting them together as a novel, and sometimes then published over multiple volumes or parts even before the process of translation, and then having differing numbers of volumes in the translation. --EncycloPetey (talk) 15:30, 1 October 2017 (UTC)

There is no consensus on the notability of Wikisource chapters on Wikidata.

Whether we need a hundred items to model all editions and translation of Oliver Twist does not depend at all on whether we have one, two or three language properties. --Pasleim (talk) 15:59, 1 October 2017 (UTC)

You've lost that train of thought we built up. What happens on the French, German, etc. editions of translations when we have so many data items and so many links to manage? How would an average user find the original language of a work in such a situation, when presented with a labyrinthine set of data items? Notability is unsettled, but that includes also those volumes where the book consists entirely of individual works by separate authors, which do seem to be accepted now. And chapters of translated books will exist on multiple WS projects, albeit in different languages. For those that will have translations on other WS, the balance is likely to tip in favor of inclusion. --EncycloPetey (talk) 01:37, 3 October 2017 (UTC)

@EncycloPetey: And simply, can you please explain that what's your qualifier usage of original language of film or TV show (P364)? That so-called usage is simply confused to me, and even the talk page of that property also disencourage it. --Liuxinyu970226 (talk) 10:59, 3 October 2017 (UTC)

I don't understand your question. I can't tell whether you meant to politely ask a question (which I do not understand) or meant to be insulting (I can't tell if that was intentional). --EncycloPetey (talk) 13:55, 3 October 2017 (UTC)

@EncycloPetey: Well

1. In Antigonae (Q24790761), what means the qualifier "original language of film or TV show (P364)Ancient Greek (Q35497)" within language of work or name (P407)German (Q188)?
2. In those 4 items Choephori (Q22972166), Agamemnon (Q22810156), Eumenides (Q23012889) and The Persians (Q23308144), what means the qualifier "original language of film or TV show (P364)Ancient Greek (Q35497)" within language of work or name (P407)English (Q1860)?

--Liuxinyu970226 (talk) 06:58, 4 October 2017 (UTC)

That is a work-around to indicate the language of the source text from which the translation was made. We currently have no standard to identify the source text (or edition), nor the means to identify the language of the text from which a translation was made. This is a significant point, as a translation is not made from a "work" but from a specific text or texts, and neither is a translation always made from the "original" but may be done from a translation. We have no preferred means to indicate any of this information. --EncycloPetey (talk) 12:17, 4 October 2017 (UTC)

And even once we have a method for indicating source text and source language (for the immediate source, not the ultimate one), there are challenges. I was a translation of Euripides that was made from Dindorf's edition. However, I have no access to a copy of Dindorf's edition, so I have insufficient information to create the various data items that would be needed, such as which volumes contain which plays. Further, Dindorf's edition of the plays would have its language marked as both German and ancient Greek, since the play text is in English, but all prefatory materials and internal notes are in German. Having such a work as the source of the English translation leaves the question open of whether the English copy was translated from a Greek text or from a German text. Wikidata currently has no way at all to indicate which was the source language. --EncycloPetey (talk) 13:22, 4 October 2017 (UTC)

Thank you for going ahead with this. I suggest including this to Tech News as well because templates can break when the property gets deleted.

Note that when you include subclasses of film (Q11424) to the query after the third point, it does return some results. Not many, though. Matěj Suchánek (talk) 07:30, 27 September 2017 (UTC)

We can include it to Tech News but I promise that I will fix the templates listed on Property talk:P364. Thus, there should be no broken templates. --Pasleim (talk) 21:25, 28 September 2017 (UTC)

Just  Delete as quickly as possible, all of those "keep" comments are daydream, and are illegal that try to defend their edit wars. --Liuxinyu970226 (talk) 05:28, 1 October 2017 (UTC)

•  Comment I don't think much progress seems to have been made for movies. If we proceed with the suggested merger, this would just lead to make it indeterminable. There were some suggestions that we should follow schema.org for these, but as schema has three different ones for languages, I don't think this is would be any progress from the stable solution we have now for movies. Going forward, I'd keep excluding films from the merger.
  As for books, I think it would be good to formulate a clear plan so users are able to determine what a language statement would mean on such items without loading dozens of items and attempting to check these for completeness. I can understand that some approach might seems theoretically desirable and work well in a single editor environment, but this doesn't necessarily help users with Wikidata problems.
  --- Jura 06:40, 1 October 2017 (UTC)

What kind of progress do you expect ? The principle is given: use of model based on FRBR system which is the only system which allows you to add data like voices or the publication date of each dubbed version. Until now you never provided any explanation how I can add the names of the voices like the ones available in this section of WP:fr and in this section of WP:es for The Hunt for Red October (Q507994). So your system is not applicable but this is our responsability to find a solution ? Perhaps it is time to wake up the Project Movies to define an action plan: the merge of the 2 languages properties is not a problem, this is a situation which reveals the problem.

So I propose you a very simple deal: let us working on the book cases and from your side start to work on the movie cases. And please provide me an example how I can add the dubbed voices for the case of The Hunt for Red October (Q507994): I hope you won't consider this as a theoretical problem. Snipre (talk) 21:40, 1 October 2017 (UTC)

@Jura1: Per above, the de facto most big problem with your P364 is how to handle actors of dubs, please just answer it, otherwise my delete vote is still okay. --Liuxinyu970226 (talk) 23:23, 4 October 2017 (UTC)

 Comment Snipre: Thanks for giving me credit for the Wikiproject Movies structure, but it's mostly undeserved even though I made efforts that it was spelled out, properly applied and even key indicator defined. As you notice, it's fairly clean, complete and even noise can be removed without much problem. It might be too ambitious, but I'd expect a similar working approach for books. The existing movie structure should work for your The Hunt for Red October (Q507994) sample without problems. Once done, we can then work together to make sure it appears in the Spanish infobox (French wont work, as I don't think they use Wikidata for films). Alternatively, if available, you could do one for Catalan (Catalan Wikipedia also uses Wikidata in film infoboxes). If you have problems with the properties for movies, please ask at the WikiProject. Please help us keep away purely disruptive or non-contributing efforts.
--- Jura 09:38, 8 October 2017 (UTC)

Although you claim that the WikiProject Movies structure is fairly clean and complete, some major information are missing. For example, why are two or even three language properties necesseary to describe a movie? --Pasleim (talk) 17:07, 9 October 2017 (UTC)

Some people favoring merging advocated following schema.org which has three different scheme's for movies. Personally, I don't. We should we do with a property "subtitle language"?
--- Jura 08:38, 11 November 2017 (UTC)

@Jura1: So we agree that the current data structure described in Wikiproject Movies is the reference. So according to this data structure, the original movie requires only one language property and all dubbed movies have to be described in a different item using again one unique language property. There is no need of having 2 or more language properties in the same item so changing P364 by P407 will have no impact on items which follows the data structure described in the Wikiproject. Only the items which are not using the data structure required by the Wikiproject can be impacted but that's not our problem, that's the problem of the Wikiproject Movies which allows different data structures or didn't plan until now any data curation.

So do we agree that

1) there is no need of 2 different language properties (based on the data structure of Wikiproject Movies) ?

2) we can deprecate P364 starting now (after changing the data structure of Wikiproject Movies) ?

3) we have to define a strategy to convert P364 by P407:

• for every item defined as instance of (P31):film (Q11424), short film (Q24862), television film (Q506240), anthology film (Q336144) and having one property original language of film or TV show (P364) ==> change original language of film or TV show (P364) by language of work or name (P407)
• for every item defined as instance of (P31):film (Q11424), short film (Q24862), television film (Q506240), anthology film (Q336144) and having one property original language of film or TV show (P364) and one or several language of work or name (P407) ==> this item is not following the data structure of Wikiproject Movies and has to be curated
• for every item defined as instance of (P31):dubbing of film (Q26204053) and having one property original language of film or TV show (P364) and one or several language of work or name (P407) this item is not following the data structure of Wikiproject Movies and original language of film or TV show (P364) can be deleted.
• for every item defined as instance of (P31):dubbing of film (Q26204053) has to be linked to the original movie using edition or translation of (P629) so it is possible to extract the original language by using the language of work or name (P407) of the original movie.

All other cases are not following the data structure of Wikiproject and have to be curated. Snipre (talk) 11:50, 20 October 2017 (UTC)

@Jura1: Please answer the above questions by Snipre and me. If you don't do so, I will soon start with the conversion outlined above, we still have to respect that a majority of users voted for merging P364 with P407. --Pasleim (talk) 08:29, 10 November 2017 (UTC)

Also the question that about NTSC/PAL/SECAM issue that I asked more than 3 times here. --Liuxinyu970226 (talk) 12:49, 10 November 2017 (UTC)

Pasleim: I don't really see how Snipre's proposal will help him achieve what he planned to do (sort out the books part, add the dubbed versions of "Red October") and why instead WikiProject movies gets told it's their responsibility to fix it for him. I don't think this is particularly respectful from participants in the discussion who don't actually contribute to Wikidata otherwise in the field. If we continue this way, it might just end up as an endless soap. Accordingly, I have asked this discussion to be closed as stale. Obviously, I could try to help you sort out the books part, but this doesn't need a deletion discussion nor is a deletion discussion a suitable forum There does seem to be consensus that books need help, but unfortunately it's not clear how this should be done. Merely voting isn't going to build a plan. Given the countless participants of the books projects, it's unclear why people of other projects should do that. Pasleim, I do appreciate your efforts to get some sense into this, but we probably both focus on more important things. Maybe Matěj Suchánek wants to address the SECAM question, I avoid doing that as he asked me not to do in another context.
--- Jura 08:38, 11 November 2017 (UTC)

I'm not going to address any made up terms like "SECAM". The result of initial discussion, which I closed in May, is clear: to merge two properties. Since this cannot be done by software (like with items), we need to migrate one to another. I gave users opportunity to share what issues we need to know about before the migration but now I see I shouldn't have.

So yes, this discussion is stale and can be closed. The community had already decided anyway. Matěj Suchánek (talk) 15:37, 11 November 2017 (UTC)

The problem is that it failed to develop an implementation plan. So we are just where we were 6 months ago. Despite a general idea, it's not something that can be acted upon. Maybe we should try to develop better support for WikiProject Books going forward. Users seems to be confused by conflicting approaches and chat in forums.
--- Jura 16:09, 11 November 2017 (UTC)

Closure of stale thread

As this hasn't really gotten ahead, I think we should leave it to the relevant WikiProjects to address possible needs for improvement. --- Jura 08:38, 11 November 2017 (UTC)

 Oppose The roadmap is only stucked by you, so peoples are discussing how you could be softhearted. --Liuxinyu970226 (talk) 09:16, 12 November 2017 (UTC)

PS: Let's simply count the votes above:

1. Arguments to keep (6, 30%): Arbnos, Jklamo, Finn Årup Nielsen (fnielsen), ValterVB, Jura, and EncycloPetey;
2. Arguments to delete (13, 65%): Pasleim, Kareyac, ArthurPSmith, Tubezlob, 50.53.1.33, Thierry Caro, Fralambert, billinghurst, Strakhov, Liuxinyu970226 (don't surprise, I already decided to migrate), Snipre, Queryzo, d1g
3. Arguments neutral or no idea (1, 5%): Eran

Maybe it's worth to encourage those 30% to change their brain on P364. --Liuxinyu970226 (talk) 11:51, 12 November 2017 (UTC)

• Actually, we were trying to figure out a plan, not bean count. As nothing useful came up, we can close the discussion and leave it to the projects to sort out.
  --- Jura 13:10, 22 November 2017 (UTC)

FINAL VOTE: Suggested closure reasons

1. Close as "No consensus to do actual delete/Consensus to keep"

 Oppose Such "consensus to keep" overwritten are violating the MediaWiki Code of Conduct (Q45161493), and if Jura1's opinion is this, it can even be subject to one reason that I request fireing their Administrator right. --Liuxinyu970226 (talk) 04:36, 30 December 2017 (UTC)

What the hell are you talking about Liuxinyu970226? Multichill (talk) 20:35, 5 February 2018 (UTC)

2. Close as "Consensus to remove all usages like P794 below, then delete"

 Neutral Will ask @Deryck Chan: separately and privately for the possibility of this opinion. --Liuxinyu970226 (talk) 04:38, 30 December 2017 (UTC)

@Liuxinyu970226: The P794 experience showed that this is possible, as long as people agree on what use cases migrate where. Deryck Chan (talk) 11:38, 24 January 2018 (UTC)

 Support only reasonable solution --Pasleim (talk) 18:16, 27 March 2018 (UTC)

 Support First choice. There are only 487 uses of original language of film or TV show (P364) where an item presents different values for original language of film or TV show (P364) and language of work or name (P407). Most external uses of original language of film or TV show (P364) are for film infoboxes and it seems that none of them use original language of film or TV show (P364) and language of work or name (P407) in the same infobox. We could simply copy all existing statements of original language of film or TV show (P364) to language of work or name (P407), switch all film infoboxes over to language of work or name (P407), then deprecate and delete original language of film or TV show (P364). Deryck Chan (talk) 10:53, 11 January 2019 (UTC)

3. Close as "remove all except films' usages"

 Support --Liuxinyu970226 (talk) 14:34, 20 December 2017 (UTC)

 Support --Pasleim (talk) 13:41, 21 December 2017 (UTC)

 Oppose even after months no reason is provided why the language of a movie should be described in a different way than for examples songs, websites or books --Pasleim (talk) 18:16, 27 March 2018 (UTC)

 Support and P794 has to be relabelled as movie original language to avoid any other use of this property. Snipre (talk) 21:30, 28 December 2017 (UTC)

 Support and change label per Snipre ArthurPSmith (talk) 21:52, 5 February 2018 (UTC)

 Support and change label - seems like a consensus solution to me. - PKM (talk) 19:15, 31 July 2018 (UTC)

 Weak support Second choice. Deryck Chan (talk) 10:53, 11 January 2019 (UTC)

4. Discussion

Since when did we resolve matters by voting, rather than reaching consensus through discussion? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:32, 5 February 2018 (UTC)

Since this request has been open for a year. It is not uncommon to have a vote if some discussion gets stale. Also, the arguments of the discussion are being repeated in the vote (suggested closure reasons). Sjoerd de Bruin (talk) 13:48, 6 February 2018 (UTC)

@Pigsonthewing: I must point that the discussion related to P364 is opened for a whole year, A WHOLE YEAR, how can a consensus not be happened within a whole year? --Liuxinyu970226 (talk) 04:34, 7 February 2018 (UTC)

There are only 487 items where the same item presents different values of original language of film or TV show (P364) and language of work or name (P407):

SELECT ?item ?itemLabel ?worklang ?worklangLabel ?origlang ?origlangLabel
WHERE 
{
  ?item wdt:P407 ?worklang .
  ?item wdt:P364 ?origlang .
  FILTER (?worklang != ?origlang) .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
ORDER BY ASC(?itemLabel)

Try it!

--Deryck Chan (talk) 10:53, 11 January 2019 (UTC)

Also, "remove all except films usages" is relatively undisruptive because there are only 608 250 Update: I've now excluded film series as well, which brings down the total non-film/TV items, mainly songs, using original language of film or TV show (P364). But as I had stated above, other than those 487 items in the query above (which I think are an issue of data quality rather than refinement), I don't see original language of film or TV show (P364) and language of work or name (P407) having different purposes at this point.

SELECT (COUNT(?item) AS ?count)
WHERE 
{
  ?item wdt:P364 ?origlang .
  FILTER NOT EXISTS {?item wdt:P31/wdt:P279*  wd:Q2431196 }.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
ORDER BY ASC(?itemLabel)

Try it!

--Deryck Chan (talk) 17:41, 11 January 2019 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

This section was archived on a request by: --Pasleim (talk) 14:40, 17 January 2019 (UTC)

download URL (P4945)

This section was archived on a request by: --Pasleim (talk) 14:40, 17 January 2019 (UTC)

P3188 (P3188)

This section was archived on a request by: --Pasleim (talk) 14:40, 17 January 2019 (UTC)

P969 (P969) (street address)

This section was archived on a request by: --Pasleim (talk) 14:40, 17 January 2019 (UTC)

P1112 (P1112) + Pokémon index (P1685)

• @Pasleim: I've just found a technical problem which I didn't notice until you closed the discussion (and I apologize for not pointing it out earlier). Pokémon index (P1685) has String datatype while P1112 (P1112) has Quantity datatype. That means merging from P1685 to P1112 is technically impossible (because some entries have non-numerical characters in their Pokemon Browser codes); but merging in the other direction is feasible. There are no known external uses of these properties except in sandboxes. Would it be acceptable if I run my script in reverse and merge all uses of P1112 to P1685 instead? Deryck Chan (talk) 18:52, 18 January 2019 (UTC)
  • for me this is okay. --Pasleim (talk) 20:29, 18 January 2019 (UTC)

This section was archived on a request by: --Pasleim (talk) 10:19, 24 January 2019 (UTC)

Soccerway player ID (P2369)

This section was archived on a request by: --Pasleim (talk) 09:22, 1 March 2019 (UTC)

Commons category (P373)

This section was archived on a request by: --Pasleim (talk) 09:23, 1 March 2019 (UTC)

Property:P1773

This section was archived on a request by: --Pasleim (talk) 09:27, 1 March 2019 (UTC)

participant in (P1344)

This section was archived on a request by: --Pasleim (talk) 09:28, 1 March 2019 (UTC)

NSZL name authority ID (P3133)

This section was archived on a request by: --Pasleim (talk) 09:31, 1 March 2019 (UTC)

charter URL (P6378)

This section was archived on a request by: --Pasleim (talk) 09:38, 1 March 2019 (UTC)

female form of label (P2521)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept no consensus for deletion and no alternative available yet. Multichill (talk) 20:40, 27 May 2019 (UTC))

---

female form of label (P2521): (delete | history | links | entity usage | logs | discussion)

Given that we now have Lexemes, there's no good reason to store this information in the item namespace ChristianKl ❪✉❫ 12:59, 14 January 2019 (UTC)

•  Oppose Until an alternative is proposed (which should be a requirement when proposing a deletion). As far as I know, this property is currently being used at least in the French Wikipedia, so it would be a good idea to start with understanding the rational of the property creation. Going in that direction, maybe @Jura1: could elaborate on that in order to move forward. Andreasm ^{háblame / just talk to me} 13:58, 15 January 2019 (UTC)

 Delete The frwiki usage should be modified, they should query Lexemes. --2409:8902:9301:B6A9:5CB3:E6FD:4195:E1F7 04:48, 16 January 2019 (UTC)

•  Oppose Eventually maybe but there's no replacement now. Data access to lexemes is not possible yet. The same applies to demonym (P1549). Matěj Suchánek (talk) 08:41, 16 January 2019 (UTC)
•  Delete but On hold until the access to Lexemes is ready. Cheers, VIGNERON (talk) 11:59, 21 January 2019 (UTC)
• {{o}} for now per Andreasmperu and Matěj Suchánek. (vote withdrawn given alternatives below) --Marsupium (talk) 01:58, 22 January 2019 (UTC), 10:47, 25 March 2019 (UTC)
• There is also male form of label (P3321). Somehow lexeme contributors haven't found a way yet to link them in a structured way. --- Jura 13:00, 26 January 2019 (UTC)

Tracked in Phabricator
Task T212843

• On hold until we migrate all the data to Lexemes and transfer existing external uses to Lexemes, then  Support deprecation. Deryck Chan (talk) 19:38, 26 January 2019 (UTC)
•  Keep Used extensively also in Catalan Wikipedia for infoboxes deppending on sex or gender (P21). I.e. Nicole Kidman is an actress, not an actor, and this is basic for languages with gender flexion. Previously, you need to have access to Lexemes and move all data. --Vriullop (talk) 08:03, 29 January 2019 (UTC)
•  note @ChristianKl: I've mentioned this discussion in phab:T212843 as an urgent case of making Lexeme data accessible by other WMF wikis. Please head over there to discuss how Lexeme access should be implemented. Deryck Chan (talk) 14:05, 1 February 2019 (UTC)
•  Keep Until now I saw no technical support on querying Lexemes, and even one day available, this property should also be used elsewhere if one wiki can't support it due to Parsoid problems. --218.68.229.42 02:12, 2 February 2019 (UTC)
•  Keep this is a very useful and important property for my native Polish and I don't think there is a good alternative in place at the moment Powerek38 (talk) 21:28, 24 February 2019 (UTC)
• On hold until all data is migrated to lexemes and actually used on all Wikipedias. Robin van der Vliet (talk) (contribs) 14:00, 2 March 2019 (UTC)
•  Keep I agree with the comments above about the lack of availability regarding lexemas. Besides, this a useful property for Galician language, as it let us distinguish between sexes in the infoboxes.Maria zaos (talk) 16:07, 6 March 2019 (UTC)
•  Keep; It's often used in gl.wiki. --Estevoaei (talk) 21:53, 24 March 2019 (UTC)
•  Keep The property is being used in a large number of articles, it can not be eliminated until the templates that use it are modified. Bye, --Elisardojm (talk) 23:00, 24 March 2019 (UTC)
•  Delete

  (1) This property needlessly inscribes a specific gender model into the (relatively upper) ontology, which

  (a) raises point-of-view concerns and

  (b) introduces an imbalance (e.g., in terms of modeling permissions) between concepts’ genders (values of properties) as items and labels’ genders as implicit in this and other properties, allowing editors to create and use new gender items (e.g., non-binary (Q48270)), but not the label forms associated with such genders.

  (2) To the extent that gender (‘real-world’ gender, not grammatical gender;

  sexus

  , not

  genus

  , in somewhat dated-seeming linguistic terms) is, or should be, linguistically marked, the imbalance in occurrences of the properties female form of label (P2521) and male form of label (P3321), respectively, suggests that the conceptualization of these properties or the structures built around them (e.g., infobox-generating code on Wikipedias) at best only leads to a reinforcement of questionable views of male gender being the default, female gender being an aberration in supposed need of explicit mention (and other genders supposedly being a phenomenon below the bar of notability or acceptability). Such views not being universally accepted raises doubts as to whether the current property model behooves a universal ontology.

  Conclusion: This property (along with male form of label (P3321)) should be deleted and could, while a lexeme-based solution is not yet within reach, be replaced by a new property “gendered form of label” (or perhaps, more generally, “qualified label”), using qualifiers referring to gender items (rather than property-implicit senses of gender). See below for what this might look like this when used for actor (Q33999) as an example.

  However, note external use.

  ―BlaueBlüte (talk) 05:56, 11 March 2019 (UTC)

•  Keep This property is largely used in cawiki infoboxex. Until lexemes were well upload and access to lexemes being available from LUA module, it can not be delete. It's curious to observe that the hardest positions in favor to delete it comes from people with a short number of editions. Amadalvarez (talk) 09:39, 25 March 2019 (UTC)
•  Keep Same. --Davidpar (talk) 20:51, 25 March 2019 (UTC)
•  Wait for Lexemes to mature, then  Delete. NMaia (talk) 04:58, 31 March 2019 (UTC)
•  Keep This is an excellent solution which is understood by all and has been put to good use. It works, allowing infoboxes to be flexible and relevant. --FocalPoint (talk) 09:29, 26 April 2019 (UTC)
•  Keep for now used in several wikipedias. Long term, who knows. Not there yet. With regard to "gendered form of label"-proposal ...feel everyone free to propose that one. Only after getting created that property and copying the data from P2521&P3321 to that new one... propose the deletion of these two. IMHO I don't see much improvement in lumping together "male", "female" and "non-binary" labels in every language ...in the same property. And, after all, if lexemes are gonna be the long-term solution Wikidata probably doesn't need another temporal "patch". strakhov (talk) 18:11, 5 May 2019 (UTC)
•  Keep : the human gender identity binary division is another problem. Here we just need to say how we deignate a grammatical gender (which is language specific and does not necessarily match the male/female genetic classification even if it also has exceptions in many species, unrelated to the human gender identity which is a sociologic problem). We still need to refer to groups that in some languages may be considered distinct, but not in others (notably for activities or nobility titles). At least these languages (not all) create a binary division and it is common. Note that this also applies to biological species : they may have a single unified gender (masculine or feminine or neutral) independantly of the fact individuals are male or female (e.g. in French : "une fouine" is feminine for both males and females, and "un serpent" is masculine for both males and females; other species have dictinct names, "une truie" if the female domestic pork, "un cochon" or "un porc" is the male domestic pork, but sometimes "porc" is used for any male or female individual ; most domestic animals have gender-based names, and the biological gender is also an important classification useful in agriculture because it is selective for the production).

  You may argue that "masculine"/"feminine" would go to the classification of lexems (instead of items) but this will only apply to the grammatical form of names (which is independant of the group classification of items which need to refer to social gender groups, or to biological genders for species). The grammatical genders of lexems will still very frequently not match the social or biological genders of classes of items, for which we need appropriate properties to create distinct classes of items, even their translated item label is identical in some language but not all; each item in Wikidata will refer to lexems only by language-specific pairing, there will be no 1-to-1 relation between items and lexems and in fact almost very item in Wikidata for classes will have multiple associated lexems with different grammatical properties. And even some instance items, like human individuals, will have multiple lexems to refer to them in the same specific language, including contextual grammatical forms (like genitives or abbreviated names, or different usage names: official, formal, civil, artist names, nicknames, surnames given by others, or names changed/augmented during their life becaue of mariages or given honor or change of nationality or residence, or variants used specifically only in specific regions or situations...). To make things even more complex, the grammatical gender may change depending if this is a different plural form (e.g. in French: "un amour" is grammatically masculine in singular independantly of the person gender, "des amours" is grammatically feminine in plural also independantly of the gender of persons even if they are only boys/men!)

  I say keep "masculine and feminine" (grammatically and socially for persons) as classes in Wikidata, but at least create another property or classes for male/female biological gender distinctions. And of course add separately the grammatical gender distinctions and forms in lexems. Verdy p (talk) 15:30, 14 May 2019 (UTC)

1.  Keep: useful. Nomen ad hoc (talk) 14:40, 21 May 2019 (UTC).

Proposed replacements

“gendered form of label”

This example (using item actor (Q33999)) would equally serve as an illustration of a possible “qualified label” property, which would comprise “gendered form of label” as a special case based on the qualifiers used.

gendered form of label	actriu (Catalan) edit sex or gender (P21) female (Q6581072) trans woman (Q1052281) … ← editors can easily assign existing forms of the label to genders not considered by the original editor 0 references add reference actor (Catalan) edit sex or gender (P21) male (Q6581097) trans man (Q2449503) … 0 references add reference actor/actriu (Catalan) ← editors can easily add new forms corresponding to new gender items edit sex or gender (P21) non-binary (Q48270) 0 references add reference actrx (Catalan) ← (or whatever Catalan speakers may come up with) edit sex or gender (P21) non-binary (Q48270) 0 references add reference Schauspieler*in (German) edit sex or gender (P21) non-binary (Q48270) mode of derivation (P5886) Gendersternchen (Q62023201) ← external users (e.g., Wikipedias) could query for … 0 references add reference SchauspielerIn (German) edit sex or gender (P21) non-binary (Q48270) mode of derivation (P5886) ← a different (perhaps new) property might be in order here Binnen-I (Q863893) ← … specific forms of neologisms based on editor preferences 0 references add reference Schauspielerin (German) edit sex or gender (P21) female (Q6581072) trans woman (Q1052281) 0 references add reference … (…) edit sex or gender (P21) … 0 references add reference
		add value

@Andreasmperu, Matěj Suchánek, Marsupium, Vriullop, Powerek38:@Maria zaos, Jura1, Amire80, Nikerabbit, GerardM: do you all agree with the replacement here? Or you will still vote keep, regardless of it? --Liuxinyu970226 (talk) 11:49, 23 March 2019 (UTC)

This proposal is interesting but I think this isn't suitable venue for discussing it. Wikidata:Project chat or Wikidata:Property proposal will definitely have greater attention. Matěj Suchánek (talk) 21:41, 24 March 2019 (UTC)

Until this proposal (or another accepted alternative) were not totally deployed, the P2521 must be kept. Amadalvarez (talk) 09:39, 25 March 2019 (UTC)

@Amadalvarez: male form of label (P3321) too? --Liuxinyu970226 (talk) 23:16, 26 March 2019 (UTC)

@Liuxinyu970226: NO. We're not using P3321 in cawiki infoboxes. Thanks,Amadalvarez (talk) 05:15, 27 March 2019 (UTC)

@Liuxinyu970226:I agree with Amadalvarez, so  Keep P2125.--Maria zaos (talk) 20:29, 31 March 2019 (UTC)

External use

This property is being used by: ca:Plantilla:Infotaula persona via ca:Mòdul:Wikidata (list is incomplete) Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P6270 (P6270)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:41, 24 June 2019 (UTC)

LGDB game ID (P5116)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:45, 24 June 2019 (UTC)

X numeric user ID (P6552)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:46, 24 June 2019 (UTC)

P1946 (P1946)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:47, 24 June 2019 (UTC)

business division (P199)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:52, 24 June 2019 (UTC)

Property:P5482

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:55, 24 June 2019 (UTC)

Property:P2035

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:37, 24 June 2019 (UTC)

Property:P6779

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:38, 24 June 2019 (UTC)

Property:P527

has part(s) (P527): (delete | history | links | entity usage | logs | discussion)

Seems redundant with part of (P361), until I see no real need of a reverse property. A SPARQL request would certainly serve this purpose instead. —Nomen ad hoc (talk) 17:14, 28 August 2019 (UTC)

•  Keep They are not strict inverses. See Help:Basic membership properties for some background on this. There are also cases where one direction is more sensible than the other (an item could be "part of" many other things - for the element hydrogen is "part of" almost every organic molecule, so the inverse "has part" (or "has parts of the class") is the better relation). ArthurPSmith (talk) 18:21, 28 August 2019 (UTC)
•  Keep; we cannot query from Lua modules, thus redundancies like this one are often necessary. --MisterSynergy (talk) 18:30, 28 August 2019 (UTC)
•  Keep It's not redundant. It's possible that 1000 items have "has part" QXXXXXXX with the same QXXXXXXX and there we don't want to have a list with 1000 part of statements. ChristianKl ❪✉❫ 11:33, 29 August 2019 (UTC)
•  Keep I use this one a lot for the three parts of a triptych (Q79218) and in some other cases. Our data set is curated, we the editors choose if adding something like this is sensible. Shouldn't be added everywhere. Multichill (talk) 18:21, 2 September 2019 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Nomen ad hoc (talk) 18:37, 2 September 2019 (UTC)

Property:P1773

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 19:10, 4 December 2019 (UTC)

Property:P6482

incorrect closures

Repeating previous comment:

• Given that it's a controversial property, I don't think a participating administrator should be closing this. Number of uses is irrelevant to reason for which this was listed. --- Jura 22:21, 1 June 2019 (UTC)

As Liux.. isn't an admin, there isn't much they can do about it either. --- Jura 22:41, 8 July 2019 (UTC)

3rd discussion

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:46, 7 December 2019 (UTC)

Property:P5660

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:41, 7 December 2019 (UTC)

Property:P2157

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:36, 7 December 2019 (UTC)

Property:P5826

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:26, 7 December 2019 (UTC)

Property:P7288

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:22, 7 December 2019 (UTC)

P7728 (P7728)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. —Eihel (talk) 05:39, 25 December 2019 (UTC)

Property:P727

P727 (P727): (delete | history | links | entity usage | logs)

Not a persistent identifier, per talk page. GZWDer (talk) 01:21, 13 December 2019 (UTC)

• I'm semi-inclined to agree this should be deleted. See also the discussion on the proposal for a new Europeana property (which has been created now). ArthurPSmith (talk) 16:49, 13 December 2019 (UTC)
•  Delete replacement available. --Liuxinyu970226 (talk) 13:05, 8 January 2020 (UTC)
•  Keep but re-verify if values are correct. Michael FV (talk) 04:22, 9 January 2020 (UTC)

  @Michael FV: There's a new and much more proper property available Europeana entity (P7704), you don't need to keep this old school property scheme. --Liuxinyu970226 (talk) 00:29, 10 January 2020 (UTC)

•  Delete given the discussion on its talk page. --- Jura 11:04, 20 January 2020 (UTC)
•  Delete This is just a scheme change. @Michael FV: Why keep the old one? --117.136.54.109 23:27, 20 January 2020 (UTC)
•  Deleting given that this has over 77k uses, it may take a bit. Starting a batch edit to remove the statements, and I'll be back later to actually delete the property --DannyS712 (talk) 09:03, 24 March 2020 (UTC)
• On hold 70 of the uses cannot be removed; reported at phab:T248439 --DannyS712 (talk) 02:21, 25 March 2020 (UTC)
•  Delete Not persistent, replaced. --Epìdosis 13:04, 28 March 2020 (UTC)

Did the clean up for the remaining usage and Deleted it. Thanks User:DannyS712 for doing the bulk of the work. Multichill (talk) 20:40, 29 March 2020 (UTC)

@GZWDer, Multichill: Aren't you supposed to warn other projects that are using the property before deleting it? It was in use in Template:Wikidata Infobox (Q47517487), I've pulled it from the installation on Commons after it only caused 7,000 error messages, I'll check other wikis. Mike Peel (talk) 21:00, 29 March 2020 (UTC)

I think it only affected Commons, I'm purging the cache for the affected pages. Mike Peel (talk) 21:15, 29 March 2020 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Liuxinyu970226 (talk) 06:35, 31 March 2020 (UTC)

Property:P134

P134 (P134): (delete | history | links | entity usage | logs)

It can be replaced by Property:P4913 and it has been deprecated. —P134toP4913 (talk) 04:32, 4 December 2019 (UTC)

There is already consensus to delete this property, see Wikidata:Requests_for_deletions/Archive/2018/Properties/1#P134. But we haven't yet deleted it because the property is used for a few Wikipedia infoboxes. --Pasleim (talk) 19:13, 4 December 2019 (UTC)

Pinging Calatan Wikipedia editors: @Arnaugir, ToNToNi, Sarang, Amadalvarez, Dúnadan:@Martorell, ArinArin, Ludor, Glm, Pepetps:@Viktor~cawiki, Coet, David~cawiki, Vriullop, Sl:@KRLS, Spl908455, Tlustulimu, Bestiasonica, Castor:@Hinio, Jey, Visite fortuitement prolongée, Jarashi, Kette~cawiki: They should modify their local usages ca:Plantilla:Infotaula_de_llengua, ca:Plantilla:Infotaula llenguatge programació et ca:Plantilla:Infotaula família lingüística. --Liuxinyu970226 (talk) 00:13, 5 December 2019 (UTC)

@Liuxinyu970226:, thanks to ping us. Is  Done by Paucabot in ca:Plantilla:Infotaula_de_llengua, ca:Plantilla:Infotaula llenguatge programació. However, ca:Plantilla:Infotaula família lingüística do not use P134. May be this is not important but, where do you get this information from ?. Thanks, Amadalvarez (talk) 06:55, 5 December 2019 (UTC)

It was in an old version, not used anymore in this template. --Vriullop (talk) 07:28, 5 December 2019 (UTC)

Well, just from {{ExternalUse}} template of its talk page. --Liuxinyu970226 (talk) 07:00, 5 December 2019 (UTC)

---

Now slwiki users needed: @M11rtinb, Sporti, Pinky sl, Yerpo, XJaM:@TadejM, Andrejj: do we have time to modify sl:Predloga:Infopolje_programski_jezik/peskovnik and sl:Predloga:Infopolje_Programski_jezik? --Liuxinyu970226 (talk) 07:03, 5 December 2019 (UTC)

Ok. I fixed the matter. So you can continue your good work. --Pinky sl (talk) 19:26, 7 December 2019 (UTC)

•  Delete if at all, store in inverse. Michael FV (talk) 03:56, 9 January 2020 (UTC)
• Can this be migrated or not? --- Jura 11:05, 20 January 2020 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:41, 14 April 2020 (UTC)