Has MediaWiki improved at dealing with right-to-left scripts? Either than or Firefox has, as I'm hvaing a lot less trouble with copy-and-pasting (for etymologies, etc.) Mglovesfun (talk) 08:05, 4 April 2010 (UTC)

Due to my recent edits, the script of any language may be found at the main language category. Example: "Latin script" in the introduction of ]. --Daniel. 17:39, 4 April 2010 (UTC)

That's helpful. --Bequw → τ 18:46, 6 April 2010 (UTC)

Thank you! Thank you! I've been longing for this.​—msh210℠ 23:30, 7 April 2010 (UTC)

And the other 25 of the same nature, clearly. Is there any way that any bot could clear all the blue links for words that have a French section? It would make it a lot easier to find the missing words. It would really help us create French entries a lot faster). Mglovesfun (talk) 09:43, 5 April 2010 (UTC)

I think User:Equinox uses a tool to strip the blue links from a page. Ask him about it. --Rising Sun talk? contributions 09:58, 5 April 2010 (UTC)

User:Equinox/Antiblue --Rising Sun talk? contributions 09:59, 5 April 2010 (UTC)

At WT:Usability#Horizontal lists, I'm experimenting with horizontal lists. My one problem now is showing a horizontal sublist inside a vertical list (last column in the table). The </div>, from {{flatlist-bottom}}, at the end of the sublist, however, ends the outside ul causing the final element of the main list to be separated into it's own ul. Any ideas about how to keep the main list together? --Bequw → τ 18:52, 6 April 2010 (UTC)

Could we codify our policy on interlanguage links for templates at Wiktionary:Links#Interwiki links? It's been said that we don't place them directly on the template page (reducing confusion and allowing non-admins to add links for protected templates). We have, however, close to 200 templates that do have them (e.g. {{rfd}}). If we don't put them directly in the template page, do want to transclude them from another location, or just iwiki the talk pages? {{User en}}, for example, transcludes them from the talk page (hampering talk page iwikis, but those are rarely useful) whereas Wikipedia uses a full-blown “template doc page pattern” (allowing in addition documentation to be shown on the main template page while still allowing easy editing for protected templates). Are either of these approaches standard? --Bequw → τ 15:04, 7 April 2010 (UTC)

We really should adopt a pattern like Wikipedia's: iwikis don't work on talk-pages, and it's only out of a stubborn and unproductive anti-Wikipedism that we pretend to put them there. {{User en}} takes an interesting approach: it meets the "letter" of the Wiktionary norm, but violates the "spirit" by making it function properly. I'd rather just have a functional norm to begin with, but if that's off the table, then {{User en}}'s approach (or a similar one using labeled-section transclusion) is the way to go. —Ruakh_TALK 17:42, 7 April 2010 (UTC)

Transclusion of interwikis from talkpages (or elssewhere) sounds good to me. Modifying a template page itself for each interwiki change does not. (Think job queue: we have a good number of very, very heavily transcluded templates.)​—msh210℠ 23:29, 7 April 2010 (UTC)

Re: modifying the template page itself: Well, of course not. No one's proposing that. :-)   —Ruakh_TALK 13:25, 9 April 2010 (UTC)

To clarify: Will transclusion of the links from elsewhere affect the job queue when the transcluded page is modified? My understanding has always been that transclusion does not eliminate the problem. --EncycloPetey 23:31, 7 April 2010 (UTC)

To clarify that question: Note that here the interwiki links being transcluded into the template are not then transcluded with the template. Does anyone know? (If EP's present perfect continuous understanding is right, then I take back my statement that transclusion sounds good.)​—msh210℠ 00:09, 8 April 2010 (UTC)

As long as the subpage is transcluded within a <noinclude>, it should be fine: the links table won't consider the subpage to be transcluded in pages that transclude the template. (If you're concerned, you can play around with Special:WhatLinksHere and see for yourself.) —Ruakh_TALK 13:25, 9 April 2010 (UTC)

Functionally I think interlanguage wiki links should be shown on templates and that the text for those links should be stored somewhere else (either the talk page or a /doc subpage) so they can be updated with minimal hassle. I also would strongly encourage having our documentation show up on the template page rather than on just the talk page. People often navigate to templates via "What links here" and it is needlessly evasive to continually encounter "See talk page". --Bequw → τ 16:42, 9 April 2010 (UTC)

+1! +1! —Ruakh_TALK 17:06, 9 April 2010 (UTC)

If we do that, we need to update {{temp}} to link to the template page. (An easy matter.)​—msh210℠ 17:29, 9 April 2010 (UTC)

Updated. When the /doc exists, {{temp}} now links to the main template page. This should allow for a smooth transition of the documentation from talk pages to /doc subpages. --Bequw → τ 23:01, 24 April 2010 (UTC)

I've repurposed {{documentation}} to use the 'pedia paradigm (cats, iwikis and documentation on a /doc). See {{User en}}. Look fine? --Bequw → τ 02:18, 20 April 2010 (UTC)

