Wiktionary:Grease pit/2012/October

From Wiktionary, the free dictionary
Jump to navigation Jump to search


Special:WantedPages[edit]

This hasn't been run since 2009, according to the page. Is that true? Are there good reasons why it shouldn't be run? Can it be limited to pages in principal namespace? DCDuring TALK 16:12, 1 October 2012 (UTC)[reply]

Can it be limited to links from principal namespace? DCDuring TALK 16:16, 1 October 2012 (UTC)[reply]
See bugzilla:15434. Call me a pessimist, but I don't think this is something that we can bring about. However, we can probably approximate that page's functionality by analyzing the database dumps and generating some sort of page in the project (Wiktionary:) namespace. —RuakhTALK 18:09, 1 October 2012 (UTC)[reply]
Call me an optimist, but it actually looks as if they have recently identified and modified a step bugzilla:39667 that would help towards re-enabling this. It won't be long now!
I hesitate to make a request if there is a realistic prospect that MW will move on this, but if their run still works the way the prior one did, the principal namespace stuff would be swamped by items from Index and Template space. I also noted that a large number of the links that generated the list were from wanted lists on user pages and from talk and project pages. Those lists are fine as far as they go, but they have been heavily mined, so the remaining redlinks are often wrong capitalization, probably SoP, etc. This seems like the kind of list that, once debugged, would be usefully run once a month or less, if that makes a difference. As opposed to some of our lists, it enables contributors to prioritize their efforts based on more objective considerations. DCDuring TALK 18:33, 1 October 2012 (UTC)[reply]

Template talk:ku-verb form of[edit]

FYI. Mglovesfun (talk) 18:15, 1 October 2012 (UTC)[reply]

Template:recons or Template:proto?[edit]

For a while now we've had these two templates to link to reconstructed entries, along with {{lx}} and {{termx}} which fulfill more general roles. Personally I think we don't really need {{proto}} anymore, at least not for the majority of cases. My reasons are as follows:

  1. They mostly do the same things; in fact, {{proto}} now simply calls {{recons}} and {{etyl}} and does almost nothing of its own.
  2. {{recons}} supports all the parameters that {{term}} does, which {{proto}} does not. In particular the latter does not allow us to override the displayed headword, which is needed for Proto-Germanic. This would also be useful for showing several possible reconstructions but only linking to one of them (the most common one), or for linking to the e-grade of a PIE root while showing the o- or zero grade.
  3. {{proto}} dates back to times when we did not have language codes for reconstructed languages, or even any way for linking to such languages at all. Now that we do, {{recons}} is better suited at fulfilling that role, since it links to all reconstructed terms, irrespective of whether the language name begins with "Proto-".
  4. {{proto}} confusingly uses the lang= parameter to indicate the source language, not the language of the term being linked to.
  5. It's more consistent to use {{etyl}} for all foreign etymologies without exception, rather than making an exception only for reconstructed languages but requiring it nonetheless for reconstructed terms in attested languages. Also note that some languages are practically unattested, like Vulgar Latin, so they are proto-languages for all practical purposes.

So I would like to propose that we replace most occurrences of {{proto}} with a combination of {{etyl}} and {{recons}}. We can't replace all of the instances, because there are some cases where it's used for a reconstructed language that has no code. Those entries are listed in Category:Proto with language that has no code. —CodeCat 23:14, 2 October 2012 (UTC)[reply]

Support. These are all very good reasons, especially {{proto}}’s irritating usage of lang=. — Ungoliant (Falai) 23:52, 2 October 2012 (UTC)[reply]
Support iff someone makes codes and templates for all the protolangs sans codes first. --Μετάknowledgediscuss/deeds 05:04, 3 October 2012 (UTC)[reply]
Support. Good luck making the tens of thousands of changes (by the way, is there a better way to get a count of transclusions other than just counting pages of 500?). Also, what's the advantage of using {{recons}} over {{termx}}? Is there any difference other than the color of "redlinks"? --WikiTiki89 (talk) 10:19, 3 October 2012 (UTC)[reply]
Probably not much... and personally I don't think the links created by {{recons}} should be black, anyway. We want most of those entries to be created too, after all. Don't we? —CodeCat 11:19, 3 October 2012 (UTC)[reply]
Then why don't we scrap {{recons}} as well? --WikiTiki89 (talk) 11:27, 3 October 2012 (UTC)[reply]
Because I prefer it to {{termx}} at least in some cases. It has the advantage that we can track reconstructions just like we can with {{proto}}, which we can't do with {{termx}} because it's also used to link to attested entries. But we do still need {{termx}} because we have many templates that need to link to a term irrespective of where it's located. {{prefixcat}} is just one example; it would break for prefixes in reconstructed languages were it not for {{termx}}. —CodeCat 11:32, 3 October 2012 (UTC)[reply]
Just curious, but how does {{termx}} behave for languages that have both attested and unattested terms? --WikiTiki89 (talk) 11:35, 3 October 2012 (UTC)[reply]
It will always link to the terms in mainspace. That's why {{recons}} was created in the first place, to be able to link to reconstructed terms in attested languages. —CodeCat 11:47, 3 October 2012 (UTC)[reply]
Ok, I will try to run a bot to replace the regular expression {{proto\|([^|}=]+)\|([^|}=]+)\|lang=([a-z-]+)}} with {{etyl|{{subst:langrev|\1}}|\3}} {{recons|\2|lang={{subst:langrev|\1}}}}. Once that is done it will probably have covered the majority of entries. —CodeCat 14:18, 3 October 2012 (UTC)[reply]

Defining permitted template locations[edit]

I think it would be helpful (in certain cases) to define on template documentation pages the locations a template is permitted (for example, only on sense lines, or only in English entries) in a way that can be read and interpreted by bots as well as humans. That way erroneous uses can be found and corrected (by autoformat or other bots). This is in response to Wiktionary_talk:Todo#Sense_used_instead_of_context.2C_qualifier_or_gloss, and the fact that we apparently have a lot of confusion around {{sense}}, {{gloss}}, {{qualifier}}, {{context}}, {{head}}, {{infl}}. Thoughts? DTLHS (talk) 05:25, 3 October 2012 (UTC)[reply]

In a word, yes it would be helpful. Mglovesfun (talk) 11:50, 3 October 2012 (UTC)[reply]
What would the recommended format for machine readability be? Presumably it would appear on the documentation subpage. Or should it be reflected in a category of which the template is a member, eg, Category:Headword-line templates and its subcategories? DCDuring TALK 12:13, 3 October 2012 (UTC)[reply]
Well, {{head}} (redirect {{infl}}) should only be used directly under a header (though sometimes {{wikipedia}} gets put in between the header and {{head}}) and should be the first item, usually the only item on the line. Context should not be used outside of definition lines, gloss also, qualifier is commonly used on and off of definition lines, and sense should only be used outside of definition lines. Hope this helps. Mglovesfun (talk) 12:34, 3 October 2012 (UTC)[reply]
It seems almost like we need to define some kind of XML DTD or schema, except for wikitext... —CodeCat 13:26, 3 October 2012 (UTC)[reply]
It would be handy if we also used to this to improve the documentation for users to reduce the amount of error to begin with. Something that only a machine could read would be another step backwards. DCDuring TALK 16:28, 3 October 2012 (UTC)[reply]
So basically we want to make CFI machine-readable, and expand on it by adding templates to it? —CodeCat 16:34, 3 October 2012 (UTC)[reply]
I believe {{gloss}} is/should be also allowed on translation lines in order to tag a more specific or slightly different gloss of the translations as compared to that specified in {{trans-top}}. Matthias Buchmeier (talk) 07:17, 5 October 2012 (UTC)[reply]
I've only ever seen qualifier used that way. Mglovesfun (talk) 09:28, 8 October 2012 (UTC)[reply]

