Wikidata talk:WikiProject Supertemplates/documentation structure

From Wikidata
Jump to navigation Jump to search

Example[edit]

In this proposal (I do), the name of the page is Wikidata:WikiProject Supertemplates/doc/P27/case 7 because we already have six case previous in Wikidata:WikiProject Supertemplates/doc/P27. includeonly permits a display in other pages (normally) juste the content of Template:Statement+, and the page is in a category. P0027/case 7 permits to have an order ; if we have more than ten case, logical for a question such nationality (but very rare for easy properties), it will become P0027/case 07 but the name of the page will not change. I can imagine the parameter doc and quote contemporary constraint and insist on the fact Qing Dynasty finishes on for example. I already do it (in a different register) for cases 3 and 4 of P734. At this occasion, I see the width must be 80 %, not 75 % (to keep the same width when we don't have doc). JGHJ.

  • OK to left-padding zero on property and case name.
  • The result with includeonly has similar effect that I wish with noinclude on header section. OK
  • The 75% instead of 80% is recommended to hold the infobox at the right. As I'am thinking now, it only happens in conceptual blocks. If we need more space for doc parameter, we can try to increase |width_doc=.
  • I did not understand what you mean regarding Qing Dynasty.

I'll incorporate a naming criteria in the previous section. AA ✓ Done

  • Ok for naming. Idem to includeonly (now, thanks to you, I am sure).
  • The idea is to have the same width following we use or not the documenation on Statement+ (I am a little maniac...). @Jérémy-Günther-Heinz Jähnick: Easy, width=75% for everybody, with or without doc parameter. Amadalvarez (talk) 19:47, 7 November 2019 (UTC)[reply]
  • Nothing special, it is just the idea to highlight this particular constraint. The general idea on this page P27 is to highlight countries change.
== {{Q+|5816}} == <!-- Mao Zedong -->

<includeonly>{{Statement+
|P={{P-|27}}
|V1={{Q-|8733}}
|q1.p={{P-|580}}
|q1.v1={{date|1893|12|26}}
|q2.p={{P-|582}}
|q2.v1={{date|1911|12|31}}
|V2={{Q-|13426199}}
|V2.q1.p={{P-|580}}
|V2.q1.v1={{date|1912|01|01}}
|V2.q2.p={{P-|582}}
|V2.q2.v1={{date|1949|09|30}}
|V3={{Q-|148}}
|V3.q1.p={{P-|580}}
|V3.q1.v1={{date|1949|10|01}}
|V3.q2.p={{P-|582}}
|V3.q2.v1={{date|1976|09|09}}
}}</includeonly>

[[Category:WikiProject Supertemplates/Cases|P0027/case 7]]
== {{Q+|5816}} == <!-- Mao Zedong -->

<includeonly>{{Statement+ |navbar=no |width=80% |width_doc=30% |color_doc=#FFFFF5 |reference=close
|P={{P-|27}}
|V1={{Q-|8733}}
|q1.p={{P-|580}}
|q1.v1={{date|1893|12|26}}
|q2.p={{P-|582}}
|q2.v1={{date|1911|12|31}}
|V2={{Q-|13426199}}
|V2.q1.p={{P-|580}}
|V2.q1.v1={{date|1912|01|01}}
|V2.q2.p={{P-|582}}
|V2.q2.v1={{date|1949|09|30}}
|V3={{Q-|148}}
|V3.q1.p={{P-|580}}
|V3.q1.v1={{date|1949|10|01}}
|V3.q2.p={{P-|582}}
|V3.q2.v1={{date|1976|09|09}}
|doc=</br>
* {{Button ST|white}} {{Label|Q14944328}} → {{Q+|5816}}
* {{Button ST|yellow}} {{Label|Q1235196}} → [[Wikidata:WikiProject Supertemplates/doc/P27|{{Label|P27}}]] <!-- if included on a page different than Wikidata:WikiProject Supertemplates/doc/P27, idem for the example (white button) -->
* {{Button ST|orange}} {{Label|Q21510851}} → {{P|580}} • {{P|582}}
* {{Button ST|red}} {{Label|Q25796498}}
** {{Label|Q8733}} → {{P-|582}} → {{date|1911|12|31}}
** {{Label|Q13426199}} → {{P-|582}} → {{date|1949|09|30}}}
}}</includeonly>

[[Category:WikiProject Supertemplates/Cases|P0027/case 7]]

Ok, so I create Wikidata:WikiProject Supertemplates/doc/P27/case 7, and after different tries, it is not a good idea to use includeonly (it makes problem when we want to edit and verify the case, it created an obligation to edit, and a risk a error). noinclude was also to add : first to avoid to display the title twice, and then to avoid a second categorisation. Jérémy-Günther-Heinz Jähnick (talk) 12:36, 7 November 2019 (UTC)[reply]

