These templates are screwing around with the numbering in our entries - see the ] page, and the numbering goes 1, 2, 1, 2. --Jackofclubs 06:25, 6 June 2009 (UTC)

I reverted a change made June 5 in template:cite meta that seemed to have been the problem and notified the contributor. I hope that is all that is required. DCDuring TALK 09:37, 6 June 2009 (UTC)

I was wondering if anyone would be willing to help out on what should be a rather simple find/replace procedure. I have cited an online Chinese-English Dictionary in hundreds of Wiktionary entries. I provided the hyperlink in the template as well. Unfortunately, the hyperlink has changed. Instead of http://www.dreye.com/index_en.html, it should simply be http://www.dreye.com/ (see: 豁達 for example). Is there an easy way for someone to check the references section for all Mandarin entries that cite Dr. eye, and remove /index_en.html from the URL? Thanks. -- A-cai 14:34, 6 June 2009 (UTC)

User:Opiaterein has a bot called Inflectobot who can do that. Ask him. --Vahagn Petrosyan 15:59, 6 June 2009 (UTC)

This was redirected to {{nl-verb-conj}}, with the result that all Dutch verbs now have an entire conjugation table as an inflection line. Could this be fixed please? Nadando 18:33, 7 June 2009 (UTC)

The problem is that plenty of Dutch verbs are currently using {{nl-verb}} as their actual conjugation table (like, in a ====Conjugation==== section). This will require some sort of sorting-out, probably by a bot … 19:08, 7 June 2009 (UTC)

I'll take a look at this (and put Inflecto to work) when I have some extra time. Should be fun — opiaterein — 21:27, 8 June 2009 (UTC)

Is there a compelling reason for this to be in a floating box? If not, would someone with template knowledge convert to be like other inflection line templates? Nadando 03:44, 10 June 2009 (UTC)

While running FitBot the past few days, I've gotten numerous messages of "Pausing 5 seconds due to database server lag". sometimes I get this every 5 seconds for a full six minutes before the page can be created. Today, the problem has been especially bad, and several times I've gotten "Unexpected response from wiki server" with the following text dumped on my screen:

17K message excised since problem seems fixed. Message can be seen in this older version of the page.

Why is this being dumped at my bot? Please, can someone stop it from happening? When this happens, I have to figure out which page(s) wasn't created and do it manually. --EncycloPetey 05:52, 11 June 2009 (UTC)

Note: This information posted here, in part for discussion on #wikimedia-tech, where a "conflicting read lock" because of srv76 was noted as the problem. --EncycloPetey 06:12, 11 June 2009 (UTC)

The above page generates misleading text. Indeed, even its name is misleading. It is used for lists of terms that begin with a set of characters that need not be a prefix. Can this conveniently be changed to something more accurate? Does this need BP discusssion? DCDuring TALK 13:56, 12 June 2009 (UTC)

This would be "prefix" in the computing sense, not the linguistic one. We can change the text fairly easily, by creating MediaWiki:prefixindex (default: "All pages with prefix"), MediaWiki:prefixindex-summary (default: ""), and/or MediaWiki:allpagesprefix (default: "Display pages with prefix:"). Changing the name would be more difficult; it's internationalizable (e.g. on French projects it's called "Spécial:Index"), but I believe that's basically baked into the code.

We shouldn't really be sending readers to Special:PrefixIndex, since it's not part of our content per se. It's useful for editors, and sometimes as a kludge we might point readers there, but if we're worried that it might confuse readers, then the problem is that readers are seeing it, and the solution is to remove the need for readers to see it.

—Ruakh_TALK 14:15, 12 June 2009 (UTC)

Then we should kill the template that uses it: {{lookfrom}}. Though I haven't used it, I thought it affords some advantages: It allows parts of our derived terms list to be constructed on the fly so that it is not out of date and the content does not have to be down-loaded as often. Would it be possible to get the same advantages some other way? DCDuring TALK 16:04, 12 June 2009 (UTC)

