Are there any templates here that resemble the editprotected template at en:wp? It seems to me that Wiktionary:Criteria for inclusion could stand to have a few commas added, but I can't find an editprotected template to make a request on the talk page. As well, I can't find something similar to the administrators' noticeboards at en.wp and Commons. Nyttend 22:21, 2 August 2010 (UTC)

I'm not aware that we have any editprotected templates. Just make a request on the talk page, here, the information desk or on the talk page of an active administrator. We don't have any direct equivalent of the administrators' noticeboards of en.wp, what we have are the primary discussion pages

• Wiktionary:Tearoom for words and lexical discussions
• Wiktionary:Beer parlour for policies, procedures and the like. User problems that aren't clearly vandalism usually go here.
• Wiktionary:Grease pit for technical discussions
• Wiktionary:Etymology scriptorium for discussions about etymology
• Wiktionary:Information desk for general questions and things that don't fit into any other room

Just pick one that fits what you want, and don't worry too much about getting it right every time. We are a much smaller community than en.wp so we don't have the need (or resources) for as much specialisation as that project has. Thryduulf (talk) 00:00, 3 August 2010 (UTC)

Okay, thanks; I've asked Yair rand for help. Being so unfamiliar with Wiktionary, I hadn't realised that pages like this were appropriate for such requests, let alone that there weren't pages such as an administrators' noticeboard. Nyttend 01:00, 3 August 2010 (UTC)

It would be helpful if you could make a note of things like this so we can produce a more comprehensive guide to Wiktionary for those familiar with Wikipedia than the current brief welcome template (which reads quite negatively). I've made a very, very brief set of notes to start the ball rolling on seach a guide at Wiktionary talk:Beginner's guide to the English Wiktionary for experienced Wikipedians (ideas for a better title are more than welcome as well!). Thryduulf (talk) 01:48, 3 August 2010 (UTC)

In this guide page, could you address the "new messages" feature that appears next to the "my contributions" button? Yair rand replied on his/her talk page, causing me to get a "new messages (1)" notice; although I looked at the message and replied, I still have that "new messages (1)" notice. Nyttend 04:02, 3 August 2010 (UTC)

That problem is the result of a talk page that uses "Liquid Threads". It's a known bug with the LT, and there's not anything that can really be done about it unless you "unwatch" Yair Rand's talk page. It will go away eventually on its own, but not as quickly as it ought to. --EncycloPetey 04:17, 3 August 2010 (UTC)

Messages don't count as "read" until you click "mark as read" on Special:NewMessages, even if you've replied to them. --Yair rand (talk) 05:02, 3 August 2010 (UTC)

Aha. Button clicked, and message is gone. I've never before seen LiquidThreads on any WMF wiki, so it was difficult to figure it out. Nyttend 13:38, 3 August 2010 (UTC)

When you click on the "More..." it's replaced by a div that contains some useful links. However, the div is set to 50px and the contents inside are set to 40px, at least for me in both Firefox and Chrome. It ends up being a very thin column and the contents are difficult to read. The one on wikipedia.org that it is modeled from uses the respective values 200 and 190. I'm not sure where the numbers are coming from exactly. It looks fine, though not quite the same as on Wikipedia, on Firefox and Chrome if you just take out the width restrictions, though this may potentially cause problems in other browsers. — This unsigned comment was added by Redbmk (talk • contribs).

