Is it possible to sort existing pages which are labeled under a specific country and politics into a separate category? For instance, {{context|US|politics}} would go to Category:United States politics. I suppose this could be done manually, but it would be nice if one of the bots could help out. Globish 18:28, 1 February 2008 (UTC)

Automating it would confuse US terms for British politics and vice-a-versa. I think the manual approach will work better here. --Connel MacKenzie 05:36, 2 February 2008 (UTC)

Since we usually place language names ahead of topics, I would rather see such a category named Category:Politics of the United States, to avoid the confusion of potential category names like Category:French politics. --EncycloPetey 05:43, 2 February 2008 (UTC)

I created the first one from a red link, but we already have the second one. What's the difference? (I shall then delete my entry and fix the red link) SemperBlotto 17:28, 4 February 2008 (UTC)

The first one contains URL enociding pej%D0%BErative. Seems to be a unicode character for 'o' but I don't know which one. RJFJR 18:05, 4 February 2008 (UTC)

It's о, CYRILLIC SMALL LETTER O. Delete this page.—msh210℠ 19:01, 4 February 2008 (UTC)

о, that's the cyrillic o (w:O (Cyrillic)). Circeus 19:05, 4 February 2008 (UTC)

And Connel has deleted it anyway. SemperBlotto 22:14, 4 February 2008 (UTC)

FYI, The various Special: pages seemed to be updating again. --Connel MacKenzie 21:07, 4 February 2008 (UTC)

The one I'd like back still seems to be out Special:Wantedpages. --Bequw → ¢ • τ 23:56, 7 February 2008 (UTC)

See User:Robert Ullmann/Missing instead. RJFJR 22:16, 9 February 2008 (UTC)

{{wikisource}}, {{wikiquote}}, and {{WOTD}} all have unclosed <div> tags. Would there be any problem if I balanced them? --Bequw → ¢ • τ 19:21, 9 February 2008 (UTC)

No. --HotTea 20:14, 9 February 2008 (UTC)

Please do, though I think the Mediawiki software corrects unbalanced tags. (By the way HotTea has been blocked for the moment). Conrad.Irwin 22:18, 9 February 2008 (UTC)

Yes, By DCDuring. Circeus 22:47, 9 February 2008 (UTC)

Please test it out first; as Conrad.Irwin says, the software automatically corrects unbalanced tags, so it seems plausible that the intent with those templates is for the rest of the entry to be wrapped in a div for some reason or other. (I doubt it, but you might as well check.) —Ruakh_TALK 00:43, 10 February 2008 (UTC)

Depending on the value of lang= parameter for {{term}}, the first unnamed parameter for {{t}}, {{infl}} and all the other places it's used. It's really redundant to type sc=polytonic for every single Ancient Greek entry, sc=Goth for Gothic etc, when this information can be deduced from other sources. For languages that are written in multiple scripts, this would be ignored. I also assume that there are langauges written in non-Latin script where bolding the headword (by default not done when sc= is fed into {{infl}}) is a preferable choice. Could this work? --Ivan Štambuk 15:35, 10 February 2008 (UTC)

Re: default script: This could be done by modifying {{term}}, {{infl}}, etc. to check for the existence of {{language-code-script}} ({{grc-script}}, etc.). Then, for languages where it makes sense to have a default script, and where said default isn't the Latin script, this template can be made a redirect to the right template. (Actually, even if the default is the Latin script, this redirect should probably be made and protected, for anti-vandalism reasons.)

Re: bolding headwords: This could be done by modifying {{infl}} to pass a parameter like context=infl into the script template; then each script template can handle this in the appropriate way. (I imagine that most of the time, this will mean either making bolder or making bigger.)

—Ruakh_TALK 16:12, 10 February 2008 (UTC)

Alternatively, instead of making a bunch of language-specific templates, there would be just one, something like lang2sc which would have hard-coded values inside a big #switch statement, returning default script for given ISO code. Then the usage of blank {{{sc}}} could be substituted with {{lang2sc|{{{lang}}}}}. This doesn't seem very hard to code. Of course, first the list of mappings from language codes to scripts should be made. --Ivan Štambuk 17:39, 10 February 2008 (UTC)