I don't know. —Ruakh_TALK 18:29, 29 June 2009 (UTC)

Hello. Could someone who knows how please change our use of the ISO 639-3 codes heb and hbo to read Modern Hebrew and Classical Hebrew, respectively? At present, they and he (Hebrew’s ISO 639-1 code) all yield Hebrew. It would be useful for the display to be as follows:

1. {{etyl|he}} → Hebrew
2. {{etyl|heb}} → Modern Hebrew
3. {{etyl|hbo}} → Classical Hebrew

Ideally and intuitively, there would also be the autocategories Category:Hebrew derivations (which we have) for Hebrew, Category:Modern Hebrew derivations for Modern Hebrew, and Category:Classical Hebrew derivations for Classical Hebrew.
My thanks to whomever. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 13:21, 15 June 2009 (UTC)

I think the consensus has been to treat it as one language for {{heb}} purposes at least: I'm not sure about for {{etyl|heb}} purposes.​—msh210℠ 16:40, 15 June 2009 (UTC)

Why a link with the face "Classical Hebrew" and the target "Biblical Hebrew"? Just a thought. (On the same token, we seem to have favored Old Armenian over Classical Armenian, Ancient Greek over...whatever else. etc.) — opiaterein — 18:55, 15 June 2009 (UTC)

The ISO templates are designed to match language section headers. So, unless you are proposing to dismantle Hebrew entries into different periods (which would be a massive policy change), the templates should stay as they are. You could, as an alternative solution, use Webster-style templates as we do for Latin. All Latin entries are treated under a uniform "Latin" language header, but for etymologies we use templates like {{VL.}} or {{NL.}} to specify temporal periods of the language. --EncycloPetey 19:08, 17 June 2009 (UTC)

That approach is obsolete, as of February, when Bequw edited {{etyl}} to add support for {{etyl:…}}. We should replace {{VL.}} and {{NL.}} with, say, {{etyl|la-x-vulgar}} and {{etyl|la-x-new}} (though I'd welcome your thoughts on the naming). Similarly, we could create {{etyl:he-IL}} and {{etyl:hbo}} to support what Doremítzwr describes. (Note the he-IL rather than heb; he and heb are supposed to be synonymous, and even if we don't use them exactly the way they're supposed to be used, I don't think we should try to distinguish them.) This isn't going to be perfect — English and Classical Hebrew never existed at the same time, so words that entered English from Classical Hebrew either came via European languages, or were influenced by Medieval Hebrew (in the form of the Masoretic vocalization) — but it should at least help distinguish words like (deprecated template usage) sabra and (deprecated template usage) kibbutz from words like (deprecated template usage) seraph and (deprecated template usage) behemoth. —Ruakh_TALK 20:52, 17 June 2009 (UTC)

Currently, you can only use 38 of the 58 possible country parameters because this Template exceeds the MediaWiki template limits. Is there any way to fix this problem? There are some languages spoken in more than 38 countries, including but not limited to English. -- Prince Kassad 19:39, 15 June 2009 (UTC)

This doesn't answer your question, but a hack is of course to catgeorize manually. (That's all adding those parameters does, anyway.)​—msh210℠ 20:09, 15 June 2009 (UTC)

To me, the sort key appended to all country categories seems rather useless since it does not change the sort order at all, but I don't know much about templates. -- Prince Kassad 20:22, 15 June 2009 (UTC)

You can use up to sixty country parameters now, and the sort keys were removed. Of course, the manual categorization is working as well. It's up to you choose manual categorization or the {{langcatboiler}}. However, I'd prefer the latter for consistency, because as they're both accepted, I'm doing my best to add this template to all language categories, then check all the parameters for countries, language families and interwikis. --Daniel. 21:38, 15 June 2009 (UTC)

Can't this be populated automatically by {{en-verb}}? Add something like {{#if:{{{3|}}}|{{#ifeq|{{{4|{{{3}}}}}}|{{PAGENAME}}|]}}}} perhaps?​—msh210℠ 20:12, 16 June 2009 (UTC)