Not on my computer, at least. You've put the information about documentation beside the template contents, rather than below it. Can we set these up so that won't happen? We also need a clear link that allows people who drop by to add interwiki links to know where to place them. This isn't at all obvious with the preliminary set-up. --EncycloPetey 04:03, 20 April 2010 (UTC)

Conrad kindly pushed the transcluded content below what is shown visually on the template page. I've added some text linking to the (w/ edit link) to the /doc subpage. Please improve. --Bequw → τ 00:33, 21 April 2010 (UTC)

The link to the page is good, and the direct edit link seems an excellent idea. --EncycloPetey 04:36, 21 April 2010 (UTC)

Would someone be able to generate a list of template talk pages with iwiki links? Those would be a good place to start cleanup. --Bequw → τ 02:26, 23 April 2010 (UTC) Done. --Bequw → τ 22:13, 24 April 2010 (UTC)

Today there's been a strange problem in User:Dawnraybot creating pages - every dozen or so pages he tries to add don't work, and there's an error message in Python saying

Unknown Error. API Error code:internal_api_error_MWException
Information:Exception Caught: MagicWordArray::parseMatch: parameter not found

There seems to be no reason for this, as I've changed nothing on the bot settings, and there's nothing unusual about the particular pages which have caused this problem. Any techheads know how I can fix this? --Rising Sun talk? contributions 09:09, 9 April 2010 (UTC)

"They" are busy updating MediaWiki, is this still a problem? Conrad.Irwin 12:47, 9 April 2010 (UTC)

SemperBlottoBot has also stopped working. I get :-

Getting a page to check if we're logged in on wiktionary:en
Getting page to get a token.
Getting page Wiktionary:Sandbox
Getting page to get a token.
Getting page Wiktionary:Sandbox
Creating page en:fluidificazioni
Current MediaWiki message dump is one month old, reloading
Retrieving MediaWiki messages for wiktionary:en
Parsing MediaWiki messages
ERROR: MediaWiki_Msg caused error Error URL: https://en.wiktionary.org/w/index.php?title=Special:Allmessages&ot=html. Dump MediaWiki_Msg_wiktionary_en__Sat_Apr_10_08-06-47_2010.dump created.

SemperBlotto 07:09, 10 April 2010 (UTC)

Interestingly, I get a "WARNING: Token not found on wiktionary:en. You will not be able to edit any page." message, but then FitBot successfully creates the page anyway. Mind you, FitBot has has remained logged in since before whatever happened, so this may not work after FitBot next logs out. Updated files may need to be downloaded before the bots will work again, and we've had to go through this before. Does anyone know where notification of such things is posted? --EncycloPetey 07:24, 10 April 2010 (UTC)

I've downloaded the latest release of "pywikipedia" from - works OK now (but with new messages). SemperBlotto 09:25, 10 April 2010 (UTC)

Hmm... now that I've updated, FitBot can't log-in at all. --EncycloPetey 05:15, 13 April 2010 (UTC)

There was a "breaking change" to the login procedure, as usual announced after it was made, breaking every bot and automation in sight. Took me hours (and a really grody hack ;-) to get Interwicket logged in again. (on 170 projects ...)

Subscribe to the wikimedia -tech and -api lists, and then watch for trouble amongst all the noise. Don't ever try to have your bot log itself in; use login.py to do it first. If it still doesn't work, I can probably tell you how to patch together the cookies file. Robert Ullmann 15:56, 23 April 2010 (UTC)

What's happened to my audio entries at e.g. (deprecated template usage) userland, (deprecated template usage) hackerish? They show as red with no icon. Equinox ◑ 16:20, 9 April 2010 (UTC)

Maybe it's because your Latino. --Rising Sun talk? contributions 19:23, 9 April 2010 (UTC)

Fixed. Someone changed the default case-sensitivity for remote files to be the same as local files (instead of case-insensitive) by default. Wikimedia configuration has now been updated to make it case-insensitive again (like commons, and unlike wiktionary). Conrad.Irwin 22:35, 9 April 2010 (UTC)

MglovesfunBot has replaced these (rather quickly) with {{trans-top}}, {{trans-mid}}, {{top2}} and {{mid2}}. Are we ok to add the proper content now? I.e the language names. Mglovesfun (talk) 10:26, 10 April 2010 (UTC)

"rather quickly" being the operative... We should wait at least a few days to see if anyone/thing is still adding these incorrectly. As penance for being too quick, perhaps you'd like to join in the unautomated, thankless, task of Category:Translation table header lacks gloss; to appease its custodians after trebling their workload. Conrad.Irwin 11:34, 10 April 2010 (UTC)

There are 2000 more to add because the entries no longer use an outdated template. A translation table without a header is better than no translations at all, right? Anyway, I just might do that. Mglovesfun (talk) 12:15, 10 April 2010 (UTC)

Probably, though an empty {{trans-top}} is no better than a {{top}}. I've put the easy ones on WT:TODO for everyone to have a go with. Conrad.Irwin 12:40, 10 April 2010 (UTC)

