Wiktionary:Grease pit/2015/December

Can entries in Category:Korean Han characters and Category:Vietnamese Han characters be made non-lemmas?

1. Because they are not lemmas.
2. It also makes difficult to track newly created lemmas. --Anatoli T. ^{(обсудить}/^вклад) 03:41, 1 December 2015 (UTC)

Category:Zhuang Han characters probably belong there too. The choice for Japanese lemmas is not always straightforward (kanji, hiragana or katakana or all three). --Anatoli T. ^{(обсудить}/^вклад) 03:43, 1 December 2015 (UTC)

(According to Wikipedia Sawndip may still be in use. Category:Zhuang lemmas in Sawndip script?) —suzukaze (t・c) 19:15, 8 December 2015 (UTC)

@suzukaze-c Thanks, Korean hanja are not completely out of use either but are they lemmas? --Anatoli T. ^{(обсудить}/^вклад) 00:57, 10 December 2015 (UTC)

I do not know enough about Korean to say. Although, I note that Korean Wikipedia uses hanja to help disambiguate 여진 (餘震, yeojin, “aftershock”), 여진 (女眞, yeojin, “Jurchen”), and 여진 (如津, Yeojin, "son of "Yuri of Goguryeo") —suzukaze (t・c) 01:04, 10 December 2015 (UTC)

Yes, you're right but hangeul entries is the main Korean writing system, so they get pronunciations, synonyms, expanded definitions and topical categories. Hanja entries only serve as soft redirects and yes, disambiguations of numerous homophones. --Anatoli T. ^{(обсудить}/^вклад) 01:12, 10 December 2015 (UTC)

Is there a way to add a sense id to individually linked words in a template, such as {{l|en|] ] ] ] ].}}? If there isn't, should there be, and what should the syntax look like? Pinging CodeCat. --WikiTiki89 15:04, 1 December 2015 (UTC)

A section link # is probably the most intuitive. —CodeCat 15:22, 1 December 2015 (UTC)

But then the language name must be written manually. And the link must be piped manually as well if it was not already. --WikiTiki89 15:43, 1 December 2015 (UTC)

Not necessarily. Module:links can be modified so that it fixes these things. —CodeCat 16:29, 1 December 2015 (UTC)

So how will the module tell the difference between a sense-id and a language name? In fact, these could happen to coincide. --WikiTiki89 16:30, 1 December 2015 (UTC)

Senseids include the language name, such that {{senseid|en|asdf}} generates and {{l|en|id=asdf}} links to #English-asdf. — Ungoliant ^(falai) 16:32, 1 December 2015 (UTC)

Depends how you look at it. I would consider "asdf" to be the sense-id and "English" to be the language name that would have been part of the link anyway. You wanna be able to do {{l|en|] ] ] ] ].}} and not have to do {{l|en|] ] ] ] ].}}; and in fact maybe it's a good idea to indicate the sense-id by beginning it with -. --WikiTiki89 16:41, 1 December 2015 (UTC)

Why would that be necessary? —CodeCat 16:54, 1 December 2015 (UTC)

So that {{l|en|] ] “]”}} would link to Deutsch#German, while {{l|en|] ] “]”}} would link to Deutsch#English-German. --WikiTiki89 17:59, 1 December 2015 (UTC)

Our templates have never supported mixing of languages. To introduce that would be hard. —CodeCat 20:59, 1 December 2015 (UTC)

I thought that they did. At least in the sense that they allowed links like the one above. --WikiTiki89 21:05, 1 December 2015 (UTC)

No, that never worked. The section link would go to the right place, but the word would still be tagged as English. —CodeCat 21:10, 1 December 2015 (UTC)

That's exactly what I just said. It worked in the sense that the link worked. And I would oppose breaking that functionality. --WikiTiki89 21:24, 1 December 2015 (UTC)

I don't think the parameter for transliteration in {{kjh-noun}} is working. (See the entry пӱӱр to see why.) --Lo Ximiendo (talk) 10:31, 2 December 2015 (UTC)

The documentation in Template:kjh-noun says you need to supply |override=1 for the translit to be respected. Benwing2 (talk) 10:49, 2 December 2015 (UTC)

@Atitarev: What's your take on this? --Lo Ximiendo (talk) 07:39, 6 December 2015 (UTC)

I haven't designed Khakas headwords or the empty do-nothing Module:kjh-translit, of course it's not working: пӱӱр (püür). --Anatoli T. ^{(обсудить}/^вклад) 07:55, 6 December 2015 (UTC)

An IP blanked out the whole module back in October. I reverted it, but it doesn't look like that's where the transliteration was coming from, anyway. Chuck Entz (talk) 08:21, 6 December 2015 (UTC)

Thanks, Chuck. I have enabled Khakas transliteration in Module:languages/data3/k. The entry now has automatic transliteration. If the transliteration should stay 100% automatic (and override manual), then it should also stay in Module:links (override_translit list). --Anatoli T. ^{(обсудить}/^вклад) 10:08, 6 December 2015 (UTC)

I request that "Category:xxxx entry maintenance" (such as Category:Portuguese entry maintenance) not be hidden. It serves as the umbrella category for other maintenance categories of a certain language, I don't see any reason to make it hidden. I was unable to do it by editing Module:category tree/poscatboiler/data/entry maintenance. --Daniel Carrero (talk) 23:04, 2 December 2015 (UTC)

This is actually a bug that's caused by a deficiency in the module. The module doesn't currently allow for any particular way to indicate that a category should be hidden, so as a "hack" I added __HIDDENCAT__ to the descriptions of some of the categories. However, since categories also include a list of subcategories with their descriptions, this also brings in the hidden tag, and hides the parent category. It should be fixed for sure. —CodeCat 23:12, 2 December 2015 (UTC)

Ok it's now fixed. Categories can now be given the property hidden = true in the data module; much more straightforward. —CodeCat 23:23, 2 December 2015 (UTC)

That's great! Thanks. --Daniel Carrero (talk) 23:24, 2 December 2015 (UTC)

@Daniel Carrero: Just to let you know know, English has a subjunctive, so you have to say "I request that X not be hidden." What you said sounds awkward because it sounds like you are requesting that they are already not hidden, which makes no logical sense. --WikiTiki89 00:14, 3 December 2015 (UTC)

Ok, thanks. I fixed that mistake in my initial message. --Daniel Carrero (talk) 00:24, 3 December 2015 (UTC)

I wouldn't call it a mistake. Some dialects of English prefer "I ask that they not be hidden" while others prefer "I ask that they are not hidden". Context and pragmatics permit the latter to be interpreted correctly rather than in a nonsensical way. —Aɴɢʀ (talk) 08:45, 6 December 2015 (UTC)

