List of Malcolm in the Middle charactersEdit

There are various character redirects linking to Malcolm in the Middle#Characters. Could you please fix them using AWB to target to the above mentioned list? --Kailash29792 (talk) 17:36, 25 August 2020 (UTC)

  • Yeah np. I can do it tomorrow I think as I'm in the middle of something else in AWB and don't want to lose where I stopped. --Gonnym (talk) 17:37, 25 August 2020 (UTC)
  • Done. --Gonnym (talk) 14:45, 26 August 2020 (UTC)

Speedy deletion tagsEdit

Hello, Gonnym,

I know you are a veteran editor but I just wanted to remind you that when you tag a page for any kind of deletion, you need to post a notice of this tagging on the talk page of the page creator. If you use Twinkle this is done automatically, so this is very convenient and I recommend the tool. Thank you. Liz Read! Talk! 06:00, 28 August 2020 (UTC)

  • I do use twinkle, as can be seen by the edit summary :) --Gonnym (talk) 09:04, 28 August 2020 (UTC)

List of awards for supporting actorEdit

I do not want to get into an edit war over this. This is typical of the many lists linked from Lists of awards. A list of similar things is not the same as a disambiguation page. All the awards have different names, and very few readers will think there is just one global award for supporting actor. I propose to restore the list to a regular list, as is has been for many years. You may then open a discussion on the talk page over whether it should be made a disambiguation page. If it were to be done it should be renamed award for supporting actor, and stripped down to pages that contain the phrase "supporting actor".

I agree that it would be useful to review the inbound links and fix them to point to specific awards where appropriate. I note that very few articles link directly to the list. A possible approach would be to make redirects like Best Supporting Actress into disambiguation pages, with a sample of entries that contain the phrase "Best Supporting Actress" and a link to the list. These would not be very useful disambiguation pages, so do not have to be at all complete, but would show up as probable errors on pages linking to them. I can do that. Aymatth2 (talk) 22:32, 1 September 2020 (UTC)

@Aymatth2: If you think making an almost identical in nature page is the better solution, then sure. --Gonnym (talk) 07:47, 2 September 2020 (UTC)

I have done that. If you check Special:WhatLinksHere/List of awards for supporting actor you will now see six disambiguation pages, each listing articles with similar names. This is more in line with DAB standards. I see little value in the list article, but I do not watch much TV. Readers do seem interested in these things. Aymatth2 (talk) 14:16, 2 September 2020 (UTC)


User:Gonnym please look in could you please look at Talk:Bigg Boss (Hindi TV series)#Semi-protected edit request on 5 September 2020 — Preceding unsigned comment added by 2A01:4C8:41:E6FF:5DF3:9984:D5EB:2A53 (talk) 14:44, 5 September 2020 (UTC)

Category:Batwoman (TV series) episode redirects to listsEdit

Now that we have Batwoman (season 1), can you please use AWB and retarget all episodes listed in this category? Kailash29792 (talk) 17:10, 6 September 2020 (UTC)

  • Done. --Gonnym (talk) 13:49, 7 September 2020 (UTC)

Orphaned non-free image File:The Avengers The Mobile Game cover art.pngEdit


Thanks for uploading File:The Avengers The Mobile Game cover art.png. The image description page currently specifies that the image is non-free and may only be used on Wikipedia under a claim of fair use. However, the image is currently not used in any articles on Wikipedia. If the image was previously in an article, please go to the article and see why it was removed. You may add it back if you think that that will be useful. However, please note that images for which a replacement could be created are not acceptable for use on Wikipedia (see our policy for non-free media).

Note that any non-free images not used in any articles will be deleted after seven days, as described in section F5 of the criteria for speedy deletion. Thank you. --B-bot (talk) 17:53, 6 September 2020 (UTC)

Television network original programming categoryEdit

Hi, why does {{Television network original programming category|Philippine}} put Category:UNTV shows inside itself? No content category should be self-categorised. --Redrose64 🌹 (talk) 18:14, 7 September 2020 (UTC)