template:rfex[edit]

Discussion moved to the Beer Parlor. --WikiTiki89 (talk) 13:15, 5 October 2012 (UTC)[reply]

singular-only nouns[edit]

The Telugu {{te-noun}} needs a parameter added so that if I type |-, it displays (singular only). I tried to add this but could not make it work. —Stephen (Talk) 18:49, 6 October 2012 (UTC)[reply]

Added it for |pl=-. — Ungoliant (Falai) 19:10, 6 October 2012 (UTC)[reply]
Thanks. —Stephen (Talk) 20:26, 6 October 2012 (UTC)[reply]

Bot task: footnotes vs references[edit]

Speednat (talk • contribs) created a number of entries with ===Footnotes=== <references/> redundant to ===References===. Could a bot fix all such entries like this? - -sche (discuss) 18:23, 7 October 2012 (UTC)[reply]

It's at the limit of what I can do using regular expressions, but I think so, yes. Similarly, anagrams are supposed to be dead last (I think that's a ConradBot thing rather than an ELE thing, right?) but that I categorically cannot do. Mglovesfun (talk) 19:47, 7 October 2012 (UTC)[reply]
The references as far as I can tell should mainly be removed as we rely on primary sources, not secondary sources. References for the most part should be under the references header and only there (i.e. not in with the definitions as well). Mglovesfun (talk) 19:55, 7 October 2012 (UTC)[reply]
But that's not the right fix. The footnote in the ===Footnotes=== section is referring to the reference in the ===References=== section. The correct fix is not to move the footnotes into the ===References=== section, but to merge the two. (See AAL?diff=18452331.) So — a bot could start doing it, but it would hopefully get blocked before it made too much progress. :-P   —RuakhTALK 20:23, 7 October 2012 (UTC)[reply]
Haha, I would do the other way around, remove the <ref></ref> as nonstandard and keep the text under the references as it is. That sounds doable by bot. Odd as that sounds. Mglovesfun (talk) 20:31, 7 October 2012 (UTC)[reply]

Headline templates for Marathi[edit]

Can someone please create headline templates for Marathi language. Only Template:mr-noun is available. I am planning to add Marathi translations of as much words as possible and also create Marathi language pages. I would very much appreciate if someone can create templates for pronoun, adjective, adverb, exclamation, interjection, and conjunction. Shivashree (talk) 08:54, 8 October 2012 (UTC)[reply]

You don't necessarily need dedicated Marathi templates; you can use the language-agnostic template {{head}}, writing {{head|mr|pronoun|tr=...}}, {{head|mr|adjective|tr=...}}, and so on. —RuakhTALK 12:09, 8 October 2012 (UTC)[reply]
Such templates could link to Wiktionary:Marathi transliteration. But since that doesn't exist, why bother? Mglovesfun (talk) 21:44, 9 October 2012 (UTC)[reply]
Mainspace pages shouldn't really have links into the project namespace (except inside {{rfv}} and whatnot). If we want to document our transliteration scheme for Marathi, I think Appendix:Marathi transliteration would be more appropriate. —RuakhTALK 21:57, 9 October 2012 (UTC)[reply]

Fix Template:anontools[edit]

Could an admin please fix the WHOIS link at {{anontools}}? See Template talk:anontools. --Mormegil (talk) 13:31, 8 October 2012 (UTC)[reply]

Bot task: replace deprecated IPA characters[edit]

Could a bot change all instances of the following deprecated IPA characters in the main namespace?

ʧ to t͡ʃ
ʣ to d͡z
ʥ to d͡ʑ
ʤ to d͡ʒ
ʦ to t͡s
ʨ to t͡ɕ

The bot should ignore these entries: ʤ, ʦ, ʧ, ʣ, ʥ; dezh, tesh, dz, dz, ts, ƾ, ƽ, ƿ. - -sche (discuss) 01:54, 9 October 2012 (UTC)[reply]

Entries with slashes[edit]

Just curious, is there any technical difference between a subpage with no parent and an entry with a slash in its name?

And what sort of sorcery causes {{SUBPAGENAME}} to display "9/11" rather than "11" on [[9/11]]?

--WikiTiki89 (talk) 07:54, 10 October 2012 (UTC)[reply]

There is, but you won't see a difference if there is no page with the name before the slash. There is a configuration option in the wiki software that sets, per namespace, whether it supports subpages or not. The main namespace has this turned off, so 9/11 is not treated as a subpage even though 9 exists. That's why {{SUBPAGENAME}} works the way it does. In a namespace that does support subpages, like Appendix:, {{SUBPAGENAME}} will only return the part after the slash. The fact that it works differently in Appendix: and mainspace is why we can use {{SUBPAGENAME}} to conveniently categorise both mainspace entries and Appendix entries. —CodeCat 11:19, 10 October 2012 (UTC)[reply]

Orphaning Template:zh[edit]

This template failed RFD, so it needs to be orphaned. But it's used so widely that I don't really know where to start. Does anyone else have suggestions? —CodeCat 16:36, 15 October 2012 (UTC)[reply]

Are there any instances were it can't be changed to cmn? If not, it's not quite as hard as you might think. Mglovesfun (talk) 17:40, 15 October 2012 (UTC)[reply]
That is why I asked... I have no idea. —CodeCat 17:48, 15 October 2012 (UTC)[reply]
I think there are two main prongs to start with:
  • Templates that don't support cmn properly, such as {{projectlink|pedia}}/{{pedia}}/{{pedialite}}.
  • Cases that are clearly safely bottable; for example:
    • Any occurrence of {{t|zh|...}} or {{t+|zh|...}} or {{t-|zh|...}} on a line that starts with * Mandarin: or *: Mandarin: or whatnot. (I know there are a lot of these. I can take care of them during my next translations-bot pass.)  Done
    • Any occurrence of {{head|zh|...}} within a ==Mandarin== section.
    • Any occurrence of {{pedia|lang=zh}} at all, once we get {{pedia|lang=cmn}} working.