I guess you're right, but I think that that is more common with verbs other than be. --WikiTiki89 16:55, 7 December 2015 (UTC)

I have heard this is partly an American vs. British thing, with British English avoiding the subjunctive, although I don't know as I speak American English. Certainly, "I ask that they are not hidden" sounds strange to me as a request. Benwing2 (talk) 13:24, 10 December 2015 (UTC)

I speak American English and would require the subjunctive to understand what was evidently intended. DCDuring TALK 13:45, 10 December 2015 (UTC)

If anyone is willing and able to help write a template or two, Borovi4ok says that he has been long in need of a template for Bashkir nouns and verbs. User: Sinek has attempted to do some, such as {{ba-noun-c}}, but there were some problems that he could not handle. Borovi4ok can provide all the details and just needs somebody to make the actual template(s). Can anybody help? Contact Borovi4ok. —Stephen ^(Talk) 04:18, 3 December 2015 (UTC)

@Borovi4ok: write the documentation first so that everybody can see. Then link the page here. --DixtosaBOT (talk) 05:50, 3 December 2015 (UTC)

@Stephen G. Brown:, @DixtosaBOT:, thanks a lot for your help.

Let me describe the situation, as I see it.

The Bashkir noun template already exists ({{ba-noun-c}}), and it works fine in most cases. I need someone to help me correct the error in it. Dixtosa, can we do that?

I am ready to write up a documentation for it. When we're done with the noun template, I can create the documentation for the verb template, so we can create it.

I need an example or a master of noun declension template, regardless of the language. Borovi4ok (talk) 14:48, 15 December 2015 (UTC)

You can look over Georgian noun declension template

If you notice you have hard time coming up with the documentation then you can just succinctly describe the grammar of Bashkir.--Dixtosa (talk) 16:48, 15 December 2015 (UTC)

There are currently two noun templates for Bashkir: {{ba-noun-c}} (for nouns that end in a consonant) and {{ba-noun-v}} (for nouns that end in a vowel). —Stephen ^(Talk) 05:20, 16 December 2015 (UTC)

I am currently trying to escape my bête noire. There are currently 232 entries with the oldest rft tags, listed down the right side of WT:TEA. This stems from the implementation of archiving WT:TEA in order to avoid "yet more completely wasted time." @DCDuring "There is a thread in the Beer Parlour about that..." @CodeCat "The problem is, the rft tags don't seem to have taken off any of the pages..." @Prosfilaes

The discussion in July 2012 led to a proposed solution from DCDuring TALK; "I had imagined a template that had a given archive subpage as an argument and could be subst'ed at the bottom of an entry's talkpage. It would be nice to include a user-friendly identifier like month and year of the discussion in the talk page heading, eg, "==Tearoom discussion March 2012==". This would both help users directly and serve to distinguish multiple discussions. As we don't want discussions to continue in the archive, we might want to provide some kind of message to encourage anyone interested in trying to continue the discussion to do so on the talk page." "Even better, if you're willing to do the work, I'll make a template that will make it pretty fast..." said @Metaknowledge

To recap; "While tea room items don't "require" resolution, it is annoying to see a tag on an entry saying "The Tea Room is currently discussing this word" only to find that the tea room hasn't been discussing this word for months or even years." @Angr But it is even more so to eventually see a "required" solution only to find that [[Wmg iktionarians]] haven't been discussing this tea room resolution for months or even years, and it has grown cool. Though a template was create, it was soon deleted, noting that @-sche "...would have no problem with the recreation/restoration of the template by anyone interested in using it." Meanwhile in February 2014 the {{rft}} template was edited to include /{{CURRENTYEAR}}/{{CURRENTMONTHNAME}} In December 2014 @Kephir deleted "a Template:rft-archived template which doesn't have to be subst:ed". @Mglovesfun Also about this time, November Template:PREVIOUSYEAR, I attempted to reheat the discussion, and failed.

I would like to propose renewing Template:rft-archived documentation, and implementation to a programmer(s) with know how in WT:GP? Riverstogo (talk) 01:28, 6 December 2015 (UTC)

Here is another piece of archived discussion from WT:RFDO. Many templates were deleted because like {{rft-archived}} "templates can be simply substituted to yield their replacement". @Kephir This discussion appears to have been archived in a way that makes it difficult to find and impossible to edit? All of which has increased the size of my bête noire. While still wondering if all of my pings failed I would like to suggest an approach starting by editing rft template Usage documentation, perhaps {{temp|rft|2=fragment=year/month/title of Tea room discussion (for linking purposes)}}? Riverstogo (talk) 08:54, 6 December 2015 (UTC)

I didn't get your ping. As I understand it, the ping has to be in the same paragraph as a signature. —Aɴɢʀ (talk) 09:46, 6 December 2015 (UTC)

To again send out pings that failed @CodeCat @Prosfilaes @Metaknowledge @-sche @Mglovesfun. Riverstogo (talk) 22:25, 6 December 2015 (UTC)

Please don't mistake my comment for a technical recommendation about how to implement something that would achieve the result, which I still think is worthwhile. I am not competent to give truly technical advice other than the generic KISS. DCDuring TALK 13:14, 6 December 2015 (UTC)

To KISS I will continue to summarise my mistakes, though I am neither competent to assess truly technical advice about how to implement something, nor which is worthwhile . Riverstogo (talk) 22:25, 6 December 2015 (UTC)

The discussion; aWa: Archiving discussion to Template talk:archive box by User:Kephir, January 2015 "is no longer live and is left here as an archive. Please do not modify this conversation, though feel free to discuss its conclusions."

One conclusion was discussed in June, "And this is what you get when you archive discussions the "relaxing" way. (You might want to look at WT:RFDO#Archive templates.)" User:Kephir said referencing with the same now inaccurate link, that the aWa archiving tool made inaccurate, in a somewhat arbitrary and less "relaxing" way. At least from where I stand at the bottom of the steep learning curve. Riverstogo (talk) 22:25, 6 December 2015 (UTC)

Yes, I've said this before that {{rft}} should take a year-and-month timestamp as an argument. This would both make it link to the correct archive page and make it easier to find and remove really old ones. --WikiTiki89 16:58, 7 December 2015 (UTC)

Going forward this would be very useful, especially if it could be automatic. Retrospectively, would it be worth the effort to have a bot find each archived TR discussion (with a well-formed title) and insert links to it on the appropriate talk page? Ideally, the links would only be inserted where the talk page did not already contain or reference the discussion. DCDuring TALK 17:34, 7 December 2015 (UTC)

I support the idea of having a template which can be subst'd on the talk page along the lines of "==Tea room discussion== This item was discussed in the Tea Room at such-and-such a date." Also, I'm not sure if this is being suggested, but the {{rft}} tags should also expire and hide themselves after a month or so, and then be deleted by a bot or human. —Pengo (talk) 05:50, 10 December 2015 (UTC)