It allows WT:EDIT, while top (and indeed every other template at all) does not. Mglovesfun (talk) 12:44, 10 April 2010 (UTC)

Can someone please create a context tag for this (I don't know how)? I have created entries for songline, dreaming track, Dreaming and Dreamtime but at the moment the templates are all red links. Thanks. ---> Tooironic 06:19, 11 April 2010 (UTC)

Template:Australian Aboriginal mythology created, along with Category:Australian Aboriginal mythology, Template:topic cat description/Australian Aboriginal mythology and Template:topic cat parents/Australian Aboriginal mythology. --Yair rand 06:37, 11 April 2010 (UTC)

Thanks heaps, you're a legend! ---> Tooironic 08:49, 11 April 2010 (UTC)

Is there a way we can make adding synonyms and antonyms easier? My recollection is that adding to wikisaurus was kind of a chore, can we make it simpler? Would we need a bot to make it simpler? RJFJR 00:34, 12 April 2010 (UTC)

I don't know whether it's possible to have a bot do that kind of work, unless we have a very crappy WkiSaurus (no additional comment on that). To do synonyms well requires that shades of meaning and related meaning be sorted properly. --EncycloPetey 02:36, 12 April 2010 (UTC)

It should be possible, if timeconsuming, to create something that works along the lines of the translation adder. I beleive Yair looked at it briefly. I'd prefer to add synonyms to the main entry, as well as to Wikisaurus - though I'm not sure how to get away from the duplication. Conrad.Irwin 10:40, 12 April 2010 (UTC)

Is there any particular reason why Template:gloss doesn't italicise the text it displays? Unitalicised text in brackets can easily be taken as optional material. Surely the contents should be displayed using Template:italbrac? — Paul G 09:22, 15 April 2010 (UTC)

I think the idea is that it is optional (in a sense). It's used to clarify the preceding word (or phrase). Someone who understands the preceding word without the gloss needn't read it (the gloss). Kinda like the way I'm using parentheses in this post, especially my last pair.​—msh210℠ 15:13, 15 April 2010 (UTC)

What is the appropriate way to use this template? Or is it just subjective and to be judged on a case-by-case basis? Mglovesfun (talk) 12:36, 16 April 2010 (UTC)

Hi, we could get a bot to create thousands of -in' forms like this. It would be cool

==English==
===Verb===
{{infl|en|present participle}}
#{{eye dialect|suffixing}}

--Rising Sun talk? contributions 12:56, 16 April 2010 (UTC)

But not yours? Mglovesfun (talk) 12:58, 16 April 2010 (UTC)

No, too much manual work for my bot, which doesn't read from categories or templates. --Rising Sun talk? contributions 13:01, 16 April 2010 (UTC)

Since present participles like eatin' and doin' are so common, I think they should appear in {{en-verb}}. --Daniel. 13:11, 16 April 2010 (UTC)

Who would benefit if we included this information in {{en-verb}}? I have no problem with a bot creating the citable forms, I don't imagine that all verbs exist in this form, let's do some optimizin' here. Conrad.Irwin 14:39, 16 April 2010 (UTC)

I would benefit for not having to look for a link to kiddin' at possibly the Derived terms section of kid, for instance. By extension, other people might want to find these terms easily too, in the headword line which is a more intuitive place for English verb conjugations. I didn't say we should add the -in' forms to all verbs; I suppose one additional parameter to {{en-verb}} would suffice. --Daniel. 15:03, 16 April 2010 (UTC)

Nah, these are not used in formal writing, except as eye dialect. We don't even list the non-third-person-singular present (conjugate) or many other forms: I don't think we should list this one. But having entries, yes, absolutely. They can be bot-made if the bot can check for cites, which seems (to me, but what do I know) unlikely, or if people can add attested words to a list and the bot can read the list — but then it'd probably be about s easy for people to make the entries.​—msh210℠ 15:17, 16 April 2010 (UTC)

If this were to happen we may as well include -in forms too: freakin and eatin and playin etc. -z third-person singular forms are another question: freakz, eatzz, playz. As is -z as a plural - I'm surprised boyz and kidz don't have entries yet. --Rising Sun talk? contributions 18:48, 16 April 2010 (UTC)

Then there's some archaic -'d, -eth and -est forms like warn'd and warneth and warnest. I'll add something to Appendix:English verbs --Rising Sun talk? contributions 10:14, 17 April 2010 (UTC)

German also provides some amazing potential. Contractions of 2nd person singular present form + du are almost always valid. So siehst + du = siehste, lachst + du = lachste, freust + du = freuste,... -- Prince Kassad 19:59, 20 April 2010 (UTC)

You say "almost"> Is there a bot-readable criterion (besides attestation, which of course is the real criterion we care about)?​—msh210℠ 15:02, 23 April 2010 (UTC)

When I added the category Chinese surnames to two pages defining Chinese characters, those characters then showed up in the category page as their own subsection as you can see on the category page (]). This will soon get out of hand. Is there a way to simply separate out all of the Chinese characters or non-Latin entries? Wakablogger 06:25, 17 April 2010 (UTC)

