Community Wishlist Survey 2023/Wiktionary/Something like Extension:Variables to simplify template calls

Add links
From Meta, a Wikimedia project coordination wiki

Something like Extension:Variables to simplify template calls

  • Problem: As I wrote in 2020:

    Some templates used on Polish Wiktionary (e.g., wikt:pl:Szablon:imię, wikt:pl:Szablon:imię odojcowskie, wikt:pl:Szablon:forma rzeczownika, wikt:pl:Szablon:forma przymiotnika) put entries into laguage-dependent categories. To do that they need to know what language the entry is about. As many dictionary entries are stored in a single article (one section per one language), those templates cannot determine the language with the standard MW tools. Thus, the language needs to be provided in the template call (like {{imię odojcowskie|ukraiński|Абаку́м|m}} or {{forma rzeczownika|pl}})

    This could be done with the Variables extension, but it is unavailable on Wikimedia and the description page of the extension says that it “[…] is incompatible with plans to parallelize the parsing, as is intended by the use of Parsoid. Therefore, the future of this extension is uncertain, and it is expected to become incompatible with the standard MediaWiki parser within a few years.”
  • Proposed solution: Re-evaluate the “plans to parallelize the parsing” in the context of Wiktionaries and develop something like the mentioned extension or a completely new way to allow co-operation between templates.
  • Who would benefit: Wiktionary users who struggle with creating a dictionary using a software meant to edit an encyclopedia; especially the new ones for whom the complexity of the code and the differences between it and the final result are an entry threshold.
  • More comments: The workarounds are not good enough.
  • Phabricator tickets:
  • Proposer: DrogosławTALK 12:54, 28 January 2023 (UTC)[reply]

Discussion

@KSiebert (WMF): The issue is that doing it many times would make the page code a lot messier, a lot less user-friendly and require additional effort. Read the discussion you've linked, please. DrogosławTALK 11:02, 2 February 2023 (UTC)[reply]
  • As Peter Bowman pointed out,

    Expanding on PiotrekD's problem description, entry-based projects (such as Wiktionaries) may expect significant gains in enabling this feature, especially regarding stuff that can perform semantic categorization of entries - but currently doesn't, or at least not in the way categories are meant to work, rather by periodically inspecting page contents and maintaining large lists such as wikt:pl:Indeks:Francuski - Medycyna. This list collects all French entries related to medicine based on their transclusion of wikt:pl:Template:med, which doesn't accept a language parameter (precisely this would be nice for categorization purposes) and it will probably never do: we have tons of such templates used across the entire site, potentially making it quite tedious to update hundreds of thousands of tranclusions, also accounting for the process of making our veteran editors aware of this change. In contrast, we could easily upgrade {{med}} and similar to fetch the corresponding language code, conveniently exposed in a variable that relates to the language section this template is placed in, and use it to categorize the page - no need to alter the page contents at all. Peter Bowman (talk) 11:16, 18 November 2020 (UTC)

@User:Peter Bowman, User:PiotrekD, @User:Drogosław, @User:KSiebert (WMF): A different, possibly better way to address this problem is just below: Community_Wishlist_Survey_2023/Wiktionary#Add_LUA_function_to_read_out_previous_section_heading. Taylor 49 (talk) 19:07, 3 February 2023 (UTC)[reply]

@Taylor 49:: 1. You have just written it, it did not exist when I was writing this proposal. 2. It's not necessary “better”; it has definitely less versatile, though easier to implement. DrogosławTALK 19:44, 3 February 2023 (UTC)[reply]
@Taylor 49: I am convinced that your proposal is not easier to achieve than just flipping a configuration switch as it is asked for in this request. There is a prejudice we are trying to fight: previous requests had been denied on the sole basis of a dev back in 2006 saying it's unfeasible. We need attention from technical staff to re-evaluate the problem and tell us why something that works on non-WMF wikis would not work for us (as of today). As far as I can tell, the main blocker right now is phab:T250963 due to a Parsoid-related deprecation, but some work has been already started to target this: gerrit:721950. I'm afraid that adding more alternatives will drive said attention away from this issue and ultimately achieve nothing: your proposal entails something close to wikitext parsing (compare how succinct Extensions:Variables looks under the hood) and would require us, extension users, to additionally parse the contents of a section header. Peter Bowman (talk) 20:36, 3 February 2023 (UTC)[reply]
I do NOT fully understand this proposal. Is it just enabling mw:Extension:Variables? Please elaborate how you would use it.
> additionally parse the contents of a section header
You do not have to parse anything. You just have to convert lngcode <--> lngname, but this is a feature available on every intact wiktionary. My proposal is probably easier to use in wiktionary wikitext. Taylor 49 (talk) 20:45, 3 February 2023 (UTC)[reply]
Yes, this is about enabling Extension:Variables. Every language entry in plwiktionary is placed within a level-2 section and its header looks like this: == title ({{language_name}}) ==. Since it includes more elements than a simple language name or code, parsing would be unavoidable if we followed your proposal. We want the header template to define (#vardefine) some kind of variable referring to the language each section is about. Thus, this information would be made accessible (through #var) to a wide range of templates aimed at putting the current page into a language-specific category (e.g. Category:English medicine terms). In other words, we need to contextualize template calls. Peter Bowman (talk) 00:14, 4 February 2023 (UTC)[reply]
Indeed extra work, but it's a trivial task to isolate the part between brackets, no rocket science parsing. You still have ca 9'000 single templates for ca 9'000 single languages, ie a horrible design and a relict from the pre-module era. Taylor 49 (talk) 09:12, 4 February 2023 (UTC)[reply]
We are already doing such extra parsing in some similar contexts and from my experience it is not clean (regexes just aren't), not scalable (usage of expensive functions to retrieve page text) and not safe (relying on potentially untrusted input text). I am also well aware that we could just edit hundreds of thousands of pages on our wiki by adding the missing language parameter. There is a nice tool that seems to suit our needs and this proposal focuses on it. Peter Bowman (talk) 10:52, 4 February 2023 (UTC)[reply]
Taking the title ({{language_name}}) read out from == title ({{language_name}}) == according to my proposal, and isolating the language_name from it requires neither regex nor expensive functions. Taylor 49 (talk) 09:54, 5 February 2023 (UTC)[reply]
Yet it does indeed require parsing/isolating wikitext, which is way uglier and more unreliable than reading a variable, and also conveys limited information. Please discuss your proposal separately and focus here on Extension:Variables instead, thank you. Peter Bowman (talk) 11:36, 5 February 2023 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2023/Wiktionary/Something_like_Extension:Variables_to_simplify_template_calls&oldid=24623550"