@CodeCat I've started to work on Module:tearoom. It's very rough so far, but as a proof of concept, it shows the date functions work for working out whether a tearoom discussion has been archived, and it can generate an url to the archived discussion (from the year and month expressed as numbers). See examples here User:Pengo/tearoom2 ("edit" to see source and get an idea of what it's doing). WIP. I don't know if I'm reinventing any wheels here, but it seems to be easier to start from scratch than to even begin to search for existing code/modules (really, I have no idea where to look). If anyone wants to push it ahead faster then please feel free to continue on it. Pengo (talk) 07:56, 10 December 2015 (UTC)

So, the "Reconstruction:" namespace has been implemented, but there's a problem: the "Reconstruction talk:" namespace has a stray comma after the word "talk", e.g. Reconstruction talk,:Proto-Indo-European/albʰós. This should be fixed before any more pages are moved, but I don't know whom to report it to. —Aɴɢʀ (talk) 17:50, 7 December 2015 (UTC)

Pinging @Koavf, who seems to be making a lot of the moves. —Aɴɢʀ (talk) 17:52, 7 December 2015 (UTC)

@Angr: I stopped just in case it's a problem. I don't think it will be to rename them but still. —Justin (koavf)❤T☮C☺M☯ 17:53, 7 December 2015 (UTC)

OK. Other things that need to be fixed: (1) The headword line templates like {{head}} and its language-specific equivalents need to put words in Reconstruction: namespace into categories (Reconstruction:Proto-Indo-European/albʰós is currently uncategorized). (2) The link templates like {{l}} and {{m}} need to point to Reconstruction: namespace instead of Appendix: namespace. Obviously this can wait until all pages have been moved, since for now the links to Appendix: simply redirect to Reconstruction: and thus nothing is broken. —Aɴɢʀ (talk) 18:00, 7 December 2015 (UTC)

I've updated the modules I could find, except Module:links. —CodeCat 18:13, 7 December 2015 (UTC)

The talk namespace has been fixed, thanks for getting that fixed, CodeCat! Can a bot now start moving the pages, or do we want to have a discussion and possible vote about how to name Reconstruction pages ("Reconstruction:Proto-Indo-European/albʰós" vs. "Reconstruction:albʰós#Proto-Indo-European" vs. whatever) first? —Aɴɢʀ (talk) 07:36, 9 December 2015 (UTC)

I'd prefer the latter option, but I do not know whether we need to have a vote. Also wasn't there some question about the whether the namespace would be marked as content that needed voting? —JohnC5 19:17, 9 December 2015 (UTC)

Hello from en.Wikisource. I had edited a page on Wikisource with a link to Wiktionary for an archaic word. A very useful and allowed annotation. I checked the link and left the Wikt page open, finished editing and later wanted to get back to the Ws page—thought I would be clever and clicked on "What links here" on the Wikt page. Disappointed it didn't show my link in Ws. Is this because there is a time delay for inter-wiki links to happen or do they just not show up on "What links here"? If the latter, this seems an opportunity lost... My link could provide context? Cheers, Zoeannl (talk) 23:12, 7 December 2015 (UTC)

Special:WhatLinksHere does NOT link to other WikiProjects. Not other Wiktionaries nor other English WikiProjects. I think what you're proposing sounds like a Toolserver thing. Renard Migrant (talk) 23:20, 7 December 2015 (UTC)

I have wished for over 10 years that there was a way to see links from other Wikiprojects. It would make cleaning up broken links much easier. And it must be possible, since Commons does show usage of its files on all Wikiprojects. —Aɴɢʀ (talk) 06:47, 8 December 2015 (UTC)

Is there anyone we can ask at Commons? Toolserver? Totally out of my league. Cheers, --Zoeannl (talk) 20:14, 10 December 2015 (UTC)

@Zoeannl The request would have to be at Phabricator, and from memory there was a similar sort of request made, and the fact is that they are separate data bases and unable to be interconnected by the system to the amount of backend processing. ToolLabs or Quarry could both generate the data and hold it outside of the wiki. Couldn't you put in as a quotation to the use of the word, eg. vespertine. One of the aspects of Wikidata is that it is able to manage a better link process for primary links.

The other process that has recently had traction is the Community Wishlist that is run from meta: — billinghurst sDrewth 11:32, 18 December 2015 (UTC)

There are currently 4 different gadgets for slightly changing the formatting of "form of" definitions, i.e. definitions such as "First-person singular (eu) present subjunctive of dançar". According to Special:GadgetUsage, these are among the least used gadgets on the project. Of the four, only FormOfPlain is used by any active editors, and it's only used by 2. The content of these gadgets is just a trivial snippet of CSS which could easily be added to a user's custom CSS. See for example, MediaWiki:Gadget-FormOfPlain.css. Since these gadgets aren't being actively used, I propose that they be retired. Kaldari (talk) 00:38, 10 December 2015 (UTC)

Is there any point to this? Why do we need to cut down on gadgets? —Μετάknowledge^{discuss/deeds} 23:29, 13 December 2015 (UTC)

@Metaknowledge: The reasons are , , and . Basically, having more options leads to a worse user experience. In this case, the gadgets in question aren't being used by anyone, and only serve a very obscure (and rather pointless) purpose. The cost of listing them (per the 3 sources above) is far greater than the cost of removing them. Kaldari (talk) 00:35, 16 December 2015 (UTC)

Here's an even better source that lists numerous resources on the topic: http://uxmyths.com/post/712569752/myth-more-choices-and-features-result-in-higher-satisfac. Kaldari (talk) 00:41, 16 December 2015 (UTC)

No offence intended, but that's a rather silly misuse of those studies. I am struggling even to estimate how low of a priority this is. —Μετάknowledge^{discuss/deeds} 00:45, 16 December 2015 (UTC)

@Metaknowledge You don't need to estimate the priority. I can remove them myself. I just wanted to make sure no one objected. Kaldari (talk) 00:51, 16 December 2015 (UTC)

There is currently a gadget to move the {{was WOTD}} template to the absolute top-right position on the page (rather than the top-right of the body content). According to Special:GadgetUsage this gadget has only been turned on by 20 users, none of which are currently active. The gadget consists of a 2-line snippet of CSS which could easily be added to a user's custom CSS instead. Since this gadget isn't being actively used, I would like to propose that it be retired. Kaldari (talk) 00:50, 10 December 2015 (UTC)

To quote Metaknowledge (just up the page): "Is there any point to this? Why do we need to cut down on gadgets?"​—msh210℠ (talk) 19:29, 15 December 2015 (UTC)

@Msh210 See my reply above. Kaldari (talk) 00:36, 16 December 2015 (UTC)

Someone please capitalize the following (marked) characters in the MediaWiki:loginprompt system message:

Meta-Wiki, Mediawiki, Wikibooks, Wikimedia commons, Wikimedia incubator, Wikinews, Wikipedia, Wikiquote, Wikisource, Wikispecies, Wikiversity.

Thanks. - dcljr (talk) 18:29, 11 December 2015 (UTC)

 Done Equinox ◑ 18:31, 11 December 2015 (UTC)

Can an administrator (or someone of similar power) add...

m = {
	canonicalName = "Loglan",
	type = "appendix-constructed",
	scripts = {"Latn"},
	family = "art",
}

to Module:languages/datax for me?

Additionally, Loglan should be probably set as the ancestor for Lojban (jbo) in Module:languages/data3/j. Thanks for your time :) -Xbony2 (talk) 21:19, 12 December 2015 (UTC)