Discussion at Wikipedia:Templates for discussion/Log/2020 September 15 § Template:Use shortened footnotesEdit

  You are invited to join the discussion at Wikipedia:Templates for discussion/Log/2020 September 15 § Template:Use shortened footnotes. Peaceray (talk) 05:17, 15 September 2020 (UTC)


Can you please add a infobox to my profile page I'll laterly edit my own And if you can please say me how to add infobox or template to any page Priyanshu Rajkumar Jaiswal (talk) 17:02, 17 September 2020 (UTC)


Just as a note, if a template populating a category has changed, the category should be deleted under WP:G8 (specifically {{db-templatecat}}), not G6. Primefac (talk) 18:54, 19 September 2020 (UTC)

Thanks, I wasn't sure which one to choose. The template didn't change, I just added now code that places the incorrect categories in a tracking category. They might have been like this empty for years. Gonnym (talk) 19:01, 19 September 2020 (UTC)
@Primefac: Are you sure G8 is better? The language makes me think it doesn't really cover this. --Gonnym (talk) 19:49, 19 September 2020 (UTC)
If a template was (at any point in time) supposed to populate those categories, and they're no longer being populated, then I'd say that's a good use of G8. The length of time they haven't been populated is largely immaterial. Primefac (talk) 19:50, 19 September 2020 (UTC)

test cases odditiesEdit

Something makes no sense to me. At Module talk:Lang/testcases/ISO 639-1 name from tag, eleven tests fail but except for two, none of the others should. Module:Lang/sandbox no-longer uses Module:Language/data/wp languages or Module:Language/data/ISO 639-3. Module:Lang/data should, but does not yet override el and to (both are overridden in ~/wp_languages) so the mismatch in the testcases for those codes is to be expected.

