Hello, you have come here looking for the meaning of the word Wiktionary:Grease pit/2017/February. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Grease pit/2017/February, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Grease pit/2017/February in singular and plural. Everything you need to know about the word Wiktionary:Grease pit/2017/February you have here. The definition of the word Wiktionary:Grease pit/2017/February will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Grease pit/2017/February, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
Could "Template:table:suits" be renamed to "Template:table:French suits"? It's just so it could be distinguished from "Template:table:Spanish suits", which I believe ought to be renamed to "Template:table:Latin suits" per Pagat. (Speaking of table templates, there ought to be two table templates named as follows: "Template:table:German suits" and "Template:table:Swiss suits".) --Lo Ximiendo (talk) 18:57, 1 February 2017 (UTC)
Template:gloss
Template:gloss currently produces the following output: (this is an example). Does anyone have an objection to enclosing the gloss in quotation marks so that it matches other glosses generated by templates such as {{compound}} and {{m}}? (@IvanScrooge98.) —This unsigned comment was added by Smuconlaw (talk • contribs) at 18:24, 3 February 2017.
@Smuconlaw: Yes, I object, because {{gloss}} is most often used to provide a disambiguator rather than a true gloss. For example, the definition of njetopyŕ is given as "] {{gloss|small flying mammal}}", but bat doesn't actually mean "small flying mammal". Instead, the {{gloss}} tag is there merely to indicate which sense of bat is being referred to. —Aɴɢʀ (talk) 17:19, 5 February 2017 (UTC)
Is that different from a "true gloss"? I wouldn't have thought that the placement of any gloss within quotation marks (as templates like {{m}} do) implies that the gloss is exhaustive. — SMUconlaw (talk) 17:29, 5 February 2017 (UTC)
I guess the crucial difference is that {{gloss}} is usually used after English words, while the t= parameter of templates like {{m}} is usually used after non-English words. In "{{m|dsb|njetopyŕ|t=bat}}", ‘bat’ is a full definition, a full translation, of the dsb word, while in "] {{gloss|small flying mammal}}", ‘small flying mammal’ (and even more so in "] {{gloss|animal}}"), the so-called gloss is really just providing enough info so the reader knows we're not talking about a baseball or cricket bat. —Aɴɢʀ (talk) 18:37, 5 February 2017 (UTC)
{{IPA letters}} uses {{IPA}}, which uses Module:IPA which has a function that finds invalid IPA characters, using the list of valid characters in Module:IPA/data/symbols. I recently added a preview-only message that lists the invalid characters. Till now, the entry would simply be tracked with Module:debug. I'm not sure why the space is being considered an invalid character, because space is in the list of valid characters. Oh, it's because the template uses the HTML entity. I've added a rule to remove the HTML entity, so now the preview message no longer appears. — Eru·tuon20:16, 5 February 2017 (UTC)
It's now giving an error message for g - plain ordinary English g typed on a keyboard. I know there's a preferred IPA glyph for g, but ordinary typed g should translate into it automatically. --46.226.49.22810:45, 8 February 2017 (UTC)
The ordinary g has always given an "invalid IPA character" message, and it should, because it shouldn't be used in IPA transcriptions. It should be changed to ɡ wherever encountered inside {{IPA}} or {{IPAchar}} or {{rhymes}}. —Aɴɢʀ (talk) 11:24, 8 February 2017 (UTC)
The module is showing the position of the nonstandard characters instead of showing the characters themselves (see geliştir in preview mode). The error is on lines 137 and 138, result should be replaced with symbol. Redboywild (talk) 12:20, 8 February 2017 (UTC)
Actually, the solution was somewhat more complicated. But now it works. @Angr, the obsolete or nonstandard characters part of the error message was showing the position, while the invalid symbols error message was showing the characters. Now both show the characters. — Eru·tuon20:41, 8 February 2017 (UTC)
The IPA has been fixed by Angr. Erutuon has explained to me that syllables like /bl/ and /kl/ have to be indicated like /bl̩/ and /kl̩/ to be counted as a distinct syllable. — SMUconlaw (talk) 17:35, 5 February 2017 (UTC)
The links are green because of the entry creation tool. They're red links in the sense that there's no page there, I guess. — Eru·tuon08:52, 5 February 2017 (UTC)
The “New title” text box in a renaming page disappears
I cannot easily rename pages probably because of JavaScript for years, only on English Wiktionary. I cannot see the “New title” text box after the renaming page is fully loaded. Why is that?… I always have to hit ESC at the right moment to see it. — TAKASUGI Shinji (talk) 15:51, 5 February 2017 (UTC)
Problem solved. Thank you all. I turned off “When moving pages, use the namespace-qualified title in the title box, and remove the separate namespace list” in my preferences and it works fine now. (@Erutuon) — TAKASUGI Shinji (talk) 13:43, 7 February 2017 (UTC)
Oh, that was confusing. What I mean is the gadget produces copyable template code ({{unsigned}}), but it doesn't include the subst: before the template names, so you have to do extra typing after copying the template code. 07:40, 7 February 2017 (UTC)
Makes more sense, but I'm still confused. Why are you subst:ing these templates anyway? AFAIK, that's unnecessary. (Also, I find it annoying that template editors can't edit things other than templates — is it worth making a vote and filing a bug report?) —Μετάknowledgediscuss/deeds07:58, 7 February 2017 (UTC)
@Metaknowledge: Oh, I was under the impression it had to be substituted. Apparently not, according to the template documentation. Perhaps substituting it is a Wikipedia custom. As to whether template editors should have the privilege of editing JavaScript gadgets – I for one don't have that much JavaScript knowledge, so I'm not sure either way. — Eru·tuon10:38, 7 February 2017 (UTC)
Languages using punctuation as characters (Nivkh transliteration)
I've tried writing a Nivkh transliteration module today, but I've come across a problem with its ’ (single quote) character used to denote aspiration, the problem is that our modules (translit, headword) treat it as a word divider causing it to link the two parts of the word separately in headword lines and transliterating the word part by part. Normally this wouldn't cause problems, but in the case of Cyrillic e we need to differentiate between positions following a consonant and beginning a word, as one should be written e and the other je.
Take for an example к’еӄ, its transliteration ought to be k’eq, yet our current setup together with my module can only produce k’jeq.
Does anyone have an idea of how we could achieve this (or a reason for why a solution could be impossible)
This is a long-running problem which needs a solution for many languages. Compare this diff (the problem can be solved with use of the head= parameter here, but it's still a terrible default for Hän). —Μετάknowledgediscuss/deeds20:45, 7 February 2017 (UTC)
Yes: don't use the curly apostrophe ’ (U+2019) as a letter. Anytime something apostrophe-looking is used as a letter (in any language, not just Nivkh), we should be using ʼ U+02BC (MODIFIER LETTER APOSTROPHE). If you move к’еӄ to кʼеӄ, it should transliterate correctly. —Aɴɢʀ (talk) 20:46, 7 February 2017 (UTC)
Because that's what it's there for. Cases like this are exactly why Unicode has two separate characters, one for the punctuation mark and one for the letter. It's not our problem if other people use the characters incorrectly; we should still use them correctly. We can leave hard redirects from the spellings using the wrong character. —Aɴɢʀ (talk) 21:28, 7 February 2017 (UTC)
People who actually write in the language is a somewhat hypothetical category for Nivkh, I doubt that there's a standard, be it official or conventional, of how computer Nivkh should be encoded. If no one gives a better reason I'll go ahead and start moving pages. Crom daba (talk) 21:32, 7 February 2017 (UTC)
Well, it works now, I've replaced all the apostrophes per Angr's suggestion (thanks), however that wasn't even the problem it was
text = mw.ustring.gsub(text, "()Е","%1Je")
text = mw.ustring.gsub(text, "()е","%1je")
the function of which I don't understand. I've added
Looks like the search box has been redesigned recently. The script should be updated, and additional checks added to avoid breakage in case of future DOM changes.
It seems that this was missed this year. The following codes have been deprecated by SIL and need to be removed from our language modules:
Rennellese Sign Language
Shinabo
Rien
Lua'
Pu Ko
As well, there have been several new languages; I'll leave it to interested people to find these out and add them if there's demand. -- Pedrianaplant (talk) 15:38, 8 February 2017 (UTC)
I don't believe any of these have any current use in Wiktionary, so they can simply be deleted without any cleanup needed. DTLHS (talk) 16:56, 8 February 2017 (UTC)
Looking at the first one, that was deleted because it's just a bunch of private signs developed by one deaf person that never managed to develop a grammar structure or a sufficient vocabulary to actually form a language on its own merit. The other four languages could not be discovered by researchers in their respecitve region and are thought to be spurious. -- Pedrianaplant (talk) 17:09, 8 February 2017 (UTC)
After reading the reasons for deprecation for all the languages mentioned, I've deleted all the codes from the language modules. —Aɴɢʀ (talk) 17:14, 8 February 2017 (UTC)
It now has an additional form prompting for the user name, etc. However, the resulting list contains new entries from all users, not just the one I typed in the name box. Equinox◑13:06, 9 February 2017 (UTC)
Hello, please undo this change (so basically the Vector.css can be blanked).
Principle of least astonishment (aka. wtf muscle memory I clicked at the wrong place), the top section should not be different from all the other wikis…
I don't think reverting this would be a good idea. Losing the definitions below the fold is a real issue, and we shouldn't waste critical screen space just to keep consistency with other projects. --Yair rand (talk) 19:26, 9 February 2017 (UTC)
1em doesn't change much about the "above the fold" (and the TOC eats all the space, so…). But current tweaks make that top section really narrow.
If you don't want to undo the whole thing, how about changing the offset from 1em to 0.5em? We still gain a bit of space, and it really makes the top section less messy.
I just fell again on this (69511988), and kindly, I'm still disagreeing. I think being consistent with all other projects is much more important than saving a small amount of space (also, I think it makes the top section look too much condensed). Ping Jon (WMF). Od1n (talk) 07:37, 14 October 2022 (UTC)
Hi there I guess I'm being pinged because I was the last editor but all I did was limit the change to the legacy Vector skin. I'm not sure of the history of these rules.
What problem are they solving? I'm sure we can find a better way to do it - I agree this sort of customization shouldn't be necessary. Jon (WMF) (talk) 00:32, 21 October 2022 (UTC)
Is it possible to invoke a module from another language Wiktionary? It would be great to automatically get all the updates immediately propagated.
Right now invoking the copied module results in a timeout (see sv:Modul:teckeninfo). Unfortunately I have no idea how to debug this. Any tips on how I can find the errors?
I believe one Wiktionary can't use a module from another Wiktionary (I even tested a bit and failed), but it seems eventually we could move all character names and image links to wikidata:, which I believe can be accessed by other wikis. I don't know how to do that. --Daniel Carrero (talk) 01:50, 13 February 2017 (UTC)
@Moberg: Module:Unicode data currently has 69 subpages. At least the way the modules are currently implemented, I'm afraid someone really is going to have to copy all of them to other Wiktionaries to use them, like this: Module:Unicode data/images/000 to sv:Modul:Unicode data/images/000, and so on. I don't know if it's feasible to use a bot or AWB to copy these pages.
Yeah I dont really feel like manually copying that amount of pages, with the risk of not getting it to work. I'm rooting for wikidata! :) –dMoberg21:59, 13 February 2017 (UTC)
Really you should never copy pages wholesale from another wiki, you should import them. That way the edit history is maintained as is required by the licenses. It also has the benefit of doing most of the work for you. - TheDaveRoss22:05, 13 February 2017 (UTC)
Import seems like a better alternative (although not needed for history keeping?) but still too cumbersome unless there is some way to import all subpages for a page (scripting?). Another problem is overwriting previously imported pages. I really hope this can be moved to wikidata as soon as possible. :) –dMoberg19:25, 14 February 2017 (UTC)
Fixing category-creation text to mention {{auto cat}}
@CodeCat CodeCat created {{auto cat}}, which is very handy but isn't mentioned currently in the text at the top of a new-category page. Instead there's a list of the older (non-auto) catboilers. Can someone point me to the relevant page where this text is held? I searched around in the MediaWiki namespace but couldn't find it. Benwing2 (talk) 19:33, 12 February 2017 (UTC)
@Benwing2: I believe you are looking for these pages:
A new Labs Tool to visually explore etymological relationships extracted from the English Wiktionary
Hi all! I have developed a tool to visualize etymologies. Please check it out at tools.wmflabs.org/etytree.
My work is funded by an IEG grant.
Please leave your feedback on the interactive tool here. It will help improve it.
It's is impressive how well automatic extraction of data works. This is because Etymology Sections are written using well defined standars. I would like to get some feedback about some difficulties I have encountered while extracting data and some ideas I have about new templates. I wrote some notes here. Please add your comment there if you have any.
This is very interesting. I wonder if you have a list of etymologies that you found were impossible to parse? DTLHS (talk) 16:25, 14 February 2017 (UTC)
@DTLH: I don't have a list but from the visualizations you can clearly see that some of the sections are incorrectly parsed. Some of those mistakes are due to bugs in the code, others are due to imprecise etymological definitions. Consider also that while debugging I have corrected many etymology sections (see my contributions) and after those contributions I still have not updated the database. I still use a database extracted from the December 20, 2016 dump. Epantaleo (talk) 17:01, 14 February 2017 (UTC)
(answered also there in Meta) Awesome. Coincidentally and recently and unknowingly I have just tried to do that with GraphViz and Gephi, but introducing the data by myself. I just tried the uncreated en:wikt:Reconstruction:Proto-Indo-European/paw- (see What links here) < en:wikt:pavor (in order to get data, create the article and fill the gaps). My results are so alike... and you got what I sought so much. I'll try to have some time for more comments.
I'd suggest giving the option to choose different graph types (more linear).
And apply colours of distance from the lowest node (said knot?).
Do this cognates in boxes interrupt parsing? Do you process cognates? Can it find incoherences (two different nodes of the same language pointing into the same descendant)?
I also recently discovered template:etymtree]] and Template:findetym: can you feed them (there are less than 100 created)?
It says that ḿ is not a valid character, but note that this is a syllabic nasal; the word has four syllables, the second and fourth are high toned. Can this be fixed? —CodeCat23:32, 18 February 2017 (UTC)
The module returns an error because composed letters with acute accents are, properly speaking, not correct IPA: a plain letter with a tone mark diacritic should be used instead. You can enter the tone mark diacritics by placing the X-SAMPA shortcuts (in this case, _H) into {{subst:x2i}}. Or maybe we could add a full set of acute-accented letters into the "valid" list in Module:IPA/data/symbols. But using the correct character is best. — Eru·tuon23:42, 18 February 2017 (UTC)
Characters are input into Lua as precomposed characters, and are likewise converted to precomposed by the software when output. There are two functions, mw.ustring.toNFC and mw.ustring.toNFD which compose and decompose characters respectively. If the module has trouble handling precomposed diacritics, it should decompose them before doing any processing. —CodeCat00:14, 19 February 2017 (UTC)
That would be true if the tone diacritics were the same as the plain diacritics, but they are not. m plus combining acute tone mark (0x341) is not converted to m with acute ( 0x1E3F). At least this seems to be true when I enter {{subst:x2ipachar|m_H}} (which yields ḿ): no error message is displayed. — Eru·tuon00:29, 19 February 2017 (UTC)
Yes, and the low tone mark (0x340) is different from the combining grave (0x300). But now that I look, there are no distinct characters for the rest of the tonal diacritics. That's inconsistent. — Eru·tuon00:41, 19 February 2017 (UTC)
The parameter |nocap=1 doesn't function anymore. |nodot=1 does still work.
{{obsolete form of|term|lang=en|nocap=1|nodot=1}} becomes obsolete form of term with a capital O and not a non-capital o, and without a dot. -Wilhelm-231 (talk) 08:28, 19 February 2017 (UTC)
I fixed it. It was because the text "obsolete form of" had italics (''Obsolete form of''), which prevented the lcfirst: and ucfirst:magic words from working. — Eru·tuon23:41, 19 February 2017 (UTC)
Warning: Other pages link to or transclude the page you are about to delete.
This message turns up when deleting an entry, but I've come to ignore it, because if it's listed on RFV, then there'll be a link to WT:RFV. Is it possible to prevent this warning from appearing when the only links to the page are on WT:RFV, WT:RFD, or WT:RFDO? —Μετάknowledgediscuss/deeds01:08, 20 February 2017 (UTC)
Ugly charboxes in mobile view
I'll leave this issue here in case someone's interested. After I was informed about it in my talk page, I was meaning to try to fix it but didn't do it yet.
The character boxes are very ugly when seen in a cell phone, and need some proper CSS formatting.
That's right. Yes, thanks for summing it up. Plus I'd like to add "float: right" in all these boxes, because apparently we currently have to scroll past all the boxes to start seeing the actual entry. Maybe the appendix name (like "Basic Latin") could be smaller, too. --Daniel Carrero (talk) 21:45, 21 February 2017 (UTC)
I don't know, but at least I see that we have a whole CSS page specific to mobile view: MediaWiki:Mobile.css. Wikipedia has one too: w:MediaWiki:Mobile.css. If hiding content is needed, the Wikipedia page suggests this: "Do not use display:none. Instead edit the template and markup the element you want to hide with the `nomobile` class." --Daniel Carrero (talk) 08:21, 22 February 2017 (UTC)
What about making the tables collapsible, instead of making them float to the right? That would make them take up less vertical space, and require less scrolling. — Eru·tuon22:39, 21 February 2017 (UTC)
I'm puzzled by the inclusion of a left-to-right mark () in the output of Module:headword and Module:usex. This is unnecessary, since text direction for right-to-left languages is specified in MediaWiki:Common.css. I removed the left-to-right mark from Module:headword (though the edit summary is misleading; Module:script utilities no longer adds text direction markers, because they are unnecessary). It is a small thing to be concerned with, but I will remove it from Module:usex if there isn't a good reason for it. — Eru·tuon10:26, 24 February 2017 (UTC)
Language-sensitive labeling
I've added the necessary code to Module:labels and Module:labels/data/regional to allow categories to be restricted to a set of languages. You simply add a list of language codes to the data table, and {{label}} will only add the category to those languages. I've tested it with the label "Koine" (the only one that currently has a "languages" field) and it works: {{label|grc|Koine}} adds a category, while {{label|en|Koine}} does not.
Unfortunately, this does not yet allow the same label to be used by different languages with different content. I can't think of a case where this would be needed, but it should be possible. — Eru·tuon07:15, 25 February 2017 (UTC)
Okay, an example in which different content for the same label would be useful: Doric, which should refer to Doric Scots when the language code is sco, and to Doric Greek when the language code is grc.
I am thinking that one way to have this feature would be to have a table of language codes, and under each language code, a list of labels associated with that language. If more than one language uses the label, one language's table would contain the label, while others would refer to it. For instance, the label "honorific" would have to be listed under either "zh" (Chinese), or "ja" (Japanese), or "ko" (Korean), or another language, and have the other languages refer to it. This idea would result in more complexity: there would be a table of non-language-specific labels, and another table of language-specific ones.
And I am not sure how the module could return an error if an editor tries to use a label in a language that does not allow it (for instance, using "honorific" in English). — Eru·tuon00:46, 26 February 2017 (UTC)
I suppose the answer is yet another table of labels with a list of languages in which they can be used: such a table would include a table indexed by "honorific" containing {=true,=true,=true}. — Eru·tuon00:50, 26 February 2017 (UTC)
A table for "Doric" would contain =true,=true, even though the contents of the Ancient Greek and the Scots label would be different. — Eru·tuon00:51, 26 February 2017 (UTC)
But we don't want to have to list out all the languages that use honorifics. We would doubtlessly forget some, and we shouldn't have problems when someone eventually wants to add honorific terms in a new language and can't figure out why it's failing to work. —Μετάknowledgediscuss/deeds01:51, 26 February 2017 (UTC)
@Erutuon: It's fixed, thank you. Not sure by who and what was done. I only changed the title - inserted a missing word. --01:31, 27 February 2017 (UTC)
Documentation for "Template:projectlink/Wikipedia"
Hi, where does the message at top of module pages (with exisiting documentation page) come from? (See: Module:labels for example). I'm talking about the text that reads
"The following documentation is located at Module:labels/documentation.
Useful links: subpage list • transclusions • testcases"
I'm sorry if this is not the best place to request such help. I am unfamiliar with adding new templates, and I would like to start doing so. At the moment I'd like to add a new reference template, specifically a Tahitian reference template. I understand that I could simply troubleshoot, and possibly find the solution after more time and research; however, I have limited time, and I would also like to learn how to do this correctly the first time -- so that I will know the best possible manner to go about this in the future.
Additional questions:
Is there a feature/set of features that allows for automating some actions, such as adding a definition for a particular language to an existing page? By this I mean automating the following steps:
Navigating to the translations for the word, e.g. headache, and adding the term for a non-preexisting language.
Adding a new section, language specific category and any additional information.
What is the best way to cite sources for terms on articles? I see a Citations tab at the top of each article. Is there an easier/more productive way to add many words from a single source - in this case, a dictionary - without having to add the same source to the Citations tab of each term's article? To clarify, I mean both the article for a term containing the translation table, e.g. headache, and the page for the term itself, e.g. hoa.
Answers to some of your questions: the citations tab should be used for uses of the word in print, such as newspaper articles, books, etc. This is distinct from a reference, which is placed on the main entry and is usually a link to another dictionary or other scholarly source. If you state the bibliographic details here someone can make a reference template for you, or you can look at some examples at Category:Reference templates by language. DTLHS (talk) 00:51, 27 February 2017 (UTC)
What type of reference would you like to create a template for? The list of citation templates, which are used to create reference templates, is found at Category:Citation templates. You simply choose the citation template that is most appropriate for your reference (for instance, {{cite-book}}) and place it at the page name Template:R:<reference name> or Template:R:<language code>:<reference name> (for instance, {{R:LSJ}} and {{R:ar:Wehr-4}}, two templates I happen to use often), and then fill out the parameters of the template as explained on the template documentation page. — Eru·tuon01:05, 27 February 2017 (UTC)
Thank you both for your responses. @Erutuon: Would you use the latter template format (e.g. {{R:ar:Wehr-4}}) where the language code is the language in which the source is written? If not, what differentiates using this format from the format without the language code? The source for which I'm currently trying to create a template is a dictionary. The title is listed on the dictionary in both target languages; what is the best manner to handle this when formatting the reference? Would it suffice to only include the English portion of the title (e.g. English-Tahitian Dictionary)? Also, how do I handle a title that's formatted as: "English - Tahitian (newline) Tahitian - English (newline) Dictionary" in the reference itself? Here's what I have thus far, Template:R:ETD-Wahlroos
@Tezamen: There seems to be no clear criterion determining whether the template name contains the language code. I would have thought that the language code would be used in cases where, without it, the reference name would be ambiguous, but I think there's no ambiguity in the case of {{R:ar:Wehr-4}} (Wehr's Arabic Dictionary).
The language code would be the language that the reference work is about. This case is odd because each half of the dictionary is about a different language. I think it is probably fine to give the title in English, as it is given on the Google Books page. Newlines should be ignored. — Eru·tuon03:02, 27 February 2017 (UTC)
@Erutuon: Yeah, it would be useful to develop clearer criteria for when the inclusion of the language code is warranted, hmm. Regarding titling the reference, I understand that newlines are to be ignored -- I was simply trying to illustrate the formatting of the title as it is displayed on the book cover, and, moreover, was asking how I should format the title into the reference. Does the reference, as formatted in the template I made here, properly convey the title as it is on the cover here? To be clearer, should it be "English - Tahiti Dictionary" or something such as "English - Tahiti / Tahiti - English Dictionary" ? If the latter, how should I properly format it inside of the reference (i.e. Sven Wahlroos (2002) English-Tahitian Dictionary, First edition, Honolulu: The Mā'ohi Heritage Press, →ISBN ? Thanks! Tezamen (talk) 03:20, 27 February 2017 (UTC)
No parameters are given on Client, not even gender, but it's making a plural anyway and it's the wrong one. Can the template be fixed so that it no longer generates incorrect forms when no parameters are given? —CodeCat19:31, 27 February 2017 (UTC)
list:Latin script letters
An IP has been generating and adding language-specific subtemplates for a lot of languages lately. One of the more recent ones was added to the Swedish section at e, which triggered "not enough memory" errors. Previewing the section containing this (and nothing else) shows that this uses 2.74 MB of memory. Obviously, that would make it impossible to use these templates on anywhere close to all 62 of the language sections on that page if it weren't for the fact that some of the memory use is shared between many of the module calls on the page.
Still, Latin-letter entries are inherently huge and resource-intensive, and having a type of template specifically designed to be used large numbers of times on each of these pages is tempting fate. Is there any way that these templates can be tightened up/rethought so they don't use so much memory? Chuck Entz (talk) 04:46, 1 March 2017 (UTC)
That's a ridiculously large amount of memory for one template. I wonder how that is happening: does every instance of {{l-self}} require the language object from Module:languages to be duplicated in memory? — Eru·tuon04:54, 1 March 2017 (UTC)
In any case, it would be best to create a module that can generate letter and letter name templates in a consistent way. I think I'll work on that. — Eru·tuon05:00, 1 March 2017 (UTC)
I don't understand how the module works exactly, but it seems like the only difference from the previous form of the existing series of templates {{list:Latin script letters/en}} is that it doesn't include the language's word for "letter". That can easily be fixed. — Eru·tuon05:40, 1 March 2017 (UTC)
It needs a better name. {{letters}} is a template for Appendices, while {{letters/sandbox}} is for entries. I will look into how they could be merged: the differences are the presence of the word for "letter" at the beginning of the list in {{letters/sandbox}}, and the categories added by {{letters}}. Those could easily be dealt with by the module.
I'd argue that it's much more efficient to delegate these entries to appendixes than to have them as entries. They aren't "words" in the truest sense, after all. Moreover, if we do so, then any actual words that are spelled with a single letter, like Englisha or Dutchu, will not be buried under relatively useless "letter" entries. —CodeCat13:28, 13 April 2017 (UTC)