We don't include constructed languages without getting consensus first, and so far there's never been consensus to include a conlang that doesn't have an ISO 639 code (nor for many that do have ISO 639 codes); see Wiktionary:Criteria for inclusion#Constructed languages. —Aɴɢʀ (talk) 21:39, 12 December 2015 (UTC)

That's not exactly true. There's no consensus to add Loglan entries in mainspace, but they could be added in an appendix (once the code is added, of course). —Μετάknowledge^{discuss/deeds} 23:28, 13 December 2015 (UTC)

I don't think there should be any appendixes either. Our current practice is two-faced: we say no, you can't include it, but then we let it be included anyway. —CodeCat 23:48, 13 December 2015 (UTC)

I think that appendix entries linked to from the mainspace are useful. For example, many mainspace languages have borrowed terms from languages like Sindarin and Klingon that are appendix-only, and having entries for the terms they are borrowed from adds depth to the etymologies. —Μετάknowledge^{discuss/deeds} 00:23, 14 December 2015 (UTC)

That's a good point. Last summer I created an entry for silflay as an English word, but its etymology is the appendix-only language Lapine. However, I didn't use {{etyl}} for it since we haven't made up a code for Lapine; instead I just put the link to the appendix in the See also section. —Aɴɢʀ (talk) 07:09, 14 December 2015 (UTC)

How come we still need to use a mid2, like this:

 {{top2}}
 ... half the items ...
 {{mid2}}
 ... the other half of the items ...
 {{bottom}}

When Wikipedia gets to do it like this:

 {{div col|2}}
 ... all the items to be listed in two columns ...
 {{div end}}

This has bugged me for ages. Can't we steal their div col related stylesheets and templates? —Pengo (talk) 22:27, 13 December 2015 (UTC)

Agreed, definitely. The first thing we should use it for is translation tables. —CodeCat 22:42, 13 December 2015 (UTC)

I believe WP's "div col" thing only works on some browsers (e.g. it doesn't work on Internet Explorer), while our method works everywhere. —Aɴɢʀ (talk) 07:06, 14 December 2015 (UTC)

Apparently it's supported in IE since 2012, version 10 and up, which leaves us with 3.55% of Wikimedia traffic in June 2015 with versions of IE that don't support it. Enosh (talk) 08:36, 14 December 2015 (UTC)

In that case, make it so. In fact, come to think of it, {{der3}} and {{rel3}} already make columns automatically, so why not have a {{tra2}} for a two-column translation table? It wouldn't even need a separate {{div end}}. —Aɴɢʀ (talk) 10:51, 14 December 2015 (UTC)

{{der3}} and the rest work entirely differently, using Lua to balance the columns. Using it on translation tables isn't a good idea for performance reasons. DTLHS (talk) 16:30, 14 December 2015 (UTC)

We already have {{col-top}} that does this. See how it is used at WT:Wanted entries. --WikiTiki89 18:09, 17 December 2015 (UTC)

How does it look when it's unsupported is the question. Enosh (talk) 18:43, 17 December 2015 (UTC)

There would just be one column. --WikiTiki89 18:47, 17 December 2015 (UTC)

Not that bad, I guess. Enosh (talk) 18:57, 17 December 2015 (UTC)

Unless you're loading water#Translations. —suzukaze (t・c) 08:13, 23 December 2015 (UTC)

Could it be made so that single Han characters are not lumped in with other entries? For example, see Category:Korean entries needing definition where I guarantee that over 90% of these are hanja.

This is different from {{rfdef|Han}}; I am requesting that {{rfdef|lang=ko}} sort into something like Category:Korean Han characters needing definition rather than Category:Korean entries needing definition when used on a page like 乤. —suzukaze (t・c) 06:30, 14 December 2015 (UTC)

] seems to be functional, if ugly. Tests: 㗎#Korean (Han character), 𠂝#Cantonese (exotic Han character), 𪛖#Vietnamese (exotic Han character) 胃腸#Chinese (not a Han character), 경비#Korean (not a Han character). {{rfdef|Han}} would still produce Category:Translingual Han characters needing definition. —suzukaze (t・c) 22:25, 19 December 2015 (UTC)

So there was this discussion on Wiktionary's user-unfriendliness. I already wrote a couple of comments on some issues with the development process and documentation there. But somewhat unrelated to those comments, I think one the largest things we could do to improve the editing experience would be to get rid of the redundant parameters on templates.

Many templates repeat the language code from the heading of a section. It's repeated over and over again. This makes editing error prone and tedious. The unneeded parameters should simply be inferred from the language heading.

Let's simplify templates hugely and remove all the redundant lang=xx parameters.

Current redundant style for templates

(all bold parameters are redundant)

==English==
{{PIE root|en|h₂eǵ}}
{{etyl|enm|en}}
{{IPA|/ˈæk.ʃən/|lang=en}}
{{audio|en-us-action.ogg|Audio (US)|lang=en}}
{{rhymes|ækʃən|lang=en}}
{{en-noun}}
{{context|music|lang=en}}

==French==
{{etyl|fro|fr}}
{{audio|Fr-action.ogg|audio|lang=fr}}
{{IPA|/ak.sjɔ̃/|lang=fr}}
{{fr-noun|f}}
{{usex|une action promotionnelle|lang=fr|t=a promotional campaign}}

Suggested style

(without redundant parameters)

=={{section|English}}==
{{PIE root|h₂eǵ}}
{{etyl|enm}}
{{IPA|/ˈæk.ʃən/}}
{{audio|en-us-action.ogg|Audio (US)}}
{{rhymes|ækʃən}}
{{noun}}
{{context|music}}

=={{section|French}}==
{{etyl|fro}}
{{audio|Fr-action.ogg|audio}}
{{IPA|/ak.sjɔ̃/}}
{{noun|f}}
{{usex|une action promotionnelle|t=a promotional campaign}}