That would be a bit easier to code, but it would mean that every time a new language is added, the job queue would get filled with every single entry that contains {{term}} or {{infl}} or {{t}} or the like. If we use {{grc-script}} et al, only entries referring to the relevant language would be affected by the creation of a template. And I don't think my way is difficult to code; in {{term}}, for example, you'd just replace Latn with
{{ #ifexist: Template:{{{lang|en}}}-script | {{{lang|en}}}-script | Latn }}. (Not pretty, certainly, but not difficult, either.) BTW, I suggested {{grc-script}} because that strikes me as a friendly format, but if you don't like the idea of making a bunch of new templates, we can instead make use of the existing language-based script templates ({{ELchar}} and {{HEchar}} and so on) by replacing with Latn with {{ #ifexist: Template:{{uc:{{{lang|en}}}}}char | {{uc:{{{lang|en}}}}}char | Latn }}, which you can see in action at User talk:Ruakh/Test. —Ruakh_TALK 19:08, 10 February 2008 (UTC)

Wait, by "job queue" you meant invalidating server-side cache of template functions? I don't see that as a big problem, if thought properly. Category:Script templates has 52 entries out of which at least 15 or so are irrelevant for this purpose. Granted, not all of 130 currently approved ISO 15924 script codes have their respective counterparts in that category (they could be added though) - but that category is getting populated really slowly, and pretty much all relevant languages are present in it. Unicode gets updated every few years, and that time span is pretty reasonable. Or should we wait one more month until Unicode 5.1 comes out? Wikipedia/Meta template guidelines suggest ignoring the performance issue because it's not user's job to think about it anyway. Your method would require creating and protecting a bunch of redirects (more specifically, 7589 of them for those defined in ISO 639-3:2007) in format uc:<lang>char to proper ISO 15924 names (apart from a few exceptions, like grc->polytonic). It all suits for me, as long as it works. Would do others think on this "job queue" issue? --Ivan Štambuk 20:40, 10 February 2008 (UTC)

It's true that we're not supposed to worry too much about the job queue … but more generally, I think the wiki works better with "flatter" structures, such as a separate template for each language that needs it (and most probably don't), rather than one template that tries to know everything about every language. (That said, there are some cases where we've gone both ways; for example, {{lang:akk}} and {{t-sect|akk}} both produce Akkadian. The latter uses the former.) —Ruakh_TALK 21:01, 10 February 2008 (UTC)

But you said it yourself - each of those would have had to been created for anti-vandalism purposes. The template wouldn't have to know everything about every langauge, just for those using non-Latn script, which brings is down to ~ 30 actively used ones. {t-sect|akk} expands to {lang:akk}} via {{language}} in case you haven't noticed, so it's not harcoded, just optimized a bit for ~30 cases (if I not misunderstanding the code). It would be a good idea to do something similar here. --Ivan Štambuk 22:40, 10 February 2008 (UTC)

Re: "But you said it yourself - each of those would have had to been created for anti-vandalism purposes.": Nah, only those for commonly used languages. (I don't think {{MYVchar}} is a particular target for vandalism; at least, {{lang:myv}} isn't protected, and no one's vandalized it yet.) And anyway, since we're currently defaulting to {{Latn}}, it would be trivial to write a single bot run to redirect {{en-script}}/{{ENchar}} and so on to {{Latn}}, if we wanted to do that. —Ruakh_TALK 23:09, 10 February 2008 (UTC)

That bot redirects would still have to be protected by a human sysop, and the list of languages it would generate should probably be revised before creation, which makes it easier to create them manually in the first place. The list of languages that use Latn script is much more bigger than those who don't, and that makes it ideal to put the handling code for this exceptional core (~30 scripts used by at most as thrice as much languages) in a central dispatch place, which would be updated very rarely, and default other ones to Latn. I'll wait until March when Unicode 5.1 becomes official and get back to this discussion with some code. --Ivan Štambuk 23:56, 10 February 2008 (UTC)

Well, a bot acting as a human sysop can protect pages if there's consensus for that. But anyway, you seem more definitely opposed to my approach than I am to yours (and I can't pretend your arguments are flawed), so I'll concede this one. I've started {{lang2sc}}; obviously it's woefully incomplete so far, but that's what collaborative editing is for. :-) —Ruakh_TALK 02:13, 11 February 2008 (UTC)

I don't think that the use-with-mention span is really necessary since very few are interested in having the definition line itslef italicized. We only need a mention-def span or something. So I've altered Template:form of such that {{form of|word}} will wrap only the term itslef. For the time being it's backwards compatible with {{form of|form|word}} when word is the same as the link title. Where they are different then the old implementation supercedes my changes, i.e. it's not yet possible to do {{form of|word|link}} but {{form of|form|word|link}} still works. If everyone agrees that this is simpler, I would like to request that a bot go through and change

{{form of|Form|...}}

to

Form {{form of|...}}.

or more carfully checking the other parameters for various cases (esp. nodot and a different link title). After that we can knock out the backwards compatability. DAVilla 00:06, 11 February 2008 (UTC)

I'm not at all sure I understand what you are proposing, and think specific examples would help to clarify. If I do understand what you mean, then I object. The span format was the result of community discussion to allow personal customization in how those sorts of "definitions" are displayed. Removing the span would eliminate the customization. However, as I say, I don't think I fully understand whatever it is you intend. --EncycloPetey 18:43, 12 February 2008 (UTC)

The idea is that we would span only the term itelf, but not the entire definition line. So it would be possible to customize as:

1. Plural of shoe.
2. Plural of shoe.
3. Plural of shoe.
4. Plural of shoe.
5. Plural of SHOE.

But it would no longer be possible to customize as:

1. Plural of shoe.
2. Plural of shoe.

To my recollection, italicizing the definition line was initially seen as a good idea, one that I supported, but one that was dropped when it became clear that the use-mention distinction was too pedantic and that some foreign-language entries would be difficult to read with multiple long lines of italic text anyway. If there's anyone who still supports it then we could use a different template from form-of to apply to that distinction, since it's applicable to a much broader range of definitions. Otherwise it's much simpler to just drop it. DAVilla 22:26, 12 February 2008 (UTC)

That does not agree with my recollection. As I recall, people did want the "defnition" line italicized (or to at least have the option) because these are not (technically speaking) definitions. I include myself in the number of people who do want to maintain a distinction between definition lines that are definitions versus those that are "form of" messages. For one thing, this allows me to see whether a template has been applied to the page. For another, it allows me to determine whether I have a definnition or a form (see weeds for a page that has both). Based on recent conversations, I know that a number of other people still consider the distinction an important one to maintain. --EncycloPetey 22:46, 12 February 2008 (UTC)

I also want the definition line italicized. And I would like a {{form of}}-like template that could be used for any non-gloss definition, and would provide a CSS hook. —Ruakh_TALK 00:12, 13 February 2008 (UTC)

I don't get the misspelling joke with defnition/definnition. Are you saying it isn't a definition, or are you making fun of recollection?

Do you want a template to italicize any use-mention distinction, or do you want it solely for form-of lines, as it applies now? If the latter, I'll just roll back the changes. DAVilla 00:52, 13 February 2008 (UTC)

The "definnition" was a typo. Just the latter. We have templates like {{term}} that can be used for use-mention distinction already. The {{form of}} (as per its name) really ought to apply only to form-of lines, but should preserve this use-mention distinction in the way it formats the description of the term's form. --EncycloPetey 02:23, 13 February 2008 (UTC)

So would it be acceptable to you to use something like

{{term|Somewhat inflection of}} {{form of|word}}.

or

{{form-def|Somewhat inflection of}} {{form|word}}.

to accomplish the same thing? (The proposal wouldn't change the behavior of any other form-of templates other than the one in question.) Although it would still require more thought, this might be useful if we wanted to allow use-mention distinction in other types of definitions, but fairly useless otherwise. DAVilla 18:52, 16 February 2008 (UTC)

But wouldn't that break the categorization? The point of templates like {{plural of}} and {{past of}} is that they (a) shorten the verbiage needed to enter the template, (b) standardize the text displayed, (c) automatically categorize the page when the lang= is included. What you are suggesting would end all three advantages of the current templates. --EncycloPetey 21:28, 16 February 2008 (UTC)

I plan to standardize all entries on symbols for SI units of measurement with the above template (based on one used on French Wiktionary), unless anyone sees a problem with that. Cheers! bd2412 T 04:44, 13 February 2008 (UTC)

Looks like a good idea to me. --EncycloPetey 04:53, 13 February 2008 (UTC)

This template is just for the symbol entries. We could use a comparable one for the actual unit entries (e.g. kilometer vs. km). French Wiktionary does it all with one template, but I find their template confusing (and it always has too many moving parts for the job at hand). bd2412 T 05:01, 13 February 2008 (UTC)

Um, there was a problem with one or two of the chosen forms in the past. I can't tell which format you are aiming for. Is km your "before" or "after"? Can you link two diffs, please? --Connel MacKenzie 01:08, 14 February 2008 (UTC) (edit) 06:29, 14 February 2008 (UTC)

I don't think we should introduce any US vs. UK bias into it. It should be made to have a "|word2=" or something. --Connel MacKenzie 06:29, 14 February 2008 (UTC)

See Ys for an "after". Regarding bias, you mean with metres and litres? Fortunately, most units of measurement (joules, grams, kelvins, etc.) don't have that division. I would welcome the addition of the appropriate code for those special cases (or perhaps, since there are over 40 variations for meter and litre, a separate template should be used). I also note that the template is set up to indicate amounts as being in the singular - is it improper to say a kilogram is 10³ gram, or must it be 10³ grams? bd2412 T 06:47, 14 February 2008 (UTC)

I meant to say "an optional" parameter (easy enough, right?) Yes, saying "10³ grams" is correct. --Connel MacKenzie 06:50, 14 February 2008 (UTC)

I have radically altered the wording of the template to include a link to Appendix:SI_units and have added support for alternative spellings (though I don't think it is necessary nor aesthetic however it is done). {{SI-unit|kilo|meter|length}} vs. {{SI-unit|kilo|meter|metre|length}}. I strongly support its use, though someone else may want to improve it further. Conrad.Irwin 11:39, 14 February 2008 (UTC)

Shouldn't it be {{SI-unit|kilo|meter|length|metre}} - the vast majority of units (by which I mean hundreds of them) have no spelling dichotomy, so the option to reference an alternative spelling should be in the background. bd2412 T 17:06, 14 February 2008 (UTC)

• Or, as I also suggested above, we could just put up a separate template for the two base measures with a split spelling, worded to accommodate the dichotomy. bd2412 T 17:11, 14 February 2008 (UTC)

Another problem: some base units are not plurable (namely siemens and hertz) so we can't add an "s" to the end of these. Given the limited numbers, I would again suggest an alternate template, so we would end up with three templates: one for unremarkable SI units, one for those with the liter/litre dichotomy, and one for those that are not plurable. bd2412 T 17:40, 14 February 2008 (UTC)

Solves it just fine. Template:SI-unit for regular cases, Template:SI-unit-np for non-plurables, and Template:SI-unit-2 for the dichotomous. bd2412 T 18:08, 14 February 2008 (UTC)

Now that all that is dealt with, what is the difference between μ and µ? bd2412 T 20:45, 14 February 2008 (UTC)

μ is GREEK SMALL LETTER MU, U+03BC, µ is MICRO SIGN, U+00B5. Unicode has some different codepoints with different names but identical glyphs for compatibility with older standards. (lookup by the UTF-8 from the URL at http://www.eki.ee/letter/ ) Cynewulf 21:03, 14 February 2008 (UTC)

In that case, barring objection I shall redirect all the µ symbols to μ symbols. Cheers! bd2412 T 22:04, 14 February 2008 (UTC)

On second thought, perhaps they should all be put down as alternative spellings - certainly people are as likely to use µ as μ, and people handwriting it won't differentiate. bd2412 T 22:16, 15 February 2008 (UTC)

This was deleted last time, but I couldn't find a reference to the RFD using the MW search. Is there a reason that we don't have a template {{quote}} that allows us to output

* '''year''' Author ''title''
*: Text of quote here

or something that is preferred? Or have I not noticed the one that we do have... Conrad.Irwin 15:42, 14 February 2008 (UTC)

We do have {{cite meta}}, which as its name implies was intended (by me) as a rack to hang more specific templates on, such as {{quote-book}}. However, it's not entirely clear whether this is considered a good or even tolerable thing.  :-) See WT:RFDO#Template:cite meta. -- Visviva 15:53, 14 February 2008 (UTC)

NB: weird things happen when trying to render bullets at the beginning of a template; or at least they did, for me, in the past. For this reason I've always found it necessary to put the initial bullet or indent outside the template itself. Tim's preprocessor rewrite may change this, or it may just be that I was making a foolish mistake of some kind. -- Visviva 15:55, 14 February 2008 (UTC)

... Special:Whatlinkshere is a wonderful tool for this sort of thing. BTW, the general issue of quote templates was brought up at Wiktionary talk:Quotations a while back as well. There seems to be an inertia on the matter that I don't understand. (I mean, seriously, who has the spare time and neurons to keep track of all the formatting minutiae in WT:QUOTE?)-- Visviva 16:05, 14 February 2008 (UTC)

Having a template for the year, author, title, and page number only, with no *, :, or quote text, would be useful, I think. Similar to {{RQ:Shakespeare Hamlet}}. Cynewulf 21:07, 14 February 2008 (UTC)

Strongly agree. bd2412 T 22:06, 14 February 2008 (UTC)

{{quote-book}} does this; I can enter *{{quote-book|en|year=1937|author=J.R.R. Tolkien|title=The Hobbit|page=1}}, to get

• 1937, J.R.R. Tolkien, The Hobbit, page 1:

  and then I can write the quoted text down here.

Of course, for interlineal citations it makes more sense to just include the quoted passeage in the template so as to minimize formatting hassle, but there seems to be some resistance to this. -- Visviva 03:11, 15 February 2008 (UTC)

But will it allow links? What if we wish to link the author to his Wikipedia article, but the Wikipedia article name for the author is different from what a sane person would want to display? (some people are disambiguated; some include their titles to disambiguate) What if I'd like to link to the Wikipedia article about the book (whose name could have similar issues)? How do we indicate that the page number is for a particular edition, and not necessaily the same as the original edition (whose year will still be important)? And this is just for a "simple" book! --EncycloPetey 03:23, 15 February 2008 (UTC)

There are several very good reasons we don't have a quote template. The most important reasons are: (1) we have never agreed on a standard format, and (2) There are too many possible ways in which the information may need to be entered into such a template. The template would make data entry much more complicated that it is now unless the template itself were very, very complicated.

Consider that we want to link to our sister project Wikisource, but the name of the source text and the pagename on Wikisource often are different. Consider that sometimes the quoted source is a translation from another language, and we have to include the author, original date, translator, and translation date. We don't just cite one kind of source either. We have to accomodate citations for poems, essays, speeches, multi-volume works, scientific papers, newspapers, plays, inscriptions, manuscripts, and religious texts. Each of these has a different format for citation with several possible variations.

In other words, we either end up with a hideously overcomplicated template that noone will want to use it, or we end up with so many separate templates that no one can remember which one to use in each situation. Unless someone is willing to code a single, elegant, multipurpose template that accommodates a WIDE array of source types with all the necessary info, I would oppose instituting any templates for quotations. --EncycloPetey 23:20, 14 February 2008 (UTC)

1. There doesn't seem to be a lot of disagreement about WT:QUOTE, although it is still substantially incomplete. It is certainly being enforced as a de facto standard across many entries, and no one seems to have a serious problem with it. Even if we wanted to change WT:QUOTE in the future, having a template would actually make such a change easier, since we wouldn't have to go through and revise all of the entries by hand. 2. Well, of course we need multiple templates, although there is no reason they couldn't all refer to a single meta-template that would reflect basic formatting requirements and insert CSS classes. In terms of template structure, I really think we couldn't do better than to model them on w:Category:Citation templates, obviously modifying them to fit our formatting conventions and needs. 3. Handling pipes is really no more of a problem than it is in raw wikitext.

:*{{quote-book|en|year=1913|author=]|title=]}}

yields:

• 1913, L. Frank Baum, The Patchwork Girl of Oz:

...which shouldn't be too problematic. -- Visviva 03:11, 15 February 2008 (UTC)

...except that you've already shown the first problems. (a) The chapter number doesn't show up. (b) Personally, I think the title of a work should always link to the work's primary page on Wikisource. Part of the reason I feel this way is that several times I have seem them restructure source text pages -- I've seen pages split or combined, and I've seen the way subpages are labelled change completely once already on that site. And I have serious problems with the way that Wikipedia does its citation templates. I've tried to get help from people over there to fix formatting problems and extend usability to cope with sources that don't fit their current templates, but no one there has ever been bothered to assist. Please don't say "we can't do better than Wikipedia" because that's just depressing to hear. In any case, your example is merely a book with a single author, divided into chapters (but not sections) and without any of the other potential problems I've noted above. For the quotations I've added over the past two years, It would suffice for only about half of them, which isn't all that useful. That;s aside from the other problems I noted at the outset of my comment.

Please don't post individual simple examples and pretend the problems don't exist. We've already had people complaining and wondering about whether we even allow non-books to be cited here. Given the discussion by others so far in this thread, I can understand why some new users think we only allow citations from books. --EncycloPetey 03:20, 15 February 2008 (UTC)

Certainly problems exist; I put together {{quote-book}} mostly as a proof-of-concept and it doesn't yet handle difficult cases terribly well. However, I do use it to cite chapters in edited volumes, translations, etc., and have found that it works adequately, but it certainly needs to be improved. I deliberately simplified the example, but I would normally use the template like this:

• 1913, L. Frank Baum, “Chapter 7”, in The Patchwork Girl of Oz:

Of course this could be improved (there shouldn't really be quotes around "Chapter 7," for example), but it seems to convey the necessary information adequately. I didn't put a lot of work into the template at first because I wasn't sure, based on the conversations I had read, whether it would be accepted at all. And I'm still not sure, which is depressing and demotivating. I'm not terribly interested in working on tools that will simply be ignored or deleted. On the other hand, citation work is tiresome and for the most part thankless, and having a set of standard templates for the commonly used sources (quote-newspaper, quote-magazine, quote-journal, quote-newsgroup, quote-movie) would make this work much less draining. Problems exist, as they always will, but they can be addressed through improving existing templates and creating new ones.

I don't mean to suggest that we can't do better than Wikipedia; of course we can, particularly since our needs are different, but it wouldn't make sense to ignore the enormous amount of work that has been done on WP to solve very similar problems. -- Visviva 08:01, 15 February 2008 (UTC)

I was thinking of something 'much' more simple, that just put in the right apostrophes, commas and dashes. I would like to be able to write The template Template:blockquote does not use the parameter(s):

4=chapter 14

Please see Module:checkparams for help with this warning.

1234

—Enid Blyton, Five on Kirren Island

and for it to format it nicely - though the last argument could possibly of the form chapter= or page=, etc. Conrad.Irwin 15:51, 15 February 2008 (UTC)

Well, {{quote-book|en|1234|]|Five on Kirren Island|section=chapter 14}} yields

1234, Enid Blyton, Five on Kirren Island, chapter 14:

Personally, I've shied away from using numbered args because I lose track of the correct order; but they do save some keystrokes. -- Visviva 16:01, 15 February 2008 (UTC)

For a more challenging example, how about this from go off the reservation (I had to tweak the templates a bit, as previously I hadn't really worried about providing all of this information):

1. (blah blah blah).
   • 1960 January 31, Harry S Truman, “Dear Joe”, in Monte M. Poen, editor, Strictly Personal and Confidential: The Letters Harry Truman Never Mailed‎, published 1999, →ISBN, page 137:

     I'll never forget 1948 when these so called "liberals" (synthetics I call them) went off the reservation and gave New York to Dewey.

I'm sure this still isn't quite ideal, but does it seem to be moving in the right direction? -- Visviva 16:01, 15 February 2008 (UTC)

No, because it doesn't begin to address the linking problems with our sister projects. --EncycloPetey 00:14, 16 February 2008 (UTC)

Huh? What linking problems? The link to Wikipedia seems to work OK. What links do you think should be there? -- Visviva 02:54, 16 February 2008 (UTC)

Or do you mean that the example does not address the problems you see as important? Is the one I put on the (rfd'd) 5th sense of ripe any better? If not, could you give an example of a book citation that you see as presenting problems for this approach? -- Visviva 07:00, 16 February 2008 (UTC)

I'm talking about the same linking problems to sister projects I mentioned before. I'll explain again: In order to link to the Wikipedia article on an author, we have to use the exact pageneme from Wikipedia, even if an expanded or contracted form of the article name is preferrable. Consider w:A. E. W. Mason, whose full name is Author:Alfred Edward Woodley Mason. The current template forces us to use the abbreviated form of the name if we link to Wikipedia. The same applies to w:C. K. Scott-Moncrieff / Author:Charles Kenneth Scott Moncrieff. The reverse situation applies to w:William Strong (judge), where the wikipedia article forces us to use parnethetical text to complete the appropriate link. We don;t want to display "(judge)" as part of the person's name, but that parenthetical text is necessary in order to link to the Wikipedia article. There are also situations I've run into before (though I can't find an example at this moment) where the Wikipedia article is named something like Charles Edwary Lacey, 3rd Count of Montcrieffe (or even longer). Again, there is verbiage in such page names that we may not wish to display as part of the person's name.

Now, the way you've set up the author link may deal with these, but the same problem occurs when linking the Wikisource. There are works whose titles as recorded on Wikisource are either much longer than is needed, or which include linking code we don't want to display. Examples of the former situation include some of the plays of William Shakespeare. Although Wikisource uses familiar titles like Measure for Measure, for the histories and tragedies the full original titles are used, like s:The Tragedy of Hamlet, Prince of Denmark (even though Hamlet is sufficient and expected) or s:The Second Part of King Henry the Fourth (even though Henry IV, part 2 would be appropriate for Wiktionary). As an example of the latter problem of unwanted linking code, you only have to look at the various translations of the Bible, such as for the King James Version. In order to link to the KJV book of "Luke", the link is s:Bible (King James)/Luke, which is awkward to display as a source name for a work.

Unfortunately, simply fixing the title link won't completely solve the problem. First, it leaves the question of linking a chapter or section of a work (although I personally think doing that is a bad idea for reasons previously mentioned). Second, it might not allow the alternative of linking the work's title to Wikipedia, which may be desirable when WS does not have the document (possibly for copyright reasons) and we would like to link to the Wikipedia article about the work instead, so that further information and content about the work is available. --EncycloPetey 16:44, 16 February 2008 (UTC)

All of the problems with links go away if you ask the user to put the links into the template parameters, as you have so eloquently argued the template cannot guess the link target, and thus the user must supply it. What I would really like is a way to include the text in the template as well, though from experimenting it seems that this is not trivial with MediaWki. Conrad.Irwin 16:51, 16 February 2008 (UTC)

You're right that these are important issues, which is why I've written the template to simply leave them to the user for now. That is, at present {{quote-book}} just passes author/title/section/etc. exactly as supplied by the user, so the problems shouldn't be any more (or less) severe than when not using a template. If users want to save keystrokes and enter author=], they can; if they want to take the time to enter author=], that will also work just fine. I don't think a template should take over these matters until we've reached some consensus on exactly how we would want these links to be formatted. My intention with {{quote-book}} (and hopefully with similar templates in the near future) was simply to provide a labor-saving way to generate quotations that look exactly as they would if formatted directly in wikitext. -- Visviva 08:34, 21 February 2008 (UTC)

Handy links: User:Conrad.Irwin/feedback.js, WT:FEED, MediaWiki:Monobook.js, PHP on toolserver.

With >30k anonymous visitors per day, we have an enormous pool of people able to give constructive feedback. Based on an e-mail I got yesterday, I'd like to create something like this for pages:

 (*) Excellent entry
 ( ) Too much info; gimme definitions only
 ( ) Doesn't match other dictionaries
 ( ) Mistake in definition
 ( ) Entry title is a misspelling
 ( ) Wrong translation
 ( ) Too hard to find
 ( ) Other

I assume that the way to accomplish this is with Javascript adding the "feedback" box somewhere, then saving the results on toolserver (&page=${wgPageName}) with just a radio button. Eight options is probably way too many though. (Perhaps open a list of 50 possible complaints if they click "other"?) Before I run off experimenting with a way to do this, I'd like some feedback (ahem!) on whether this is a desired feature. (It seems obvious to me, but I'm getting used to surprises!) --Connel MacKenzie 19:41, 14 February 2008 (UTC)

I think feedback is an excellent idea, and I strongly support such a feature. I will admit it's possible that we won't have the manpower to go through all the responses, but that seems the worst case scenario (which really isn't all that bad). Atelaes 19:50, 14 February 2008 (UTC)

I have always wanted feedback from our users, but didn't know how to get it. Could we have one on the "not found" page so that we can add words people are actually looking for? SemperBlotto 19:55, 14 February 2008 (UTC)

Does no one have access to the http log? That'll give the same info.—msh210℠ 20:13, 14 February 2008 (UTC)

WMF policy (and German law?) prohibit access to those logs. The closest we get is "WikiCharts" when toolserver is running. --Connel MacKenzie 21:20, 15 February 2008 (UTC)

I like the idea of gaining feedback this way, as long as the survey is in the page, not a popup. If it's JS-based, then it can disappear from the page once users check a radio button and "submit". Do we want users commenting on entries or on the site? (If the latter, then (with cookies, I suppose) a user never needs to see the survey twice.) I think it should be relatively unobtrusive, though; perhaps in the left-hand column, above/below the "toolbox" (whatlinkshere, etc.)?—msh210℠ 20:13, 14 February 2008 (UTC)

I'm sorry - I said that wrong. I meant as a "float" section somewhere on the page, not an obnoxious pop-up. Making it go away after they've clicked is a neat idea. (We'd tell them they can "vote" as often as they like, right? Vote early, vote often?) --Connel MacKenzie 21:24, 15 February 2008 (UTC)

Amazon keeps it simple. Near the bottom the page, they ask: "Did you find what you want": y/n buttons. If you hit no, they ask for a full-text comment. They also offer a way to click to "customer service", which for us might be "info desk" and "requested entries". They have no way of getting back to most users, I don't think, so I think user expecations are low for these things. I would also expect less than 5% clicking even yes/no, let alone writing something <1%, let alone writing something useful <<1%. And I could be off by a factor of 10 ;)) (I'd be on the high side). 30 useful written responses a day? 3K y/n responses a day? OTOH, it would be a lot better than the nothing we now get from such casual users. With those volumes we could easily classify the long responses ourselves by hand for analysis by hand. Later we could get more automatic. DCDuring TALK 20:29, 14 February 2008 (UTC)

There is no way, that I'd write something that accepted free text comments for this. You are right, that there is no way to contact the person who commented, anyhow. No, what we actually need is a hit list of heavily-viewed entries that are "poor" (or missing) in the public's opinion. --Connel MacKenzie 21:20, 15 February 2008 (UTC)

Looks good. I'd prefer that if people see something wrong, they fix it, but if this kind of feedback is all we're going to get, there's not much we can do. Perhaps pages with lots of "it's not perfect" feedback from unique IPs could get flagged for work: Is this page perfect? Cynewulf 00:30, 15 February 2008 (UTC)

The pop-up would be: "Thank you for submitting that feedback. Now Fix It!"  :-)   --Connel MacKenzie 21:20, 15 February 2008 (UTC)

The 30k anonymous users must include many who lack the (over-)confidence to try to fix thing and the knowledge to make a net improvement. And we don't really want to clean up after them. We need to get input without inconveniencing them or forcing them to learn something, IMHO. We can probably scan it and decide what to do with it (mostly ignore, I'll bet) quite quickly compared to having to undo. DCDuring TALK 01:12, 15 February 2008 (UTC)

Actually, we do want many of them to pitch in and help. If they are willing to try to learn, we are willing to help them learn the conventions here. If we clean up after someone new, that means we have a new Wiktionarian. (It's a deceptively small - but very problematic - percentage that refuse to learn...) Balancing the desire to get feedback with the desire to encourage new contributors is tricky. If we've made it to hard for them to become Wiktionarians, we need to know it. If we've made it too hard for them to make small (but significant) changes, we need to know that, too. It would be great to know which problems people encounter the most (case sensitivity, form-of didn't have "lemma" info, found wrong word in another language, found a misspelling mislabeled as a valid alternate, desired translation was missing, Connel deleted my homepage, etc.) so that we can address the concerns in a methodical manner. --Connel MacKenzie 21:55, 15 February 2008 (UTC)

I am fully in favor of getting users to tell us what they are thinking. - DaveRoss 00:34, 15 February 2008 (UTC)

How about a button that takes them to an "Wiktionary needs your feedback" kind of link to Wiktionary:Feedback?action=edit&section=new with a preloaded template and some instructions? though this may put some people off unless they need to do very little by default. Conrad.Irwin 00:35, 15 February 2008 (UTC)

I'd be a little concerned about disorienting users by "taking them away" from where they are or delaying them, but I'm no UI designer. DCDuring TALK 01:12, 15 February 2008 (UTC)

As I said above, I'm very hesitant to ask random readers to type anything. If they can't click it, it is too complicated. If it is too detailed, we can't use it. I guess we could have a "enter comments" thing that could open a (&section=new) new section of WT:ID or something. Actually, it would have to be a separate Wiktionary:Feedback page, as the comments would be so random. But that would be stupid. When I click on a "feedback" form on a random website, I have the expectation that my comments will not be made public. Soliciting their comments on WT:FEED would require them to submit their feedback in accordance with the GFDL (for many, perhaps, negating their willingness to do so.) If it's checkboxes or radiobuttons saved on toolserver, in a user-database, we can perhaps do something useful with it. But if it requires GFDL compliance, we'll lose a significant portion of the feedback. --Connel MacKenzie 21:20, 15 February 2008 (UTC)

Response rates for these things are astonishingly low, even with simple yes/no buttons. Response rates drop the more complex the task and the smaller the visual target. Limiting length of comment to 250/500/1000 characters seems typical for free text. I'd be amazed if we got more than 100 comments a day, as opposed to yes/no. Forcing the answers into a limited, fixed set of reponses limits what we can learn. Over time we could provide subject-line type classification. I doubt if Amazon (and others) are doing it this way because it is a bad idea. Why reinvent the wheel, when we can copy it?

Let's say we got "too many" responses. It won't be so many to overload the hard drives. Users don't expect responses. The worst that happens is we throw away the responses unanalyzed. How long between updates of the software that would run this feature? DCDuring TALK 23:50, 15 February 2008 (UTC)

You totally misinterpreted what I meant by "too many" so I'll take the blame for my poor wording and try again. We have 75 sysops. We have <300 regular contributors (that edit 50 pages or more per month.) If 1% of 30,000 commented once a day, we're kinda screwed. But if 5% tell us that foobarbaz is a crappy article by clicking a radio button, then we can see it and we can fix it (the entry they complain about.) --Connel MacKenzie 00:32, 16 February 2008 (UTC)

My original question was worded in a programming-language/platform agnostic manner to allow anyone to volunteer. Presumably, like WikiCharts, it will only be turned on for anon-IPs, so there shouldn't be privacy issues...but I'd be uncomfortable if it wasn't done on toolserver (or at least planned to migrate there once someone's new account is approved.) --Connel MacKenzie 00:32, 16 February 2008 (UTC)

Yes, it's true. I totally misinterpreted (or did I even read?) your comments. Not your fault. Sorry.

As to quantity of full text, we won't get 5% - 1% to click on a yes/no button. Of those who click no, say, 50%, given the chance to type something, I'd bet on 25% starting to type, and 80% of them bailing out. This would lead to fewer than 100 responses to read, many of which would be unusable.

Estimating (WAG) for eight radio buttons that we would get 1% - .2% response from 30K, that would give us 3000-600 responses per day. If we guessed right about the 8 choices, we'd be happy, I guess. One of the choices better be none of the above. Perhaps we should at that point invite folks to comment somewhere publicly.

As to the GFDL issue, has WMF ever spoken on this question? I am aware that they intend to do some kind of survey, but I don't know how. If it is completely separate, then it's largely irrelevant. I understand that we could post them a question. but we should have a well-formulated question before doing so. DCDuring TALK 01:05, 16 February 2008 (UTC)

Connel and I had a bit of a hackfest this morning and we have the bones of a working feedback tool. If you want to turn on a test version, add importScript('User:Conrad.Irwin/feedback.js'); to Your user javascript and we should all update that as we see fit (I don't mind other people hacking Javascript in my userspace). Feel free to click the links as they do not have any effect (they pass a test parameter to Connel's php api). We now need to discuss specifics: Conrad.Irwin 12:27, 16 February 2008 (UTC)

Great! As much info as we can hope to get by clicking and option for comment. It took me a while to realize it was there, which could help limit volume of comments to read. If it doesn't generate enough, are there ways of making it more visible, like moving it above the toolbox? Would it even be possible to have it appear in the white space on the top right of every entry (instead of or above WP box!) ? If that wouldn't get feedback (preferably NOT free text in that location), nothing would. DCDuring TALK 14:20, 16 February 2008 (UTC)

Will we know what page the user was on when leaving the comment? DCDuring TALK 14:23, 16 February 2008 (UTC)

Yes, the page name is also recorded - in theory we can move it anywhere - Connel said that down near the bottom would be good to start with, as you say above. Conrad.Irwin 16:35, 16 February 2008 (UTC)

I noticed your "newNode" stuff, so I thought I'd point out this: User:Mike Dillon/Scripts/easydom.js. Not sure if you had seen it. There are a bunch of example of using it under User:Mike Dillon/Scripts. Mike Dillon 16:18, 16 February 2008 (UTC)

I like the look of those, newNode was something that I wrote a while ago for something else, and as I was monotonously typing away at the DOM function I remembered. I assume that most Javascripters have written a tool like it at some point ;).Conrad.Irwin 16:35, 16 February 2008 (UTC)

What options should be presented as quick click-throughs, here are a few I thought of on the fly. Conrad.Irwin 12:27, 16 February 2008 (UTC)

• Perfect
• Don't hide translations
• Hard to find defintions
• Too messy
• Use enPR instead of IPA

  This would only be relevant to English entries. -- Visviva 13:11, 16 February 2008 (UTC)

Any statistics book with a section on sample bias would point out that the wording above is not neutral, and will therefore present skewed results. --EncycloPetey 16:16, 16 February 2008 (UTC)

I'm sorry, but I must strongly disagree with the notion that these even should be neutral. Too much bias will throw a regular poll off, but we are looking for specific items to clean up, here, not taking a political poll. Initially, I think we want rather harsh wording, to encourage more clicks and hit up the real problem spots. I envision this changing daily or weekly though, as new concerns are added and old ones forgotten. But please remember that these should be a little biased, in order to generate feedback. We aren't taking a poll of "is Wiktionary better than 'X'," we are asking people to identify things that threw them off. --Connel MacKenzie 02:00, 17 February 2008 (UTC)

I am well aware they are not good at all, I intended them to be food for thought. I did then think perhaps a better idea would be to have a number of questions(on some kind of random cycle) and then provide several possible answers (or a rate from 1 to 5) - this would allow us to get more specific feedback and I think will be more practical than trying to ram an enormous survey into the box. Conrad.Irwin 16:25, 16 February 2008 (UTC)

This data cannot readily be made to give us a benchmark assessment of "how we are doing", IMHO. Sample bias (self-selection) already would keep it from being readily interpretable for that purpose. We shouldn't handicap ourselves by even bothering in that area. We are trying to locate areas (entries, layout, etc.) for improvement. Perhaps, eventually, when we have had a stable set of questions, stable location, and a stable user base, we could look for trends in user perceptions. DCDuring TALK 17:22, 16 February 2008 (UTC)

There has been a lot of talk about getting the feedback of readers not just editors, as they make up a large proportion of Wiktionary users. The current 'poll' of "Good/bad/Messy/Confusing" was run for five minutes earlier today eliciting two responses - so some good buttons to be clicked would be very useful. As I am a computer scientist at heart I am not good at communication skills, and I would really appreciate it if someone else could suggest a few things that people might want to click on. The current format looks something like this, it is not good: please suggest ways in which it can be improved. Conrad.Irwin 00:59, 17 February 2008 (UTC)

If it is easy to turn on and off, we could ask different questions at different times about overall experience Wiktionary. Tge placement we ha$ve seems to me to "belong" to Wiktionary as a whole rather than to any one entry. Maybe we should try both classes of questions: one week (?) of questions targetted at the entry, one week of questions about more general things such as user demographics, historical experience with Wiktionary, overall evaluation of the site, etc.

Illustrative questions sets (check boxes, multiple answers for most):

Which features do you use generally at Wiktionary/Which features did you use this time?

Etymology, Pronunciation, Wikipedia links, Wiktionary entries, Synonyms, Translations

What are you looking for?

Etymology, Pronunication, Synonyms, Links, Examples of usage, Definition, Translation, Other

How many pages did you visit this time?

1, 2 , 3-5, 6-10, 11-20, Too many

How did you come to Wiktionary this time ?

Wikipedia, Google, Other search engine, Other, Don't remember

How would you describe yourself?

Student, Teacher, Writer, tranalator, Other professional, other

For what do you use/are you using Wiktionary ?

School, Non-school reading, Writing, Other work-related, Curiosity, Other

Have you ever used?

Wikipedia, Urban Dictionary, Merriam Webster Online, OED online, Other online dictionaries

Have you ever used?

Audio pronunciation, Synonyms, Related terms, Categories, Translations

Have you ever tried to?

Ask a question, Request an entry, Make a correction, Enter new definition, Start new page, register as user

It's easy to come up with question sets. These are all first drafts. The real question is: What decisions are we trying to make now that would benefit from the feedback. DCDuring TALK 03:27, 17 February 2008 (UTC)

AS far as I can see there are murmurs about how our format can be improved, the recent topic "Alternative spellings take up too much real estate" following on from the vote about "Homophones" as an alternative spelling shows that we are not really united in our entry layout, and I certainly think it can be improved. Some of the questions above I like, others I don't really see the point of.I very much like the idea of changing questions randomly - and it is fairly easy to do. Given the current system it is much easier for us to have questions that only have one "most correct" answer, though I am sure we can work out a way to give multiple answers too. The most important questions are (in my opinion) "What do you use Wiktionary for: Checking spelling, Defining words, Grammar tables, Pronunciation, Synonyms/Antonyms, Word history/trivia." and "How could we make Wiktionary easier to read: Making the definitions more obvious, removing information from entries, unhiding all the translations, hiding more things." As there is no limit to the number of possible questions, I reckon we should start it going and add/remove more questions as and when we wish to. Conrad.Irwin 11:31, 17 February 2008 (UTC)

We could always keep asking a question until we either get an answer or know that we aren't going to get an answer. If we get one response every 10 minutes, that's 144 answers per day, a thousand answers in a week. We're likely to know where we stand by that time. Out protocol could be something like: run a question for a day; see whether the answers, esp. the comments, suggest a problem with the question set; and then correct the problem and try again untilt we have a good question set, then run the questions as long as the value of the additional day of info is worth delaying the answer to the other questions we have. DCDuring TALK 12:11, 17 February 2008 (UTC)

Questions that are focused on an individual entry would be better if they were not in that side panel, but it would be worthwhile to see whether we could get good feedback on specific articles by trying it out with questions that are focused on the specific entry.

For example: Find what you were looking for ? Y/N; Find it right away? Y/N. DCDuring TALK 12:11, 17 February 2008 (UTC)

• OK, I take it back. Either EncycloPetey is right, that the skewed wording throws it off too much,' or a lot of people think Wiktionary sucks. --Connel MacKenzie 20:16, 17 February 2008 (UTC)

• Don't take it personally. Even when all you have to do to is click a link, people with negative opinions are more likely to leave feedback than people with positive opinions. —Ruakh_TALK 20:28, 17 February 2008 (UTC)

• Ruakh is right. There is no wording that would make us immune to the likelihood of getting negative feedback. This is unlikely to be a "feel good" exercise. It's just a chance to get better. It's a similar impulse to the vandal impulse, I think. It caused me to make some new entries based on immunoFISH that put us "ahead" of WP. How many "ratings" do we have so far?

Should we allow users to add text comments, if so where should it be? I think we should allow users to add comments to Wiktionary:Feedback or some other such page. Conrad.Irwin 12:27, 16 February 2008 (UTC)

As to privacy, doesn't WMF have a facility to handling such comments without them having to be "published" and be part of GFDL? Is it OTRS? We could have wiktionarians be part of that to handle that specific source of e-mail (I think they mainly handle public e-mail). Perhaps we should just offer users a private-communication option? Or give user option of giving e-mail address so we could contact them or notify them of entry improvements. DCDuring TALK 14:01, 16 February 2008 (UTC)

However that would mean that everyone who wants to see the results would have to be on OTRS, which isn't really feasible (though it would be good for recruiting ;) I don't like the idea of asking them to give us their email addresses, as people tend to ignore the mailing lists they sign up to (or I do anyway) it would be a bit of wasted effort. Conrad.Irwin 16:35, 16 February 2008 (UTC)

• Having user-entered comments on WT:FEED means that the users see the GFDL warning under the edit box, so I think that part of it is OK (i.e. still GFDL compliant.) But it will probably discourage most feedback that we want to use. I'd really like a thing in the Javascript that opened up 50 or so radio buttons. --Connel MacKenzie 18:32, 16 February 2008 (UTC)

I think, as the comments are anonymous there should be no problem with publishing the count on site, though we will have to be careful that we don't publish things that people have written without their consent. 12:27, 16 February 2008 (UTC)

Could we have a list of the pages with any negative comments for general viewing? It would seem like yet another improvement opportunity queue, better than many because of user-generated. DCDuring TALK 14:06, 16 February 2008 (UTC)

• Any query result are going to be available on toolserver only. Since the anon-IPs won't be entering their comments via the radio buttons, that part shouldn't have to worry about being GFDL or not. Since it will be purged regularly, (weekly? monthly?) there shouldn't be any weird privacy issues cropping up. If we don't allow results to be viewed if there are less than ten clicks...even less so. --Connel MacKenzie 18:30, 16 February 2008 (UTC)

I've turned this back on for anonymous IPs again. Last test had result frighteningly soon, but this time of day seems calmer (or perhaps the moderate rewording helped?) Testing feedback is appreciated. Still problems with IE being worked out, but FF (et al.) should work fine. --Connel MacKenzie 01:31, 17 February 2008 (UTC)

Preliminary results:

cmackenzie@hemlock:~$ grep "cmackenzie/feedback" /var/log/apache2/access.log | wc -l
141
cmackenzie@hemlock:~$ grep "cmackenzie/wotd-rss" /var/log/apache2/access.log | wc -l
835

The logs are "logrotate"-d daily, a couple hours before I did this check. So, it looks like a fairly rabidly popular feature, (by comparison to the ridiculously popular RSS feed.) I guess we should have done something like this a very, very long time ago. --Connel MacKenzie 18:23, 17 February 2008 (UTC)

It's a great relief to me that the full text isn't generating too many responses, not too much utter nonsense, and some constructive stuff that the users didn't seem to want to do themselves (lack of confidence in item or in editing skills or not noticing edit tab?). That means we could consider trying to increase response by moving it up the screen on a slow day after we've had a week or two of experience with this placement. Only 3-4% of total responses take advantage of full text. DCDuring TALK 21:01, 17 February 2008 (UTC)

I think we need a very aggressive archiving scheme for WT:FEED. I think moving the "feedback" stuff to the bottom-center would be the single-most intuitive place for it. --Connel MacKenzie 21:50, 17 February 2008 (UTC)

• TheDaveRoss had about 1/2 dozen really good suggestions for the PHP/mysql components, most of which I implemented. He also has about 500 other suggestions, so I told him to f*** off do it himself. So the script will move from http://tools.wikimedia.de/~cmackenzie/feedback.php to http://tools.wikimedia.de/~daveross/feedback.php sometime very soon, now. The first two day's responses are probably best simply discarded, allowing him to start clean. --Connel MacKenzie 21:50, 17 February 2008 (UTC)

hello, I recently added a redirect for waht I thought was a common type of mispelling, failure to capitalize within a hyphenated word. I was then sent a message stating that wiktionary does not use redirects and that the entry had been deleted. Since I obtained the format from another redirect, I know that wiktionary does this sort of thing ater all and wonder why this one was REALLY considered inappropriate, and what are the guidelines for redirecting. TRKritzer

Hi there, the redirects that we do have are mainly left over from a conversion script that made Wiktionary case-sensitive, those are being systematically deleted by Robert Ullmann in bot mode. The reason that we do this is that it is entirely possible that a word has different meanings with different capitalizations cat and Cat for example. The other thing is that different spellings can have different information about them, and particularly for misspellings it would be very misleading if someone types in a misspelling and gets the information out as though it was correct. Thus soft-redirects, which can be generated using {{misspelling of}} or {{alternative spelling of}} instead of a definition should be used instead (see lepper for an example). Conrad.Irwin 15:10, 15 February 2008 (UTC) PS. please sign your posts on talk pages with ~~~~.

There are a lot of redirects around, but most of them should be deleted (or will be eventually) for the reasons described by Conrad. -- Visviva 07:10, 16 February 2008 (UTC)

Said EncycloPetey earlier: "There is a potential problem with using {{a|la|Classical}}, however, since many languages have a "Classical" period and might want to use the same accent header for a pronunciation line. This might be an issue for the WT:GP; someone there might be able to code this so that the language can be specified as an argument."

Can anybody do this? Harris Morgan 00:08, 16 February 2008 (UTC).

More specifically, can {{a}} be set so that {{a|la|Classical}} specified Classical Latin, and so that the template could be similarly expanded for other language periods for which there is no ISO code? (eg, Medieval, Ecclesiatical)--EncycloPetey 00:12, 16 February 2008 (UTC)

I think encouraging it to display as if it were a valid language, will mislead people into thinking "Classical Latin" might be valid elsewhere within Wiktionary, which it is not. The free-text portion of it should just remain free-text. --Connel MacKenzie 00:45, 16 February 2008 (UTC)

What is the free-text portion? Harris Morgan 11:34, 16 February 2008 (UTC).

I'm asking it to display "Classical", just as it might display "RP" or "US", or any of the other parameters it currently might display. This template ({{a}}) is only used withitn the pronunciations section, so there is no real chance people will assume it is a separate language. I merely want the language argument in there so that, although it displays "Classical", it will link to a page about Classical Latin, and so that other Classical periods of languages can use the same template by having the specific language specified. The alternative is to not have "CLassical" link to anything at all. --EncycloPetey 16:14, 16 February 2008 (UTC)

I noticed for the first time today that Wiktionary:Privacy policy is found at the bottom of all the pages, and being a curious fellow clicked it. Not a very good page is it...Wouldn't it be better for whatever Mediawiki pages that includes it to link straight to the meta page? --Keene 00:12, 16 February 2008 (UTC)

Did you notice on June 1st, when the actual policy changed? Why do we need one more thing to try to keep in sync? The soft-link is better than mangling it (as was done previously.) --Connel MacKenzie 00:49, 16 February 2008 (UTC)

I have tidied up the wording to make it easier for non-WMFers, but it still points to meta. Conrad.Irwin 10:18, 16 February 2008 (UTC)

Yeah, that'll do--Keene 10:20, 16 February 2008 (UTC)

Connel, I think you may have misread Keene's suggestion; it looks to me like he's suggesting that the "Privacy policy" at the bottom of each page point directly to meta. We can do this, if we want, by creating MediaWiki:Privacypage with the content

meta:Privacy policy

. However, since readers might not expect the link to take them to an entirely different site, I'm not sure whether we should do this or not. (Maybe it should be mentioned at BP?) —Ruakh_TALK 16:50, 16 February 2008 (UTC)

Looking at http://wikimediafoundation.org/Privacy_policy I think we are supposed to do this, so unless anyone objects I will... Conrad.Irwin 17:55, 16 February 2008 (UTC)

Done. Conrad.Irwin 00:51, 17 February 2008 (UTC)

O.K., cool, thanks. —Ruakh_TALK 14:47, 17 February 2008 (UTC)

I think the links at the top of the page in Wiktionary:General disclaimer should be linked straight to the relevant Wikipedia page, and not to our soft redirect Wiktionary:Medical disclaimer and Wiktionary:Legal disclaimer pages.

I thought that too, and I started a discussion on meta to see whether the Disclaimers should, like the privacy policy, actually be hosted on meta instead. I certainly agree with linking the sub-disclaimers to 'pedia, but their main disclaimer seems to be specific to them. Conrad.Irwin 17:58, 16 February 2008 (UTC)

On a similar theme to the previous - In the "Utilities" section of Special:Recentchanges "Deletion" links directly, "Verification" links to a shortcut, and "Cleanup" links to a redirect of a talk about the process. Could the last two be changed to link directly to "Wiktionary:Requests for verification and "Wiktionary:Requests for cleanup". SemperBlotto 08:11, 18 February 2008 (UTC)

Done Conrad.Irwin 01:23, 19 February 2008 (UTC)

Yo, what's going on with {{IPA}}? The font has suddenly gone all small and rubbish on me. Has there been a change? Is it just me? Widsith 08:50, 19 February 2008 (UTC)

It says in the template that it should appear at 110%, certainly it looks slightly larger than other text to me - presumably it is specified right for someone. Conrad.Irwin 12:00, 19 February 2008 (UTC)

Huh, I've changed machines and it's ok now. Must have been some weird font I installed on the other computer.. Widsith 13:02, 19 February 2008 (UTC)

What is the wiki-code for the "feedback" column on the left? 24.21.133.237 03:39, 21 February 2008 (UTC)

See User:Conrad.Irwin/feedback.js. Mike Dillon 05:10, 21 February 2008 (UTC)

If no one minds, I'd like to modify MediaWiki:Common.js to support a preloadtitle query-string parameter on index.php when action=edit and section=new; it would pre-load a title for the new section. Then {{rfc/v/d/etc.}} could use preloadtitle=%5B%5B{{urlencode:{{PAGENAME}}}}%5D%5D so the new section would by default be headed by a link to the referred-from page, and the wonderful new anonymous-feedback tool could do the JavaScript-y equivalent, so we wouldn't need to waste valuable documentation-space telling readers to do something that we could really handle ourselves.

(Note that my proposal would make preloadtitle a bit different from the existing built-in non-JavaScript-y preload, in that the latter takes the name of a page to include, while the former would take the actual wikitext, for reasons I think y'all can guess.)

So, does anyone object to my doing this?

—Ruakh_TALK 04:07, 21 February 2008 (UTC)

That sounds like a good idea, please do - until we can get MW to support it natively. Conrad.Irwin 12:08, 21 February 2008 (UTC)

This would be a pretty easy patch for MediaWiki. In fact, I just created it: bugzilla:13100. Please vote for it and/or add comments about how useful it would be. Mike Dillon 04:00, 22 February 2008 (UTC)

w00t! Conrad.Irwin 11:24, 22 February 2008 (UTC)

Cool, thanks! In the meantime, I've created MediaWiki:Preloadtitle.js. I haven't added imported it from MediaWiki:Common.js yet; could those of you with JavaScript-fu look it over? (I'm good with modern JavaScript, but have little sense of portability. I gather that, shockingly, regular expression support was not widespread until recently?) Incidentally, my script differs from Mike Dillon's patch in that mine requires action=edit, while his would work at action=submit. This is essentially a no-op difference, though, since the preloadtitle=… would only be specified in the original link. (His patch does it that way because it integrates better with the existing PHP. My script does it my way because it's simpler when going from scratch.) Also, his script requires section=new, while mine doesn't bother; so, my script would allow any edit link to specify a default edit summary. (This restriction wouldn't be hard to hack in to my script, though, if people want it. The section=new thing isn't quite so trivial to grab in the JavaScript as in the PHP, but still quite simple.) —Ruakh_TALK 13:08, 22 February 2008 (UTC)

You needen't worry about support for regular expressions, they have been around (according to google) since IE 4, and most people have more modern browsers than that. Conrad.Irwin 19:17, 22 February 2008 (UTC)

Good to know, thanks. :-) —Ruakh_TALK 20:03, 22 February 2008 (UTC)

P.S. I'm assuming that the typical Bugzilla patch takes quite a while from when it's posted to when it's live on the site. If you have an inside track and we don't need to bother with in-the-meantimes, let me know. ;-) —Ruakh_TALK 13:08, 22 February 2008 (UTC)

Simple patches can be accepted quite quickly actually, especially if people comment on them in substantial ways (beyond "me too" type stuff). MediaWiki patches for simple stuff usually languish only when nobody notices them the first time around. You're probably right that this doesn't need to be restricted to section=new; if that's the case, it should probably be called "preloadsummary" or something.

As for the Javascript code, the one thing that needs to be fixed is that you need to use decodeURIComponent instead of unescape. The unescape function does funky stuff with high-byte characters that doesn't match the encoding created by {{urlencode:...}}. I'd also like to see us provide query string handling as a standard function, since most of the code is related to extracting "preloadtitle". I've got some code at User:Mike Dillon/Scripts/params.js, but like most of my code written for my own use it was written in a very verbose style and would have to be compacted if we were to use a version of it site-wide. I've also seen a number of other people with similar code/libraries (obviously). Mike Dillon 15:57, 22 February 2008 (UTC)

To be clear, escape does the weird stuff with high-byte characters, but unescape only works to reverse escape. Try doing unescape('%C3%B1') and you'll probably get two characters, not ñ like you'd get with decodeURIComponent('%C3%B1'). Mike Dillon 16:09, 22 February 2008 (UTC)

Thanks. Oddly, I did test window.unescape locally with non-ASCII characters, and it seemed to work for me; but now I see it's because aleph (the character I tried) turns into a cross-multiplication sign (which, in the monospace font I was using, just looked like a weirdly small aleph — so I was surprised, but unfortunately not suspicious). I'll fix that. I agree about a standard parameter library; indeed, when I began my script I was surprised to find that we didn't already have one. I considered writing one myself, but given my uncertainty about what's portable and what's not, I decided I probably wasn't the man for the job. As for preloadtitle vs. preloadsummary, I really have no opinion. I don't have any special desire for this to work with non–new-section edits; I just didn't bother to hack in that test, and figured it didn't make a difference. If we do want this to work with non–new-section edits, then we should probably append the preloadsummary to the built-in edit summary, rather than overriding it. (I'll leave these issues — parameter name, non–new-section edits, appending vs. overriding — up to you, since it's presumably easier for me to change my script than for you to change your patch.) —Ruakh_TALK 16:57, 22 February 2008 (UTC)

So, is this working? if so could someone add it to Common.js until the patch gets submitted. Conrad.Irwin 19:17, 22 February 2008 (UTC)

I've made a lot of changes, and probably am not done yet; tonight, I'll finish it up, test in the two browsers I have (FF2 and IE7), and add it to Common.js. —Ruakh_TALK 20:03, 22 February 2008 (UTC)

Implemented. Please let me know if you encounter any problems because of it. (Note: In its current version, it works only on edit-pages with section=new; there's a similar script at MediaWiki:Preloadsummary.js that would use preloadsummary= instead of preloadtitle= and would work at all edit-pages, but it's not obvious to me that there's any use for it, so it's currently not imported anywhere.) —Ruakh_TALK 01:34, 23 February 2008 (UTC)

Update: The MediaWiki patch for server-side support of this param has been applied to SVN in rev:31329. We're currently running 1.44.0-wmf.2 (8fd6c9c), so you can see whether it's been applied yet or not (1.13alpha (r31291) at the time of this message). Mike Dillon 03:23, 27 February 2008 (UTC)

Gah. The patch doesn't work... Some code later in the initialization cycle wipes out the summary from preloadtitle... I guess I'll have another go at it. Mike Dillon 05:43, 1 March 2008 (UTC)

Alright. A working version of this is now live. We should be able to remove the Javascript version now. Mike Dillon 16:21, 3 March 2008 (UTC)

Hi. Could someone please add the Chao tone marks (˧, ˨, ˩, etc) to the IPA set? I'd do it myself but I always seem to break something when I mess with it. Widsith 12:03, 21 February 2008 (UTC)

Looks like you got to this yourself. The changes look fine. Mike Dillon 03:24, 27 February 2008 (UTC)

Suggestion: Make the Wiktionary favicon different from the Wikipedia one.

Reasons:

1. Bookmark toolbar icon confusion. In Firefox, when a url's icon is dragged from the location bar to the bookmark toolbar, it creates a bookmark there. When you edit this and clear out the text, you are left with a nice icon button to click on. (A favorite FF power user trick.) Trouble is, I have one like that already -- for Wikipedia. Both use the same image! (I have a similar problem with Google vs Google Maps.)

2. Same problem with search engines. It is possible to add Wiktionary search to the search engines list (again, Firefox). So now, I have one for Wikipedia and one for Wiktionary. How to tell them apart? You can't, other than by position or actually clicking on the thing (which pulls down the list). Power users never click on the thing: they use the ^K shortcut to get there and keys to navigate up and down through the list.

3. It's a different site, right? I had to create a login here, in addition to the one I use for Wikipedia, didn't I? Should it not have a different icon? I like the "W" but maybe it could be slightly different, for example by having a colored "D" behind it (for Dictionary).

Sorry if this is the wrong place to add suggestions. I couldn't figure out where they go. I see the "Feedback" thing is not yet implemented. (There's nothing on the left menu here, for example, nor on the "Contact Us" page.)

Thanks

--Thundt 22:02, 23 February 2008 (UTC)

I agree that we need our own favicon. (The feedback thing is in fact implemented, but by default the left menu thing doesn't appear if you're already logged in, since then it wouldn't be anonymous feedback. Though for many users I suppose their IP addresses are less anonymous than their Wiktionary accounts! Perhaps we should just say "submit feedback" instead of "submit anonymous feedback", and show it to all non-autoconfirmed users? At any rate, I'll add a link to Wiktionary:Feedback to the "Contact us" page, thanks.) —Ruakh_TALK 22:24, 23 February 2008 (UTC)

I see only the "W" favicon...it has been a long time since I've seen the puzzle-globe favicon. I believe there is a WMF problem where the first WMF site you visit, asserts the favicon for all subsequent pageloads. I don't know the bugzilla: number offhand, though. --Connel MacKenzie 20:21, 2 March 2008 (UTC)

I see a different favicon for tools, meta, source, news, etc. The only two which share favicons are pedia and wikt. Is there any chance our favicon and theirs are using the same cookie or something? Nevermind, we are both just using the same icon. - DaveRoss 20:38, 2 March 2008 (UTC)

Please make a different icon for Wiktionary! I waste a lot of time searching for a foreign word in Firefox only to find out that my search engine is currently set to Wikipedia, and vice versa. Maybe someone can at least paint it in a different color as a quick and dirty solution?

In a recent BP discussion, people were agreed that {{en-verb|foos|fooing|fooed}} should expand to to foo (third-person singular simple present foos, present participle fooing, simple past and past participle fooed) instead of to to foo (third-person singular simple present foos, present participle fooing, simple past fooed, past participle fooed). Now the question for the GP is: can someone do this?—msh210℠ 07:01, 24 February 2008 (UTC)

Could people please test/ rewrite better the working solution at {{en-verb2}}. Conrad.Irwin 13:52, 27 February 2008 (UTC)

It looks good to me. I see you've left both columns in the table-formatted output. That was intentional, right? Rod (A. Smith) 23:57, 27 February 2008 (UTC)

Yes it was, as I don't use that view - and the discussion wasn't about it I left it be. Conrad.Irwin 00:01, 28 February 2008 (UTC)

Well, being hasty, I have implemented the change - feel free to continue to improve {{en-verb2}} and then we can copy it across, with a mere 9kjobs it doesn't take the server a ridiculously long time to chew through. Conrad.Irwin 00:22, 28 February 2008 (UTC)

I'd like the {{t+|lang|word|gender}} templates among the other templates ({{en-noun}}, {{en-adj}} etc.) in the edit section. That would make it much easier to use them, and more people would probably remember to use them while entering translations. /Natox 10:54, 25 February 2008 (UTC)

I could see that being useful, but what would you want it to look like? Particularly, which parameters would be provided and how would new users know which of the unnamed parameters are which? I could see it being useful if we had named parameters for everything and dealt with empty parameters gracefully (if we don't already): {{t|lang=<CURSOR>|term=|gender=|script=|transliteration=}}. Since Tbot looks at all of these things anyways, it could deal with formatting them down to a more compact form. Mike Dillon 16:42, 25 February 2008 (UTC)

I think that's a good idea, the problem I can see with {{t|lang=<CURSOR>|term=|gender=|script=|transliteration=}} is that I will take up an awful lot of space among the other templates, purhapse we could narrow it down to {{t|lang=<CURSOR>|term=|gender=}} or something? Since the other parametres are used by a smaller amount of languages than gender for example. But on the other hand i seldom use any other parametres than gender etc. so purhapse it would be better if someone who enters Cyrillic, Arabian or Chinese entries would give thier thoughts on this... /Natox 15:28, 26 February 2008 (UTC)

The gender and script/transliteration params are not mutally exclusive, but practically speaking the languages that get a lot of attention here tend to need either gender or script/transliteration, but not both. One thing that could ameliorate this slightly are the proposed changes at #default values for sc= and Template talk:lang2sc. This would eliminate the need for the "sc" parameter in many common cases. Mike Dillon 03:28, 27 February 2008 (UTC)

Stumbled across this notice over on Wikipedia yesterday. It seems that categories can now be hidden from display by using the __HIDDENCAT__ magic word on the category page; doing so also includes the category in Category:Hidden categories. I tested this (briefly) here on Wiktionary, and it does seem to work. Is this a feature we can put to good use? For example, would it be a good idea to hide the translations-to-be-checked categories? -- Visviva 07:05, 27 February 2008 (UTC)

I could also see this being useful on temporary categories for things like template parameter usage. For example, if we wanted to see where there are uses of templates that are using a deprecated parameter, we could add the category to entries that use the parameter and clean them up before removing support for the parameter or turning it into an obnoxious visible warning. Mike Dillon 07:10, 27 February 2008 (UTC)

What about separating different types of categories on different lines? For example, on cow the translations to be checked could go in a collapsible box, the derivations could go on a new line, the English verbs English noun categories could go on a separate line. The way it looks now is really mixed up. Nadando 00:24, 28 February 2008 (UTC)

I dislike the idea of hiding categories, the reason they are displayed at the bottom is to give a link back to the category - often something very useful if you can't remember exactly what it is called. I don't think that we have enough control to format the list nicely yet, unfortunately - but that isn't too much of a problem. Conrad.Irwin 00:27, 28 February 2008 (UTC)

I mostly agree, but I think this might be useful in some cases, provided we're careful with it. For example, if {{ttbc|French}} added both ] and ], then we could prevent entries from having fifty-gazillion TTBC categories, while still making it fairly easy to find Category:Translations to be checked (French) again. —Ruakh_TALK 01:52, 28 February 2008 (UTC)

There are certainly a few places this would be useful, as Ruakh points out, ttbc is one; we have had requests before to hide the plethora of ttbc cats. Note that the {{checktrans}} template already adds Category:Check translations so {ttbc} does not need to add another in addition to the language cat. (It does look like someone tried to rename or move that to Category:Translations to be checked?)

I have created {{ttbccatboiler}} to be used in all the ttbc cats, that has HIDDENCAT in it. Added into the Dutch ttbc cat, and it does disappear from the listed categories. I think this is worth doing.

I do agree with Conrad that most cats should not disappear this way. But there may be another case or two that is useful. Do note that all hidden categories appear in Category:Hidden categories. Robert Ullmann 15:09, 2 March 2008 (UTC)

Hi all, looking at mw:Extension:Title Blacklist I have added a regexp that prevents the foohttps://en.wiktionary.org/w/index.php pages from being created by anonymous users, as I can't see any of them being valid dictionary entries this shouldn't cause too much concern. Conrad.Irwin 20:25, 27 February 2008 (UTC)

Cool, thanks! And worse come to worst, an administrator can start any needed entry with a blacklisted title. (It doesn't even have to be a contentful start; I believe just creating a blank entry should work, and allow non-administrators to edit.) —Ruakh_TALK 02:01, 28 February 2008 (UTC)

While we are on the topic, are there any other pagenames or usernames we want to preemptively strike? - DaveRoss 02:27, 28 February 2008 (UTC)

Ahem (Comment striken for w:WP:BEANS.) --Connel MacKenzie 05:11, 28 February 2008 (UTC)

Is it possible to preemptively block an account from being created? Or do you mean, blocking certain userpages from being created? —Ruakh_TALK 02:55, 29 February 2008 (UTC)

Yes. See mw:Extension:Username Blacklist. Mike Dillon 03:07, 29 February 2008 (UTC)

Would it be possible to generate a list of ==English== entries and a sublist of longer-titled entries that have the shorter title as a sub-title (set off by spaces of hyphens) and that are not linked to from the shorter-titled entry? That was an awfully-worded question, so let me give an example. Let's say windshield doesn't link to windshield time, but the latter is bluelinked. Then on the requested list would be

windshield

windshield time

or

windshield time

windshield

(whichever is easier: list by longer title or by shorter one).—msh210℠ 17:41, 28 February 2008 (UTC)

I certain I do not understand your question, as it is currently worded. Do you mean some trickery with Special:Prefixindex/windshield like this:

or something? --Connel MacKenzie 20:18, 2 March 2008 (UTC)

I believe he's asking someone to go through the last XML dump and create something like User:Robert Ullmann/Missing, but instead of listing entries that need to be created, it would list existent entries that need a derived term added. —Ruakh_TALK 21:43, 2 March 2008 (UTC)

Precisely.—msh210℠ 18:06, 3 March 2008 (UTC)

As part of my endless quest to take over Wiktionary I have moved Category:Articles that need to be wikified to Category:Entries that need to be wikified. I am about to run through and update all 15ish of the links, but if there is something else that breaks please come and knock on my talk page and I will fix it. Conrad.Irwin 22:42, 28 February 2008 (UTC)

The translation bars and the place and appearance of the "show" in them have been discussed for some time on WT:BP, but who can edit the "show" tags? If I remember correct the "edit" tags have been in different places sometimes, is editing "show" similar to them? Best regards Rhanyeia♥♫ 16:30, 29 February 2008 (UTC)

It is in the Javascript MediaWiki:Monobook.js, so any sysop who feels comfortable can do it. Conrad.Irwin 16:32, 29 February 2008 (UTC)

I didn't see a consensus as to what should be done in the WT:BP discussion. Mike Dillon 05:18, 1 March 2008 (UTC)

Is this a general notion or does it mean that you would be able/willing to do something if you knew exactly what to do to it? There's a consensus to design it, and what to try first could be to move "show" after the title text, and if it's technically possible to add triangles 9650 and 9660. It looks like a consensus to these two changes, and although there are some other ideas too it would be easier to discuss about them if this was tried first. Best regards Rhanyeia♥♫ 09:06, 1 March 2008 (UTC)

I thought there was consensus on those points, though no vote. The changes can be reversed. I think that folks probably need to see how it looks to know what further changes may be needed. Perhaps "we" could create alternate templates {{transA-top}} {{relA-top}} and test them on a small number of entries. The en-verb change went quickly that way. Should a more explicit proposal be put up for vote? DCDuring TALK 09:52, 1 March 2008 (UTC)

I'll make a few changes and see what people think, it can always be reverted. Conrad.Irwin 10:03, 1 March 2008 (UTC)

I have added the downward arrows, but will leave the position for now, I had a better idea - why not let the whole bar be clickable, so it doesn't matter where people click it still opens? Conrad.Irwin 10:25, 1 March 2008 (UTC)

That's a good idea, but I think there should still be some sort of "show" link to make it a bit clearer that there's something hidden. (Also, to give a well-defined guaranteed click area, since the navbar titles can include real links.) —Ruakh_TALK 14:11, 1 March 2008 (UTC)

It should be fine to test this; I don't see a need for a vote. Changes to MediaWiki:Monobook.js don't need to propagate through the job queue despite affecting every page, but there can be cache retention issues if we add something that people hate. I'm not big on asking people to force-reload to pick of reverts of changes to MediaWiki:Monobook.js. Mike Dillon 16:39, 1 March 2008 (UTC)

The triangles look great. Could the next thing to try be the place right after the text? Best regards Rhanyeia♥♫ 16:13, 4 March 2008 (UTC)

I've done it, but I suspect this will be a less popular move - please revert Mediawiki:Monobook.css anyone who wishes to. (but don't use RollBack as I edit that file to often ;). Conrad.Irwin 16:37, 4 March 2008 (UTC)

I like it for our users. I'll like for myself once my own fingers are used to it. I think I like the idea of edit being less of an impulse than show. I hope feedback is good, but I expect a little grumpiness from regulars. DCDuring TALK 19:47, 4 March 2008 (UTC)

I saw it before it was changed back and I think it was much better when the "show" was after the text. To improve it yet, it could have slightly more space between the title and the "show". It's also a very small area to click, and "show" is very small too. Is there a reason that "show" is smaller than "edit"? Best regards Rhanyeia♥♫ 16:52, 5 March 2008 (UTC)

Did anyone have any complaints about this? Is there any reason for it not to be permanent? I am in whole-hearted agreement with this non-expert-user-oriented improvement and with the improvements that Rhanyeia suggests above. DCDuring TALK 17:00, 5 March 2008 (UTC)