Wikidata talk:Property proposal/Proposal preload

formatter URL

I'd like to add:

|formatter URL =

after the "example" line, but don't know how to do so, without breaking the translation markup. Can someone assist, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:24, 19 March 2015 (UTC)

 Done Matěj Suchánek (talk) 13:58, 20 March 2015 (UTC)

@Matěj Suchánek: Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:38, 20 March 2015 (UTC)

Translate the "Motivation" heading?

I think that the text T:12 = "Motivation" should not be translated. Unlike other texts this one is not meant as an editor's help, which he is going to replace with his own text. Petr Matas 06:51, 26 April 2015 (UTC)

Why the invisible character is needed

@Lectrician1, AntiCompositeNumber:

1. Go to Wikidata:Property proposal/Place.
2. Type "foo" into the input field and hit "Create request page".

Now the comment for formatter URL = is <!-- for identifiers, URL pattern where place replaces the value -->. Obviously, there should be <!-- for identifiers, URL pattern where $1 replaces the value -->. This happens because the $1 is interpreted when the page is being preloaded. There was a workaround in place to have an invisible character inserted between $ and 1, and the tvar would ensure this "hack" works in the translated templates as well. --Matěj Suchánek (talk) 11:00, 7 February 2022 (UTC)

@Matěj Suchánek Ohhhhhhhhh. So it has nothing to do with translation but instead preloading. Is there any way to escape the parameters? I don't see anything on the documentation. Is there a Phab Task then? Lectrician1 (talk) 11:08, 7 February 2022 (UTC)

We don't need a phab task for this, we had a working solution.

In fact, we could also escape it by writing <!-- for identifiers, URL pattern where $2 replaces the value --> and then in Wikidata:Property proposal/Header, add preloadparams[] = $1.

Either way, the tvar should be kept, so that translators don't have to deal with this technical stuff (this is exactly what tvars are for). --Matěj Suchánek (talk) 11:15, 7 February 2022 (UTC)

@Matěj Suchánek I find it actually kind of a tiny problem because before I've used the $1 from the template instead of typing it myself and because it includes that invisible character, the module that parses the template thinks the link is not a valid link. IDK, I would prefer if we could escape it for that reason if we could. Lectrician1 (talk) 11:33, 7 February 2022 (UTC)

I have implemented the second solution. Please test it and tell me if there is something wrong. As for a phab task, I had already created phab:T259505 to avoid a wikitext-based form. --Matěj Suchánek (talk) 12:09, 7 February 2022 (UTC)

Extra parameter for external identifiers

I'd like to add:

|implied notability = <!-- for identifiers, use either {{Q|62589316}} if the existence of this identifier on an item suggests notability or {{Q|62589320}} if not -->

This will make it more clear for the proposer that getting the property created does not unconditionally unlock a massive data import, and will also be a good property to add by the property creator to have the usage be as clear as possible from the start. Can someone help me add it so that I don't break the translation tags (oh, how they make my head hurt every time I see them)? Ainali (talk) 20:57, 9 September 2022 (UTC)

Done by Lectrician1. But it still needs to be implemented by the template (module). --Matěj Suchánek (talk) 10:31, 11 September 2022 (UTC)

Why this castrated version?

@Lectrician1 why did you castrate this template so badly back in Dec 2022?

https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Proposal_preload&diff=1827163033&oldid=1784904695&diffmode=source

• You gave this motivation but I don't understand it: "remove preloaded fields part of the Property proposal template so that they can be centralized around the TemplateData documentation and be autofilled by TemplateData"
• Perhaps this makes it easier for newbie users to make prop proposals, but it makes it much harder for experienced users to do it
• Every time I have to go to the old revision link and copy the source from there. How does this "autofilling" that you mention work?
• Prop proposals should be made by experienced users not newbies, so what is the value of that castration?
• @Ainali, Ameisenigel , Dhx1, Eihel , GZWDer, Mahir256: what do you think?

--Vladimir Alexiev (talk) 09:29, 12 March 2024 (UTC)

• The following is solely my opinion. The 2018 to 2022 versions were better for ontological understanding, but more time was needed to make a proposal. Minimalist proposals annoy me. Learning more about how properties work, so Wikidata, is not too bad for beginners. There's nothing stopping newbies from asking questions or asking for help. Correcting information is one thing, filling out a proposal in place of others is another thing: double the work. People who offer themselves as property creators only see part of the work to be done with truncated proposals.
  The automatic creation of property was refused to Pintoch, but there, no one can comment on the future content of the property. Asking the opinion of the participants in the admissibility debate for a major change to a property no longer makes sense since the content has not been debated before.
  I also don't understand the phrase "The parameters listed above are mandatory". The proposal presents a false aspect of what is necessary for beginners to make a property work, when all statements are necessary. IMHO. Cordially. ―Eihel (talk) 10:35, 12 March 2024 (UTC)