To get a section template working as above, we'd need to install Extension:Variables. Here's the discussion on mediawiki.org where I initially brought it up and got the suggestion of this particular solution. I've also made a larger diff, just to see how much code would be reduced. (I count 28 redundant language parameters or parts of template names on the page "action". I chose that page an example just because it's a word in both English and French).

There would be a lot of work in editing existing templates to use the heading section variable as the default language, and I don't know if "section" would be the best name for the template, and also we'd have to work out what the variables it creates should be called and what syntax we want to use, across templates, to override them, etc.

For now I'm just looking to get a rough idea of what people think of this idea, and if the =={{section|French}}== format is acceptable or if we should try to make a MediaWiki extension which does the same thing invisibly on the backend, allowing the headings to stay as they are, but making the H2 header language name and code available to the templates under it.

All those redundant lang=xx parameters just seem to weigh down the wikitext so much. The code without them seems much clearer, and more intuitive to write and edit, and much easier to memorize the syntax for. Thoughts? —Pengo (talk) 07:38, 20 December 2015 (UTC)

I can vouch for Variables' potential since I've coded stuff for Wikia wikis before (where Variables can be enabled if one asks). But can it cooperate with Lua? —suzukaze (t・c) 07:56, 20 December 2015 (UTC)

If we do this (and I don't know enough about it to say whether it's feasible but it seems like a good idea), I'd rather the parameter for {{section}} (or whatever equivalent we end up using) be en than English. There's less potential for screwing everything up because of a little typo; I'm far more likely to remember djr than to remember how to spell Djambarrpuyngu. —Aɴɢʀ (talk) 08:07, 20 December 2015 (UTC)

I went for "French" over "fr" mainly to keep it as similar to the existing headings as possible. It also keeps it more user-friendly as you don't need to know the code to create a language heading. The idea would be to then pass that heading to a lua module which spits out the language code for use elsewhere in the code. e.g. you'd end up with variable lang_heading=Djambarrpuyngu and lang_heading_code=djr OR you'd end up with an error (if the language was not found). Currently to use a language code for a heading you can do this: =={{subst:#invoke:languages/templates|getByCode|djr|getCanonicalName}}== but uh, maybe we could find a nicer way. I don't know how well the extension integrates with Lua but I'm pretty sure you could pass the variables to Lua via a template. —Pengo (talk) 08:40, 20 December 2015 (UTC)

I bet it would even be possible to accept either one and have the module distinguish them on the basis of whether the first letter is capitalized or not. Then {{section|Ari}} would be interpreted as the Trans-New Guinea language Ari (aac), while {{section|ari}} would be interpreted as the Caddoan language Arikara (ari). —Aɴɢʀ (talk) 11:26, 20 December 2015 (UTC)

This seems like a great idea to me; I had no idea it was possible. Even better would be if there was a way for one template to store its parameters to be used by another template. For example, currently in both Russian and Arabic, the noun headword and noun declension templates have exactly the same info in them, and the same goes in Arabic for the verb headword and verb declension templates. I've been using a bot to keep them in sync but it would be a lot nicer if the headword (which comes first) could somehow store the full set of parameters used in it and have them retrieved by the declension. Forgive me if this is exactly what the Variables extension does; I'm not familiar with it. Benwing2 (talk) 12:23, 20 December 2015 (UTC)

BTW, I like Angr's idea of allowing both language name and code to be used. I personally find it hard to remember the 2-letter or 3-letter (or sometimes 6-letter or 9-letter) language code, esp. for obscure languages, and it's not always that easy to look it up. Benwing2 (talk) 12:25, 20 December 2015 (UTC)

I like the idea of allowing both code and full language name, but I'm worried more that we'd end up with an inconsistent style, with some pages having =={{section|en}}== and some with =={{section|English}}==, and some with a mix of the two styles throughout. I guess we could allow both and see if a general style emerges, and vote on it down the line. Using the module for other things like declension tables sounds plausible. We need to be careful to document such things well, so we don't end up with too many undocumented global variables. Pengo (talk) 14:44, 20 December 2015 (UTC)

I'd prefer we use language codes, but that's not especially newbie-friendly, to be honest. I think allowing both to work and periodically having a bot fix them to a standard would be good. —Μετάknowledge^{discuss/deeds} 18:00, 20 December 2015 (UTC)

Yep. That sounds ideal. —Pengo (talk) 22:31, 20 December 2015 (UTC)

Wow, I had no idea this was possible. Support 200%! The extra 100% is for just in case. —CodeCat 15:30, 20 December 2015 (UTC)

This seems like a change well worth, 1., the risk of some inconvenience from unanticipatables in the transition and, 2., some manual effort to bring our headings up to the standard required. DCDuring TALK 16:37, 20 December 2015 (UTC)

Support, let's do it. --Daniel Carrero (talk) 16:40, 20 December 2015 (UTC)

Make it so. —JohnC5 17:47, 20 December 2015 (UTC)

Support fully. —Μετάknowledge^{discuss/deeds} 18:00, 20 December 2015 (UTC)

I created a vote: Wiktionary:Votes/2015-12/Install Extension:Variables. —CodeCat 19:51, 20 December 2015 (UTC)

• IIRC, the devs have rejected requests to enable Extension:Variables in the past. --Yair rand (talk) 20:31, 20 December 2015 (UTC)

What were their specific objections to it? DTLHS (talk) 22:41, 20 December 2015 (UTC)

I found the discussion from 2011: Wiktionary:Grease_pit/2011/January#Idea:_constants_in_templates with CodeCat looking to reduce other types of redundancy in pre-Lua templates. That discussion links to discussion from 2006 which is found on phabricator where Brion Vibber wrote:

Would strongly recommend against this sort of meta-programming features in wikitext.

Tim Starling replied with further objections:

I'm against it on the grounds of interaction with caching, the need to maintain flexibility of parser implementations, and expected application (wikitext is not a programming language).