Probably, but is the added strain to the server worthwhile? It must be a very, very limited set of English verbs that have this property. Adding an extra if check to every English verb entry on Wiktionary seems to more than counterbalance a desire to save on adding the category. It also wouldn't catch the verbs like (deprecated template usage) burst that optionally have the same past participle and have had explicit multiple forms added. --EncycloPetey 20:23, 16 June 2009 (UTC)

For one point of view, see w:wp:don't worry about performance.​—msh210℠ 21:58, 16 June 2009 (UTC)

Wikipedia makes far less use of these sorts of templates, and so seldom has to consider them. In cases like this, the effects have been measurable and considered before on Wiktionary. And there is still the second point I raised, which would not be solved by a template change. Further, any addiitonal variant forms of past participles added in a verb's template would de-catagorize it under the proposal. I think tracking down the verbs and categorizing them by hand (or by a bot given the list) is a smarter move. --EncycloPetey 22:08, 16 June 2009 (UTC)

Okay, fair enough. I suppose a bot could even track them down. (It shouldn't be too hard to find even those that list more than one past participle, I imagine.)​—msh210℠ 22:39, 16 June 2009 (UTC)

Along the same lines, is there any reason {{homophones}} with language not set (or set to English) should not categorize in Category:English homophones? (Here, there's no big waste of server use, since the #if will be true and executed in the vast majority of cases that the template is used, so, while it'll be server use, it won't be waste of server use.) Something like {{#ifeq:{{{lang|en}}}|en|]}}, perhaps? (I'd recommend this for all languages, but English is the only one with a category at this time.)​—msh210℠ 22:47, 16 June 2009 (UTC)

Sort of realised that 24 hours later nobody has commented on this - perhaps I posted it to the wrong place? Anyway, please add your two cents if you feel like it. Mglovesfun 18:57, 17 June 2009 (UTC)

You didn't get comment because the vote page isn't properly formatted, nor was it ever added to the WT:VOTE page. See the instructions at the top of that page to see how to initiate a vote. --EncycloPetey 19:03, 17 June 2009 (UTC)

Every day somebody adds two or more words, separated by commas, using the excellent assisted translation system. Of course, it produces a single, red-linked entry instead of the multiple separate entries intended. Could the system be modified to either produce the multiple entries, or to give a warning message? SemperBlotto 11:39, 18 June 2009 (UTC)

If you clear your cache (ctrl+shift+F5) you should see the new version that will produce one of two error messages (by default everyone will see "You can only add one translation at a time. If this is one translation that contains a comma, you can add it by clicking here." and nothing will happen. However if they have previously clicked on that message they will see "Please click undo if you were trying to create a list of translations in one go, this is currently not supported." and the translation with a comma will be added. When they click on the second message, the system will default back to the first behaviour). Conrad.Irwin 02:38, 19 June 2009 (UTC)

This page is now over 26K, which is too large. The entire thing has to download each time you open an edit window, and there are some machines I use where I may have to wait 20 seconds for the edit window to open now. How can we shrink the size of this overgrown monster? Ruakh seems to have done some work, but can we do more? --EncycloPetey 15:05, 18 June 2009 (UTC)

I think the next step would be removing unneeded letters. For example, the plain Latin letters (A, B...) in the Yoruba section are not needed as they're on everyone's keyboard. -- Prince Kassad 15:13, 18 June 2009 (UTC)

I've just now finished my changes; all told, I've brought the edit-tools down from 172KB to 27KB, without actually changing anything. 27KB is still a lot — it's more than half the page, bit-wise — but it should reduce your wait-time by a factor of roughly 4. Next up, we should consider changes that do actually change things:

• removing the plain Latin letters that Prince Kassad mentions.
• removing, or at least merging, the duplicate Latin/Roman sections. I understand that it's a pain to use the huge "Latin/Roman" section for languages with just a few diacritics, but then, it's also a pain to navigate a huge list of identical languages.
• removing "heavy" sections, such as sign languages, and creating a way for interested editors to re-add them as a customization.
• removing little-used sections. I don't know which these are, but we can probably get statistics on which languages aren't really active. (I think Visviva can help with this.)
• removing some of the excessive explanations, both in-line and in tooltips (hover-text). Does every single edit-page on the site the "approximately equals" tooltip?

—Ruakh_TALK 16:25, 18 June 2009 (UTC)

The correct solution to this is to use javascript (I think w:User:Mike_Dillon has some already written, or we can write our own). That way the size does not matter, it will only be downloaded once per month, the first time a user edits the page, it also means we can plug it into other places (like translations and search). The one downside would be that all edittools would need rewriting (including all the customised ones). I'm not sure how much time I have at the moment, but this is third on my "tofix" list after the bug-reports to editor.js and the indexing on my talk page (though obviously if someone else does it before I get round to it, that suits me best :p) Conrad.Irwin 00:02, 19 June 2009 (UTC)

Well, we already are using JavaScript. Heavily. I assume you mean we should move the actual characters into an external JavaScript page? If so, I agree, but there are some things to keep in mind:

• We're down to 27KB for now. As I said above, that's a lot — it (slightly) more than doubles the section-edit page I'm currently editing — but even on low-end dialup connections, we're talking less than 1.5 seconds of download time. All told, it's small enough that I think it's worth examining the advantages and disadvantages of external JavaScript.
• A too-big edit-tools has other problems besides just download time. There are also technical issues (the eating up of browser resources — not a big deal if you're editing from a modern PC, but potentially an issue for users editing from older computers, from phones, etc.) and usability issues (the list of languages/scripts is pretty long to scroll through, and within some of the scripts there are just so many characters). This is potentially an argument for external JavaScript, done right — done in a way that only presents the languages/scripts that a user wants to see — but it's definitely an argument against external JavaScript, done wrong — done in a simplistic way that just preserves the current problems, but also adds a big neon sign telling admins that it's now O.K. to add lots of bloat.
• Currently, the edit-tools degrade somewhat usefully for an editor with JavaScript disabled. (My recent changes were actually an improvement in this regard: instead of non-functional links, they get plain text that's easy to copy and paste out of.) I'm loath to completely remove that.
• The more we externalize, the harder/slower it is to make changes, because of the way external JavaScript-s are cached. However, we can mitigate this by storing version/revision information in the edit-tools proper, so that whenever there's a change that needs to propagated immediately for whatever reason, we can do so.

All told, I don't think someone should just " it before get round to it" — details need to be hammered out, preferably with input from BP-izens.

—Ruakh_TALK 15:28, 19 June 2009 (UTC)

I am not sure there is a connection, but I have twice today had the same problem. Selecting the alt spellings template from edittools led to the non-recognition of the template on saving. I would guess that there was a look-alike character in there. This is the problem version cut and pasted: "alternative spelling of". Cutting and pasting from the template headword or typing generated the expected response. DCDuring TALK 18:05, 19 June 2009 (UTC)

Does this happen each time you use the Edittools for that template, or just intermittently? It worked just fine for me a moment ago. --EncycloPetey 18:26, 19 June 2009 (UTC)

Thanks for letting me know. The code that changes non-breaking spaces to spaces must not be working properly in all browsers; for now, I've switched the headers and the templates back to <charinsert> (bringing the size back up to 30 KB). I thought I'd tested that, but I must have missed something. I'll look into it. Thanks again! —Ruakh_TALK 18:44, 19 June 2009 (UTC)

FWIW, I use FF 3.0.11. OK just now. DCDuring TALK 19:20, 19 June 2009 (UTC)

OK, I've now fixed the underlying issue. However, since it was in MediaWiki:Monobook.js, which gets cached, we'll have to wait a month before restoring the <span class="charinsert">'s for those. (Not a big deal; it's just two of the sections. We're still at 30 KB, which isn't as good as 27 KB, but is loads better than the 172 KB we started off at.) Thanks again for letting me know! —Ruakh_TALK 19:27, 19 June 2009 (UTC)

From what I can see, the French and Spanish sections add nothing that isn't already in the Latin/Roman section, apart from the upside down exclamation and question marks. Mglovesfun (talk) 17:46, 4 July 2009 (UTC)

We have just deleted a term an old hand at, which seemed appropriate. I had assumed that a search for "an old hand at" or "old hand at" would find ], especially because the term appeared in Derived terms and in a usage example. It didn't put it on the first page anyway (I didn't search all 2000+ pages offered). When I quoted the term it didn't find it at all.

] has been in the system in its current for for a little more than two years, so an indexing delay doesn't seem like an acceptable excuse. Is there something about the entry that makes search ineffective? If search is normally so ineffective, what adjustments, crutches, or kludges can help overcome its shortcomings? DCDuring TALK 16:03, 18 June 2009 (UTC)