The other failures are unexpected; more so because comparing live against sandbox {{#invoke:}}s here, shows that all of these that fail at the testcases page do not fail here. Since they work independently, that suggests that there is something amiss with the testcases code.

cu – override exists in Module:Lang/data - FIXED

  • l – Church Slavonic
  • s – Church Slavonic

el – override exists in ~/wp_languages

  • l – Greek
  • s – Greek

fy – override exist in ~/data - FIXED

  • l – West Frisian
  • s – West Frisian


  • l – Interlingua
  • s – Interlingua


  • l – Malay
  • s – Malay


  • l – Nepali
  • s – Nepali


  • l – Occitan
  • s – Occitan


  • l – Odia
  • s – Odia

ps – override exist in ~/data - FIXED

  • l – Pashto
  • s – Pashto


  • l – Swahili
  • s – Swahili

to – override exists in ~/wp_languages

  • l – Tongan
  • s – Tongan

Do you have an explanation?

Trappist the monk (talk) 16:05, 21 September 2020 (UTC)

  • The way I set it up (and it might be incorrect, seeing as it doesn't take into account overrides), was to get the list from the relevant module. So in this case, from Module:Language/data/ISO 639-1. Then I compare the result of #invoke:Lang|name_from_tag with the the first language returned from the data entry in the list. "Church Slavic" is the first entry, which is why it returned that. I'll need to see how I can add the override logic there. --Gonnym (talk) 16:14, 21 September 2020 (UTC)
    • Down to 8 now. The rest have disambiguation and I'm not sure how to handle that in the /testcases. --Gonnym (talk) 16:40, 21 September 2020 (UTC)
      Similar issue with the ISO 639-2, -3 codes? Lots of errors but the iana source (which is 'the' source) sometimes reorders language name aliases so tests fail. For example idc in Module talk:Lang/testcases/ISO 639-3-2 name from tag: ISO 639-3 has: "Ajiya", "Idon" but iana has: "Idon", "Ajiya". In the data set 'coalesced' by Module:Language/name/data, iana has priority over ISO 639.
      I think that the current goal is to abandon Module:Language/name/data which is why Module:Lang/sandbox doesn't use it. That being the case, shouldn't the primary data for the testcases be derived from Module:Language/data/iana languages? We might retain the ISO 639 -2, -3, -5, deprecated testcases for reference.
      I've been wondering recently about the use of variant tag descriptions in the rendering of link labels, tool tips, category names; pretty sure that I wrote about that on my talk page. Without anyone dissuades me, I'm going to disable that after adding appropriate overrides for existing uses to Module:Lang/data. Did that already for cs-valencia and tw-asante.
      Also, I notice that the tests sometimes fail because they take to long to render.
      Trappist the monk (talk) 17:46, 21 September 2020 (UTC)
      • The testcases don't use Module:Language/name/data, but they do use every name present in the relevent tables. So for "idc" it checked both "Idon", "Ajiya" (as both are in Module:Language/data/iana languages). Should it not? Regarding the long tests, I don't really know what else to do. Part of my musing comment was based on the complex work that is needed to get a piece of static data, which in this case also causes the timeout (if I'm not mistaken, the timeout started after your recent change to the lang module. So it's very fragile to any "extra" processing). --Gonnym (talk) 18:26, 21 September 2020 (UTC)
        These tests validate Module:lang/sandbox against a static reference list of language names taken from Module:Language/data/ISO 639-3. I think that that is the wrong list to be using.
        Because you aren't fetching data from Module:Language/name/data (for the live module, that is the relevant data) then you should be using Module:Language/data/iana languages because when Module:Language/name/data is 'coalesced', Module:Language/data/wp languages is first, followed by Module:Language/data/iana languages, and finally by Module:Language/data/ISO 639-3. So, for idc, we end up with this:
        ["idc"] = {"Idon", "Ajiya", "Ajiya", "Idon"}
        The first pair of names came from iana, the second pair of names came from ISO 639-3. From this list of four names, Module:Lang will only take the first name. Because the testcases code takes names from the ISO 639-3 module, wherever the ISO 639-3 name-order differs from the iana name-order, the test will fail. Also, the test will fail because Module:lang and ~/sandbox strip the parenthetical disambiguators but the reference lists retain them.
        If these are going to be the tests against which Module:lang is validated, the static reference lists must be correct. They are not while they derived from the ISO 639-3 module and retain disambiguation. For the category_from_tag() tests, the reference lists will need to retain the disambiguators.
        Trappist the monk (talk) 20:01, 21 September 2020 (UTC)
        But if I get the data from the iana file, how do I know what ISO it is? If you have fixes to the testcases feel free to change anything there as I'm not sure how to proceed here. --Gonnym (talk) 22:58, 21 September 2020 (UTC)
        Module:Lang could not care one whit about ISO parts. Is the code valid? Should it be promoted from three-characters to two? Humans might care simply for the purposes of organization (else we wouldn't sort the list) but Module:lang just does not care. Maybe I'll poke around tomorrow. I'm currently hacking an awb script to remove the no-longer-needed positional parameters from {{Category articles containing non-English-language text}}.
        Trappist the monk (talk) 23:35, 21 September 2020 (UTC)
        If we don't split it by ISO that could work. Before you use the script, let me know please. I'm using the positional parameters to validate categories before G8 them. Also, I'd like to standardize the template names so was thinking of renaming it to "Non-English-language text category" to match the source one, but wasn't sure yet. --Gonnym (talk) 23:56, 21 September 2020 (UTC)
        awb script ready to go when you are.
        I tweaked Module:Lang/testcases/ISO 639-1 name from tag to remove disambiguators; all tests pass. In thinking about doing the same for Module:Lang/testcases/ISO 639-3-1 name from tag it occurs to me that there is no need to keep all of the assigned names since Module:lang only looks at the first one so it will simplify the undabbing to undab only the first name.
        Trappist the monk (talk) 09:58, 22 September 2020 (UTC)
        If lang will never support finding the tags of the alternative names then I guess you are right. If in the future that changes, we can adjust the tests again. I'll make a final pass of the /documentor module and update to live so you can use the script. --Gonnym (talk) 10:04, 22 September 2020 (UTC)
        /documentor and changes live. --Gonnym (talk) 10:44, 22 September 2020 (UTC)
        I tweaked Module:Lang/testcases/ISO 639-3-1 name from tag to remove disambiguators. Because it is necessary to look at each language code to exclude ISO 639-1 codes, I also used that opportunity to pare the list to those codes specified by the range so I removed the range restrictions from the call to testcases_name_from_tag(). No errors testing Module:Lang/sandbox against the list. When I tested Module:Lang against the list there are errors. I expect that because Module:Language/data/wp languages overrides codes that Module:lang/data does not yet know about. I can use that to get a definitive list of updates needed in ~/data.
        Still an issue with timeout so I shortened the 639-3-1 from a–h to a–f. Famous last words, the change that you mentioned should not have made Module:Lang/sandbox run slower unless time spent creating a data module doesn't count. The change spins through Module:Language/data/iana scripts, Module:Language/data/iana regions, and Module:Language/data/iana suppressed scripts to set the keys to lowercase. It might be better to just modify local script and region indexes to their canonical form because they are generally rarely used. I'll see if that makes a difference.
        Trappist the monk (talk) 12:13, 22 September 2020 (UTC)
        Astonishing. Doing as I just suggested speeds up everything to the point that a single testcase can do all of the three-character code testing without timing out (close at 9.7 seconds ... but gets it done).
        Trappist the monk (talk) 14:27, 22 September 2020 (UTC)
        Wow, that's really is amazing. I thought that the ISO3s would always time out because of the amount of entries in the list, not because of the time it took. Learn something every day :) --Gonnym (talk) 14:42, 22 September 2020 (UTC)
        Are you sufficiently finished with G8ing that I can run the awb script?
        Trappist the monk (talk) 16:52, 24 September 2020 (UTC)
        Yeah, I'm done as I don't know which of those will be valid or not. It's also just a not a lot left so I can manually check the pages. --Gonnym (talk) 17:17, 24 September 2020 (UTC)
        Ok, I'll run it over the next few days.
        Trappist the monk (talk) 17:21, 24 September 2020 (UTC)
  • Completely unrelated to your question, but something I was thinking about while writing the /testcases. I wonder if our current data structure is the best and most optimal one we have. Currently, we do a lot of changing of values based on overrides and reverse lookup is quite taxing. I was thinking that if we change our structure to a static one, we could save a lot of time and code. What I mean is something like this: make files -> static ISO-# list -> static complete list. The complete list would be in a format like this: [code] = {type = {iso#, ... }, primary = "primary_name", alt_names = {"", ...}, local_overide = bool (might not be needed), prefixes = {"", ...}, (used in the variants tables), article_override = ""}. This way when we need to get the "correct" title for a category, it would be as easy as table[code].primary and using that name. We can also then have a reverse static table which is just in the format of [language] = "code". These static pages would need to be updated only whenever a change to the data is wanted. Probably hundreds of things I didn't think about wanted to share :) --Gonnym (talk) 16:22, 21 September 2020 (UTC)


@Trappist the monk: does the Module:Lang/testcases/ISO 639-3-1 name from tag 3-2 and 3-3 now include -2 and -5 codes? If so I'll move the names and delete the commented out modules. --Gonnym (talk) 19:00, 22 September 2020 (UTC)

All of ISO 639-1 and -2T are in the iana list; none of the ISO 639-2B are in iana; all of ISO 639-3 except hbs (a deprecated code though still listed in 639-3) are in iana; all of ISO 639-5 except bih (promotes to bh) are in iana; none of the deprecated ISO 639 codes are in iana. I do not think that there is much value to keeping the ISO 639-2B, ISO 639-2B, and ISO 639 (dep) tests. Also, I have disabled the variant description-as-language-name so that test can be withdrawn.
Trappist the monk (talk) 23:08, 22 September 2020 (UTC)
I think that there is a problem with the category_from_tag() testcases. For example, Module_talk:Lang/testcases/ISO_639-1_category_from_tag runs but if you look in the parser profile data:
Lua memory usage: 48.96 MB/50 MB
I took those same {{#invoke:}}s into Test page and previewed:
Lua memory usage: 13.76 MB/50 MB (sandbox)
Lua memory usage: 14.32 MB/50 MB (live)
Module_talk:Lang/testcases/ISO_639-2_category_from_tag has more tests (486 vs 185) and uses less memory:
Lua memory usage: 27.32 MB/50 MB
I got similar results from the independent live and sandbox tests with the 486 -2 {{#invoke:}}s: 13.76 and 14.43 MB
this test can go away
All of Module_talk:Lang/testcases/ISO_639-3-1_category_from_tag, -2, -3 run out of memory
Lua memory usage: 50 MB/50 MB
Module_talk:Lang/testcases/ISO_639-5_category_from_tag has fewer tests (115 vs 486) but uses almost the same amount of memory as the -2 test:
Lua memory usage: 25.59 MB/50 MB
this test can go away
Module talk:Lang/testcases/ISO 639 deprecated category from tag:
Lua memory usage: 31.35 MB/50 MB
this test can go away
Module talk:Lang/testcases/ISO 639 deprecated category from tag:
didn't test
this test can go away
So these data suggest that there is something wrong with the testcases?
Trappist the monk (talk) 12:19, 23 September 2020 (UTC)
I'll take a look. They all originally ran when I did them, but the bigger ones were always fragile. I'll see what changed. --Gonnym (talk) 12:22, 23 September 2020 (UTC)
As a quick answer, this test is the only one comparing the same exact code live and sandbox, and not to a specific table. So maybe that is why, as other than that, it just does a simple code extraction so the table can be made. --Gonnym (talk) 12:25, 23 September 2020 (UTC)
Maybe the get_ietf_parts (source, args_script, args_region, args_variant) function * the amount of codes is just too much for it? --Gonnym (talk) 12:28, 23 September 2020 (UTC)
I'm skeptical. get_ietf_parts() is also used by name_from_tag(). Looking at memory usage for Module_talk:Lang/testcases/ISO_639-3-1_name_from_tag: 2492 tests
Lua memory usage: 46.92 MB/50 MB
and doing the independent live and sandbox tests of those same {{#invoke:}}s:
Lua memory usage: 13.76 MB/50 MB (sandbox); recognize that number?
Lua memory usage: 14.5 MB/50 MB (live)
I wondered what would happen if I changed to a static table of category names, bypassing ~/documentor tool entirely like this:
local p = require('Module:UnitTests')

function p:test_lang_ietf()
	self:preprocess_equals_preprocess_many('{{#invoke:Lang/sandbox|category_from_tag|', '}}', '', '',
		{"aa", "Category:Articles containing Afar-language text"},
		{"ab", "Category:Articles containing Abkhazian-language text"},
		{"ae", "Category:Articles containing Avestan-language text"},
		-- all of the other code / cat names here ...
		{"zu", "Category:Articles containing Zulu-language tex"},
		}, {nowiki=1})

return p
Lua memory usage: 14.22 MB/50 MB (sandbox)
Lua memory usage: 14.55 MB/50 MB (live)
So, it would seem that the memory problem isn't caused by Module:lang, Module:lang/sandbox, or Module:UnitTests.
Trappist the monk (talk) 13:42, 23 September 2020 (UTC)
I don't think your conclusion is correct. What you did is removed all the processing time and complexity by just writing two strings. Of course that would work better. The previous one retrieved a list, removed the language and left only the codes, sorted it, then compared the sandbox code to the live code (again, two invokes, compared to one invoke in the other testcases), which requires much more time and actual processing to work. The above example, is not really flexible, as you'll have to make sure the ISO list is always in sync with whatever dataset you are using (and these things always fall out of sync) and in case you change something in the category structure, you'll have to make sure it is also updated here. But I will say this (which I said a few times on this page before), the way we are using the /data isn't the optimal way as the data is static, but we are generating it dynamically for no reason. --Gonnym (talk) 13:52, 23 September 2020 (UTC)

Some of what you say is no-doubt true. I continue to believe that there is something amiss in the Module:Lang/documentor tool version. This hack creates a list of codes and expected results from Module:Lang so that Module:UnitTests can test Module:Lang/sandbox. I extended the code_mask out to [^a-m]%l%l without overrunning memory (which happened at [^a-n]%l%l). The current version of Module:Lang/testcases/ISO_639-3-1_category_from_tag overruns memory even when constrained to range = "^[a]".

local p = require('Module:UnitTests')

local cat_from_tag = require ('Module:Lang')._category_from_tag;				-- use Module:Lang to create the 'expected results'
local iana_data = mw.loadData ('Module:Language/data/iana languages');			-- use the iana data
local code_mask = '^[a-h]%l%l';													-- used to limit number of tests

--[[--------------------------< T E S T _ P A T T E R N S _ G E T >--------------------------------------------

build a table of test patterns where each entry in the table is a table with two members:
	{"<code>", "<cat name according to Module:Lang>"}


local function test_patterns_get ()
	local tpats = {}															-- collect test patterns here
	for code in pairs (iana_data) do											-- list of names not needed here
		local pattern = {};														-- here we assemble the test pattern for <code>
--		if 2 == code:len() then													-- no limits for two-character codes
		if code:find (code_mask) then											-- if code within limits (three-character codes)
			table.insert (pattern, code);										-- add it to the pattern
			table.insert (pattern, cat_from_tag ({code}));						-- call module:lang and add the 'expected results' for code to pattern
			table.insert (tpats, pattern);										-- accumulate in list of patterns

	local function comp (a, b)													-- local function used by table.sort()
		return a[1] < b[1];														-- assending sort by code
	table.sort (tpats, comp);													-- make the list pretty
	return tpats;																-- and done

local test_patterns = test_patterns_get();

--[[--------------------------< T E S T _ C A T E G O R Y _ F R O M _ T A G >----------------------------------

function p:test_category_from_tag()
	self:preprocess_equals_preprocess_many('{{#invoke:Lang/sandbox|category_from_tag|', '}}', '', '', test_patterns, {nowiki=1})

return p

Vaguely related, because Module:Lang won't be using data from the ISO 639 tables, perhaps the testcases names should be changed to something along the lines of:


Trappist the monk (talk) 16:10, 23 September 2020 (UTC)

I removed one invoke and it runs (without any actual valid result of course). I removed the code not needed anymore from the /documentor tool but there is not a lot more optimization that can happen there as all it does it gets the data ready to call the module. As a test what we can do is create a static table of the iso codes, pass it to it and just call the lang module and see if it runs or not. Regarding the names, I agree they need to be changed. I was thinking maybe /iana but yours seems to be better. Feel free to move them. --Gonnym (talk) 17:06, 23 September 2020 (UTC)
Ok, so the test passed. But I'm still not sure why it failed before. --Gonnym (talk) 17:17, 23 September 2020 (UTC)
I don't have an answer. So, I propose to replace the category_from_tag() tests with clones of the above test so that there is something to test against. I will likely do something similar for the tag_from_name() testcases (the last thing I'm working on before updating Module:Lang) – I can test the ISO 639-1 codes but the -3 testcases overrun memory because I-don't-know-why. After the update we can revisit the question of how to consolidate these tests?
Trappist the monk (talk) 13:56, 24 September 2020 (UTC)
The latest change you did causes it to timeout simply because you asked for the value in the for loop. I have no freaking idea why the lua here is so fragile that it can't handle that. But to your question, yes, let's make the code work, even if ugly, and try and clean it up after it goes live. Semi-related to this, in Module:Lang/data you have override tables which are in the format of: k = {}. My question is, can an override even be more than one? If it can't, wouldn't a: k = "" (string) be more efficient? --Gonnym (talk) 14:10, 24 September 2020 (UTC)
I did it as tables so that whatever read the value from any table didn't have to first ask if value is a table or a string. Right now, the iana data modules are loaded as part of Module:Language/name/data; reprocessing those same modules again to make the value strings seemed a waste. When I moved loading of the data modules into Module:Lang/data/sandbox for this upcoming update, it did occur to me to change the override table and to also change the loaded forms of Module:Language/data/iana languages, Module:Language/data/iana regions, and Module:Language/data/iana scripts because from them we take only the first name; Module:Language/data/iana variants and Module:Language/data/iana suppressed scripts are oddballs; I violated my own rule with Module:Lang/ISO 639 synonyms which uses string values ...
Now that all of these are handled inside ~/data/sandbox, switching all except ~/iana variants and ~/iana suppressed scripts is something to think about.
Trappist the monk (talk) 14:49, 24 September 2020 (UTC)

Arrowverse task force‎Edit

  As someone who has frequently edited the Arrowverse article in the past, you may be interested in participating in the newly created Arrowverse task force‎. -- /Alex/21 03:43, 25 September 2020 (UTC)

fix needed for Template:Non-English-language text category?Edit

Have a look at Category:Articles containing Jewish Babylonian Aramaic (ca. 200-1200 CE)-language_text. In the first line, the language name is redlinked and disambiguated. Is that the correct thing to do?

Would it be better were the template to use the disambiguated language name there?

Also, shouldn't the "This category should only be added ..." proscription be the last line of text rendered by the template?

Trappist the monk (talk) 13:28, 25 September 2020 (UTC)

Not sure I understood the first question. the language name is redlinked and disambiguated and Would it be better were the template to use the disambiguated language name there? seem to be the same, or did you mean non-disambiguated name? So in that case, your suggestion is to do an exists() check on the title, if it doesn't, then de-dab and use that name?
Regarding the order of text, I used the exact one from the original template, but looking at the text, the order seems ok-ish. Line #1 gives the scope, line #2 says what template controls what pages are added and line #3 gives an example of how that template is used. But if you feel a better order (or text) is available, go for it (just keep the strings in the string.format style). --Gonnym (talk) 13:35, 25 September 2020 (UTC)
I was trying to ask if the first sentence should at read like this (no disambiguation in the wikilink):
This category contains articles with Jewish Babylonian Aramaic text.
That rendering uses {{lang|fn=name_from_tag|tmr|link=yes}} – no exists() check required. And, you already use name_from_tag() for the language tag in the {{tlx}} template expansion.
No matter how I rearrange the sentences in that template, I'm never really happy with it. I'll think on it some more; perhaps a complete rewrite is required. If that is the case, I'm doubtful that such an effort is really worth the time...
Trappist the monk (talk) 15:11, 25 September 2020 (UTC)
Oh, I now I understand. So you want to remove the manual link that has the word "-language" with the link provided by the lang template?
Are the above examples all ok (I think it covers all variations)?
Regarding the re-write, if you come up with a better style, I don't have a problem implementing it. It should* be pretty straight forward. --Gonnym (talk) 15:19, 25 September 2020 (UTC)
Sort of. Except for the collective codes, should include '-language' which, for consistency should probably be linked because 'languages' from the collective codes names will be linked:
Make sense?
Trappist the monk (talk) 15:35, 25 September 2020 (UTC)
Yeah, now it's clear. I'll see what I can do. --Gonnym (talk) 15:37, 25 September 2020 (UTC)
Ok, the /sandbox seems to be working with the above examples. --Gonnym (talk) 16:00, 25 September 2020 (UTC)
Yeah, works for me.
Trappist the monk (talk) 16:18, 25 September 2020 (UTC)
That does mean though that you should probably implement my list of language link dab fixes as these categories shouldn't have those links that lead to them. --Gonnym (talk) 16:02, 25 September 2020 (UTC)
I don't know what you mean by that. Explain?
Trappist the monk (talk) 16:18, 25 September 2020 (UTC)
Since the links are now generated by the module itself, we should implement the fixes I posted at Module talk:ISO 639 name. See Category:Articles containing Tonga (Zambia)-language text as an example, where the live version gives the correct link, while the /sandbox version sends to the dab page (the iso link at the bottom also used the module link). --Gonnym (talk) 16:23, 25 September 2020 (UTC)

Duplicate override listsEdit

@Trappist the monk: Now looking more closely, it seems we have duplicate override tables at Module:Lang/data and Module:Language/data/ISO 639 override. Can we merge this, so we don't need to maintain two lists like this and for the ISO to call the general one just for the data it needs (or the other way around)? --Gonnym (talk) 16:51, 25 September 2020 (UTC)