So I'm guessing the "metaprogramming" or "expected usages" concerns are less of an issue now (there's no need to use lualess wikitext to create "a horizontal clade tree in a single table" any more). I'm guessing the caching problems are less of an issue now too (Lua would have the same issues). However, the desire to "maintain flexibility of parser implementations" is still an issue, as using this extension will likely break anyone's re-implementation of wikitext-parsing. For example, Xowa, an offline Wiki reader which stores compressed Wikitext in its database and renders it to HTML with its own Java code. Xowa would need to update their parser just for us (I searched the source code and it looks like the extension is not currently supported). There's a list of alternative parsers here, though Xowa is the only one I've seen that can actually handle a modern lua-containing Wiki page. The rest would not be able to render much of Wiktionary's templates anyway. There's only one other listed that mentions Lua (also written in Java), but there's possibly others. Apart from full parsers, there'd also be plenty of simpler scripts which are hardcoded to expect ==Middle Persian== or whatever. These are the things I was initially more concerned about, and was looking if we could even roll our own extension which keeps the heading syntax identical but quietly has the same effect of creating a "language section" variable. Though now I'm divided on the approach, as using Extension:Variables would at least be using an existing somewhat standard extension (and it already exists). Whichever approach, I'd say it's more of a roll-out issue. We should give warning about the change, and perhaps restrict the usage of the extension to headings initially to give third-parties time to catch up. The objections were from 2006. the context is quite different. The requested extension has been around since at least then. It would be worth requesting it again. —Pengo (talk) 00:00, 21 December 2015 (UTC)

Could the template {{section}} use MediaWiki:Gadget-WiktCountryFlags.css? --Lo Ximiendo (talk) 00:04, 21 December 2015 (UTC)

It would be nice if it worked like Conrad Irwin's Translation editor, where the language code is preferred, but you can also enter the language name, which will be automatically converted to the correct code. —Stephen ^(Talk) 01:36, 21 December 2015 (UTC)

If this is actually doable, I love it! The {{section}} template should definitely accept a language code and not a language name. --WikiTiki89 15:50, 22 December 2015 (UTC)

If this doesn't happen we could always just move pages to titles that include the language name as a prefix. No more language codes needed. DTLHS (talk) 05:13, 23 December 2015 (UTC)

And link them from the term's entry. Kind of like our Beer parlour and discussion pages.

But I oppose moving 4m entries just to reduce redundancy. --DixtosaBOT (talk) 07:22, 23 December 2015 (UTC)

Yeah, I've always been saying that each language should be on its own page. We've had many BP discussions on this in the past and none of them led anywhere. --WikiTiki89 15:20, 23 December 2015 (UTC)

Do you have a specific naming system in mind? Examples: pizza#English could be en/pizza or pizza/en. --Daniel Carrero (talk) 15:28, 23 December 2015 (UTC)

I think both of those have been considered. --WikiTiki89 15:31, 23 December 2015 (UTC)

I believe the naming format pizza/en has one technical advantage: If we have pízza/en, pízza/pt, pízza/es and also pízza to transclude them all, it should be easy enough to add a single template to pizza to transclude the other pages automatically as they are created, or create a bot to update pizza if needed. --Daniel Carrero (talk) 15:37, 23 December 2015 (UTC)

Although I agree that moving pizza#English to pizza/en would be an overall better design for Wiktionary (and I was considering bringing it up myself as an alternative to this proposal), ultimately I think it would be too disruptive to change over any time soon. The redundancy problems in the templates are a symptom of a mismatch between what we want to display at once to the user (the meaning of a string of text across languages) and the type of record most bits of data belong to (a word in a single language). Using pizza/en would help resolve that mismatch. There's a host of small and large benefits that would flow on from doing that. e.g. It'd be great if I could add just minor/la to my watchlist (which gets very few of the edits to minor), or start a discussion page about a word in a specific language, and I bet it would even make Wikidata integration easier. But changing to this format would be hugely disruptive. Basically it breaks everything that uses {{{PAGENAME}}}, breaks up the "history" view of every entry on Wiktionary, and creates many issues and questions around linking. To me it's almost like saying "let's make a Wiktionary 2.0". It's not a change that lends itself to being done incrementally. So I'd support it over the current system if it were 2002 and Wiktionary just launched, and I'd support it if Wiktionary had a dedicated army of template coders and QA who could work towards moving all templates and entries across in a fell swoop, and I might support it in future after Wiktionary manages to develop a stable machine-readable format for its entries (which could remain the same during the change), but in reality I just don't see it being a practical change, even if everyone agreed to it. I suggested the {{section}} proposal instead because I think it would be far less disruptive and can be done incrementally (i.e. old templates with lang=xx will still work just fine until they're updated), and everything works the same as everyone expects it to, and there should only be minor breakages during the switch over with third party tools/scripts. It might also be a good middle step to moving to the pizza/en format, as templates which are aware of the "section language variable" could be more easily switched over to be aware of the /en in the url instead, if we wanted to consider it in the future. Pengo (talk) 00:23, 24 December 2015 (UTC)

@Pengo: Some thoughts:

1. "add just minor/la to my watchlist" -- I agree: being able to do that would be great!
2. "Basically it breaks everything that uses {{{PAGENAME}}}" -- A possible problem/obstable to overcome: I used {{BASEPAGENAME}} in the page pizza/en, but the result was pizza/en, not pizza. Subpages seem to be disabled in the main namespace, probably because otherwise AC/DC would be considered a subpage of AC. If we are able to enable subpages in the main namespace, does it mean that AC/DC/en is going to be a subpage of AC and as well as AC/DC? That does look bad. We can always keep subpages disabled and use Lua to create a proper replacement for {{{PAGENAME}}} (suggested name: {{pagename}}), but it would be weird using subpage-like pages ("pizza/en", "pizza/fr") if they aren't actual subpages.

--Daniel Carrero (talk) 14:11, 26 December 2015 (UTC)

@Daniel Carrero: Hmm... the AC/DC problem. You'd think MediaWiki would have added something like a __NOTSUBPAGE__ switch to solve this problem by now. E.g. something you could add to AC/DC so that it would not show the breadcrumbs and so AC/DC/en would work as expected (linking to AC/DC but not to AC). Instead they suggesting bad hacks like using a backslash instead, or weird unicode slash-like characters (ugh). A neater hack that could work for us might be to build our own exception list, which {{pagename}} could check against. It wouldn't fix the breadcrumbs (at least without some additional javascript hackery), but at least other templates could automatically show "AC/DC" instead of "AC". I've just realised though, the biggest problem with the format is if Norwegians adopt the word yes, and then what would we do with yes/no? I guess we could move it to Unsupported titles/yes/no and keep yes/no for the Norwegian "yes" page. Probably not the end of the world. I made a list of all the pages that currently use a slash and couldn't see any non-hypothetical conflicts with the pizza/en naming scheme though. —Pengo (talk) 01:06, 27 December 2015 (UTC)

Languages could be namespaces as well, although that just brings on another set of complications. Personally I like the idea of subpages down to the definition level, so that a definition page includes the definition, quotations, translations and usage notes (and anything definition specific I am not thinking of) which then flows into a heirarchy of subpages (def => POS => etym => language => string). This would resolve the complications around keeping definition specific content together and make great strides towards machine-readability. It is technically and practically very daunting though. - TheDaveRoss 19:25, 6 January 2016 (UTC)