If you place a letter/character at the end of the category statement thus: ] this entry will be listed under that letter/character - in this case X — hth —Saltmarsh^{απάντηση} 19:12, 20 April 2010 (UTC)

Great, thank you! I've put them under 字 for the time being and will refer the question of what character/letter is best to the Tea Room. Wakablogger 20:26, 20 April 2010 (UTC)

The standard method is to use a radical stroke key, followed by the entry title. So 张 uses a sort key of 弓04张. That way they all appear under the canonical order. And you can "steal" the radical index from Category:Han characters ({{categoryTOC-radical}}) to put in the cat page. Robert Ullmann 13:43, 22 April 2010 (UTC)

If the Latin and Chinese can be separated out and the Chinese sequenced that way, that sounds great. I tried adding the template to the category:Chinese surnames page, but could not figure out how to get it to work. Wakablogger 01:07, 23 April 2010 (UTC)

Of course the Latin appear first, under keys A-z, not surprisingly. No trouble "separating" them. I added the TOCs. Robert Ullmann 15:47, 23 April 2010 (UTC)

I did not know this was possible. Unfortunately, the radical ordering is not working. The character 李 comes after all the other characters, even after other characters with the 木 radical. Wakablogger 23:36, 23 April 2010 (UTC)

Please could anyone who is able have a look at Template talk:el-form-of-nounadj. There may perhaps be stndard argument/variable names which would be more appropraite. thanks —Saltmarsh^{απάντηση} 19:06, 20 April 2010 (UTC)

It should be replaced with Template:inflection of that is made for the same purpose. Now, It's time. Octahedron80 (talk) 00:52, 7 December 2024 (UTC)

{{IPA}} and {{SAMPA}} currently it seems support up to four parameters. However at pwned, six are needed. {{enPR}} may need expanding as well but I don't know. Could someone who understands the templates work the magic please. Cheers, Thryduulf 23:37, 20 April 2010 (UTC)

Done. --Yair rand 23:44, 20 April 2010 (UTC)

Now that is excellent service. Thank you. Thryduulf 23:54, 20 April 2010 (UTC)

I've noticed in the pronunciation section of several Italian entries there are respellings of the word with a grave accent marking the vowel in the stressed syllable.

As a quick and dirty start at harmonising the presentation of these, I've created template:it-stress, which at present does nothing but precede the input with the label "Stress:". Please feel free to discuss/improve/expand upon/throw it all out and start again. Thryduulf 13:23, 21 April 2010 (UTC)

Should these automatically categorize in English categories when no language is given? I was planning on add lang= to these, but there's no category for the ones that don't have a language specified, as they just get categorized in English anyway. Mglovesfun (talk) 14:20, 21 April 2010 (UTC)

I'm trying out something with {{grc-test}}, somewhat similar to {{trans-top}}, except inside the definition list. The problem that I'm having is that the <div>'s are being ended immediately after the template (see the page source of User:Atelaes/Sandbox), while I want them to continue until they're ended with {{grc-test2}}. Any ideas why? -Atelaes λάλει ἐμοί 04:20, 22 April 2010 (UTC)

Oh dear, it would appear that the problem has to do with partially overlapping elements, which, I believe, are not allowed. This could be trickier than I expected. -Atelaes λάλει ἐμοί 05:02, 22 April 2010 (UTC)

