Community Wishlist Survey 2023/Wiktionary/Add LUA function to read out previous section heading

From Meta, a Wikimedia project coordination wiki

Add LUA function to read out previous section heading

  • Problem: Ca 99% of templates in wiktionary need a language code. The same code must be fed separately into every single template. This is junk work, and brings risk of wrong codes. Also, templates intended to be invoked from certain sections only cannot check whether they are used correctly.
  • Proposed solution: Add a LUA function to read out previous section heading of specified level. The most interesting levels are 2 and 3. Level 2 requested below ==Swedish== (at any distance until a different level 2 heading appears) would return "Swedish", level 3 requested below === Subordinator === would return "Subordinator", if no heading of given level has been passed then return empty string or type "nil".
  • Who would benefit: All contributors of wiktionary, template editors on wiktionary, to a lesser degree also all other wikis.
  • More comments: Probably relatively easy to implement, but maybe ideological obstacles.
  • Phabricator tickets: There is at least one but I can't find it anymore.
  • Proposer: Taylor 49 (talk) 19:02, 3 February 2023 (UTC)Reply[reply]


  • @Taylor 49: Question. Is this a problem because wiktionary is multilingual, yet repeats the same language within a certain section ? And maybe your proposal would be helped by linking to a very good example page, not everyone voting is likely to be familiar enough with wiktionary to understand the problem otherwise. —TheDJ (talkcontribs) 15:23, 5 February 2023 (UTC)Reply[reply]

#{{tagg|anatomi|språk=en}} [[läderhud]]
#:{{etymologi|Av ny{{härledning|en|la|derma}}, av {{härledning|en|grc|δέρμα|tr=derma|hud}}, av ''[[δέρω]]'' (''dero'', “att flå skinn”).}}
#{{tagg|kat=mat|språk=en}} en [[judisk]] [[maträtt]] av kött och mjöl med mera

It is because wiktionary supports many languages. In the example above, the code "en" must be fed in 5 times, and this is redundant because the relevant information is already available in the word "Engelska" above. Missing or wrong language code is a common problem. Big wiktionaries workaround this by hacky JavaScripts and bots, the small ones are out of luck. Allowing to read out the word "Engelska" from a module, the need to feed in the same code again and again could be dropped. This would be a much more elegant and efficient solution. Futhermore, the templates could whine if an invalid or no language or word class has been specified above. Taylor 49 (talk) 15:43, 5 February 2023 (UTC)Reply[reply]

From {{inh|id|ms|derma}}, from {{inh|id|ms-cla|derma|t=alms}}, from {{der|id|sa|धर्म||morality, religion, duty, law}}, from {{der|id|inc-pro|*dʰármas}}, from {{der|id|iir-pro|*dʰármas}}, from {{der|id|ine-pro||*dʰér-mos}}, from {{m|ine-pro|*dʰer-||to hold, support}}.  {{doublet|id|darma|firma}}.

* {{IPA|id|[dərˈma]}}
* {{hyphenation|id|dêr|ma}}


# {{l|en|alms}}, something given to the poor as charity, such as money, clothing or food.
#: {{syn|id|amal|bantuan|donasi|infak|pertolongan|sedekah|sokongan|subsidi|sumbangan}}

====Affixed terms====
| bederma
| mendermakan
| penderma
| pendermaan
The code "id" has to be fed in 17'000 templates again and again despite the heading "==Indonesian==" above. Here additionally the parameter "noun" could be dropped below "===Noun===". Taylor 49 (talk) 15:51, 5 February 2023 (UTC)Reply[reply]
The issue is similar in French Wiktionary, and the suggested solution is interesting but perhaps not the best workaround. Another way may be to have a subpage for each language, then using a part of page names to identify the language for each template and transclude content from subpages to the unique page with a blend view displaying all languages concerned by this unique sequence of characters. So, I think a dev team should explore your proposal deeply and solve this on-going critical issue that over-complexify wikicode in Wiktionaries! Noé (talk) 10:51, 6 February 2023 (UTC)Reply[reply]
Thank you for that comment. While the hack with subpages presumably is feasible (with existing technology, or with changes making the transclusion easier), it is frequently preferable to see all languages at same time. For example, if I want to move the word "proton" from "Category:Physics" to "Category:Nuclear physics", it is much easier to do so manually or with bot if all languages are on same page, instead of editing 100:s of subpages. Taylor 49 (talk) 12:34, 6 February 2023 (UTC)Reply[reply]
  • This is a very interesting use case, but I'm not convinced that "accessing the heading tree" is the best way to solve it. Fundementally, both the French wikitionary and the proposed wish here are stashing some relevant context inside someplace that /happens/ to contain it (the article title and "some section heading somewhere above the current point") but both of those places are user-visible and so not a great place to stash arbitrary information. The French wikitionary approach is slightly "better" in that the title suffix is "hidden" and so can actually be the language code directly, whereas the suggested wish here would need to parse "English" -> "en" multiple times, unless you were going to put machine-readable language codes directly in the heading. And I suspect if we were to continue down this path we'd end up hacking in other invisible things, like <h2>Some heading <span style='display:none'><span class="langcode">en</span><span>...other stuff...</span></span></h2> or [[Foo/en-otherstuff-morestuff]]. That seems like a disaster waiting to happen. I'd rather see a first class "context" extension, similar to mw:Extension:ArrayFunctions, with syntax like <context variable1=value1 variable2=value2>....</context> which would yield wikitionary markup like:
==English ==
<context lang=en>

... templates can access the "current context"...

This is slightly more involved, but would be scalable to many more uses and wouldn't leave to embedding arbitrary information inside page titles and section headings. Cscott (talk) 15:42, 6 February 2023 (UTC)Reply[reply]
That's another interesting approach, and I agree, it could meet other needs too! The option I was suggesting is not how French Wiktionary work, actually, it was just another option to explore :) Noé (talk) 15:58, 6 February 2023 (UTC)Reply[reply]
I of course meant taking the visible text "English" and converting it back to the code "en" (a feature readily avaialable on all decent wiktionaries), not putting invisible stuff into the headers. Taylor 49 (talk) 11:09, 7 February 2023 (UTC)Reply[reply]
I have long wished that something like this were feasible, to make programming templates a little less frustrating, but maybe there are some language design issues. In this application I think the variable should have a more specific name, perhaps lemma-lang. Obviously we need this variable to be available within templates and modules invoked in their scope, but I wonder if there are cases where that is undesirable, as it could produce unintended interactions. Should templates (¿+modules?) specify how much of this environment they inherit? Should there be namespaces (formally or informally)? PJTraill (talk) 00:21, 15 February 2023 (UTC)Reply[reply]
My idea is easier to use and access and more generic than variables like lemma-lang, and hopefully more difficult to abuse too. No need for variables, no need for namespace considerations. Taylor 49 (talk) 17:56, 15 February 2023 (UTC)Reply[reply]
Right, generic, as in accessing previous H4 heading, previous H3 heading, previous H2 heading, whatever they may be. If it's "Indonesian", then it'd not be this particular function's concern to determine that the corresponding language code is "id". Something to consider is a broken header "==Indonesian=" that might cause the previous H2 heading to "spill-over" into the next. One way to get more control is to be able to access an array of all headings in the page, and an index of the template's or module's position in it. Then necessary precautions can be taken care of programmatically, based on the need in different use cases. ~ Dodde (talk) 18:28, 15 February 2023 (UTC)Reply[reply]