That seems like an awful lot of namespaces- at least a couple of orders of magnitude more that all the ones we've used so far. Any way you look at it, there are going to be tradeoffs between time spent creating/manipulating/navigating-between subpages and page complexity. The problem is that what we're modeling is inherently rather complex and difficult to simplify. Parts of it are very regular, but there are areas with all kinds of mutually-interacting and/or recursive levels/groupings- not to mention patterns that apply one way in some circumstances, but another way in others. I'm not very optimistic about finding The Right Way to structure our entries. Chuck Entz (talk) 02:35, 7 January 2016 (UTC)

It's going to be a little off-topic, but maybe it would be a good idea making all definitions use a unique ID number, rather than separate definition-level namespaces? Say bat means "nocturnal flying mammal" (ID 1789994) and "club used in sports" (ID 1789995), among other definitions. There could be some way to visualize only contents (quotations, translation tables, etc) specific to a single definition. Also: if we added "ID 1789995" in all mentions ({{term}}, {{m}}) of the word "bat" with that meaning in etymologies of all entries, maybe it could fill in the gloss automatically. The word batter (meaning: the player attempting to hit the ball with a bat) would be etymologically bat (ID 1789995) + -er (with another ID). --Daniel Carrero (talk) 04:00, 7 January 2016 (UTC)

And now we're getting into the territory of why a dictionary is better off as a database than as a wiki... --WikiTiki89 17:01, 7 January 2016 (UTC)

Unless we want to throw everything out and start from scratch, the movement to a fully normalized data structure has to be in increments. - TheDaveRoss 17:05, 7 January 2016 (UTC)

If we transclude all the existing languages from the main entry, how will this affect a? Will it load faster or slower? --DixtosaBOT (talk) 06:19, 24 December 2015 (UTC)

The fundamental problem with Extension:Variables is that it requires the whole page to be parsed in order. So it prevents asynchronous or parallel parsing, incremental parsing and various sorts of caching. It makes implementation in Parsoid difficult since it is fundamentally asynchronous. It would be much better to have a scoped, immutable declaration in which information is propagated down the parse tree:

{{#declare: lang=en | {{PIE root|h₂eǵ}}
  {{etyl|enm}}
  {{IPA|/ˈæk.ʃən/}}
  {{audio|en-us-action.ogg|Audio (US)}}
 }}

Or even just expose the current <h2> section title. If we implement phab:T114072 then sections will have a fixed scope in the parse tree. You could theoretically attach attributes to that scope:

=={{section|English}}==
{{#sectionproperty:lang=en}}
{{etyl|enm}}
{{IPA|/ˈæk.ʃən/}}
{{audio|en-us-action.ogg|Audio (US)}}

This looks a lot like Extension:Variables except that declarations are automatically terminated at the end of the section, and you can't set the same property more than once in the same section. Declarations would need to come immediately after the heading. -- Tim Starling (talk) 17:16, 3 January 2016 (UTC)

@Tim Starling I don't think many people here care about the specific underlying details. The most important point is to make templates aware of the L2 section they appear in, so that we can get rid of the collection of template parameters that are currently needed to specify it instead. Personally, I think the best implementation would be if templates/modules could access the whole tree of sections. Templates could retrieve this with something like {{#section|2}} (to retrieve the L2 section name), while Modules might be given this information as a table that is part of the frame object. —CodeCat 17:24, 3 January 2016 (UTC)

@Tim Starling Thanks very much for your input. It's much better to get an explanation like this why Extension:Variables is a problem rather than simply "we won't do it". I agree with CodeCat that any solution that avoids the duplication of parameters is a good one. If you can implement one of the other solutions that you describe, that would be great. Benwing2 (talk) 18:54, 3 January 2016 (UTC)

I filed phab:T122934 for this. -- Tim Starling (talk) 18:58, 6 January 2016 (UTC)

Speaking of language codes, I'm thinking of running a bot to add language codes to {{audio}} calls based on the language section that the audio call is within.

1. Any objections to doing this? Should I skip doing this for English?
2. What's the magic invocation to convert a language name to a language code? Benwing2 (talk) 12:28, 20 December 2015 (UTC)

Given the proposal immediately above this one, I think we should wait with this. —CodeCat 19:53, 20 December 2015 (UTC)

That proposal might take some time. I can't see any harm to doing this if Benwing wants to put the time into it. —Μετάknowledge^{discuss/deeds} 19:56, 20 December 2015 (UTC)

I'm running this now; it only took maybe 20 minutes, if that, to write the code. Benwing2 (talk) 02:08, 21 December 2015 (UTC)

Special:Contributions/WingerBot Great job! --Anatoli T. ^{(обсудить}/^вклад) 02:11, 21 December 2015 (UTC)

I have a couple of questions regarding quotations:

1. If the source material uses scribal abbreviations (e.g. a Medieval text abbreviating Latin cum to cū, with the superscript implied nasal), is it best to follow the original style and reproduce (where possible) the abbreviations in the quotation, or to just write all complete words?
   
2. Often in older Italian printed texts are words, which — in modern Italian — would be separated by an apostrophe, that appear tied together (e.g. laltro for l'altro (“the other one”)). Would it be okay, in such cases, to add apostrophes for the sake of clarity (for example, “l'altro”) — perhaps even between square brackets (“laltro”) to indicate it is an addition — or is it best to just reproduce the source material?
   

— GianWiki (talk) 18:19, 20 December 2015 (UTC)

@GianWiki: In quotations it is always best to reproduce the original style as much as possible. So in other words, follow the abbreviations used in the original text and do not include apostrophes not found in the original text. --WikiTiki89 15:51, 22 December 2015 (UTC)

I was looking at malo, and I noticed that the links to the lemma in {{inflection of}} in the 'Etymology 2' section did not link directly to the appropriate section of malus (the lemma) and instead simply took you to the language header. I attempted to remedy this by setting the first parameter in {{inflection of}} (the parameter that controls what exactly will be linked to) in the template calls there to "malus#Etymolgy_2', but when I did so, the link was actually to 'malus#Etymology_2.23Latin', which obviously doesn't exist. At first, I thought there was simply a problem with {{inflection of}}, but when I attempted to do the same thing in the etymology section itself, which uses {{term}}, I ran into the same problem. What's going on here? Esszet (talk) 21:23, 20 December 2015 (UTC)

You need to use the id= parameter to link to specific parts of a language section, and then place {{senseid}} in front of the appropriate sense. —CodeCat 21:27, 20 December 2015 (UTC)

That seems rather annoying; can't the templates just be made to properly interpret parameters such as 'malus#Etymology_2' for links? Esszet (talk) 23:23, 20 December 2015 (UTC)

No, because that feature of the software has always been broken. If there are multiple Etymology sections on the page, it always links to the first one. So if someone else then adds another one, all links break. —CodeCat 23:28, 20 December 2015 (UTC)

What do you mean? The first two 'Etymology' sections on si have distinct URL's and can thus both be linked to: si#Etymology and si#Etymology_2. Esszet (talk) 01:32, 21 December 2015 (UTC)

This is a wiki. People add, remove, and rearrange things all the time. What is now "Etymology 2" could become "Etymology 1" or "Etymology 3" without warning. Language sections get added and/or split into multiple etymologies all the time The only header that you can guarantee won't be duplicated or replaced with something else is the language header. Chuck Entz (talk) 07:10, 21 December 2015 (UTC)

I realize that, but does it really happen so often that adding links to specific sections is pretty much useless? Esszet (talk) 17:53, 21 December 2015 (UTC)

Perhaps templates which use the id= parameter could be made to give an error and automatically suggest the preferred solution to the user when they detect this kind of link? —Pengo (talk) 00:46, 23 December 2015 (UTC)

id= is not actually affected by this. On the contrary, it is the solution to this. --WikiTiki89 00:55, 23 December 2015 (UTC)

Maybe I wrote it confusingly, but that's what I meant. Templates where it is available as a solution it should be offered. Pengo (talk) 14:55, 23 December 2015 (UTC)

I still don't quite get what you mean, but for a module to actually check the page it is linking to would be way too time-consuming to do for every link on a page. --WikiTiki89 15:21, 23 December 2015 (UTC)

It's not checking the contents of the target page, it's just checking if there's a # in the link. If there is then it can suggest using id= in an error message. Pengo (talk) 22:50, 23 December 2015 (UTC)

Do we allow definitions in other languages on this Wiktionary? I've compared other similar lists and I can't come to terms with this page User:BAICAN XXX/Protologisms (Romanian). Shouldn't the definitions be in English? --Robbie SWE (talk) 14:02, 23 December 2015 (UTC)

@Robbie SWE: In normal entries, the definitions should be in English, not in a foreign language. User:BAICAN XXX/Protologisms (Romanian) is a user page. We don't have any rule concerning the language of definitions in a userpage list AFAIK.

In the future, please use WT:ID for questions like "I would like to learn how this aspect of Wiktionary works."

WT:GP is for development/templates/CSS/JavaScript and so on. --Daniel Carrero (talk) 14:35, 23 December 2015 (UTC)

(edit conflict) This is really a Beer parlour (policy) issue. The Grease pit is for technical matters. Yes, definitions should be in English, but it's user space and if it keeps that garbage out of the dictionary proper, it might be worth it. Chuck Entz (talk) 14:40, 23 December 2015 (UTC)

Ok, thank you for your answers and I apologise for posting in the wrong forum. I'll be more careful next time. --Robbie SWE (talk) 16:21, 23 December 2015 (UTC)

Starting in the Portuguese section, everything that uses Lua gets an out of memory error. This has nothing to do with recent edits to the page- old revisions have the same problem. There are only two possible explanations: either a change has been made to one or more of the templates/modules used in the entry that increased memory usage, or the behavior of the system has changed. Someone needs to track this down. I tried previewing a few of the sections, and none of them uses less than a megabyte of Lua memory. Given that there's apparently a limit of 50 MB of available memory, and there are far more than 50 sections on the page, the obvious question is: why is this only starting to happen now? Before you ask, I'm aware that sections probably share some of their overhead, but it still looks like the numbers aren't adding up. Chuck Entz (talk) 04:52, 30 December 2015 (UTC)

You should rather be looking into "Related changes" not in its history itself. And I am seeing half a megabyte increase in those related Lua codes. This might be it. Not sure.--DixtosaBOT (talk) 06:55, 30 December 2015 (UTC)

What am I supposed to be seeing in the Related changes that could've caused this? The edits to the Chinese modules? In any case, this is a major issue. @CodeCat, Yair rand, suzukaze-c —Μετάknowledge^{discuss/deeds} 07:03, 30 December 2015 (UTC)

It seems like Module:zh/data/skeys was the culprit, because commenting out {{zh-hanzi-box}} seems to have fixed it... Is there a way of making it so that the ugly things doesn't load unless needed? —suzukaze (t・c) 07:04, 30 December 2015 (UTC)

The "thing" part is only loaded when necessary. Is there any practical and common function in Module:zh that does not use m_data? --DixtosaBOT (talk) 10:48, 30 December 2015 (UTC)

Also, in response to this. Yes, it would. Do separate them.--DixtosaBOT (talk) 11:02, 30 December 2015 (UTC)

I believe that most of the functions of Module:zh use Module:zh/data, but I'm new to Lua and I didn't write Module:zh (and my Module:zh/data/skeys seems to be the source of the problems). However it seems like 1. Moving local m_skeys = mw.loadData('Module:zh/data/skeys') to inside the skeys function is fine (see Module:Sandbox), and 2. {{zh-hanzi-box}} has no need for Module:zh/data/skeys, and {{cmn-pinyin}} (present in a#Mandarin) also calls on a lot of unnecessary stuff such as Module:zh/data and Module:zh/data/cmn-hom just to convert pinyin to bopomofo (if I am interpreting "Templates used in this preview" correctly), which may have also contributed to problems. —suzukaze (t・c) 11:12, 30 December 2015 (UTC)

3. zh-hanzi-box uses very large yet awkward chunk of data (at Module:zh/data/glosses). The data is only shown in title (that is, when you hover the main text). How can one allow that? But I guess small entries can enjoy that luxury. --Dixtosa (talk) 19:04, 30 December 2015 (UTC)

"Lua memory usage: 15.39 MB/50 MB" I imagined servers groaning but not something like this... —suzukaze (t・c) 07:12, 30 December 2015 (UTC)

50MB isn't much these days. Even my laptop has 16GB. Although maybe the limit is there so they can run many page updates in parallel ... Benwing2 (talk) 17:38, 30 December 2015 (UTC)

Servers generally have less RAM than personal computers, and yes, of course they are doing many things at once, so 50MG adds up. --WikiTiki89 17:46, 30 December 2015 (UTC)

Depends on the server. Maybe a server devoted to low-intensity tasks would have less RAM, but a compute-intensive server will have more RAM than personal computers. Benwing2 (talk) 17:58, 30 December 2015 (UTC)

I meant the average web server, and I don't think Wiktionary is doing anything unusually computation-intensive. --WikiTiki89 18:12, 30 December 2015 (UTC)

When an edit is made to only a subsection we are more likely to want to move to that subsection. And I, personally, find → this symbol difficult to locate xD. So I present a userscript called RushToSubsection, that can make page titles link to the subsection. --Dixtosa (talk) 19:24, 30 December 2015 (UTC)