• It looks like an attempt to simplify the creation of a property attempt, mislead probably. I said in the past that, compared to the Wikipedia infobox creation attempt, a user can create a whole infobox by himself, or add fields into an infobox simply. Here it’s very different because just to add do the equivalent stuff of adding a field to a, say, satellite infobox, we have to go through the property creation process in front of the whole project. The attempt to simplify this form does not really change that, this is where it is maybe mislead and miss the point. author  TomT0m / talk page 11:28, 12 March 2024 (UTC)
• While I understand the difficulty experienced users (or rather, those who either have VisualEditor disabled or instinctively switch away from it the moment it appears to them) may have now that not all fields are present, I have found making property proposals easier to describe to newcomers with this change (and I too have begun creating property proposals this way):
  1. Go to a proposal subpage, such as Wikidata:Property proposal/Computing, put a property name in the "Property name" text box, and click "Create request page".
  2. The VisualEditor mode should show a small property proposal box with several fields ("Data type" and three "Example"s) missing, hovering over which box should highlight it. Click on the box.
  3. On clicking on the box a pop-up with the words "Template" and "Generated from: Property proposal" should appear. Click the word "Edit" that appears within that pop-up.
  4. Each of the possible property proposal fields is now provided in a nice display where, on the left side, different fields can be enabled or disabled, and the enabled fields show up on the right side where they can be filled in. Once those fields have been filled in, click "Apply changes" at the top of the display.
  5. "Add your motivation for this property [t]here and your signature" and then publish the page.

  Mahir256 (talk) 16:18, 12 March 2024 (UTC)

@Vladimir Alexiev @Eihel @TomT0m @Mahir256 My explaination:

The draft page I will be updating with better instructions for the new system is located here: User:Lectrician1/Property_proposal_process

The disucssion about this page is here: Wikidata_talk:Property_proposal#Dedicated_page_for_describing_the_property_proposal_process

Lectrician1 (talk) 19:12, 12 March 2024 (UTC)

@Mahir256 and @Lectrician1 Thanks for the explanation!

(Lectrician, your video is a bit rambling, if you want to win hearts with it, please rerecord it :-).

I'm ashamed to be so stupid, I never thought to click on the blue area! (And dclick opens it directly for editing).

This is a nice UI and I have a couple of suggestions for improvement:

• After autocompleting an item, please show its label not just ID.
• If possible, turn boxes that expect text but in fact take items/props, use real items/props. For example:
  • implied notability (takes one of 2 predefined items)
  • See also (takes props)

I still have a requirement to make it easier for advanced users:

• I often gather info in a text file, by browsing or even querying related props and data, and then it's faster for me to edit this text and place it in the template, rather than going field by field.
  • I sometimes write prop proposals at night on my phone. I can do it in a text editor, but not in the Visual Editor field by field.
• So the prop proposal page should:
  • Either respect each user's setting Visual Editor vs textual editor
  • Or there should be 2 buttons/links to make that choice when you start the process
  • Or at least show all fields in the template. What is the harm to show them all in the blue area? Are you afraid of scaring the novice user? The Edit interface shows all fields anyway, so he'd be scared on the second step if not the first
    • That way I can switch from the Visual Editor UI to the textual editor, and still get all fields

Thanks! -- Vladimir Alexiev (talk) 12:19, 22 March 2024 (UTC)

@Vladimir Alexiev

After autocompleting an item, please show its label not just ID.

As far as I know, this is not possible in the visual editor.

If possible, turn boxes that expect text but in fact take items/props, use real items/props. For example:implied notability (takes one of 2 predefined items), See also (takes props)

This would take some messing with Module:Property proposal to get working with past and future proposals that I unfortunately don't have time for.

Or at least show all fields in the template. What is the harm to show them all in the blue area? Are you afraid of scaring the novice user? The Edit interface shows all fields anyway, so he'd be scared on the second step if not the first

The problem with that is we would return back to the original situation where if we add a field to the template, it then has to be updated on the preload page and its accompanying commented description would need to also be added and translated. Unfortunately there's no way to automatically do this with TemplateData, so instead, I found it easier to just direct all users to use the Visual Editor. That's also why I would be against having 2 buttons to create with either editor and respecting settings as they might be confused/have a more tedious time creating the proposal if they are directed to the source editor page which has less information than the VE. Lectrician1 (talk) 21:08, 27 March 2024 (UTC)