Templates can be pretty inscrutable. Commenting out newlines/linefeeds in templates makes them more readable:

  {{#switch:{{{g}}}<!--
    -->|m={{m}}<!--
    -->|f={{f}}<!--
    -->|n={{n}}<!--
    -->|p={{p}} ...

Is this deprecated? Is the overhead too great? If used should they be removed after development? —Saltmarsh^{απάντηση} 05:15, 3 August 2010 (UTC)

I think the overhead isn't very significant. One of the first things the parser does is strip out all comments, but that's just a matter of search-and-replace, which is a fairly cheap string operation. It does that even before it does any transclusion, I suspect. And in any case, any small overhead is worth having readable templates, I think! —CodeCat 09:09, 3 August 2010 (UTC)

How do I insert the page name in the middle of the text like {{subst:PAGENAME}}, then take off the last two letters? I'm trying to automate some verb conjugation. ~ heyzeuss 21:29, 3 August 2010 (UTC)

You can't. The closest thing would be to add a parameter to the template, called verb_stem or something similar, which would be the verb without the last two letters. Nadando 21:55, 3 August 2010 (UTC)

I found one method, but I have to drag some new templates over from Wikipedia: w:Template:Trunc and w:Template:Str len. It worked when I tried it over there. A more elegant solution would be quite welcome. Now I'm going to bed.

{{Trunc|{{subst:PAGENAME}}|{{#expr:{{Str len|{{subst:PAGENAME}}}} - 2}}}}

~ heyzeuss 22:36, 3 August 2010 (UTC)

See the recent WT:GP#String processing in templates. We generally do things the way Nadando mentioned. --Bequw → τ 02:18, 4 August 2010 (UTC)

I believe it is possible, with some effort, to create a page User:Heyzeuss/cut2 such that {{subst:User:Heyzeuss/cut2}} on page named foobar results in the wikitext foob. It's not trivial to do, because template substitution is a bit finicky, but it's possible. I think. You don't want to just import the Wikipedia templates, because they're very server-intensive, and don't support substitution, so we'd end up with a lot of server-intensive pages; but you can use them as your starting-point. (Actually, feel free to modify {{str len}} to get it to support substitution. It's not currently used anywhere, so don't worry about breaking it.) —Ruakh_TALK 02:34, 4 August 2010 (UTC)

I imported the most recent version of {{str len}} from WP, which does support substitution. Any problem with just using this substituted? ({{subst:padright:|{{subst:#expr:{{subst:str len|{{subst:PAGENAME}}}}-2}}|{{subst:PAGENAME}}}}) --Yair rand (talk) 02:57, 4 August 2010 (UTC)

Thanks, that works really well! ~ heyzeuss 06:24, 4 August 2010 (UTC)

Kudos! (It's interesting that they updated {{Str len}} to support substitution, but not {{Trunc}}.) —Ruakh_TALK 11:32, 4 August 2010 (UTC)

There seem to be a lot more than you might thing, see diff. Mglovesfun (talk) 09:40, 4 August 2010 (UTC)

I've created User:Msh210/unsupp.js, which is meant to replace the ugly "Appendix:Unsupported titles/Colon hyphen right paren" in the =first header= at ] with ":-)". It works in my browser (FF). Can others please make sure it works, too? (You can use

importScript('User:Msh210/unsupp.js');

in your skin .js file, usually monobook.js, to test it.) If it works, I propose we make it part of the default script for the site; what think you all?​—msh210℠ (talk) 18:50, 6 August 2010 (UTC)

Works in Chrome 5 and IE8. --Yair rand (talk) 21:19, 6 August 2010 (UTC)

Okay, then I propose we make it part of the default script for the site; what think you all?​—msh210℠ (talk) 17:46, 12 August 2010 (UTC)

I'm a bit confused. The linked script contains this comment of yours:

  // This currently goes through these manually.  We should instead
  // have a template {{unsupportedpage|:}} which generates
  // <span id="unsupportedpage" title=":"></span>, and then use here
  // string=document.getElementById('unsupportedpage').title; .
  // There'd be a problem when the title includes a "; is there
  // a fix for that?

Why are you asking for people to test this script, and why are you proposing adding this script to the site-wide JS, if this isn't the actual implementation you want. Is it just that the comment is obsolete, and you now do prefer this implementation?
(By the way, I support the concept. It's a good idea, and I agree that something implementing it should be added to the site-wide JS.)
—Ruakh_TALK 18:18, 12 August 2010 (UTC)

The current script works. It does go through the list manually, which is ugly from a scripting standpoint, but that ugliness is invisible in the result. I have no plan to improve the script, simply because the only improvement I can think of has a problem (as described n the comment you quote). I left the comment there in case someone can improve it, but it's good as is.​—msh210℠ (talk) 18:21, 12 August 2010 (UTC)

I too would prefer the <span> solution. Currently there aren't any titles that use a ";" but if need be you could use a custom escape-scheme.--Bequw → τ 21:51, 12 August 2010 (UTC)

Re: "Currently there aren't any titles that use a ';'": The problem that the comment refers to is not with ';', but with '"'. (Confused me, too.) We don't really need a custom escape scheme, in that " would already work fine. —Ruakh_TALK 11:53, 13 August 2010 (UTC)

Meaning, &quot;, right? Yeah, that'll work.​—msh210℠ (talk) 17:50, 13 August 2010 (UTC)

Okay. I've created {{unsupportedpage}} and modified ] accordingly. Works here, but others' (re)testing would be helpful.​—msh210℠ (talk) 17:50, 13 August 2010 (UTC)

I'd like to hear Conrad or others as well. Should implementation be put off until after the new usability changes September 1? DCDuring TALK 17:56, 12 August 2010 (UTC)

I can't see why the changes should affect this (or be affected by it), but someone who knows more about them may.​—msh210℠ (talk) 17:50, 13 August 2010 (UTC)

It seems to work well, except that (in the Vector skin) some style is applied to #firstHeading to ensure that the sub-page navigation looks correct. I suspect the easiest solution is just to do document.getElementById('firstHeading').innerText = document.getElementById('unsupportedpage').innerText; I assume you didn't to avoid breaking anything that relies on that having the correct text, but I can't think of anything that would when wgPageName and wgTitle are available. Otherwise, we can just copy the CSS rules around a lot. Conrad.Irwin 10:11, 15 August 2010 (UTC)

Okay, I effected that solution. It works here (FF, monobook); other-browser testing, yet again, would be appreciated. Then can we make it site-wide?​—msh210℠ (talk) 17:26, 18 August 2010 (UTC)

It works for me in Chrome 6.0 beta, FF 3.6.8, and IE 8.0 (all on MS Vista) in both Vector and Monobook. Go for it. --Bequw → τ 21:12, 18 August 2010 (UTC)

Effected. Thanks, all.​—msh210℠ (talk) 18:13, 19 August 2010 (UTC)

I'm trying to edit user-fixes.py so that my changes don't leave too many blank lines, but it's not working and autoformat is coming right behind me to clean up.

(r'\n{3,}', u'\n\n'),

~ heyzeuss 16:42, 7 August 2010 (UTC)

Update: It works with a Windows carriage return line feed \r\n. That just seems really strange to me. ~ heyzeuss 12:17, 8 August 2010 (UTC)

I've been wondering how one would transcribe an affix in IPA/enPR/SAMPA, specifically the affixing part. From the examples I've seen, almost all of them have used an em dash in the transcription, which is a probem because the em dash is an illegal character in SAMPA (not to mention it's visually indistinguishable from the plain dash in the monospace font we use for SAMPA). I would have thought you don't spell the connecting dash and therefore it should not appear in the phonetic transcription, but I don't know what others think. -- Prince Kassad 12:22, 8 August 2010 (UTC)

Why write a dash if you don't actually pronounce it as anything? I say leave it out. —CodeCat 21:51, 8 August 2010 (UTC)

Omit it IMO.​—msh210℠ (talk) 15:10, 9 August 2010 (UTC)

Exactly. Over and over- are exact homophones. Mglovesfun (talk) 14:04, 10 August 2010 (UTC)

Following this discussion, I'm trying to create a proper category structure for Proto-Germanic entries and templates. The only problem is that the boiler templates don't seem to work as they require the language to be specified as etyl:gem. That's not a problem as such, but {{etyl:gem}} returns 'Germanic' even though the proper name of the language in question is 'Proto-Germanic'. I imagine this makes sense for etymology templates, but now that we want to treat Proto-Germanic as a 'language' rather than a family, we need a different solution. I was thinking of creating {{gem}} (with content 'Proto-Germanic') but as it has been deleted previously I thought I'd run it through here first. —CodeCat 11:35, 10 August 2010 (UTC)

Well, we don't want valid-looking language templates for invalid languages, because we use those templates in lots of ways: they're not just a convenience for people who don't want to type out Germanic or whatnot. (By invalid languages, I mean languages that we don't create mainspace entries for, languages that can't be used in (X)HTML lang="" attributes, and so on.) In which contexts exactly do you want this "Proto-Germanic" template to be used for? Is it just for use in {{etyl}}? If so, then I'd suggest creating something like {{etyl:Proto-Germanic}}, or maybe something like {{etyl:proto:gem}} if you expect that we'll only be interested in proto-languages of ISO-coded entities. —Ruakh_TALK 13:39, 10 August 2010 (UTC)

We'd want to use them in all the contexts that other language templates are used in. So for example in {{infl}}, {{langcatboiler}} and friends, {{compound}} and so on. We would be treating Proto-Germanic as a proper, albeit theoretical and reconstructed, language, and would have entries in the Appendix namespace. I actually ran into the problem in the first place because {{langcatboiler|etyl:gem}} doesn't work for Category:Proto-Germanic language. I propose we use templates prefixed with proto: for such languages, i.e. {{proto:gem}}. That would destinguish it from {{etyl:gem}} which would indicate the language family as a whole and be used in etymologies rather than Proto-Germanic appendix entries. —CodeCat 14:52, 10 August 2010 (UTC)

I think this requires a bit more thinking through. Templates such as {{infl}} and {{compound}} and {{term}} and {{l}} and {{onym}} don't just use the language-code to determine the language-name; they also use it in generating (X)HTML lang="" attributes. We don't want to be generating <span lang="proto:gem">. And they also generate links to main-namespace entries, not appendices. Maybe we should have templates like {{proto-infl}} and {{proto-compound}} and so on, which then make use of language-code templates like {{proto:gem}} and generate (X)HTML like <span lang="gem-x-proto"> and link to appropriate appendices? —Ruakh_TALK 19:42, 10 August 2010 (UTC)

We also don't want to make duplicate sets of templates if unnecessary. Does it always work to put "Proto-" in front of a w:ISO 639-5 language family name? Are there cases where no proto language exists for a family, or cases where there's a proto-language for which no family code is (or will be?) assigned? --Bequw → τ 20:57, 10 August 2010 (UTC)

Re: "Are there cases where no proto language exists for a family ?": No, but ISO 639-5 includes not just language families but also language "groups" such as artificial languages ({{etyl:art}}), North American Indian languages ({{etyl:nai}}), and so on, and those don't have proto-languages. (Well, and technically some real genetic groupings don't have proto-languages in that they descend from attested languages — Proto-Romance is a form of Vulgar Latin.) But I don't see that that's a big problem; we don't have to use the codes that we don't want or need to. —Ruakh_TALK 21:24, 10 August 2010 (UTC)

To pick this discussion back up... As far as I can see, the problem is that we want to emit xml:lang= attributes but with values that aren't valid languages in any ISO 639 standard. However, from what I found, the xml:lang= attribute allows possibilities for private-use extensions, beginning with x-. So maybe we could settle on something like x-gem or x-pgem? We could also use the art-x- prefix, used for constructed languages and such. Proto-languages, while real in the sense that they were actually spoken as a proper language at a certain time, are still constructed languages in the modern sense because they are not attested by native speakers, but created (from evidence, but nonetheless) by linguists. So we could also go for art-x-gem or art-x-pgem or similar, although the names do become rather long then. —CodeCat 11:35, 25 August 2010 (UTC)

Well, that's what I suggested above, but again, it's just one small part of the problem. The big problem is that the language templates are designed to be used with a whole host of other templates (as you write above, "{{infl}}, {{langcatboiler}} and friends, {{compound}} and so on"), and none of those other templates supports anything like what you want. There's the "language templates for constructed languages" part of the problem, and there's the "all other templates that use language templates: using them for constructed languages" part of the problem. The latter is much bigger. —Ruakh_TALK 12:00, 25 August 2010 (UTC)

But what exactly is the latter problem in this case? As far as I can see the main objection is breaking ISO 639 compatibility. But with the suggestions I've made that should be fixed, right? —CodeCat 14:45, 25 August 2010 (UTC)

Your suggestion, like my suggestion, addresses the issue of ISO 639 compatibility. But you apparently want {{infl}} to link to appendices. How will it know to do that? —Ruakh_TALK 14:51, 25 August 2010 (UTC)

I don't think it needs to. I'm more interested in the automatic categorisation and additional boilerplate text that many templates provide (standardisation is a good thing, after all). And that won't change, as long as the language template correctly expands to 'Proto-Germanic'. But right now there is no such language template. —CodeCat 14:56, 25 August 2010 (UTC)

So you don't want appendix-links, fine, but does that mean you're O.K. with the mainspace-links? For example, you want {{compound}} to display redlinks that we don't want linkified? —Ruakh_TALK 16:35, 25 August 2010 (UTC)

Well, just take a look at this: {{compound|und|Appendix:Proto-Germanic *langaz|Appendix:Proto-Germanic *tīnaz|alt1=*langaz|alt2=*tīnaz}}. So it seems to work just fine in any namespace, and the only issue there is the hard-coded naming of proto-terms ({{proto}} being mandated and all to prevent that). But I believe that's fixable with some puzzling, and it's not a big issue to just forego using those templates anyway until a proper fix is found for that problem. —CodeCat 17:33, 25 August 2010 (UTC)

Ugh. I agree with your statement that "standardisation is a good thing", but I disagree with your implication that {{compound|Appendix:Proto-Germanic *langaz|alt1=*langaz|Appendix:Proto-Germanic *tīnaz|alt2=*tīnaz}} promotes standardization! —Ruakh_TALK 18:21, 25 August 2010 (UTC)

That wasn't my implication at all, actually the opposite, and it's why I suggested that it's a workaround at best and needs a proper fix, and not to use that template preferably until there is a fix. —CodeCat 22:22, 25 August 2010 (UTC)

The text of the page does not flow around the rhs ToC. Is that the result of something erroneous in Wiktionary:Information desk/header? DCDuring TALK 19:28, 10 August 2010 (UTC)

I'm guessing it has something to do with the either the archive search box or a failure to have some code for the floating text. Wiktionary:Grease pit/header seems to have it right, with archive search. DCDuring TALK 19:36, 10 August 2010 (UTC)

What do you see exactly? For me it flows around the RHS ToC until it reaches the long link (which isn't wrapped) in Wiktionary:ID#HTML_entity_for_.3D pushing everything below that to below the bottom of the ToC. Archive that section (or make your window wider) and it should flow continuously. --Bequw → τ 20:52, 10 August 2010 (UTC)

For me it is much worse: there is no flow-around. The ToC and the text simply overlap so some of the text is illegible. I don't remember it happening except at ID. It may be that I need to clear out my monobook pages, as most of what was there is now implemented in "my" or "Wiktionary" preferences. Then we could reduce the likelihood of it being simply idiopathic. DCDuring TALK 21:06, 10 August 2010 (UTC)

I cleared out both monobook.js and monobook.css, logout and in and cleared the cache. The problem at WT:ID changed. The text and ToC don't overwrite each other. But the page is several times wider than my screen, so I have a horizontal scroll bar. The ToC extends just off the right hand side of the page. IOW, there is probably something defective in the WT:ID header page code that I could live with, but my give someone else worse heartburn. The monobook clear out was long overdo. I had some CM stuff in there. DCDuring TALK 21:24, 10 August 2010 (UTC)

Oh, and I have lost rhs ToC on non-entry pages, except WT:ID. I had gotten used to them on the right for all pages, but don't really need them. WT:ID just is different from the other "high-volume" discussion pages. Why should it be? BTW why don't all of them have an archive search box? DCDuring TALK 21:32, 10 August 2010 (UTC)

BTW, I now have a horizontal scrollbar for other discussion pages that I don't recall having. DCDuring TALK 21:39, 10 August 2010 (UTC)

I've cleaned some format issues on the page. Does it look OK now? --Bequw → τ 04:56, 20 August 2010 (UTC)

Thanks, yes. The ToC now appears on the right and the pagewidth is no longer ~3 times my screen width. I still have a horizontal scrollbar (apparent page width ~1.1 times my screen width), but that also appears on WT:BP and WT:GP (apparent page width ~1.6 times my screen width). In contrast, WT:TR and WT:ES have no scroll bar. On all but WT:ID the ToC appears on the left.

The horizontal scrollbar is more significant than the RhS ToC for non-entry pages like this IMO. DCDuring TALK 09:25, 20 August 2010 (UTC)

BTW, among clean-up pages, WT:RFD alone has the 1.6 times apparent page width and associated horizontal scroll bar. DCDuring TALK 09:40, 20 August 2010 (UTC)

Ah, I see that in FF but not in my standard Chrome. In the ID, RFD, BP and part of the GP it was due to wide content in <pre> tags which can be (and should in the future) fixed by using <pre style="overflow: auto;"> instead of just <pre> (you can see at WT:CUSTOM#More how to always view <pre>-tags that way). In the GP it was due to FF not word-breaking at hyphens in <tt>-tags. I've inserted some zero-width spaces (&#x200B;) to force breaks at certain points. How does it look now? --Bequw → τ 19:22, 20 August 2010 (UTC)

Thanks. All four pages seem good with respect to page width. I hope the changes don't cause something else to come unglued for some browser setup. DCDuring TALK 19:53, 20 August 2010 (UTC)

Wouldn't you know it: the page-width problem occurs at Help:Customizing your skin! DCDuring TALK 19:57, 20 August 2010 (UTC)

How can I search wiki markup? I want to search by template parameter. ~ heyzeuss 13:33, 12 August 2010 (UTC)

I'm not sure if that's possible. I've often solved it by modifying the template to add the page to a special hidden category (something like 'CodeCat's test category') depending on the parameters. Obviously not a good solution at all, but it worked well for more elaborate projects. I'm sure someone else would have a better idea though. —CodeCat 16:25, 12 August 2010 (UTC)

If you are comfortable with parsing XML you can download the most recent dump here and search for your template. Or just ask here and I'd be happy to do the search for you. Nadando 17:24, 12 August 2010 (UTC)

I'm going to try these suggestions, although I will have to learn how to do both of them. I figured out how to parse a dump, but I don't know how to search with a regex string in python. Here's what I have:

import xmlreader

for entry in xmlreader.XmlDump('enwiktionary-20100812-pages-articles.xml.bz2').parse():
  if 'fi-conj-tulla' in entry.text:
    print entry.title

and here's what I have now, with regex capability. ~ heyzeuss 18:31, 13 August 2010 (UTC)

import re, xmlreader
dump=xmlreader.XmlDump('enwiktionary-20100812-pages-articles.xml.bz2')

for entry in dump.parse():
    if re.search(r'fi-conj-tulla\|.*?\|.*?\|tt', entry.text):
        print entry.title.encode('utf-8')

As for adding categories, I'm trying this, but it's not working yet.

<includeonly>{{#ifeq:{{{3}}}|tt|]
]
}}</includeonly>

I don't know anything about how to read the dumps (though I'd love to), so can't help you with that, but the code for including a category, above, won't work, as it has <includeonly> around it (which means that it'll only add the category to a page that transcludes the page you're adding it to). By the way, you should also use subst:#ifeq rather than #ifeq.​—msh210℠ (talk) 17:11, 18 August 2010 (UTC)

Is there a problem with the server or is someone testing out something that's broken? I'm getting a script error on every Wiktionary page once I log in, including the "successfully logged in" page and edit windows. I have to respond to a dialog box each time to stop the script that's slowing down page loads, and then refresh the page. --EncycloPetey 23:03, 5 May 2010 (UTC)

Not seeing it in FF 3.6.3. DCDuring TALK 23:09, 5 May 2010 (UTC)

I was seeing it in IE for about 30 minutes, but in the time I've been away on Wikisource (where there was no problem), it seems to have cleared up. --EncycloPetey 23:35, 5 May 2010 (UTC)

I had the same problem yesterday. Mglovesfun (talk) 11:27, 7 May 2010 (UTC)

For future reference, if you do get an error message, it's useful if you can copy/paste it into WT:GP (along with Browser and version). Particularly in this case, I've no idea what might have caused the problem. There should never be any javascript error messages, so please do report those that you see. Conrad.Irwin 13:45, 7 May 2010 (UTC)

It's still pretty frequent, and I experienced it a few minutes ago. It only affects my IE, FF works fine.

This might be related to the problems (it could also be useless for all I know :-D) (it's translated by me, so some technical words might have been given a poor translation):

Details on website error

User agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; ImageShack Toolbar 4.3.5; .NET CLR 1.1.4322; WWTClient2; InfoPath.1; .NET CLR 3.0.30729; .NET4.0C) Time: Mon, 5 Jul 2010 12:32:01 UTC

Message: The object does not support specified property or method Line: 218 Sign: 5 Code: 0 URI: http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=-&action=raw&gen=js&useskin=monobook&283l

I have never experienced it on any Wikipedia, but I think I experienced it on the nn wikt after copying the MediaWiki:Common.js and MediaWiki:Common.css pages here and pasting them there. --Harald Khan Ճ 12:46, 5 July 2010 (UTC)

I downloaded the file above and opened it in my Python editor, where line 218 was part of the following code:

===] to display differently for non-newbies with JS than for others===
*/
if (wgUserGroups && wgUserGroups.join("").indexOf("autoconfirmed") > -1)
{
  addCSSRule(".msgfornewbies", "display: none");
}else{
    addCSSRule(".msgfornonnewbies", "display: none");
}
/*

The actual line 218 is addCSSRule(".msgfornonnewbies", "display: none");. I removed this section from the nn wikt, while I was experiencing the error there, since it's not supposed to be there anyway. When I hit "save", the problem was still there, but upon pressing ALT + F5 it disappeared, though it was also gone on the en wikt when I returned there, where the problem had run in parallell. Could this be it? --Harald Khan Ճ 09:53, 13 August 2010 (UTC)

Currently at least 5 Wikipedias and 2 Wiktionaries propose it. JackPotte 20:43, 17 August 2010 (UTC)

But what is it? I can't read Catalan or French so the links don't help me in that regard. Are you suggesting we do or don't implement/approve/install/whatever it? Why? Thryduulf (talk) 00:00, 18 August 2010 (UTC)

It lets you create a little frame with tabs. If you go to ], there's an example, showing both the wikitext to call the template, and the resulting tab-frame. I assume that JackPotte is suggesting we add the relevant CSS, JS, and template, so that editors can add such tab-frames to pages here; I can't speak to "why", though. —Ruakh_TALK 00:12, 18 August 2010 (UTC)

Could this help (or merge with) WT:GP#Tabbed language browsing? --Bequw → τ 00:59, 18 August 2010 (UTC)

Yes, it could help the design of this extension. Moreover fr.w uses it only in the "User" namespace, it.wikt at the bottom of its main page, and I've suggested on fr.wikt to use it to separate the languages in the translations paragraph. If we want to install it here, we have to import the template and a little common.css and .js stuff. JackPotte 05:34, 18 August 2010 (UTC)

Ok, I can now see what it does in terms of producing a frame with tabs. But I still don't understand what the benefits of using it would be? I've only had a quick play with tabbed language browsing (because I find the one-page layout preferable) but that seems to do something very similar without adding reams of complicated wikicode to the page? Exactly what do the other projects use it for and what advantages does it bring over any other method of doing that? Thryduulf (talk) 16:27, 18 August 2010 (UTC)

Actually if I'm allergic to the Korean characters (it's all Greek for me) I can avoid to see them without clicking on their tabs. JackPotte 20:39, 18 August 2010 (UTC)

Since we have a considerable number of uncomplete appendices (and being "completeness" such a subjective but worthy goal), I feel we need a way to formally request for their expansion and point out where it is necessary.

The most natural choice would be, of course, using a template for that. After reviewing the existing templates, I've concluded that they're not good enough:

For instance, Template:attention is too subtle; Template:rfc implies there's something wrong or badly formatted, as opposed to simply uncomplete; and Wikipedia "stub" templates, if used in Wiktionary appendices without much conversion, would likely indicate that said appendices are short in contents, which would not always be true. Then, I created a brand new template for that, Template:rfexp.

It is formatted specifically for appendices, because entries already have similarly named ones like rfdef, rfap, rfe for virtually every section. Although, rfexp could foreseeably be used in Help:, Rhyme: or other namespaces eventually if necessary. --Daniel. 03:20, 20 August 2010 (UTC)

I've recently created the template {{lang}}. I believe its purpose is quite simple and understandable as explained at its documentation.

However, it lacks a function that I believe is very important. Can that template be upgraded to work if , alternatively, someone types names of languages instead of their codes? Some examples that should work properly after such an upgrade would be {{lang|English}} and {{lang|German}}. --Daniel. 05:15, 20 August 2010 (UTC)

I believe existing templates perhaps do that by checking whether Template:{{{1}}} is an existing page, given that {{{1}}} is a language code. —CodeCat 21:18, 20 August 2010 (UTC)

I think you're misunderstanding what Daniel. (talk • contribs) wants. The difficulty is not in recognizing whether the argument is a language code or a language name; that can be done using #ifexist:, as you suggest, or (as {{langname}} does) by checking if the argument is all-lowercase, in which case it's presumably a language code. Rather, the difficulty is in actually converting a language name to the corresponding code.

By the way, I don't think {{lang}} is a good name for this template.

—Ruakh_TALK 22:12, 20 August 2010 (UTC)

diff, it seems that {{present participle of}} no longer accepts language names instead of codes, it simply showed Template:French which isn't a template. Surely it should use some sort of {{#ifexist:Template:{{{lang}}}}}. Mglovesfun (talk) 14:19, 21 August 2010 (UTC)

Form-of templates are supposed to use language codes, not language names. I would much prefer having a bot fix up the entries to use codes rather than changing the template to accommodate the entries. --Yair rand (talk) 21:23, 23 August 2010 (UTC)

It's probably tied to the changes being done to {{lang}} in the discussion above. —CodeCat 21:51, 23 August 2010 (UTC)

??? {{lang}} isn't used in {{present participle of}}. {{lang}} was only created a few days ago. I don't see how this could be related. --Yair rand (talk) 22:07, 23 August 2010 (UTC)

It looks like Daniel. (talk • contribs) broke that with his {{deftempboiler}} stuff. —Ruakh_TALK 22:31, 23 August 2010 (UTC)

Or one could say that I broke it by not using {{langname}} in {{wlink2}}. There are currently 904 entries broken (see Special:WhatLinksHere/Template:French), all created by User:Keenebot2, I think. Could someone run a bot through them? --Yair rand (talk) 23:02, 23 August 2010 (UTC)

I agree with Yair on the statement "Form-of templates are supposed to use language codes, not language names.", mainly for preemptive conveniency: it is evidently easier to change a language name if all related form-of templates use language codes.

As for the diff of "servant", indeed, {{wlink2}} was affecting {{langname}} and causing codes similar to {{present participle of|whatever|lang=Portuguese}} to not work. I could change it quickly, so the code of Template:present participle of (and similar templates) now allow any language name as a value for the parameter lang. I wouldn't blame you, Yair, mainly because I remember how {{wlink2}} happened to be useful when I was developing {{deftempboiler}}. You saved me some effort and I saved you some effort; then I believe we're even on this subject. --Daniel. 02:24, 24 August 2010 (UTC)

By the way, I also agree that we should be using language-codes exclusively. Language-names let us link to the right section and add the right category, but they don't let us mark up the HTML correctly, select the right default script, and so on; and not all templates can support them, since sometimes the category name includes the language-code, which means that we have a confusing mess when lang=fr works in some templates and not others. But, we need to change the entries that rely on language-name support before we change the templates to remove it. —Ruakh_TALK 13:23, 24 August 2010 (UTC)

Browsing the entry for (deprecated template usage) keep on my phone earlier using Wapedia I noticed that when an entry is marked "transitive" or "intransitive" and something else, e.g. "archaic" or "cricket", then it gets marked as, e.g. "(transitiveSpecial, archaic)". I've not got time to hunt down where this problem is (could be {{transitive}} or {{context}} at a guess) let alone what it is. Thryduulf (talk) 22:22, 23 August 2010 (UTC)

I think it's because Wapedia doesn't expand templates perfectly (note the "safesubst" stuff that appears above where it tries to parse {{proto}}s). Not sure exactly where it fails, though. Some more links for the curious: uncle and blow. Some thoughts from eyeballing things: (a) It's not just (in)transitive, (b) it appears to rarely affect the last parameter, and (c) sometimes it appears before a label and sometimes after. I wish we could play around with their parser. --Bequw → τ 00:04, 24 August 2010 (UTC)

My declension tables and other tables are closing again. Opening them once isn’t setting them to "open" anymore. I still use Monobook. I tried to tick the expand-box option under Preferences, but it no longer accepts ticks. —Stephen 12:23, 25 August 2010 (UTC)

Fixed it. Deleted history and cookies and it’s working again. —Stephen 13:50, 25 August 2010 (UTC)

Some javascript tools I've been working on, available in WT:PREFS (and hopefully to be enabled by default at some point):

• User:Yair rand/wsedit.js ('Enable Wikisaurus editor.' in PREFS): For adding synonyms, antonyms, etc. to Wikisaurus entries. Also can edit glosses.
• User:Yair rand/usexeditor.js ('Enable example sentence editor.' in PREFS): For editing existing example sentences.
• User:Yair rand/adddefinition.js ('Add "Add definition" and "Add image" buttons to the toolbox.'): Adds "Add definition" and "Add image" buttons to the toolbox.

Some feedback would be great. --Yair rand (talk) 00:48, 27 August 2010 (UTC)

1. The example sentence editor didn't display text to the right of a comma in the edit box.
2. The +/- character is not suitable if this ever were to become some kind of default capability. DCDuring TALK 13:42, 2 September 2010 (UTC)

Whenever the template {{de-verb form of}} is combined with another template which is put before it, no space is displayed between these two (here's an example, no space between "(colloquial)" and the form-of template). How can this be fixed? Longtrend 10:14, 27 August 2010 (UTC)

Damn, that's new to me, I can look but I suspect you'll need a more experienced user than me. Mglovesfun (talk) 22:20, 30 August 2010 (UTC)

Though having said that, perhaps it's to do with the categories. I'll vandalise a page and see what happens. Mglovesfun (talk) 22:22, 30 August 2010 (UTC)

Yes, put the categories after the form-of text. Mglovesfun (talk) 22:26, 30 August 2010 (UTC)

Yeah, I think that's the best approach in general. But in this case, I didn't want to mess too much with a functional, existent template, so I just "cheated": I changed Category:German verb forms (before which MediaWiki drops any linear whitespace) to <nowiki/>Category:German verb forms (before which it does not). —Ruakh_TALK 13:52, 31 August 2010 (UTC)

Thank you! Longtrend 14:07, 31 August 2010 (UTC)

Now that Wonderfool has been blocked... again, there's no French conjugation bot on Wiktionary. Could anyone (notably SemperBlotto, Nadando, Codecat and/or Prince Kassad) help me make one? I know there's a help file Help:Conjugation bot but that's about all I have right now. That and my brain. Mglovesfun (talk) 10:24, 30 August 2010 (UTC)

I've written MewBot to be easy to adapt to another language. If you know some Python, you should give it a try. If not, then I don't really know, other than trying to learn it... —CodeCat 14:57, 30 August 2010 (UTC)

In Category:English idioms, for example, the following appears:

Entries in category “English idioms”

The following 197 pages are in this category, out of 6,116 total.

The term "pages" is confusing here, since it appears that it is referring to 197 pagefuls of idiom entries, when in fact it refers to the 197 entries being displayed on the current page. Thus "entries" would be a better choice of words than "pages", and would also be consistent with the lead-in text "Entries in category". Facts707 14:25, 30 August 2010 (UTC)

The text can be changed at MediaWiki:Category-article-count. Having it always say "entries" might cause some problems for categories of templates, project pages, or users, though. --Yair rand (talk) 20:43, 30 August 2010 (UTC)

Maybe There are $2 entries in this category, including the following $1.? Or heck, maybe just There are $2 entries in this category.? —Ruakh_TALK 22:11, 30 August 2010 (UTC)

Entries is a term we use for dictionary entries; using it for category entries (members of a category) would be confusing IMO. (Not all categories have only dictionary entries, of course.) Perhaps (based on Ruakh's suggestion above) "There are $2 members of this category, including the following $1:"?​—msh210℠ (talk) 15:12, 1 September 2010 (UTC)

Re: "Entries is a term we use for dictionary entries; using it for category entries (members of a category) would be confusing IMO": That's an excellent point — it is confusing — and we should fix it, by deleting MediaWiki:Category header. I'll start a BP discussion. —Ruakh_TALK 12:50, 10 September 2010 (UTC)

Hi. I've noticed that both OneLook and Merriam-Webster have wildcards enabled in their search features, that is, * stands for a string of characters and ? for one character. Is there a way it could be implemented here? Thanks, ~ lexicógrafo | háblame ~ 14:43, 30 August 2010 (UTC)

They have wildcard search for headwords. I assume that such restricted wildcard search is what you have in mind. Next steps would be wildcard searches limited by language and by language and part-of-speech header or PoS category, or by language-PoS category. DCDuring TALK 15:09, 30 August 2010 (UTC)

Well yes, for headwords only. Although M-W at their unabridged site also has the ability to search with wildcards in definitions, etymologies, quotes and usage notes, if you so choose. ~ lexicógrafo | háblame ~ 15:17, 30 August 2010 (UTC)

For wildcards at the end (e.g. super*) you can use the Special page "All pages with prefix". Otherwise, there is no obvious facility. SemperBlotto 15:24, 30 August 2010 (UTC)

I wonder whether there is something on the toolserver at least, something analogous to CatScan. DCDuring TALK 15:44, 30 August 2010 (UTC)

For two years, http://wikiwix.com allows the French Wikipedia to read the external sites, which URL are in its article, even if they're stopped, thanks to a link after each URL. Today they're proposing to extend their backups to us, and it's working on the French Wiktionary. Could we please get a consensus to install it here? JackPotte 21:26, 31 August 2010 (UTC)

I *think* it sounds interesting and useful. Can you give us an example of what it looks like on fr.wikt? --Bequw → τ 03:59, 3 September 2010 (UTC)

Sure, do you see the reference at the bottom of fr:welcome? I've just added it and the archive link is already available. JackPotte 12:13, 3 September 2010 (UTC)