After different tests, I encounter a problem : the category Category:WikiProject Supertemplates/Cases is displayed in Wikidata:WikiProject Supertemplates/doc/P27 even when I play with noinclude at the category and even if I add includeonly (to the content of Statement+). But I dont found P27 in the category Case. It is not logic and I can't explain this. Jérémy-Günther-Heinz Jähnick (talk) 13:06, 7 November 2019 (UTC)[reply]
✓ Done Solved. It was due because I use as classification in category P0027/case 7, I delete the /, I now have P0027 case 7 and it works. Jérémy-Günther-Heinz Jähnick (talk) 13:40, 7 November 2019 (UTC)[reply]
All subpages are created.
I suggest we create a category Category:WikiProject Supertemplates/Properties to group all the pages about properties we have. Jérémy-Günther-Heinz Jähnick (talk) 14:35, 7 November 2019 (UTC)[reply]
@Jérémy-Günther-Heinz Jähnick: OK !.Amadalvarez (talk) 19:47, 7 November 2019 (UTC)[reply]
@Jérémy-Günther-Heinz Jähnick: in the same line, I proposed to have a category by each level defined in "structure documentation": bars, themes, property, blocks (doesn't matter wheter are "conceptual" (that I defense for describe infoboxes) or sub-thematic), properties and cases. Is it OK?. I'm going to include in naming pending confirmation. Thanks,Amadalvarez (talk) 07:53, 8 November 2019 (UTC)[reply]
OK for these points. It is important to do this and to think at these questions when we have very few pages. In few minutes I will create the Category:WikiProject Supertemplates/Properties. Jérémy-Günther-Heinz Jähnick (talk) 09:22, 8 November 2019 (UTC)[reply]
✓ Done. And by wiewing Category:WikiProject Supertemplates, we can determinate in one sight an average of cases by property. Jérémy-Günther-Heinz Jähnick (talk) 09:30, 8 November 2019 (UTC)[reply]

Comments to structure proposal[edit]

JGHJ : for thematic pages, I am not a fan of collapsible sections. But I follow you for the rest. I am little worry for description texts and foot texts because of the risk we lack of translators. But I think we can take the risk. Also ok for more thematical navigation bars.

@Jérémy-Günther-Heinz Jähnick: I move comments to this discussion page in order to have a "final document" on the page. When any open topic we agree here, then we can incorporate to the page.
description and foot texts: My idea is to minimize them, but from the point of view of "documentation structure", we must have. We can not start a document without explain what is it and what does it serve for. May be two lines, a paragraph, and nothing else.
Collapsible: I changed description to let it open to decide in any case. I'm not a fan of collapsible, too, in normal text. However, we're writting a Handbook and handle a long homogeneous list could be difficult to read. Look that I proposed it for "thematic", not for property level. You started defining "person" and I guess it's gonna be long. When you finish, probably changed your opinion. But now, we have free choice. Amadalvarez (talk) 19:47, 7 November 2019 (UTC)[reply]

Thematic page & Property full definition[edit]

My highest priority is to document the infoboxes to create an installation kit to make export easy to implement, not only technically, but also with good community acceptance. Obviously, I am interested that derivated methodology from our work, become a a model for other uses. I explain this because, for the moment, I have no need of the thematic level "person", "place", etc. with all its properties. Regarding the complete description of each property, something similar happens. I'm only interested in defining cases as they are managed by the infobox that I describe. The rest of the qualifiers, for example, I prefer not to include in the documentation of the case, although we could incorporate a link to the property page.

Look that in the "futur" for "Property full definition ", I write "To be decide", because you have work better this topic and I prefers you develope this point, please.Amadalvarez (talk) 20:28, 7 November 2019 (UTC)[reply]

In fact, for me the documentation must be like a huge city in which it is very easy to get lost, we must manage to guide the Wikimedian by small means but it is necessarily very different from his colleague Wikiproject and navigate in its own way, it is for this reason that it may be interesting to have several gateways. To go into the same house (a property documentation page), two Wikimedians will not necessarily use the same path, one for example will use the yellow navbox, the other will start from the page "Place" or a thematic page, or another one will directly use the category. I saw similar ways on the French version of Wikipedia where contributors were browsing via articles, via naboxes, categories or portals or search bar, sometimes varying a bit.
I assume that the biographical infobox will be a success. A navbox concentrating the properties for the people will besides be necessary in addition to that which lists all the properties. But based on the experience of the module: Cycling race, I am almost certain that we will be asked very quickly to create other infoboxes and tables. In this sense, I plan to detail additional properties now and in December, even before these new functions come into being. At first, on Cycling race, it was only an infobox, then it went very far. But cycling will still only represent 1% of articles in a language version of Wikipedia.
On the field of documentation, I have a way to do a little special that is inspired by that of a very large company in which I worked and in which I return soon (that's also why I concentrate work now): a very large section, all new, is open (here the documentation). Then very quickly, questions arise and it is necessary to solve them. For example, for the documentation of surnames and forenames, it appeared that there was a risk of homonymy, and I think about making it known in the documentation.
For the moment, almost nobody knows our initiative, so we have time to create a huge basic documentation, time-consuming. Then, by thinking back, for example at night, to the project, or by browsing Wikidata, or by reading old threads about the Wikidata introduction in Wikipedias, we will gradually think of many special cases. The opportunity to mention them in the documentation.
When we see our pace of work over a week, with all the problems that had to be solved in a few days, I am convinced that already at the end of the month we will have a very good level of documentation, and that it will already prepare future infoboxes and tables. Jérémy-Günther-Heinz Jähnick (talk) 10:16, 8 November 2019 (UTC)[reply]
Example with P735 and P734. Jérémy-Günther-Heinz Jähnick (talk) 10:56, 8 November 2019 (UTC)[reply]

Leading zeros in property (in names for sorting categories)[edit]

Hi. I believe we must use 5 zeros leading for properties (i mean P00748), because now we have 7000 properties and in a year we'll arrive to 10.000. Another proposal: what d you thing to add a short description to the case code?. Now, we have "/P748/case 1" and could be "/748/case_1_platon". I was creating a new page and looking category, did not know which one pick up without open (wrong) 2-3 cases. Last one. Use of lowercase-uppercase in naming. We must define the criteria. I use to work allways in lc because is a rule easy to remember. However, if you know/have a normative criteria, please share it and discuss to adopt. Thanks, Amadalvarez (talk) 14:00, 8 November 2019 (UTC)[reply]

I don't know what is precisely lc, I just see it is in Template:Label.
Ok for five zeros (it can take time but it is possible we arrive at 9999+1).
I think at this problem (with P27), so to keep always the same naming, and having no problems, I include cases in properties. For your case with Platon, for example, I include it today in Wikidata:WikiProject Supertemplates/doc/P569. This way, it is impossible to loose case (at this moment, we have 50 cases, but in few time, it will be 500 at least). Jérémy-Günther-Heinz Jähnick (talk) 14:49, 8 November 2019 (UTC)[reply]
✓ Done It is done for the use of five zeros. I create documentation pages to incorporate two of your cases. And continue to make documentation for properties (it is possible I am not on computer tomorrow). I also create two templates for arrows : their directions change in arabian (for example), I will ask their adaptation in very few time.
Sorry I have not explained well. lc means lowercasse (minuscule, lowercase letter (Q8185162)). I talk about the use (or not) of uppercase letter (Q98912) within the name of pages and categories. For instance, seeing the category:WikiProject Supertemplates, we may observe:
category:WikiProject Supertemplates/Cases
Wikidata:WikiProject Supertemplates/doc/Persons
Wikidata:WikiProject Supertemplates/doc/P6/case 1
Wikidata:WikiProject Supertemplates/doc/person/death
in other words, we mixed lower and uppercase in the name. It would be useful to have a criterion, whatever it was. My suggestion is to use uppercase in Pnn and Qnn, and also for the first word of the category names (as it is now), but lowercase in all the words of pages
The "Platon affaire" may be I explained incorrectly. I mean, if you look category:WikiProject Supertemplates/Cases and want to get the "P569 case" for Platon, there is no clue to identify which of the four is it, and we need open to see. As you say, we have 50, but will have 500. Opinion ?.
Answer to your last comment: Thanks to change P00000 in all cases. Mentioning arrows and RTL I remind that you use align: right & left (in navbar, for instance). Is better use "start" or "end", in order it runs correctly in RTL language. Salut !, Amadalvarez (talk) 19:11, 8 November 2019 (UTC)[reply]
If you suggest we should do Wikidata:WikiProject Supertemplates/doc/P6/Case 1 (Paris) or Wikidata:WikiProject Supertemplates/doc/P22/Case 1 (Jarre), finally it is ok but if it stay short. I don't know for doc, at the origin it is the use for a documentation, doc, not Doc. I have no opinion on this subject. I understand you use the category case to navigate when I use documentation's pages, so it is finally logic you have an help to find a case. Normally, I will left home in few time to ride bike all the day (the friend has problem to understand 9 h 00 is not 9 h 10... or more). I don't know if I will take the computer today, so I propose you say if the new naming of cases is good, and I will can rename tomorrow. Jérémy-Günther-Heinz Jähnick (talk) 08:13, 9 November 2019 (UTC)[reply]
Yes, this is my idea, just on word to have a help, but not a long description in the name. Don't worry to rename existing cases, it is not urgent.... by now. Amadalvarez (talk) 08:20, 10 November 2019 (UTC)[reply]
No problem, for the moment I always have the time. It is never a problem to work one or two hours in more. Today I also plan to describe properties. Jérémy-Günther-Heinz Jähnick (talk) 09:50, 10 November 2019 (UTC)[reply]
✓ Done. Jérémy-Günther-Heinz Jähnick (talk) 17:23, 10 November 2019 (UTC)[reply]
I ask to a friend for a module to create parameters for template:Statement+ from real cases of WD. I have no answer yet. Amadalvarez (talk) 13:21, 10 November 2019 (UTC)[reply]
Ok. Jérémy-Günther-Heinz Jähnick (talk) 17:23, 10 November 2019 (UTC)[reply]
✓ Done ca:module:createStatement. Amadalvarez (talk) 17:51, 19 November 2019 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata_talk:WikiProject_Supertemplates/documentation_structure&oldid=1833775918"