Hi. In creating some Portuguese present participles, where there should be ''' , my bot added ’’’ instead, because my word file auto-corrected them, e.g. with nadando. Can I hire the services of one of our correct-o-bots to fix these? --Rising Sun talk? contributions 06:38, 22 April 2010 (UTC)

Run the pywikipediabot's "replace.py" script. Conrad.Irwin 09:04, 22 April 2010 (UTC)

I think I can do that rather quickly anyway. Mglovesfun (talk) 09:06, 22 April 2010 (UTC)

You shouldn't have to though. Conrad.Irwin 09:09, 22 April 2010 (UTC)

This doesn't address your question, but for future use, Word (at least versions I've used) has auto-correction of straight quotation marks optional: you can turn it off. (Or use a good editor.  :-) )​—msh210℠ 15:04, 22 April 2010 (UTC)

I've noticed we have FOUR templates for Catalan adjectives (ignoring {{ca-adj-form}}. {{ca-adj-table}} should definitely be deleted as redundant. {{ca-adj}} and {{ca-adj-mf}} should IMO be merged into {{ca-adj-2}} (since renamed) which seems to be the most functional of the templates. It's gonna require some serious AWB use to get all of these in line, luckily we have just a few hundred Catalan adjectives! There are similar problems with Catalan nouns (but not verbs AFAICT) but I'll get to them later, maybe tomorrow morning. Mglovesfun (talk) 11:12, 25 April 2010 (UTC)

Ok, I'm working on {{ca-adj/New}}. However {{ca-adj-mf}} doesn't seem to work like {{fr-adj-mf}} where it assumes that the masculine and the feminine are the same, it seems to have exactly the same function as {{ca-adj}}. I'd expect something like global

global m and f (plural globals)

Which would be the same as {{fr-adj-mf}} would produce for French, but it would actually list four form: global, globala, globals and globales. Which (at least according to what I'm reading) is in correct. So I'll make a start on {{ca-adj-mf/New}} as well. Mglovesfun (talk) 11:38, 25 April 2010 (UTC)

I think I've worked out what to do, but in the process of doing it will make a mess of some entries. Does anyone if I make a mess then fix it myself with say, one day. We have 290 Catalan adjectives and some of those use {{infl}} so they won't be affected. Mglovesfun (talk) 12:10, 25 April 2010 (UTC)

Done, all of that. There are a couple of things I need to add back to {{ca-adj}}, but that's it. Mglovesfun (talk) 11:29, 26 April 2010 (UTC)

There's been a suggestion that this should categorize in ]. We usually set English as a default, but that's gonna load up the English category with lots of non-English words. The other possibility, which we seem to never use here, is for it to only categorize when lang= is given. In any event, a bot will be needed because of the number of transclusions. Mglovesfun (talk) 17:01, 27 April 2010 (UTC)

Where was the proposal made? What purpose does categorising homophones serve? ]

just leaves me thinking "homophones of what?" Conrad.Irwin 17:31, 27 April 2010 (UTC)

See WT:RFDO#Category:English_homophones.​—msh210℠ 18:14, 27 April 2010 (UTC)

What he said. I'm against it, but it seems other are not. Mglovesfun (talk) 09:53, 29 April 2010 (UTC)

I suppose the homophones are listed in the entry. But in terms of a category, per what SemperBlotto recently said "is this supposed to help users?" I tend to agree. Homophones in entries very helpful. Having these entries in a category, not all that helpful. Might be useful for school children who are given a homework of finding homophones. That's all I have. Mglovesfun (talk) 11:53, 2 May 2010 (UTC)

I've created this. Please better it and/or comment.​—msh210℠ 17:26, 27 April 2010 (UTC)

Hey, would anyone interested in trying out a wacky bit of probably dangerous code be willing to add 'importScript('User:Atelaes/InlineBox.js');' to their monobook.js (without the apostrophes, mind you)? If so, follow that up by taking a look at User:Atelaes/Sandbox. It's something I've been working on and finally managed to get going, with some much appreciated help from Conrad.Irwin. I thought I'd bring it here and get the bugs worked out of it by the techies before I started asking folks on the BP whether this is something we can accept seeing on Wiktionary. Also, does anyone know if it's possible to get the template itself to import the script? It seems kind of silly to have to ask everyone to edit their own js page to see it in action. It also seems a bit silly to have to load every bit of js on every page. I guess I'm kind of new to this realm of Wiktionary. Be gentle. -Atelaes λάλει ἐμοί 14:51, 28 April 2010 (UTC)

If you add a node with an id to the template's output, then you can add a snippet to Common.js (otherwise you can just check wgPageName) - there are already a few scripts that do a combination of both for the edit-page and search-page which you can copy. Something like: Conrad.Irwin 14:57, 28 April 2010 (UTC)

if (wgPageName == 'User:Atelaes/Sandbox' ) { 
  importScript('User:Atelaes/InlineBox.js'); 
} else {
  addOnloadHook(function () { if(document.getElementById('grc-cite')) 
   importScript('User:Atelaes/InlineBox.js'); 
  });
}

Well, I suppose that's something, but it still requires making edits to our only global javascript page, and it still requires utterly useless calculations being performed on most pages. Granted, the time taken on these calculations is probably on the order of microseconds for most users, which I suspect is well below their absolute threshold, but still. It just doesn't seem like a terribly scalable methodology. -Atelaes λάλει ἐμοί 01:44, 29 April 2010 (UTC)

That's the only truly automatic way, if you don't mind asking people to click buttons, you can add it to WT:PREFS (User:Hippietrail/custom.js) or to Special:Gadgets. The javascript itself looks good, though it seems to make the definition list have irregularly heighted lines, and the text is perhaps too small (perhaps change the label to be "quotations", and the hover-text to be "show" if the button is too big). Conrad.Irwin 14:16, 29 April 2010 (UTC)

I've embiggened them to .65em. You're right, of course, that they were too small to be easily legible, but my concern is that they be clearly set apart from the def text. I think .65 makes for a happy medium, but feel free to disagree with me on that. As for the line spacing, it does seem to be slightly larger with the JS in play, but I am at a loss as to how to solve it. Then again, the difference is quite subtle; I had to zoom in pretty far to even see it. -Atelaes λάλει ἐμοί 23:37, 30 April 2010 (UTC)

Neat. Setting "line-height: 1.5em" on the <span> seems to fix it, but I'm not sure why either. Conrad.Irwin 10:30, 1 May 2010 (UTC)

I like it. Could this be expanded to allow for selective showing of more data sections between the sense lines? I think it would be great if all the sense-specific info (translations, antonyms, synonyms) could be actually right next to each sense and viewable with adjacent links. This would obliviating the need for cludgy "glosses".--Bequw → τ 23:06, 29 April 2010 (UTC)

Unfortunately, it can't. Truth be told, it was my original intention to create it with such expandability, but the way Wiktionary does the ordered listing precludes it. The problem is that almost any deviation from the standard breaks the definition ordering, i.e. the next definition becomes number one. If someone can think of a way to jam other kinds of content inside a def to begin with, I might be able to figure out a way to let the template see it and do piecemeal showing. -Atelaes λάλει ἐμοί 23:43, 29 April 2010 (UTC)

Using the "cludgy" glosses (iff they are present), it is quite possible to re-unite sections at page in javascript. This has been done by "paper view" since 2007 (ouch, that makes me feel old). I think that we should concentrate on getting the quotations button working and accepted by the community before we start making (heaven forbid) "progress" - though it would be cool. Conrad.Irwin 00:03, 30 April 2010 (UTC)

In cleaning up the pronunciation section of the quadrillion entry, I've found that it has one of the two pronunciations written in the w:Shavian alphabet. To support this, I've created template:shavian, but my template skills are low and it needs more work. Specifically it needs support for multiple parameters (up to 6) and setting to use the {{Shaw}} script template. It may need more stuff too, and documentation probably wouldn't go a miss either.

I'm not fussed about the name, or the target of the link, so if anyone has better ideas then go for it. So far only the single entry uses it. Thryduulf 15:13, 28 April 2010 (UTC)

Truth be told, I'm not sure that this is something we want to encourage. The pronunciation sections already have a lower signal to noise ratio than I'd really like, and adding stuff for the dozen people in the world who understand the Shavian alphabet seems a poor investment. -Atelaes λάλει ἐμοί 01:35, 29 April 2010 (UTC)

Can we do a mapping from IPA->Shaw (like we want to for SAMPA) and keep everything in IPA? Then we'd need no manual intervention. --Bequw → τ 03:02, 29 April 2010 (UTC)

I know nothing about it beyond what I've read on Wikipedia, but that does indicate a 1:1 correspondence between shavian symbols and IPA symbols, so automatic conversion would be theoretically possible and possibly even easier than the IPA<->SAMPA (e.g. /ɻ/ = Template:X-SAMPAchar). You've just given me an idea though that maybe we should have a drop-down box or something where you select the pronunciation scheme you want to view, defaulting to IPA but also offering SAMPA and Shavian with only one stored on the page and the others autogenerated. I don't know whether automatic translation between IPA and enPR would be possible though?

This isn't something I've spent more than 30 seconds thinking about so I haven't even started to see whether it is technically possible or desirable. Thryduulf 07:40, 29 April 2010 (UTC)

That's not a bad idea. No idea if it's feasible. -Atelaes λάλει ἐμοί 13:23, 29 April 2010 (UTC)

With most of these things, it's only feasible in the IPA -> direction (as that tends to be better specified and more useful than other formats). I have some javascript that can do IPA->SAMPA (stolen from fr.wiktionary), haven't though much about how to integrate it - I don't speak pronunciation :). Conrad.Irwin 00:05, 30 April 2010 (UTC)

It seems to me that the best approach would be one with cookies, because everyone likes cookies. They're sugary, and doughy, especially when fresh baked. My suspicion is that most users would prefer a single format, i.e. if you like IPA, you generally don't need anything else, if you prefer SAMPA because your computer can't handle the IPA characters, then you never want to get IPA. If we could set up a little link of some sort, that is integrated into {{IPA}}, it could take users to a help page, where the various pronunciation schemes are explained. They pick one, and get a cookie sent to them. Some javascript is put in MediaWiki:Common.js which looks for the cookie. If the cookie is not found, it leaves the IPA as is. If it is found, it imports the correct conversion script, replaces the IPA with the transliteration, and perhaps changes the link. We might even consider getting AF in on this. If we got this in place, we could then have AF go through and remove everything but IPA, so users wouldn't get bombarded with three redundant pronunciation formats. It could even check and make sure it's only removing equivalent SAMPA's and enPR's, and flagging the rest as needing human review. I'll see if I can whip up some proof of concept code. -Atelaes λάλει ἐμοί 01:37, 30 April 2010 (UTC)

I think that's a good idea, altohugh if possible the option to display multiple formats simultaneously would be good, e.g. if someone knows enPR and is learning IPA then they would benefit from being able to see both, although this wouldn't be a default setting. Thryduulf 08:26, 30 April 2010 (UTC)

Ok, I've got a prototype up and working. Add importScript('User:Atelaes/pronunciationCustomization.js'); to your monobook.js and go to Wiktionary:Pronunciation/User Customization. You should see a set of options about your preferred format (if you don't, you may need to refresh the cache or something). Anyway, the only option which really does anything is SAMPA. Clicking IPA simply turns the script off. Don't click on the other two, as they don't work yet. It takes any IPA pronunciation on the page and converts them to SAMPA. It still needs some tweaking, however. It doesn't utilize <tt>. It also converts the IPA to SAMPA, even if there's already a SAMPA. Once I smooth some of those things out, I'll probably present it to the wider community and get some feedback, but I figured I'd at least let you two (and anyone else who happens to be reading this) know, so you could try it out if you like. Any feedback, critiques are welcome, and feel quite free to edit the JS yourself if you think you can improve it. -Atelaes λάλει ἐμοί 06:10, 2 May 2010 (UTC)

Hmmm....it appears that I've got some memory leak or something accessing one of my functions, so the script goes crazy when you try and edit a page. I'll have to see if I can lock that down. Until then, the script works, but it might go a bit wonky if you try and edit anything. Sorry. -Atelaes λάλει ἐμοί 09:26, 2 May 2010 (UTC)

Ok, now it's fixed. It was converting a large swath of the edittools character set, using a ridiculously resource intensive methodology. This has now been fixed and it should be safe to use. -Atelaes λάλει ἐμοί 10:41, 2 May 2010 (UTC)

Looks good. An alternative approach would be to always show IPA and show the others with a checkboxes allowing multiple to be shown. When you think it's ready we can add it to Special:Gadgets. --Bequw → τ 17:49, 2 May 2010 (UTC)

Please unprotect fag and faggot. anons n noobs could be useful for these terms. --Soleil levant 23:10, 28 April 2010 (UTC)

Absolutely not. Anons may well have useful input on these terms, but the signal to noise ratio is simply too low. They can still suggest changes on the talk pages. We may well miss constructive changes because of the protection, but we are not willing to slog through the inevitable vandalism that deprotection would lead to in order to get them. -Atelaes λάλει ἐμοί 01:31, 29 April 2010 (UTC)

Is it just my computer? I can't see properly the last character ൽ (l) in the word പാട്ടിൽ (pāṭṭil), it looks almost like character ® on my computer. --Anatoli 05:43, 29 April 2010 (UTC)

Well yes, this character is an addition to Unicode 5.1. Your font might not be new enough to be able to display this character. -- Prince Kassad 07:25, 29 April 2010 (UTC)

Mine is displaying a weird symbol too. How do we upgrade? ---> Tooironic 08:30, 29 April 2010 (UTC)

You might want to try out this. -- Prince Kassad 09:58, 29 April 2010 (UTC)

It fixed it, thank you, Prince Kassad! I tried to install some Malayalam fonts before but it didn't help. --Anatoli 13:33, 29 April 2010 (UTC)

Shouldn't we have something uniting Sydney Opera House, Hadrian's Wall, Statue of Liberty, Uluru, etc? ---> Tooironic 08:29, 29 April 2010 (UTC)

Are they included in the placenames vote? DCDuring TALK 17:42, 29 April 2010 (UTC)

The first three aren't lexical units, but proper names. You should be able to find articles about their referents under w: Category:World Heritage Sites. —Michael Z. 2010-05-21 02:50 z

See WT:FB#What is a general election. Would it be practical to make certain collocations used in natural-language queries (English or pidgin) (like "what is", "what is meaning/definition", "what mean", "what means", "what meaning", "what define") into search stopwords? Is there another way to accommodate the practice of typing in natural-language queries? Do we have any way to determine how often users use natural-language queries in our site's search? DCDuring TALK 17:41, 29 April 2010 (UTC)

There was a recent discussion on the mailing lists that logging search queries would be a privacy invasion (I don't agree, but hey this is a democracy). I certainly think we should try to strip these words from searches when they are with other words (obviously "what" is a good term on its own) - not sure what the best way to go about it is, I don't think it'd be easy to do with javascript (though that wouldn't stop us trying :p). Conrad.Irwin 00:54, 30 April 2010 (UTC)

Because someone might hack the logging process while user info was still there? As long as folks think like that there will be plenty of opportunity for those who take a more pragmatic approach to trying to understand user behavior.

Doesn't each project get to modify the list of stopwords used in the mediawiki search engine? Stopwords can be "stopterms", can't they? DCDuring TALK 01:03, 30 April 2010 (UTC)

Not that I know of, but they should be able to :). (re privacy, the problem was deemed to be that you might identify someone simply from the searches - imagine if they accidentally paste the wrong thing into the box or if they then go on to create the entry they search for). Conrad.Irwin 08:44, 30 April 2010 (UTC)

You've got to be careful not to exclude multi-word entries that include stop words, e.g. what a lovely day. Thryduulf 08:29, 30 April 2010 (UTC)

That's the bit that would be hard to do in javascript. Conrad.Irwin 08:44, 30 April 2010 (UTC)

Is there a way to find all broken filenames? Do we have any idea how many images or audio files from Commons aren't working? --Bequw → τ 22:56, 29 April 2010 (UTC)

Isn't this what CommonsDelinker is supposed to do, or am I misunderstanding you? Nadando 23:36, 29 April 2010 (UTC)

That only works for cases where the filename is wrong because it was deleted from Commons. I want to know when someone miss-typed the name and forgot to check after saving. --Bequw → τ 01:15, 30 April 2010 (UTC)

I've found http://toolserver.org/~daniel/WikiSense/BrokenImageLinks.php but all of the ones that I checked from the list actually work so I'm not sure how to use the tool. --Bequw → τ 14:50, 2 May 2010 (UTC)

I assume that it lists false positives because we have no image, or maybe because we have no image page, for the images listed (as they image and info are at the Commons only).​—msh210℠ 17:04, 3 May 2010 (UTC)

Note:I'v noticed that Commons Delinker doesn't always get run the way it's supposed to. More than once (but not frequently), I've come across a red-linked image left in an entry after a deletion on Commons where our entry page with a link was not fixed. --EncycloPetey 15:49, 8 May 2010 (UTC)

I updated Template:si, mainly according to a quick conversation I had with Bequw at my talk page . Please see that template; can that system be used widely with other language templates, such as {{en}}, {{pt}}, {{oko}}, {{gmq-osw}} and others? Opinions would be appreciated. --Daniel. 21:41, 30 April 2010 (UTC)

Such complexity is very unadvisable in templates that are so widely used. I would normally say not to concern ourselves with performance, but when the templates are used hundreds (if not thousands) of times on tens of thousands of pages, adding features like this is not the correct solution. If you want to store all the other attributes for languages, please create new sub-templates. (There would be slightly less of a problem if you abolished {{langtempboiler}} sitting in the middle, but I think it's still a serious issue). If you want to prove me wrong, please create a page similar in scope to water for an accurate comparison of speed. Conrad.Irwin 22:00, 30 April 2010 (UTC)

I tested it in the sandbox by copying the trans section from water and replacing all the language codes with "si". There was no noticable impact in performance. So it should not pose any technical problems. -- Prince Kassad 00:05, 1 May 2010 (UTC)

The test is to look at the server time used in the HTML source served out, not whether it is noticeable (;-) Robert Ullmann 00:32, 3 May 2010 (UTC)

Interesting, it seems that although the template itself is much more complicated (about 7 times) this is lost in the noise, so when used with {{t}} it's only 1.5 times the cost; I had expected it to be much worse. Conrad.Irwin 10:32, 1 May 2010 (UTC)

Yeah complexity is unadvisable. For anything using {{poscatboiler}}, it now takes my connection at least 30 seconds to load it up, presumably because the serve expands all the "ifs" before displaying the page. Mglovesfun (talk) 10:39, 1 May 2010 (UTC)

This is completely unacceptable. We went to a great deal of effort to make this level simple, consistent, and reasonably fair to the servers (;-).

Please remove this immediately from the "production" language templates. We can then talk about why this cannot be done. DAVilla tried something like this before, and it just doesn't work: one of the primary objectives (and the original use) of the templates is to subst: them. See what happened at deionises when Palkia correctly did {{subst:en}}. That must work; you can't use parser functions and so on.

For future reference, I have "fixed" this limitation, see safesubst:. Conrad.Irwin 16:07, 3 May 2010 (UTC)

Sorry, I know you are trying something "neat". But like most neat things, if it was a good idea, it would already have been done. As I said, please remove it ASAP and then we can explain more if you like. Robert Ullmann 00:25, 3 May 2010 (UTC)

I reverted {{en}}, which is a very large number of cases. Which other ones need fixing? Robert Ullmann 00:30, 3 May 2010 (UTC)

Also (not to pile on, but) if this was used on any large number of language templates, it would blow past the template expand limit on pages with large translations sections, and the page would not render. We've stayed clear of this limit so far with a little care! Robert Ullmann 00:41, 3 May 2010 (UTC)

So could we store the multiple names in a separate subtemplate like Template:fa/names? --Bequw → τ 01:54, 3 May 2010 (UTC)

Yes, that seems the most sensible thing to do, though how many places need this information? Conrad.Irwin 16:07, 3 May 2010 (UTC)

We keep names of languages at ]. Why do they need to be in templatified?​—msh210℠ 17:00, 3 May 2010 (UTC)

That is the question: it isn't where we "store this information", but, rather, what would it be used for, and why? If it is solely documentation, it should not be in template: space at all, but in WT: or template talkspace.

What is the objective here? Robert Ullmann 17:14, 3 May 2010 (UTC)

Ideally this information would be shown at WT:LANGNAME and on the documentation for each of those templates (and maybe other places). So the point is to keep documentation in sync. We use templates for reused bits of text used in many namespaces so I see no problem with storing the info at /names subpages. --Bequw → τ 03:31, 7 May 2010 (UTC)

I've switched {{fa}} over to using /names so that WT:LANGNAME and {{fa/doc}} are synchronized. Assuming no problems we can convert the others as well.--Bequw → τ 23:16, 28 May 2010 (UTC)

As a result of the short-term "upgrades", there is now a cleanup list Special:WhatLinksHere/Template:langtempboiler for items that were subst'ed with the template documentation, which will therefore need to be removed. --EncycloPetey 03:39, 7 May 2010 (UTC)