After that, we can look to see if it's still "used so widely".
—RuakhTALK 18:43, 15 October 2012 (UTC)[reply]
I did a spot check, and the vast majority are Mandarin, either in a {{t}} following the word "Mandarin:" or an {{etyl}} under a Mandarin L2 header, with zh as the second parameter. I think a pass or two with a bot should leave us a few thousand to figure out further. {{attention|zh}} is a sizable chunk of the un-bot-able residue- especially on the talk pages- and then there are the pedia templates. I've already swapped out all the categories. Chuck Entz (talk) 05:11, 16 October 2012 (UTC)[reply]
I can already see the effects of the bot run: yesterday there were 24 pages of 500, now there are 9. I still see a few eligible {{t}}s, so I'm assuming it's still in progress. By the way, the only pedia template I ran into on my spot check was {{pedialite}}, so I'm guessing that would be a good one to start with for recoding. Chuck Entz (talk) 14:47, 16 October 2012 (UTC)[reply]
I seem to think {{wikimedia language}} is supposed to solve the cross-wiki linking problem. Mglovesfun (talk) 10:52, 17 October 2012 (UTC)[reply]
My sandbox is saying that {{pedia}} and {{slim-wikipedia}} aren't using {{wikimedia language}}. But wikimedia language seems to handle zh perfectly. Mglovesfun (talk) 11:04, 17 October 2012 (UTC)[reply]
Yes, exactly. —RuakhTALK 12:05, 17 October 2012 (UTC)[reply]
User:Conrad.Irwin/editor.js should auto-correct zh to cmn if possible. Mglovesfun (talk) 11:22, 17 October 2012 (UTC)[reply]
It currently doesn't: diff. I could try to fix it if everyone is ok with that, although I'm not quite sure what the best way is yet. —CodeCat 13:45, 18 October 2012 (UTC)[reply]
{{pedia}} and {{slim-wikipedia}} now support cmn as a language code. There are probably a few other templates that need fixing, but are rarely used for languages other than English (e.g. Wikispecies). Mglovesfun (talk) 11:25, 18 October 2012 (UTC)[reply]
  • I am still using these two templates; the first when there is only one form of a word, the second when there is a difference between traditional and simplified:
    ==Mandarin==
    {{zh-hanzi|[[回]][[想]]}}
    {{Hani-forms|[[美国]]|[[美]][[國]]}}
    Can someone please tell me the correct code for the second one? Thanks ---> Tooironic (talk) 22:30, 17 October 2012 (UTC)[reply]
Me too. Are they being deleted? Actually, we need one template for both cases above, which would allow one or two parameters. The existing templates could be made redirects perhaps? --Anatoli (обсудить/вклад) 02:16, 18 October 2012 (UTC)[reply]
I'm confused; this discussion is about orphaning {{zh}} in favor of {{cmn}}. How do {{zh-hanzi}} and {{Hani-forms}} figure into it? —RuakhTALK 02:48, 18 October 2012 (UTC)[reply]
Ah yes you're right sorry I got my wires crossed. {{zh-hanzi}} and {{Hani-forms}} are not related to the above discussion but my question stands - is there a more standard way to use those templates? I want to make sure I'm doing it right. ---> Tooironic (talk) 21:50, 18 October 2012 (UTC)[reply]

This template has now been orphaned as much as possible. The remaining transclusions seem to be from lists of ISO 639 codes, which are probably harmless. —CodeCat 19:16, 19 October 2012 (UTC)[reply]

Of course, in some cases it should not be orphaned, like in discussions such as this one, or any Grease Pit, Beer Parlour (etc.) archived. Mglovesfun (talk) 19:31, 19 October 2012 (UTC)[reply]
I've fixed those cases where the code was used to provide a link, and all cases of {{attention|zh}} and {{question|zh}}. Surely the spirit of an archived discussion is better preserved when the link still works, than if it ends up as something like [[word#Template:zh|word]]? —CodeCat 19:34, 19 October 2012 (UTC)[reply]

"Tagged but not listed" bot[edit]

Perhaps some of our more bot-savvy contributors can say if this is feasible and desirable or not:

Have a bot periodically check which entries transclude {{rft}}, {{rfv}} and {{rfd}}, i.e. make a list of which entries which transclude those templates. Then, check which entries are listed on the respective requests pages. (My idea of how to do that: make a list of strings that follow == [[ or ==[[ and precede ]]. That catches the relevant part of == [[foo]] - Spanish section ==.) Find any entries on the first list which aren't on the second list, and add them to the relevant requests page as "tagged but not listed". If it's possible to add the tag-comment ({{rfv|comment}}) when there is one, do so. Such a bot could run anywhere from once every few days to once every few months, just to catch things people may not. - -sche (discuss) 23:44, 16 October 2012 (UTC)[reply]

template:&lit[edit]

Shouldn't {{&lit}} use the given lang= to use the correct script and link to language sections? Currently the only thing the lang= is used for is for categorization. Also, is there any way to display alt text? --WikiTiki89 (talk) 11:11, 17 October 2012 (UTC)[reply]

Good now?​—msh210℠ (talk) 06:40, 22 October 2012 (UTC)[reply]
The alt text is good now, thanks. How about supporting sc= and/or inferring the script from the lang=? --WikiTiki89 08:42, 22 October 2012 (UTC)[reply]
Nevermind I did it myself. --WikiTiki89 09:10, 6 November 2012 (UTC)[reply]

Rukhabot[edit]

Rukhabot (talk • contribs) is polluting my watchlist! What's goin' on? -- I have only 367 pages in my watchlist, so I can imagine the disturbance for those who have thousands of pages... Can anyone stop him? — Actarus (Prince d'Euphor) 12:56, 17 October 2012 (UTC)[reply]

You should have a link at the top of the watchlist page to hide bots. I wouldn't want to stop any of the bots, because they do important work, Chuck Entz (talk) 13:08, 17 October 2012 (UTC)[reply]
Oh yes! Hide bots! I just forgot that one. Thanks for the tip. — Actarus (Prince d'Euphor) 13:15, 17 October 2012 (UTC)[reply]
Unfortunately, the "hide bots" option doesn't work very well; it hides any page whose most recent change is a bot-edit, even if the next-most-recent change is a non-bot-edit that's still within the time-range of interest. For example, I have [[stunod]] on my watchlist. It was edited on the 15th by -sche, and on the 16th by Rukhabot. "Hide bots" hide Rukhabot's edit, but doesn't reveal -sche's. (Unless I turn on the 'Expand watchlist to show all changes, not just the most recent' preference, but if you're worried about watchlist pollution . . .) —RuakhTALK 13:42, 17 October 2012 (UTC)[reply]
Re: "what's going on?": That's how bots work. You get used to it. (Actually, it's probably easier for those of us with thousands of pages on our watchlist, because we're more used to having to skim!)   Re: "Can anyone stop him?": Yes: as mentioned on User:Rukhabot, you can make the bot stop all activity by posting a message on its talk-page. But, um, don't do that. ;-)   (And anyway it's already finished its latest batch of edits.) —RuakhTALK 13:42, 17 October 2012 (UTC)[reply]

template:prefixsee[edit]

Is it just me or is this broken on some pages? (see [[e-]], as opposed to [[pseudo-]] where it works) --WikiTiki89 16:08, 17 October 2012 (UTC)[reply]

The "+" didn't generate the list for [[e-]], but did for [[pseudo-]] with the same syntax for the template. DCDuring TALK 17:01, 17 October 2012 (UTC)[reply]
It works if you call {{deriv}} directly, so the problem must be somewhere within {{prefixsee}}'s source code... -- Liliana • 17:09, 17 October 2012 (UTC)[reply]
The difference is that [[e-]] had * {{prefixsee|en}}, whereas [[pseudo-]] had {{prefixsee|en}} (no bullet). I changed the former to match the latter, and it works now. —RuakhTALK 17:27, 17 October 2012 (UTC)[reply]
Just curious, why would that cause a problem? --WikiTiki89 17:30, 17 October 2012 (UTC)[reply]
Because MediaWiki is fragile and finicky. Or, more specifically, because this: 
* {{prefixsee|en}}
expands to this: 
* <nowiki/><div class="derivedterms<nowiki/> {{{sc}}} CategoryTreeTag" data-ct-mode="10" data-ct-options="{"mode":10,"hideprefix":20,"showcount":false,"namespaces":[0]}"><div class="CategoryTreeSection"><div class="CategoryTreeItem"><span class="CategoryTreeBullet"><span class="CategoryTreeToggle" style="display: none;" data-ct-title="English_words_prefixed_with_e-" title="expand" data-ct-state="collapsed">[<b>+</b>]</span> </span> <a class="CategoryTreeLabel  CategoryTreeLabelNs14 CategoryTreeLabelCategory" href="/wiki/Category:English_words_prefixed_with_e-">English words prefixed with e-</a></div>
                <div class="CategoryTreeChildren" style="display:none"></div></div>
                </div>
                <nowiki/>
with only the first line being part of the bullet-list created by *. So you would get HTML like this: 
<ul>
<li>
<div class="derivedterms {{{sc}}} CategoryTreeTag" data-ct-mode="10" data-ct-options="{"mode":10,"hideprefix":20,"showcount":false,"namespaces":[0]}">
<div class="CategoryTreeSection">
<div class="CategoryTreeItem"><span class="CategoryTreeBullet"><span class="CategoryTreeToggle" style="display: none;" data-ct-title="English_words_prefixed_with_e-" title="expand" data-ct-state="collapsed">[<b>+</b>]</span></span> <a class="CategoryTreeLabel  CategoryTreeLabelNs14 CategoryTreeLabelCategory" href="/wiki/Category:English_words_prefixed_with_e-">English words prefixed with e-</a></div>
</li>
</ul>
<div class="CategoryTreeChildren" style="display:none"></div>
</div>
</div>
except that we pass our HTML through HTML Tidy, which addresses the misnested tags. Specifically, it detects that the <li> contains unclosed <div>s, so it closes them, and then later it detects some (now-)meaningless </div>s, so it removes them. The end result is this: 
<ul>
<li>
<div class="derivedterms {{{sc}}} CategoryTreeTag" data-ct-mode="10" data-ct-options="{"mode":10,"hideprefix":20,"showcount":false,"namespaces":[0]}">
<div class="CategoryTreeSection">
<div class="CategoryTreeItem"><span class="CategoryTreeBullet"><span class="CategoryTreeToggle" style="display: none;" data-ct-title="English_words_prefixed_with_e-" title="expand" data-ct-state="collapsed">[<b>+</b>]</span></span> <a class="CategoryTreeLabel  CategoryTreeLabelNs14 CategoryTreeLabelCategory" href="/wiki/Category:English_words_prefixed_with_e-">English words prefixed with e-</a></div>
</div>
</div>
</li>
</ul>
<div class="CategoryTreeChildren" style="display:none"></div>
with the div.CategoryTreeChildren being completely outside the div.CategoryTreeTag and div.CategoryTreeSection, which means the JavaScript that handles this stuff has no hope of finding it.
If we really want the bullet, we can use <ul><li>...</li></ul>, which doesn't get broken by a line-break. Or, we can push for the extension to be modified so that it doesn't include these line-breaks.
—RuakhTALK 18:15, 17 October 2012 (UTC)[reply]
Oh — or we could handle this in our own JavaScript: on page-load, we could search for misplaced div.CategoryTreeChildrens, and move them where they belong. —RuakhTALK 18:35, 17 October 2012 (UTC)[reply]
Personally, I think the less we do client-side, the better. --WikiTiki89 18:41, 17 October 2012 (UTC)[reply]
Interesting... We don't need the bullet, that was just a mistake anyway, but I would still say those linebreaks should be removed. Not sure how much influence we would have on those MediWiki people for such an insignificant problem. --WikiTiki89 18:31, 17 October 2012 (UTC)[reply]

label testing[edit]

I just tested the {{label}} template on water. The results were as follows:

Before: 

NewPP limit report
Preprocessor visited node count: 211061/1000000
Preprocessor generated node count: 140992/1500000
Post-expand include size: 513582/2048000 bytes
Template argument size: 163642/2048000 bytes
Highest expansion depth: 24/40
Expensive parser function count: 99/500

After: 

NewPP limit report
Preprocessor visited node count: 208845/1000000
Preprocessor generated node count: 136241/1500000
Post-expand include size: 506688/2048000 bytes
Template argument size: 162459/2048000 bytes
Highest expansion depth: 24/40
Expensive parser function count: 116/500

The savings compared to {{context}} are only marginal, however the big problem is the #ifexist call in {{label}}. If there was any way to get rid of it, label might become a viable alternative to context, but not like this. -- Liliana • 19:39, 17 October 2012 (UTC)[reply]

Am I missing something? I don't see #ifexist anywhere in {{label}}. --WikiTiki89 19:52, 17 October 2012 (UTC)[reply]
Firstly — it's in {{label/label}}. But secondly — Liliana has [[water]] on the brain. Unless you share her belief that a change is for the good if-and-only-if it improves [[water]], you won't find this discussion worthwhile. —RuakhTALK 19:59, 17 October 2012 (UTC)[reply]
It's going to be a problem for all pages that make heavy use of context templates, like go. -- Liliana • 20:00, 17 October 2012 (UTC)[reply]
Why don't we just wait for lua to make a new context template? --WikiTiki89 20:07, 17 October 2012 (UTC)[reply]
@Liliana: {{fact}} —RuakhTALK 21:04, 17 October 2012 (UTC)[reply]
Consider the fact that {{label}} is by far not the only template that makes use of #ifexist. {{etyl}}, another commonly used template, uses it as well. With both together, it's easy to hit MediaWiki's limit on #ifexist calls. -- Liliana • 21:49, 17 October 2012 (UTC) (addendum: and if that is not enough, {{a}} is yet another common template making use of #ifexist.)[reply]
This has been suggested before, but: shouldn't we just have two sets of templates, one designed for the majority of our pages (like გიშველის, which are small), and one designed for the handful of very large, template-heavy pages like water, a, go, go, iron and run? - -sche (discuss) 20:43, 17 October 2012 (UTC)[reply]

Problems with internal editor[edit]

A problem seems to have arisen with the internal editor during the past 12 hours. All seems fine when I am using Firefox - but the problem arises when I use Chrome (I'm not aware of having changed any of its settings in that time). The problem:

  • With both "beta feature" boxes ticked - the edit box/window is empty
  • With neither "beta feature" boxes ticked - the edit box/window has no rows in it (its about 1 mm high!)

I just tried using Internet Explorer to edit a page and IE just stopped working. Is it me - or what? — Saltmarshαπάντηση 04:49, 19 October 2012 (UTC)[reply]

To eliminate personal preference settings I just tried all 3 browsers without logging in - with the same results. — Saltmarshαπάντηση 04:52, 19 October 2012 (UTC)[reply]
I found it quite slow to load the entire page for a while earlier, but not at this time. DCDuring TALK 05:30, 19 October 2012 (UTC)[reply]
My apologies for having bothered you with that (but on the otherhand others might encounter it). I installed OpenOffice 3.4.1 yesterday (using v 3.3 ... previously) and I had set Chrome to use DejaVu Sans Mono as its monospaced font. Here lies the problem - which disappears when Courier new is chosen. DejaVu fonts work in OpenOffice - but do peculiar things in (for example) WordPad - where they appear "invisibly" in the pulldown font list - and do odd things to the cursor if selected. No more time to investigate - but the problem is explained. — Saltmarshαπάντηση 09:47, 19 October 2012 (UTC)[reply]

Broken Assisted translation adding?[edit]

Since yesterday afternoon I am not able to add translations with Conrad Irvin's Assisted tool any more. When I click Preview translations It get an error message Could not connect to server on pink background in the page editing window located the left top corner of the webpage. This is irrespective of browser (I tried Firefox, Chrome and IE on different PCs, Linux and Windows) and whether I'm logged in or not. I have also noted that no Assisted translations apear to be added at recent changes, at least not among the latest 500 edits. Does anyone know what is happening? Matthias Buchmeier (talk) 10:51, 19 October 2012 (UTC)[reply]

I’m having the same problem. It is probably the result of Wiktionary:Beer parlour#Upcoming software changes - please report any problems. —Stephen (Talk) 11:15, 19 October 2012 (UTC)[reply]
It seems to be working again. A big thanks to Ruakh. Matthias Buchmeier (talk) 13:40, 19 October 2012 (UTC)[reply]
I've fixed it for now, but not in the best way.
  • To get the fix: Visit http://en.wiktionary.org/w/index.php?title=User:Conrad.Irwin/editor.js&action=raw&ctype=text/javascript and perform a hard-refresh (Shift+F5). Or, just wait, and you'll get the new version eventually.
  • What the problem was: Rather than knowing which API calls expect title=... and which expect titles=..., the script just covers both cases by always using title=...&titles=.... Apparently the API used to completely ignore spurious parameters, so this wasn't a problem; but now it gives a warning-message, at least in some cases. The script was designed to take warnings just as seriously as errors.
  • What I changed: The script now ignores warnings.
  • What should be changed: The script should take warnings seriously, at least when the person viewing the page is an admin. We should only pass title= when it's needed and titles= when it's needed.
—RuakhTALK 13:42, 19 October 2012 (UTC)[reply]

Uh, help?[edit]

I wanted to replace Template:langprefix with a faster version. I put my version at User:CodeCat/langprefix and when it was done I wanted to move it, so I did. Except now the move failed but the original has been deleted and I can't restore it! I keep getting database errors and timeouts! Help! —CodeCat 20:57, 20 October 2012 (UTC)[reply]

You shouldn't have done that. -- Liliana • 20:59, 20 October 2012 (UTC) </internetmeme>[reply]
Really now??? Seriously I'm scared... I just broke all of Wiktionary. Help please? —CodeCat 21:00, 20 October 2012 (UTC)[reply]
In all seriousness, you should ask on the IRC, in #mediawiki... the developers hang out there and they may be able to help you. -- Liliana • 21:01, 20 October 2012 (UTC)[reply]
Is it possible to create it and paste the new code? — Ungoliant (Falai) 21:03, 20 October 2012 (UTC)[reply]
Why didn't you just edit the page, but deleted it with whole history? Maro 21:03, 20 October 2012 (UTC)[reply]
I tried re-creating it with the old code, and that didn't work either. —Angr 21:04, 20 October 2012 (UTC)[reply]
I'm afraid no. -- Liliana • 21:05, 20 October 2012 (UTC)[reply]
Oh, I think Angr fixed it. -- Liliana • 21:06, 20 October 2012 (UTC)[reply]
Yeah, I just pasted CodeCat's new code in and that worked. Even then I got a "Wikimedia Foundation Error", but it worked anyway. —Angr 21:07, 20 October 2012 (UTC)[reply]
It works??? Thank goodness! *sigh of relief* I feel so stupid... —CodeCat 21:08, 20 October 2012 (UTC)[reply]
Etyl and recons aren’t working correctly with proto: languages here. — Ungoliant (Falai) 21:12, 20 October 2012 (UTC)[reply]
No, my original intention was to move all of the subpages from User:CodeCat/langprefix too. I'm moving them now, any help would be appreciated! See [1] —CodeCat 21:14, 20 October 2012 (UTC)[reply]
All done! —Angr 21:25, 20 October 2012 (UTC)[reply]

Ok... crisis averted. Hopefully. Thank you for your help Angr and everyone else. I feel so stupid...

But let me explain what I meant to do... From experience we know that switches tend to be slow in templates, while looking up subpages is faster. That is why {{langrev}}, {{catboiler}} and all the language templates use subtemplates. {{langprefix}} was an exception, which seemed strange because of how widely transcluded it is. So I wanted to change it so that it works just like {{langrev}} does, with subtemplates. And it does work... it was just MediaWiki that failed me. Now there is one rather big 'security' hole in this new system that should be fairly easy to fix. Currently, anyone can create {{langprefix/en}} and break everything, so that subpage along with the subpages for every other possible code will need to be create protected. The easiest way to do that is probably the same way we already do it with the language subtemplates, by transcluding them all to one page and then cascade protecting that page. —CodeCat 21:29, 20 October 2012 (UTC)[reply]

Well, you're an admin, can't you do that? —Angr 16:23, 21 October 2012 (UTC)[reply]
Ok I've created it: Wiktionary:Index to templates/languages/protection/langprefix. —CodeCat 17:00, 21 October 2012 (UTC)[reply]

xte[edit]

Hello. I have been brewing this script for some time and I am quite pleased with how it turned out. Right now it primarily processes translation lists so that they use {{t}}. If anyone wants to join me in running it through Wiktionary, they can install the script (the link is on its page). You can also give it language names to ask it for codes and vice versa. So, if it sounds good to you, try it out. And maybe answer my two questions about what to do next.

  • I have been wondering if it would be feasible to automate romanisation. Can anyone tell me how and for which languages (if any) can it be reliably done algorithmically, and preferably without blowing up the script size too much? I am a bit afraid I might forget about some exceptional cases.
  • What things could a translator want (semi-)automated, which existing tools do not cover already (and are not merely extensions of these other tools' functionality)?

I am going to have little free time in the near future, so I do not promise I will implement anything. I just want some directions if I ever come back to this. Keφr (talk) 18:35, 21 October 2012 (UTC)[reply]

FYI, there are 55 transclusions for scriptrev. Moral of the story: it never hurts to go to the template and click What Links Here. Chuck Entz (talk)
Then 1 = 55. But branches of mathematics in which this equality holds are considered rather dull. I retract that statement. Fields of characteristic 2, for one, are quite fascinating. On a less serious note, even though I would be surprised if this template already found use anywhere else (I created it yesterday, and it is not even fully working — a good task for a bot, I think), I was wondering if there are any current or future uses that WhatLinksHere will not show. Keφr (talk) 10:41, 22 October 2012 (UTC)[reply]
If template A is transcluded as <includeonly> in template B then template A's What Links Here will not show template B but only the pages that transclude template B. I.e. if B is not used then A's What Links Here is also empty. --WikiTiki89 11:20, 22 October 2012 (UTC)[reply]
I specifically mentioned transclusions, so having Hide Transclusions selected is comparing apples and oranges. I may have been mistaken, but that was a non-response. At any rate, other templates are apparently linking to it by way of the category it's in, so there may be potential for interactions you're not expecting, since people could see it in the lists of supplementary templates and put it to use. Chuck Entz (talk) 13:55, 22 October 2012 (UTC)[reply]
diff It looks like it parsed the qualifier wrong and thought it was part of the translation. It should really convert ''(for posher soups)'' into {{qualifier|for posher soups}}. —CodeCat 16:09, 22 October 2012 (UTC)[reply]
Also, on [[bug]], it fails to process the last Portuguese translation. --WikiTiki89 16:21, 22 October 2012 (UTC)[reply]
It looks like it mangled the Hebrew translation too. —CodeCat 16:26, 22 October 2012 (UTC)[reply]
Yeah but the transliteration should not have been like that in the first place. --WikiTiki89 16:29, 22 October 2012 (UTC)[reply]
Why not? Is there anything in principle against having transliterations with parentheses in them? —CodeCat 16:31, 22 October 2012 (UTC)[reply]
The transliteration was incorrect, but the script made it much worse. —RuakhTALK 16:45, 22 October 2012 (UTC)[reply]
I disagree, it made it stand out even more so as being wrong, causing us to notice it and fix it. --WikiTiki89 16:47, 22 October 2012 (UTC)[reply]
Who is us? It looks like you actually didn't notice it. CodeCat noticed it in the diff, but she wouldn't have looked at that diff if you hadn't linked to it. But even supposing it's true that the brokenness caused the problem to be noticed faster than otherwise. What if the editor using the script hadn't known what the right fix was? Or what if the transliteration had been correct? (That specific transliteration should not have included (, but that's not true of all transliterations.) It would be one thing if the script had detected the issue and added some sort of cleanup category, but "it was already less-than-perfect" is not a good reason to completely break something. —RuakhTALK 16:55, 22 October 2012 (UTC)[reply]
That was mostly intended humorously. What I meant was it happened to turn out better than it would have. That of course is not a good reason to leave bugs unfixed. --WikiTiki89 16:57, 22 October 2012 (UTC)[reply]
I took some effort to address the issues raised. Personally though, I think this is the kind of case that should be handled manually. Also, can anyone show me an example where parentheses legitimately appear in a transcription? Keφr (talk) 17:51, 22 October 2012 (UTC)[reply]
Also, there are a few other suspicious Hebrew entries in bug. Search for ", literally". No script can fix that. Yet. Until someone creates an AI construct in JavaScript, that is. People just have to look through it. Keφr (talk) 18:00, 22 October 2012 (UTC)[reply]
Of course, the mere fact that something can't be handled correctly by a program doesn't always — or even usually — mean that it's O.K. for a program to handle it incorrectly. Rather, it usually means that scripts need to leave it be. —RuakhTALK 19:02, 22 October 2012 (UTC)[reply]
Also a suggestion about the error alerts, instead of showing an alert for every translation that causes an error, can't you just collect them all in a list and show one big alert at the end? --WikiTiki89 16:29, 22 October 2012 (UTC)[reply]
Done. Keφr (talk) 16:52, 22 October 2012 (UTC)[reply]
It did something weird with Korean here and with Finnish here. --WikiTiki89 08:29, 23 October 2012 (UTC)[reply]
To use the cliché, this is not a bug, but a feature. The Finnish diff is expected behaviour. A multi-word phrase is treated as idiomatic and joined together to make a link to a single article. Also, a piped link ([[a|b]]) will have its label extracted (b), rather than the link target (a), as the label will probably have the word inflected, and I think the inflected word is a better link target. On the other hand, this sometimes makes a link to an article with accent marks, which should appear in a link label, but not in the article name (like for Latin or Russian). That could be improved, I guess. The Korean diff may look a bit awkward, but I am not sure what the best behaviour would be; probably generating two different {{t}} invocations. I guess this is the same the word written in Hangul and then in Hanja. I am not sure if handling this one is worth the trouble.
Also, take a look at the next "tree" diff — Syriac Hawaiian? Please, review the diff thoroughly, and before saving. Do not just run it and save immediately. I cannot stress this enough. Keφr (talk) 18:07, 23 October 2012 (UTC)[reply]
All of those expected behaviors are wrong. You should not join together multi-word phrases into a single link; you should not assume that [[a|b]] is supposed to be [[b]]; and in a case like the Korean one where it's not clear what the correct behavior is, you should do nothing. It's better to leave something alone than to break it. —RuakhTALK 18:49, 23 October 2012 (UTC)[reply]
Agreed, I spotted this and would raise the same point. Mglovesfun (talk) 21:43, 24 October 2012 (UTC)[reply]
I haven't been able to successfully run this, can anyone tell me why? The [fix] button appears but does literally nothing. Mglovesfun (talk) 18:13, 25 October 2012 (UTC)[reply]
A typo in the code, fixed. Flush your caches. Keφr (talk) 19:17, 26 October 2012 (UTC)[reply]
Well, this is how these entries would look like if they were added with WT:EDIT — or is that wrong too? Personally, I considered that assumption a relatively safe one. To which form, do you think, entries like that should be converted? Leaving them as they are is obviously suboptimal. Keφr (talk) 19:17, 26 October 2012 (UTC)[reply]
Leaving unclear cases as they are, but fixing common/easy/straightforward/low-risk cases, is still a huge improvement over the status quo. Until AI improves significantly, "obviously suboptimal" is our only option. —RuakhTALK 19:51, 26 October 2012 (UTC)[reply]
Yes, but how about the amino-acid intelligence which is operating the script? Because it is ultimately up to them to decide which markup is right. That the script does something instead of nothing means it will show up in the diff and catch their attention. The question is, what should they do next. (I still think treating piped links as inflected and multi-word phrases as idiomatic is in almost all cases a reasonable thing to do. Any specific couterexamples?) Keφr (talk) 08:30, 27 October 2012 (UTC)[reply]
Well, for example, I just tried fixing [[yes]]. None of the piped-links were inflected forms. (Actually, if they had been inflected forms, then it would have been wrong to change them: we want to point readers to the entry that actually has the information they need. But whatever.) In several cases, the piped-link was of the form [[pagename#langname|text]], with text being the same as pagename; those cases can be safely converted to {{t|langcode|pagename-cum-text}}, but they still generate a warning, which I think conditions the human reader to ignore the warnings. (That's a minor problem, but IMHO still worth fixing.) But more problematically, one of the piped-links was Arabic; the translation linked to أجل, but displayed أجَل. This is completely correct, but your script wanted to change it. Even if a human editor noticed that something was strange here, what is (s)he supposed to do about it? The script has already changed the text in the edit-window, and what with the strange script and the right-to-left rendering (putting the pagename on the right side of the pipe and the linktext on the left side) it's not so easy for a non-Arabic-speaking editor to work out what's going on and how to undo the script's mistake.
As for counterexamples on the idiomatic front . . . check out Special:WhatLinksHere/Template:t-SOP. Pages that actually use that template are immune to your script (it gets confused and bails out), but that template is only a few months old and not well-known, and already it's on scores of pages. Clearly human editors, who actually speak the languages they're translating into, sometimes feel that unidiomatic foreign-language word-sequences are sometimes the best way to translate English terms. Neither your script, nor the human who's running it, should override that judgment without knowing anything about it.
—RuakhTALK 14:48, 27 October 2012 (UTC)[reply]


I've taken to posting specific issues at User talk:Kephir/gadgets/xte.js, where they will all be kept together, not on various different Grease Pit pages. Mglovesfun (talk) 12:26, 4 November 2012 (UTC)[reply]

Edit conflict while editing a section.[edit]

When there is an edit conflict while editing a section, there is a glitch that causes everything outside the section to be removed from the edit window in the edit conflict screen. This has caused several editors to accidentally delete large chunks of pages. Anyone know what's wrong? --WikiTiki89 22:39, 21 October 2012 (UTC)[reply]

No idea, but it's happened to me at Wikipedia too. —Angr 20:23, 22 October 2012 (UTC)[reply]
This is a known issue and it has been filed in the issue tracker under https://bugzilla.wikimedia.org/show_bug.cgi?id=41280 --Malyacko (talk) 19:48, 23 October 2012 (UTC)[reply]

Improving communication between your wiki and "tech people"[edit]

Hi. I'm posting this as part of my job for the WMF, where I currently work on technical communications.

As you'll probably agree, communication between Wikipedia contributors and "tech people" (primarily MediaWiki developers, but also designers and other engineers) hasn't always been ideal. In recent years, Wikimedia employees have made efforts to become more transparent, for example by writing monthly activity reports, by providing hubs listing current activities, and by maintaining "activity pages" for each significant activity. Furthermore, the yearly engineering goals for the WMF were developed publicly, and the more granular Roadmap is updated weekly.

Now, that's all well and such, but what I'd rather like to discuss is how we can better engage in true collaboration and 2-way discussion, not just reports and announcements. It's easy to post a link to a new feature that's already been implemented, and tell users "Please provide feedback!". It's much more difficult to truly collaborate every step of the way, from the early planning to deployment.

Some "big" tech projects sponsored by the WMF are lucky enough to have Oliver Keyes who can spend a lot of time discussing with editors, basically incarnating this 2-way communication channel between users and engineering staff. But Oliver can only do so much: he has to focus on a handful of features, and primarily discusses with the English Wikipedia community. We want to be able to do this for dozens of engineering projects with hundreds of wikis, in many languages, and truly collaborate to build new features together. Hiring hundreds of Community Liaisons isn't really a viable option.

There are probably things in the way we do tech stuff (e.g. new software features and deployments) that drive you insane. You probably have lots of ideas about what the ideal situation should be, and how to get there: What can the developer community (staff and volunteers) do to get there? (in the short term, medium term, long term?) What can users do to get there?

I certainly don't claim to have all the answers, and I can't do a proper job to improve things without your help. So please help me help make your lives easier, and speak up.

This is intended to be a very open discussion. Unapologetic complaining is fine; suggestions are also welcome. Stock of ponies is limited. Guillom (talk) 14:46, 23 October 2012 (UTC)[reply]

As a less technical contributor (ie, when I try to contribute, I feel like I am wasting people's time), I am frustrated by the relative hopelessness expressed by our more technically adept contributors once a matter is connected with MediaWiki software changes or a long-standing bug or change request. My list of wishes and perceived problems is growing. Some apparently can be overcome by special bot runs to compensate for MW software-connected dysfunction, but it seems like an imposition on our technically adept contributors. Two favorites of mine are the non-functionality of Special:WantedPages and Special:WantedTemplates, the first associated with a long-standing MW bug, the latter with a complexresource-intensive workaround that is in widespread use. DCDuring TALK 15:32, 23 October 2012 (UTC)[reply]
This is something that I've been hearing a lot: as soon as an issue (or possible improvement) requires a change to the MediaWiki software, the perceived likelihood of it ever being implemented dramatically decreases. As a long-time editor, this is also something I've been feeling, and it's probably due to the fact that the WMF has long been ridiculously understaffed. Now that they have more developers, they can tackle more bugs and features, but this may not have been perceived yet by editors. There's also an issue with giving visibility to the requests from editors, and some great ideas have been suggested to improve that. If you have any other suggestions or concerns, let's continue this discussion. It's very useful to me. Guillom (talk) 12:24, 25 October 2012 (UTC)[reply]

No "Edit" link at main Grease pit[edit]

I don't see an "edit" tab at the main Wiktionary:Grease pit page or individual section edit links. I think I used to. (People can of course edit at the month-specific page if they think to, but it's less obvious.) Is this an intentional change by Wiktionary folks, or shall I report it as a bug so it can get fixed?

best, Sharihareswara (WMF) (talk) 18:58, 23 October 2012 (UTC)[reply]

All the discussions are now in the subpages, the main page is only really to give an overview of the last three months. I do see edit links, though. —CodeCat 19:01, 23 October 2012 (UTC)[reply]
Re: "I do see edit links, though": That's because you're an admin, so can edit protected pages. (I think it could be considered a MediaWiki bug that non-admins don't see the section-edit links, seeing as those point to edit-pages for unprotected pages, but I wouldn't hold my breath for the developers to fix it!) —RuakhTALK 19:07, 23 October 2012 (UTC)[reply]
Yes I agree. That is a bug. All users can edit the sections that are transcluded from the subpages, they just can't edit the main page itself. So they should see edit links. —CodeCat 19:08, 23 October 2012 (UTC)[reply]
Shouldn't we have view source section links even when the page it links to is protected? --WikiTiki89 19:11, 23 October 2012 (UTC)[reply]
Not much point. There generally isn't much need to view the source of a section of a protected page.
The bug is not specific to here, by the way. See w:WP:VPA, for example, where there are no edit section links, despite it being probably very frequently used by non-admins. --Yair rand (talk) 19:14, 23 October 2012 (UTC)[reply]
Wiktionary:Grease pit is protected, as it's not supposed to be edited directly except when adding a new month section. --Yair rand (talk) 19:06, 23 October 2012 (UTC)[reply]
Maybe that is tolerable for WT:GP, but it would seem to make the subpage approach unacceptable for discussion pages that are supposed to be open for all. Is there a way to make the subpage-associated edit behavior look more consistent with the normal MW edit behavior? DCDuring TALK 19:16, 23 October 2012 (UTC)[reply]
We should probably just unprotect the page, and maybe use CSS to hide the top edit button for non-admins, until the bug is fixed. --Yair rand (talk) 19:20, 23 October 2012 (UTC)[reply]
That sounds like a promising kludge, but this would seem to be a show-stopper for further deployment of the subpage approach. I note that w:WP:VPA has a fairly elaborate alternative user interface to help overcome the lack of edit links on the top page. DCDuring TALK 19:25, 23 October 2012 (UTC)[reply]
The fact that it's protected wasn't clear to me at all. I was just confused to not see "Edit" links for sections and had no idea how to add a comment. Maybe I missed the "If you want to comment on a topic, go to the month page" comment somewhere, or does it not exist? --Malyacko (talk) 19:50, 23 October 2012 (UTC)[reply]
Doesn't exist. Any objections to unprotecting the page? --Yair rand (talk) 19:54, 23 October 2012 (UTC)[reply]
What happens when the current GP is transcluded onto another page that isn't protected? Does that bring the section links back? —CodeCat 20:03, 23 October 2012 (UTC)[reply]
Just had a strange deja vu. Have we had a conversation like this in the past? --WikiTiki89 20:17, 23 October 2012 (UTC)[reply]
I've unprotected the page and added the CSS. --Yair rand (talk) 22:22, 24 October 2012 (UTC)[reply]
It looks good. I notice that the link is hidden even from admins, but to be honest, if someone can't figure out how to get to the edit-page when there isn't a tab there, then they probably shouldn't be editing the main GP page. :-P   —RuakhTALK 22:40, 24 October 2012 (UTC)[reply]
Hm? It's not hidden for me. Strange... --Yair rand (talk) 23:26, 24 October 2012 (UTC)[reply]
Oh, weird, I see it now. I guess my browser didn't immediately pick up the new sysop-specific CSS? Or else I had some sort of weird brain-fart/blindness thing. Either way, never mind. :-)   —RuakhTALK 23:34, 24 October 2012 (UTC)[reply]
Thank you for the fix, Yair rand. I appreciate it. And thanks to everyone here for un-confusing me. :-) Sharihareswara (WMF) (talk) 15:02, 28 October 2012 (UTC)[reply]

template:ethnologue[edit]

What is the purpose of the template link in {{ethnologue}}? For example on [[Belorussian]], the ethnologue code is different from the template name and so it just shows up as a redlink. --WikiTiki89 15:46, 28 October 2012 (UTC)[reply]

Whatever its purpose, it's not made clear that it's a link to our template, not to anything at Ethnologue. Even when it's a bluelink, I'm sure users not familiar with our templates are going to be very confused if they click on it- even more so if they click on a redlink. Do we really want to send people there without explanation? And do we want to redlink templates which we went to the trouble of deleting as redundant? Chuck Entz (talk) 16:04, 28 October 2012 (UTC)[reply]
I think those redlinks constitute the most up-to-date accessible "documentation" of the validity of a given language code for we should use for a language in any template that requires such a code. DCDuring TALK 16:25, 28 October 2012 (UTC)[reply]
Not sure what you're saying there, DCDuring. --WikiTiki89 17:37, 28 October 2012 (UTC)[reply]
There is no purpose. It should be removed. -- Liliana • 18:31, 28 October 2012 (UTC)[reply]
It shows the ISO 639-3 language code, but its intent was to show the language code that we use on Wiktionary, which is not ISO 639-3. Belarusian should be be. —Stephen (Talk) 20:15, 28 October 2012 (UTC)[reply]
We have Template:ISO 639, which does what you want. -- Liliana • 20:25, 28 October 2012 (UTC)[reply]

Nonstandard languages/names in translations sections[edit]

Is it feasible to make a list of all top-level / un-nested entries in translations sections, i.e. entries of the form * foo: or *foo:, where foo is not the name of a language we have a template for? This would catch things like Algherese (a lect we don't recognise as a language), Rapanui (nonstandard spelling of Rapa Nui), etc. It might catch a lot of things, in which case we could identify and bot-fix the spelling variants, and then re-make the list. - -sche (discuss) 02:23, 30 October 2012 (UTC)[reply]

Any nonstandard names should probably be added to {{langrev}} and to the /names template of the code template. For example {{langrev/Algherese}} should be "ca" and {{ca/names}} should include "Algherese". That way, such fixups can probably be somewhat automated. —CodeCat 02:31, 30 October 2012 (UTC)[reply]
I've already changed some of these by bot, such as Sinhala to Sinhalese. I was thinking of making a similar request too. Mglovesfun (talk) 11:37, 30 October 2012 (UTC)[reply]
What's the best way to get/create a list of languages we do have templates for? I had hoped to use Wiktionary:Index to templates/languages/protection/A-M and N-Z, but they include some nonexistent templates (such as {{diq}}), and leave out some existent ones (such as {{vi}}, and more generally any that begin with v or w). —RuakhTALK 23:23, 30 October 2012 (UTC)[reply]
Well ideally you could look for templates with the string "<noinclude>{{langt}}", and from there look for any subpages of those templates. I don't think all of our language templates follow this format exactly though. Another option would be to just take all of the members of Category:Language code templates (from the category dump). DTLHS (talk) 23:49, 30 October 2012 (UTC)[reply]
The category dump sounds like the best idea. Perhaps a list made from the category dump could be compared to a list made of templates with the string DTLHS mentions, and duplicates removed, just to be sure everything gets on. My first thought would have been to figure out how to extract them from WT:LANGLIST—or figure out how LANGLIST is made!
If the protection pages are missing some templates, that means I made some mistake/oversight when I set up those pages. If CodeCat's restructuring of the pages doesn't catch {{vi}} et al., I'll work out a way to add them myself. - -sche (discuss) 00:13, 31 October 2012 (UTC)[reply]
Templates are still being added, and some like {{zh}} are also removed. So it would be better to make the new lists from scratch, based on the current contents of Category:Code templates. Although, I imagine it might be desirable to also have a list of templates we once had in (significant) use, but then deleted. We wouldn't want someone else recreating {{zh}} on a whim, after all. —CodeCat 13:24, 31 October 2012 (UTC)[reply]

template:quote-book[edit]

A problem appeared at borne. I have no idea what caused it or how to fix it. Perhaps someone else does.​—msh210℠ (talk) 17:23, 30 October 2012 (UTC)[reply]

The fix that you made at 17:16 to the non-templanated version, changing ''borne''' to '''borne''' is exactly the fix that you could have made to fix the templanated version. —RuakhTALK 19:06, 30 October 2012 (UTC)[reply]
This is a good spot to use <b> and <i> instead of ''' and ''. Mglovesfun (talk) 19:10, 30 October 2012 (UTC)[reply]
Good idea. —RuakhTALK 19:42, 30 October 2012 (UTC)[reply]
 Done: Template:quote-book/source?diff=18675143. —RuakhTALK 12:53, 31 October 2012 (UTC)[reply]
Ah, oops.​—msh210℠ (talk) 05:08, 31 October 2012 (UTC)[reply]

Emptying and deleting Category:Spellings by language[edit]

This category failed RFD and contains mostly empty categories, which need to be deleted as well. Is there an easy way to delete them all? My bot has no administrative powers so it can't delete things. —CodeCat 17:51, 31 October 2012 (UTC)[reply]

Each admin can choose five of them and delete them ;). Maro 18:13, 31 October 2012 (UTC)[reply]
I'll see if I can get them with AWB. - -sche (discuss) 18:23, 31 October 2012 (UTC)[reply]
I've deleted all the subcategories, but I note that the following categories still exist, and some need new homes:
Category:German words affected by 1996 spelling reform
Category:Latin medieval spellings
Category:Greek terms by their sequences of characters (compare Category:Latin terms by their sequences of characters)
Category:Portuguese terms ending in N
- -sche (discuss) 18:33, 31 October 2012 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2012/October&oldid=71471687"