From poking around, I get the impression that the search is getting thrown off by the '''-s. If that is indeed the case, I don't have a suggestion how to improve matters. —Ruakh_TALK 17:02, 18 June 2009 (UTC)

But it also didn't find the redlinked an old hand at (now deleted) in ], though it did find it on other pages. The exact way this works and its potential for remediation should effect how he propose to handle some common collocations that don't meet WT:CFI. Should we put in many more redirects, omit bolding of headwords in usage examples (amend WT:ELE, or amend WT:CFI (heaven help us!) to allow more collocations that are no so idiomatic so that users have a chance of finding the true idioms. DCDuring TALK 00:23, 19 June 2009 (UTC)

It seems to be working now. I'm not sure what changed; maybe they improved the search functionality? Regardless, ] is now the first hit for "an old hand at" (with or without quotation marks, with or without the "an"). —Ruakh_TALK 18:43, 14 July 2009 (UTC)

Indeed. You had replicated the earlier problem, right? Or could I have been wrong about it? I hate to be a leading exemplar of the wisdom of fallibilism. DCDuring TALK 19:09, 14 July 2009 (UTC)

Yes, I had. —Ruakh_TALK 19:33, 14 July 2009 (UTC)

That's a relief. DCDuring TALK 19:35, 14 July 2009 (UTC)

There seem to be subtle differences in the farsi/arabic script that I cannot detect but that lead to the creation of pages that the wiki system considers different. Can someone help me understand waht is going on and advide how to avoid this kind of problems? All I have to write this script is the Windows character map. Jcwf 23:39, 24 June 2009 (UTC)

In the header of this section, you link to the talk-page for فروردین, with the second-to-last letter being U+06CC ARABIC LETTER FARSI YEH. In that talk-page, you link in turn to the talk-page for فروردين, with the second-to-last letter being U+064A ARABIC LETTER YEH. These two letters seem to be indistinguishable, or nearly so, in the middle of a word, but at the end of a word the former lacks the two dots of the latter, as you can see by inserting a space after each: فروردی ن vs. فروردي ن. (The exact details might depend on your fonts: I'm not sure how well the various fonts reflect the different forms of Arabic letters at their various positions in a word. Since I can't read the script, I've never had occasion to worry about it.)

If you have JavaScript enabled, I recommend using the edit-tools instead of Character Map. Right below the "Save page" button, you should see a drop-down menu; if you choose "Arabic", you'll get a list of links to insert Arabic letters into the edit-box. The Persian-specific letters are well indicated.

—Ruakh_TALK 02:54, 25 June 2009 (UTC)

Right. Until Unicode, there was no difference in initial or medial Arabic and Persian yeh. Arabic also has an undotted yaa’ called alif maqsura, and this was always the letter that Persian used for final and isolated yeh. In Unicode, it was decided to differeniate, and now Arabic has ي and ى, while Persian has only ی, different from either Arabic letter. It’s not unusual for a Persian to use an Arabic keyboard and therefore use the Arabic yehs, so both spellings are found. —Stephen 05:04, 25 June 2009 (UTC)

Thank you very much for the explanation. I might add that for some of the months of the Persian calender pronunciation files do exist but their name at commons contain the Arabic yeh.

Jcwf 13:47, 25 June 2009 (UTC)

Shouldn't the shortcut to Wiktionary:About Serbo-Croatian be WT:ASH? --Daniel. 08:27, 25 June 2009 (UTC)

Right, corrected. --Ivan Štambuk 12:38, 25 June 2009 (UTC)

I include this subtitle to allow functioning section-linking to this discussion. My initial post should exemplify this problem.

When {{temp}} is used in section-header fields, the → links produced for section-linking which appear in one’s watchlist (well, in mine, at least) do not take one to the desired section, but rather only to the top of the page (which is a pain for the main fora WT:ID, WT:TR, WT:BP, WT:GP, WT:RFV, WT:RFD, WT:RFC, &c., which are all large pages and require a lot of scrolling otherwise). I noticed that the same problem was caused by other code in the past, but that this functionality problem has since been rectified. Is there any hope that the same can be done for {{temp}}? I presently eschew its use in headers (except in this case, where I use it to exemplify the problem), but it is used by others (e.g., by Michael Z. in the Beer Parlour sections {{chiefly}} > {{mainly}} and {{markedly}} > {{very}}: ). † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 12:16, 25 June 2009 (UTC)

Seems to be fixed when you clear your cache (ctrl+shift+F5). Conrad.Irwin 20:51, 25 June 2009 (UTC)

Great! Thanks for fixing this persistent problem so quickly. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 21:30, 25 June 2009 (UTC)

Thanks! That's always driven me crazy. BTW, when viewing a diff, the section-link in the edit summary is similarly nonfunctional. That's a bit harder to fix — you'd have to isolate the link and alter its href — but if you're in a fixitive mood, it would be appreciated. :-)   —Ruakh_TALK 01:26, 26 June 2009 (UTC)

Oh, actually, it’s not yet working perfectly. ATM, section linking is sending me, conversely, to the bottom of the page now. That’s not much of a problem for this discussion or for new discussions, and is an improvement on the old problem, but it still isn’t ideal. Any idea why it’s switched to this new behaviour? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 09:26, 26 June 2009 (UTC)

Another possibility might be to add something like

addOnloadHook(function () {
  if(wgAction != 'edit')
    return;
  if(! /section=\d/.test(window.location.href))
    return;
  var wpSummary = document.getElementById('wpSummary');
  if(! wpSummary)
    return;
  if(! /^\/\*.*?\/\* $/.test(wpSummary.value))
    return;
  wpSummary.value = wpSummary.value.replace(/\{\{temp(late)?\|/g, '{{');
});

What this does is, if the user is currently editing a numbered section, and the edit-summary looks "fresh" — we don't want to mess with an edit-summary the user has already touched — then it finds all instance of {{temp| or {{template| in the edit summary, and changes them to plain {{. This won't work when the user is creating a new section (and can't be made to work in that case, because the same field serves both as the edit-summary and as the new section header), and it won't work for pre-existing edit summaries; but then, it doesn't have to replace Conrad's code. The two aren't mutually exclusive.

I'll wait a day or so, and if no one objects, I'll make the change.

—Ruakh_TALK 01:27, 29 June 2009 (UTC)

Done. (I ended adding slightly different code from what I listed here, but the functionality is the same.) —Ruakh_TALK 14:12, 30 June 2009 (UTC)

How do I edit the word of the day? I clicked on "edit" and changed it, but the changes didn't come through on the main page, even after I clicked refresh.

Here's what's wrong with today's definition:

prolix: Tending to use large or obscure words, which few understand.

1. Grammatical error: the comma means we are stating that few people understand long or obscure words, as if the definition read: "Tending to use large or obscure words (which few understand)." This is not what is meant.

The intended sense is "Tending to use large or obscure words understood by few people". This requires the removal of the comma, and, if we want to be really clear, the replacement of "which" by "that", giving "Tending to use large or obscure words that few understand."

2. Vocabulary error: "THE" in 120-point letters is a large word but everyone who speaks English understands it. "Large" should be "long".

— Paul G 14:21, 25 June 2009 (UTC)

The Main Page displays via a template. So, you make the changes but the display on the Main Page will not change until (a) you clear your cache, and (b) the system gets around to updating all calls to that template. This may take several minutes to much of an hour.

I notice that you have made the chnage to the WOTD template, but not to the entry for the word itself, which was the source of the definition. Yuo are always welcome to update the selected entries before their definitions are copied into the WOTD templates. --EncycloPetey 14:54, 25 June 2009 (UTC)

Ah, now that's what I was looking for. It's academic now because we have a different word of the day now, but thanks for the information. — Paul G 13:05, 26 June 2009 (UTC)

Hi. I was wondering if someone could please create the template grc-0 (so I can put it on my userpage)?  :) I know a few roots from ancient Greek (from studying word etymologies) and Latin and there is a lt-0, de-0 and fr-0 but I don't want it to look like I know Greek better than the others. Thanks! Logomaniac 22:23, 27 June 2009 (UTC)

Generally, the X-0 templates aren't very useful here, and we tend to discourage them. It would be better to describe your minimal skill in a text portion of your user page, appropriately labelled, rather than advertise in your user box that you don't understand that language. --EncycloPetey 00:01, 28 June 2009 (UTC)

Yes, I know that . . . it has been discussed elsewhere. So then should I delete all of my xx-0 Babel boxes? and is that a no for creating the grc-0 template? Logomaniac 01:15, 28 June 2009 (UTC)

I would say so, yes. If we started listing xx-0 templates for languages we know only a little, Stephen, I, and others would have a huge list in our Babel templates. In my case, I've studied Spanish and Latin formally, have independently studied Galician, have watched PBS programs teaching French, have pored over Romanian grammars, and as a result have a rating between 0 and 1 for most Romance languages. That doesn't consider the fact that I've picked up a slght bit of Polish from working with medieval records that contain Latinized Polish, and have done the same with Hungarian.... you get the idea. Stephen is even more eclectic, having worked in many scripts and as a translator.

It would make more sense, and be more use if that kind of information were briefly summarized as userpage text, rather than reducing it to a cryptic "0" rating. Such a rating could just as easily mean that you don't know the language at all. The only truly suitable I know of for an xx-0 is for people who work across multiple Wiktionaries in such areas as interwiki linkking, where a person may wish to indicate that the local language is one he doesn't know. --EncycloPetey 03:17, 28 June 2009 (UTC)

OK, I'll delete my lt, grc, fr, and de Babel templates.  :) One question tho - why the heck does Wiktionary even have xx-0 templates? It's been puzzling me . . . . . . . . Logomaniac 18:55, 28 June 2009 (UTC)

Primarily because users copy them over from Wikipedia, where they sometimes are useful, such as when a person works on many Polish history pages, but does not speak Polish. --EncycloPetey 20:25, 28 June 2009 (UTC)

But can't that also happen here? For example, someone with Ancient Greek knowledge might edit a lot of etymologies (going where {{attention|grc}} leads), but not speak the relevant languages. If said editor finds himself (or herself) frequently editing entries in some specific languages (say, Greek), the zero-level Babel might be useful, no? —Ruakh_TALK 01:35, 29 June 2009 (UTC)

I do understand what you're talking about, but editing etymologies that come from Ancient Greek isn't my specialty (at the moment, at least). I don't speak it either though. :) I will now delete xx-0 boxes from my Babel - I hadn't gotten around to it before. You two can drop the subject if ya want to. Logomaniac 17:04, 29 June 2009 (UTC)

Not that I can tell.​—msh210℠ 17:35, 29 June 2009 (UTC)