Wiktionary:Grease pit/2010/January

January 2010

Word of the Day error

When I click on the audio file for vociferation @ Wiktionary:Word_of_the_day/Archive/2010/January it comes up with Permission error... The action you have requested is limited to users in the group: Administrators. Tooironic 08:02, 1 January 2010 (UTC)

Thanks for pointing this out. The problem is that if a given media file doesn't exist, then [[Media:filename]] redlinks point to Special:Upload — but we don't use Special:Upload, we use commons:Special:Upload. I think the right solution is this:

• {{WOTD}}, in its call to {{audio}}, should pass in some sort of allow-red=no parameter.
• {{audio}} should check if the file exists (using {{#ifexist:Media:filename}}), and if it doesn't, then it should check the value of allow-red=. If yes or unspecified, then it should create a link to commons:Special:Upload; if no, then it should not produce any output.

(alternatively, it could just always produce no output, under the theory that we never want any media redlinks; however, I think editors might find it useful to be able to insert the {{audio}} template and then use the redlink to upload a pronunciation file).

—Ruakh_TALK 17:47, 3 January 2010 (UTC)

That is this bug. #ifexist also does not work for media files hosted on commons. Conrad.Irwin 18:51, 3 January 2010 (UTC)

Re: #ifexist: I don't know what you mean. It seems to behave exactly as I'd expect: {{#ifexist:Media:en-us-vociferation.ogg|blue|red}} {{#ifexist:Media:en-us-smudge.ogg|blue|red}} produces red blue. —Ruakh_TALK 17:14, 7 January 2010 (UTC)

Ah, interesting, using File: instead of Media: doesn't work (which makes sense I suppose). Conrad.Irwin 17:24, 7 January 2010 (UTC)

usage context for reappropriated words?

There doesn't appear to be a "reclamatory" usage context label for a word sense where a formerly pejorative word has been adopted or reappropriated as one with an acceptable or positive meaning for people who would self-apply it, possibly but not necessarily with the intention of making it acceptable for others. E.g. Yankee, queer. Should there be, or would this be problematic? Incidentally, I note no entries for reclamatory or reappropriation, though there are reclaim and reappropriate; something for me to work on, maybe. Peptonized 19:39, 1 January 2010 (UTC)

I think we have something at nigger that is exemplary in at least one sense.

1. You could hand-make one {{context|reclamatory}}.
2. Could a non-linguist (or even the majority of linguists) be sure what you meant? We already have intelligibility problems with headings for semantic relationships (meronyms, coordinate terms, hyponyms, etc) and some other context tags like "modal", "speech act", etc for adverbs.
3. I don't recall that we permit in context labels the wikilinks that would put the definition of a problematic term just a click away.

We usually put such things in usage notes. Admittedly, we have to then add some words to establish the link to the specific sense, but it does let us make the point. If the usage notes uniformly contain a word like "reclamatory", then we could readily make such notes, senses, and entries as consistent as was appropriate. DCDuring TALK * Holiday Greetings! 20:17, 1 January 2010 (UTC)

There might be a better term for it. Your example does apparently automatically link the usage context "vulgar" to Appendix:Glossary#vulgar. Peptonized 20:49, 1 January 2010 (UTC)

Incidentally, a number of the Category:Usage context labels seem to overlap. What's the distinction between avoidance and euphemism? If ethnic slur needs to exist separately from derogatory, should it perhaps be a subcategory? Peptonized 22:48, 1 January 2010 (UTC)

Sum of parts and handling variants

Is there a page that goes into more detail about "sum of parts" than the glossary? It makes sense that one would not bother to define every combination of words, but the point at which the sum becomes different might not always be clear, I'd think.

Also, and perhaps related, I was wondering with regard to the comment I left on the requests "give a rat's ass" at Wiktionary:Requested entries:English#G 2009 how Wiktionary handles that. Pretty much all, if not all, "(not) give X" expressions are basically the same, whether positively or negatively expressed, and however imaginative the X might be. Peptonized 22:40, 1 January 2010 (UTC)

We should either have [[a rat's ass]] or [[give a rat's ass]] imo if it's attested (as I suspect). (The other can redirect to it.) WT:CFI discusses sums of parts, in the section on idiomaticity. There are vast differences of opinion among regulars over what is worthy of inclusion (with respect to idiomaticity), and there is unlikely to be consensus on that point for the foreseeable future. WT:SURVIVOR has some "case law".​—msh210℠ 16:11, 4 January 2010 (UTC)

derived terms versus related terms versus synonyms

Derived and related are not defined in the Appendix:Glossary. In e.g. monster, the related terms seem like they could have been called derived ones. Peptonized 22:52, 1 January 2010 (UTC)

We have pretty much dispensed with the hobgoblin of consistency. You should find some statement of what we mean by these terms at WT:ELE and linked pages. As I understand it, "derived terms" are supposed to only be terms in the same language that are derived from the headword other than by inflection. That list could include blends. Related terms are cognates in the same language, again excluding inflected forms. Terms from which the headword is descended are supposed to be in the etymology section. Formerly, the trivial morphological derivations were not shown in an etymology section, so etymological ancestors sometimes appeared in related terms. Now, the use of the templates {{prefix}}, {{suffix}}, and {{confix}}, which put the headword into categories of terms derived from the affixes, makes that practice undesirable. DCDuring TALK * Holiday Greetings! 23:49, 1 January 2010 (UTC)

Hmm, Wiktionary will take some getting used to... I also find it peculiar that there's separate entries for things like to-day and today whereas the OED handles those in a single entry. Peptonized 00:26, 2 January 2010 (UTC)

Deleted or rename Template:nav

nav is the ISO 639 code for Navajo, but we use nv because we use 2 letter codes when one exists. However, I've replaced it on the last three pages that use it with {{topic cat}} which is much easier to use. Is there any reason to rename it to something like {{nav.}}, or {{navigation}}? Mglovesfun (talk) 14:12, 2 January 2010 (UTC)

Bot request(s)

Do bot request go directly here, or nowhere in particular? I was thinking of having someone to a concordance of some Old French texts on Wikisource, which might be a quicker way to find out which words are most widely used/needed. Mglovesfun (talk) 16:33, 2 January 2010 (UTC)

Wiktionary:Bots/Tasks exists, but I don't know whether anyone reads it. Otherwise, I guess this is the page. Or the talkpage of a particular user who you know has run a similar bot in the past.​—msh210℠ 18:18, 7 January 2010 (UTC)

Template:etyl and multilingual terms

{{etyl}} does not categorize into categories suffixed with ":mul". I can't think of a good reason for this. Some 20 months ago the special treatment of translingual terms by was discussed briefly by EP and Atelaes on the talk page for the template. Per that discussion, I am asking whether there is any reason for the special treatment. DCDuring TALK * Holiday Greetings! 12:56, 3 January 2010 (UTC)

Seems to me like ":mul" isn't special in this regard. --Bequw → ¢ • τ 07:08, 4 January 2010 (UTC)

"Dictionary" view

I had an interesting conversation with a friend recently. I was showing him Wiktionary and its benefits, and asked him if he was likely to use it. He basically said maybe, but he was more likely to use a print dictionary. Why? Because in flipping through the pages to look for a word of which he has a vague idea, he can come to a page with a lot of words on it, and perhaps see above or below the word he thought he was looking for, the one that he actually needed to find. So, can we make Wiktionary do this, display entries on a "page" with nothing but dozens of words and the definitions themselves, which can be scrolled through, and then simply clicked through upon the discovery of the "right" word? bd2412 T 17:02, 3 January 2010 (UTC)

Are you suggesting some extension to the "Index" pages? --Yair rand 19:05, 3 January 2010 (UTC)

I think it would have to be, yes. Looking at the list of "all pages" for example does not give definitions. What I'm thinking of is something where Wiktionary could be "flipped through" like a printed dictionary (sorted by language, or perhaps other parameters set by the user, such as templated legal terms or sports terms):

bd2412 T 21:25, 3 January 2010 (UTC)

Request

for WT:TODO, all the pages using the wrong script. I tend to speedy delete these. Mglovesfun (talk) 23:03, 3 January 2010 (UTC)

That seems exceptionally wasteful, why not transliterate them and hope? Conrad.Irwin 23:07, 3 January 2010 (UTC)

Nine times out of ten, there is no usable content. And for most of us, transliterating the page name in the hopes of hitting on the correct one just isn't feasible. --EncycloPetey 23:58, 3 January 2010 (UTC)

I speedy deleted some Bengali nouns using the Latin script last night. In most cases, we either already have it in the right script or we have no way of knowing what the correct script version would be. For example άλφα (álfa) can be transliterated alpha, álpha, alfa or álfa. Mglovesfun (talk) 16:11, 4 January 2010 (UTC)

Have created Template:wrongscript to deal with this. Mglovesfun (talk) 17:11, 4 January 2010 (UTC)

I've someone can run that request, we can tag them and let someone attempt to clean them up. Mglovesfun (talk) 06:48, 5 January 2010 (UTC)

new template:quote-magazine

Could someone create template:quote-magazine along the lines of {{quote-journal}} et al.

I've cited a magazine in the new entry for Chrismahanukwanzakah, which uses all of the following parameters except coauthors, so if you change any names please make the adjustment in that entry.

#*{{quote-magazine
|year=
|author=
|coauthors=
|title=
|issue_date=
|volume=
|number=
|page=
|magazine=
|publisher=
|issn=
|url=
|passage=
}}

I've had a look at the source for both {{cite-magazine}} and {{quote-journal}} and the former needs much expansion and the complexity of the latter is far above my skill level, so I'm not confident to just do it myself. Thryduulf 13:57, 4 January 2010 (UTC)

I've copied {{quote-journal}} across and changed it to take magazine= instead of journal=. As such it uses date= where you used issue_date= and issue= where you used number=. Conrad.Irwin 16:54, 4 January 2010 (UTC)

Excellent, thank you. Thryduulf 17:54, 4 January 2010 (UTC)

Protecting ISO 639 templates

Do we always protect ISO 639 templates like {{pcd}}, even when not much used? There's not much to them that needs changing; you just write out the name of the language. Mglovesfun (talk) 15:22, 4 January 2010 (UTC)

Protecting 7,000 templates just because they exist seems like overkill to me. -- Prince Kassad 16:22, 4 January 2010 (UTC)

Looking through the last few years of protect log your spree today was the major cause of protection of these templates. There is no need to gratuitously protect templates, it just irritates people who can't edit them (even if they don't want to - I know it irritated me). All the script templates seem to be protected, I don't understand that either. If it's not used on a few thousand pages, it doesn't need protecting. Conrad.Irwin 16:45, 4 January 2010 (UTC)

Most script templates are used on the Main Page which explains their protection. -- Prince Kassad 17:01, 4 January 2010 (UTC)

I don't mean protecting literally every language template, but that *in theory* it's a good idea to protect all of them. I was surprised for {{fro}}, which must have no less than 10 000 transclusions, most of them in English entries. Mglovesfun (talk) 06:33, 5 January 2010 (UTC)

Request: Link to WT:CITE when creating Citations page

When creating a Citations page, could a link to the policy page WT:CITE be added? Currently the “creating page” text reads:

Wiktionary does not yet have a citations page for <Foo>.

• To start the citations page, type in the box below and click "Save page". Your changes will be visible immediately.

…but linking to policy would be helpful.

Thanks, greasers!

—Nils von Barth (nbarth) (talk) 21:07, 6 January 2010 (UTC)

I added the notice, but I don't know if it's correctly worded. -- Prince Kassad 21:29, 6 January 2010 (UTC)

Thanks Prince Kassad!

The wording is a bit strong:

WARNING! Please read the Wiktionary policy on Citations pages before creating a Citations page.

I don’t know if “WARNING!” is necessary, particularly as the policy is not terribly picky or contentious, but otherwise the wording is fine, and the link quite useful – thanks again!

—Nils von Barth (nbarth) (talk) 08:00, 13 January 2010 (UTC)

API to wiktionary for open source software application

Hello,

I am exploring the use of the wiktionary database for populating words in the open source educational game called 'anagramarama'. I have various ideas which all start with 'First I need lists of words in languages from around the world'. Wiktionary might help in that regard.

This would be good thing since anagramarama is already an excellent game, but its dictionary is much too advanced for children. What the game needs is easier play for younger kids and harder play for older people. To achieve this, I am thinking...

(1) Read-only access to the wiktionary database could be provided to each game (probably too much stress on your servers), or to an external proxy that in turn would provide the data to the games (probably the better solution). This may involve an application programming interface (API) or database queries. As a bonus, an API or queries might help other software developers create other games.

(2) The difficulty level would be adjustable by adding or removing less commonly used words. Actually, I have many ideas on this, but they are not important now.

Thank you in advance for any help, comments or suggestions.

-Mark Mitchell

You can download all of Wiktionary at http://download.wikimedia.org/enwiktionary/, and you are free to do as you like (well, almost, see CC-SA-3 and GFDL); there is also an API to download entire entries, see the software documentation. If you are looking to run the game in many languages, you may also wish to download their versions of Wiktionary (found in a similar place), each language version aims to define "all words in all languages" using definitions written in the home language. For finding common words, I suggest you look for Swadesh lists, we have a few in Category:Swadesh lists, but seem to be missing an English one (oops). If you want simple stuff for English, there is also a version of Wiktionary. (We have thought about writing a more useful Wiktionary API, but the technical structure of Wikimedia is very Wikipedia-centric, so trying to get anything done is quite tricky) Conrad.Irwin 11:00, 7 January 2010 (UTC)

IPA template request

Hi there all. When in the editing window, there is that drop down menu that allows you to select languages and IPA, enPR, SAMPA from a list and you see a whole bunch of symbols that are otherwise not very easy to type in using a regular keyboard. I would appreciate it if someone could add the two symbols listed at User:Razorflame/EO Pro to the IPA list of symbols because they are used very often in Esperanto pronunciation. Thanks, Razorflame 22:33, 12 January 2010 (UTC)

Helping hand required

Can someone work out how to get the columns sorted out on Transwiki:Annexe:Pays et leurs gentilés en français (see letter B)? That's all I need, although other help is of course welcome. Mglovesfun (talk) 14:38, 14 January 2010 (UTC)

Did some work which I abandoned after an edit conflict. I used the format from w:Charlotte Uhlenbroek#Synopsis, in particular the line breaks between column entries. However, this introduced a new problem of occasional missing horizontal lines. That looked like a bug, perhaps a version difference from Wikipedia. Pingku 18:19, 14 January 2010 (UTC)

Unable to create new pages

Hi all

Since about 3 hours ago, I have been having issues creating new pages and editing existing pages with the Edit link at the top of the page (editing in-line seems to work). What happens is whenever I create a new page, the browser starts to prompt me to save index.php file. Now I examined the php header of the page creation link as below, which is very different from normal. It only occurs with this account incidentally. I have tried different browsers and different PC's,and different connections to no avail. Works like a gem when I create pages anonymously and when I use a different account.

[Process] Type=Edit text Engine=MediaWiki Script=http://en.wiktionary.org/w/index.php Server=http://en.wiktionary.org Path=/w Special namespace=Special [File] Extension=wiki URL=http://en.wiktionary.org/w/index.php?title=User:Jamesjiao&action=edit&internaledit=true

UPDATE: it seems that if I attach &internaledit=true to the end of the edit/create link, it stops the browser prompt.

Go to Special:Preferences, Editing, and uncheck "Use an external editor by default". Conrad.Irwin 11:19, 16 January 2010 (UTC)

Stroke of genius. Thanks Conrad. I stil haven't a clue how it got turned on in the first place. Jamesjiao → ^{T ◊ C} 23:52, 16 January 2010 (UTC)

Navigation box merger

I was thinking about merging some of the code for the right-hand side navigation boxes (not conjugation tables). This would ease editing, keep new editors from creating extraneous templates, make the overall layout look more consistent, and allow for better management of color selections (in case someone ever worries about this in the future). As a first step I was thinking that {{enum}} could be extended to be the base, formatting template for {{Zodiac}}, {{ru-Zodiac}}, and {{elements}}. Some of these template would continue to exist as convenient front-ends while others might not be that useful in the long-run (eg {{ru-Zodiac}}). In the future, maybe {{cardinalbox}}, {{ordinalbox}}, {{hu-daybox}}, and {{hu-monthbox}} could be combined somehow as well. Does the first step, however, sound fine? --Bequw → ¢ • τ 22:35, 16 January 2010 (UTC)

It is a good idea, I personally prefer the horizontal format to the {{enum}} format and have created a meta-template at {{sequence box}} which resembles {{hu-monthbox}} and {{ordinalbox}} and that class of templates. When used with only the sequence parameters, it can resemble {{elements}}, but without the purple (colours, eww!). I think this box format lends itself to more purposes than {{enum}}'s; it does not require the "previous" and "next" labels, they can be added in by the template that calls this; nor does it require that the "current" is represented by an image/symbol (though obviously it would be easy to create a middle-man template that calls this and provides those features). What are your thoughts? Conrad.Irwin 00:45, 17 January 2010 (UTC)

I like the idea of having a simplified central code for most of these boxes, but I think the temporal sequence ones ought to be combined first (e.g. months, days, zodiac). I'm not sure that combining the elements into the same format is advisable, since the three chemical symbols could then be more easily confused and the names of some elements are quite long. As a result, I don't think a horizontal sequence would work well for the elements. I'm also skeptical about combining {{cardinalbox}} and {{ordinalbox}}, since they specify several optional parameters and display parameters. Trying to patch that into a single master template for a pair of templates that (in principle) could appear on every numeral entry in every language could generate a lot of additional server strain with little or no benefit from the merger. --EncycloPetey 04:26, 17 January 2010 (UTC)

Pr: Praseodymium Nd: Neodymium Pm: Promethium

Chemical elements

Pr 59 Praseodymium	Nd 60 Neodymium	Pr 61 Promethium
We can even mimc the empty grey box at the bottom of the cardinal/ordinal template (It's possibly more aesthetic with it).

Days of the week

←  Monday

Tuesday

Wednesday  →

The only option not supported by this is the {{ordinalbox}} form where no numerals are given. This could be added to this template trivially, or be done by using the name of the previous and subsequent ordinals, leaving the top two boxes blank, or by not using this template. That form of that template fails to be the correct width, three of the longest chemical elements juxtaposed fit with just a minor stretch, though if they were much longer the template would get wider to cope. I hope this addresses some of your concerns, obviously it would be possible to have more than one style of list; but I am a huge fan of uniformity. Conrad.Irwin 12:39, 17 January 2010 (UTC)

Well no, because you seem to be advocating that we link from the chemical symbol, which logically should be an article about the symbol, not about the word. It also doesn't address what happens for users whose poor vision requires them to use a larger font size, as many of our users do. And, no, the ordinal symbols cannot be added trivially because there are languages that do not use symbols for ordinals or which have no single set that is standard. You've simply opened additional cans of worms to look at. --EncycloPetey 16:38, 17 January 2010 (UTC)

Chemical elements

Pr Praseodymium

Nd Neodymium

Pm Promethium

Latin Ordinal Numbers

septimus	octāvus	novenus
Cardinal: octō Adverbial: octiēns Distributive: octōnī

As always you pick on the details of the examples, not the proposal. I will resay what I have said with hopefully more clear examples: There is no obligation to force all templates to use this as a meta template (i.e. if you personally don't want it, don't use it). The ordinals idea, which I did not express clearly enough, was to use the words not the symbols. My revised proposals are on the right; the advantage here is that to create the proposals, I didn't have to faf around with wikitables, floating right, colours or anything, just filled in the arguments to a general purpose box - this is the advantage of using the meta-template. I am not proposing that "all lists must look like this", merely that it would be useful to have a backend for lists (which was Bequw's proposal originally). I claim that {{sequence box}} is more useful, flexible, and in my opinion aesthetic, than the originally proposed {{enum}}, but it does not have to be used everywhere. Conrad.Irwin 22:24, 17 January 2010 (UTC)

I did not miss commenting on the proposal. You seem to have missed my lead comment (the most important one): "I like the idea of having a simplified central code for most of these boxes." That was my response to the proposal, then I fretted over some details in the original suggestions. One concern I have with {{sequence box}} is that it would have to be channeled through more specific templates becuase we would otherwise have non-uniform titles / formatting in the boxes. As you have noted in comments, including the text in the main box of the ordinals template is "ugly", because (as I noted) there are many optional parameters involved, which is messy.

Whatever we do will also require ISO code support, which is not presented in your examples; how technically feasible is that? It looks like it might be messy to include, and would have to be done individually in every template rather than supporting it in {{sequence box}}, since there will be optional display forms possible in many languages (Arabic, Hebrew, Latin, etc.). --EncycloPetey 23:48, 17 January 2010 (UTC)

Days of the week

← Monday

Tuesday

Wednesday →

Sorry, yes. For a more directly useful template you could create something like {{sequence}} and then use

{{sequence|en|Days of the week|Monday|Tuesday|Wednesday}}

The problem with this is that you need to write the same caption in all entries; thus creating a template per-sequence seems sensible (but we should be able to re-use the per sequence templates in many languages). It may be the case that many of the sequences can use {{sequence}} instead of {{sequence box}} if they want to take advantage of that format. I would intentionally leave {{sequence box}} as devoid of logic as {{maintenance box}}, its only purpose is to define the layout.Conrad.Irwin 00:50, 18 January 2010 (UTC)

{{Zodiac}} now uses {{sequence box}} and {{ru-Zodiac}} uses {{sequence}}. Look okay? --Bequw → ¢ • τ 03:22, 27 January 2010 (UTC)

Yes. Conrad.Irwin 20:12, 27 January 2010 (UTC)

Definition(s) and or application(s)?

== I am asking this 'community' about what is thought about the word / term "anthropomorphic" in terms of its application to inanimate natural objects such as mountains, trees, lakes, etc.

I understand that the term applies to the figurative 'humanization' of animals especially in children's stories. But is the term commonly extended to the religious notions of, say, spirits that are said to live in natural objects?

Warren.

==

You may wish to post your question in the Tea Room. This discussion page is for technical issues and software-related discussion. --EncycloPetey 05:30, 18 January 2010 (UTC)

Bot adding audio

Can you review the latest edits of DerbethBot? I want to make a full normal run of it soon, but I don't track changes in English Wiktionary policies. --Derbeth ^talk 13:47, 20 January 2010 (UTC)

As far as I can tell, the changes that your bot is making are very good. Audio files are very much so requested (and there are a lot of entries that could use audio files), so anything that your bot can do to help us add audio files to entries correctly would be very appreciated. Looking through the last 100 edits made by your bot, I could find no outstanding issues with the edits, although my opinion might not be the only one you should get before you make the run. I would suggest waiting for another person's input before going ahead with the full normal run of your bot. Cheers, Razorflame 13:52, 20 January 2010 (UTC)

Edit buttons, rhs ToC

Two questions:

1. Assuming that the vote to set ToCs to be on the right by default passes, does anyone know if there's any way to make the side boxes that would otherwise be in that place to float to the left of the ToC instead of below it?

   You could edit all the templates to do this; but don't people have screens too narrow for it to be pretty. Conrad.Irwin 09:35, 21 January 2010 (UTC)

   We could benefit from a BP discussion to check for agreement on the desired appearance (including vertical (or, not to prejudge horizontal) order) of elements. Once consensus is established we might amend WT:ELE. DCDuring TALK 14:57, 21 January 2010 (UTC)

2. After reading this, I tried to fiddle around with the edit buttons using my monobook.js, and although adding new buttons worked, I couldn't figure out how to modify the existing buttons. Does anyone know whether it's possible to change the buttons, and if so, how?

   I don't know of any existing functions, but it's just DOM manipulation, what were you wanting to do? Conrad.Irwin 09:35, 21 January 2010 (UTC)

Thanks. --Yair rand 07:18, 21 January 2010 (UTC)

Nasa DICTIONARY OF TECHNICAL TERMS FOR AEROSPACE USE

Nasa has a DICTIONARY OF TECHNICAL TERMS FOR AEROSPACE USE from 2001. It has a good few thousand terms that aren't in wiktionary...and being that its from nasa, its in public domain. Anybody care to write a bot to add these in?Smallman12q 01:28, 23 January 2010 (UTC)

No. Definitions should be our own, not copied directly from another source, even if there are no copyright issues. Also, there are quite a few spelling mistakes in the definitions - they need to be checked by a human. SemperBlotto 11:37, 23 January 2010 (UTC)

How about adding them, but making use of a template like {{webster 1913}} for them? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 11:45, 23 January 2010 (UTC)

See User:Conrad.Irwin/nasa (if you've got accelerated creation enabled). THis should get you started, but all of them need extensive copyediting. Conrad.Irwin 12:14, 23 January 2010 (UTC)

I would prefer to make use of something like the webster 1913 template, and have a human go through them when they get the chance.Smallman12q 14:27, 23 January 2010 (UTC)

The formatting of the definitions is far too unreliable for that, sorry. Conrad.Irwin 14:30, 23 January 2010 (UTC)

I made a start at defining terms found in this resource. But I have found so many dictionary-only words that I am going to stop. It is very unreliable. SemperBlotto 22:31, 25 January 2010 (UTC)

“define word”

The following was added by an IP on Wiktionary talk:Announcements several years ago:

I noticed that when I type "define word" on Yahoo or on Google, I get definitions from their dictionaries, but Wiktionary pages do not come up. Traffic might be increased to Wiktionary if all pages had <meta name=keywords content="word, define word">. Just a suggestion.

If this is not the right place to make the suggestion, where should it be done. It's not obvious. —The preceding unsigned comment was added by 207.126.231.78 (talk • contribs) 17:47, 19 January 2006 (UTC)

Is this correct, that Wiktionary would somehow come up more on search engines if this was done? If so, how could we go about doing this? --Yair rand 05:06, 25 January 2010 (UTC)

They used to be there, and were removed because most search engines completely ignore the keywords meta tag. -- Prince Kassad 05:49, 25 January 2010 (UTC)

Not exactly true, see this bug report which I filed to fix the problem, and got (as usual) completely blanked by the admins. Conrad.Irwin 16:21, 25 January 2010 (UTC)

Category redirects

A plea to anyone who wants to do it, or just make a list so that I and other can do it. Categories should not be used as redirect in the form #REDIRECT[[:Category:Name of the category]] because {{movecat}} is much more functional. There are probably quite a few cases where the categories could easily be speedy deleted, or worse, they contain entries while they are redirects, which causes all hell when you click on the category and it redirects to something unexpected. Mglovesfun (talk) 05:42, 25 January 2010 (UTC)

Wiktionary:Todo/redirected categories. --Bequw → ¢ • τ 19:12, 25 January 2010 (UTC)

phrasecatboiler

New template: {{phrasecatboiler}}.

Example: [[Category:English phrases]].

--Daniel. 16:16, 25 January 2010 (UTC)

Right to left character

Should our templates that print right-to-left text (eg {{Hebr}} and {{Arab}}) use the &rlm; "right to left marker" like w:Template:Rtl-lang does? --Bequw → ¢ • τ 19:27, 25 January 2010 (UTC)

Logically, there should be no need for it, since the dir="rtl" subsumes it. Are there any cases in which any browsers behave differently with it as without it? If so, I'm pretty sure that's a browser bug, and the only way to decide whether to include the &rlm; would be to examine the behaviors with and without it and decide which seems preferable. I don't think we can decide it in the abstract. (If I'm wrong, and there is in fact a case where a browser would be correct in treating the two cases differently, someone please speak up and correct me.) —Ruakh_TALK 20:48, 25 January 2010 (UTC)

AFAIK you're right, Ruakh. I've found myself adding LRM (sic), though, around Hebrew-script stuff in running English text (because of a bidi-neutral adjacent character). Perhaps template:Hebr should include an LRM at either end?​—msh210℠ 17:47, 26 January 2010 (UTC) 18:32, 26 January 2010 (UTC)

Yes, good idea. —Ruakh_TALK 21:12, 27 January 2010 (UTC)

I tried it, but it messed up {{term|עד|עַד|sc=Hebr}} {{term|כאן|כַּאן|sc=Hebr}} {{term|לשונו|לְשׁוֹנוֹ|sc=Hebr}} (which exists at [[עכ״ל]]), and similar. Reverted.​—msh210℠ 16:37, 1 February 2010 (UTC)

I tend to think that such cases should be fixed, since the mention isn't of each of those words individually, but rather, of the three-word phrase they compose. So, it should be {{term||[[עד|עַד]] [[כאן|כַּאן]] [[לשון|לְשׁוֹנוֹ]]|until here [is] his language|lang=he|tr=ad kan l'shonó}}. But it doesn't seem very urgent to fix every entry using that pattern, especially since it seems non-trivial to find them all. —Ruakh_TALK 18:54, 4 February 2010 (UTC)

Such should be fixed, yes. I don't see how the ease of a task affects its urgency, but I agree that this is not urgent: but IMO Hebr can't be fixed until these cases are.​—msh210℠ 19:03, 4 February 2010 (UTC)

Re: ease vs. urgency: touché. :-)   Re: Hebr being fixed: Yes, I agree. —Ruakh_TALK 19:27, 4 February 2010 (UTC)

Please note that some scripts need to be enforced the right-to-left order (using right-to-left override) because operating systems are not aware of their direction. See, for example, {{Khar}}. -- Prince Kassad 17:51, 26 January 2010 (UTC)

I don't follow. In such cases, why is it better to use an RLO than to specify dir="rtl"? —Ruakh_TALK 21:10, 27 January 2010 (UTC)

For some reason, browsers ignore the dir="rtl" when text in this script is written. -- Prince Kassad 21:22, 27 January 2010 (UTC)

Alphagrams

Alphagrams give the letters of anagrams in alphabetical order. This confuses our users and some of them try to "correct" them by replacing them with the word in which they appear. I revert several of these attempts every week (without blocking the user!).

Could we have something, such as an html comment, that only shows up at edit time to tell people not to do this. SemperBlotto 17:17, 26 January 2010 (UTC)

An example. Mglovesfun (talk) 17:21, 26 January 2010 (UTC)

They should certainly show the page name somewhere, otherwise it's a bit confusing. -- Prince Kassad 17:53, 26 January 2010 (UTC)

I can modify it so it includes the paeg name in the list, or we could remove the alphagram from the list, or change the label to "other anagrams of <blah>" - which do people prefer? Conrad.Irwin 19:17, 26 January 2010 (UTC)

Anagrams always refer to existing words (or sentences, etc.). Strictly speaking, a meaningless alphagram is not an anagram of anything, and people trying to correct pages are right. I would remove the alphagram (it does really not provide any info), or, at least, change its line to (alphagram: ...). Lmaltier 20:23, 27 January 2010 (UTC)

I have removed the alphagram from display, seeing as it casuses so much controversy. Anyone can bring it back by editing {{alphagram}} (note that the parameter is linked when the alphgram is a word, and not otherwise). Conrad.Irwin 20:57, 27 January 2010 (UTC)

IsValidPageName means what it says: the parameter is a valid pagename (not an existing one: for that you want #ifexist).​—msh210℠ 20:58, 27 January 2010 (UTC)

isValidPageName is correct - see my note in brackets above. Conrad.Irwin 21:00, 27 January 2010 (UTC)

Yeah, sorry. (Shouldn't have doubted a Template Master.)​—msh210℠ 21:03, 27 January 2010 (UTC)

Collapsible sections have stopped collapsing?

Is it just me or is anyone else finding that the collapsible sections (using {{rel-top}} and {{trans-top}} and their accompanying formatting templates) have stopped collapsing? Is someone fiddling with the internals? -- WikiPedant 19:37, 26 January 2010 (UTC)

There have been some recent tweaks to the javascript, but none that should have caused this. I assume you don't have the WT:PREF to keep them open checked? If not try clearing your cache (ctrl+shift+F5), maybe you got given the javascript in some inconsistant state. (Failing that, which browser and which version are you using?) 19:44, 26 January 2010 (UTC)

Hello Conrad -- I'm using Firefox 3.5.5. Clearing cache seems to have done the trick; they're collapsing again. -- WikiPedant 19:56, 26 January 2010 (UTC)

Oddly, my didyoumean autoredirects stopped working briefly today, but are back.​—msh210℠ 19:45, 26 January 2010 (UTC)

Gadgets

I just uploaded a gadget to the Wiktionary preferences page (find it under the "Gadgets" tab). It's a small customization that allows timestamps, such as those in discussions, to be displayed in local time rather than UTC time. I think it's a minor improvement. Files created where: MW:Gadgets-definition, MW:Gadget-section-interface-gadgets, MW:Gadget-CommentsInLocalTime, MW:Gadget-CommentsInLocalTime.js and User:Bequw/comments in local time.js.

Gadgets are a bit nicer than WT:PREFS. You only have to set a preference once rather than in each browser. It is integrated into Special:Preferences so newer users will be able to find it easier. Also the interface is easier to understand (it's got a real save button and no global "Use the preferences set on this page" checkbox). For these reasons I think we should encourage its usage. How would people feel about migrating some of the more "stable" and "appealing" customizations from WT:PREFS to gadgets? WT:PREFS could stay as more of a staging ground for alpha-release customizations as well as the repository for more idiosyncratic customizations (eg "Hide the maximal amount of parentheses. [Can cause sentences to appear ungrammatical]"). --Bequw → τ 18:41, 28 January 2010 (UTC)

Would make sense, now we need a volunteer to transfer everything across. The disadvantages of gadgets are (still) that it's inefficient for the small tweaks (but if you don't want to transfer them, that's fine) and also that it precludes anonymous users (we have very few of those, though they have been spotted using prefs). Conrad.Irwin 21:08, 28 January 2010 (UTC)

Yes, we've discussed this before; at [[Wiktionary talk:Preferences#Move to Gadgets tab in Special:Preferences ?]]. The general consensus seemed to match your comment — Gadgets is the way to go for a relatively small number of customizations that are stable, thoroughly tested, well documented, and worth supporting — though you may want to read the earlier discussion for some of the more detailed concerns that people raised. —Ruakh_TALK 22:27, 28 January 2010 (UTC)

Here's the ones that I was thinking of "promoting":

1. Navigational Popup's (Lupin's)
2. Clock. Instead of three options I'd have it be just UTC (people have local time on their screen) and always updating.
3. Add input boxes to pages to assist with adding translations.
4. Translate sidebar interwiki links to English
5. Color translation links orange instead of blue if the target language is missing on an existing page.
6. Show an interwiki link under the language heading when one exists in the sidebar.

Any additions or subtractions? Is ACCEL stable? Do the Next/Previous links cause too much slowdown to add? We should probably also setup a Wiktionary:Gadgets for extra gadget documentation, concerns, etc. --Bequw → τ 22:56, 28 January 2010 (UTC)

ACCEL should be stable enough, by adding the translations box as a gadget, do you want to turn it off by default? I'd quite like some of the sysop-only ones (patrolling enhacements, but only expert mode, and show a box if a user is blocked). Conrad.Irwin 23:10, 28 January 2010 (UTC)

It's unclear if we can make the gadgets on by default. Some said that $wgDefaultUserOptions controls this, but I'm not sure what it's set to. Once they're in Gadget space should they be removed from WT:PREFS do avoid duplication? --Bequw → τ 00:37, 29 January 2010 (UTC)

Yes, probably. Though we could wrap the entire file in runOnce(function nameOfJavacscript() { }); or something similar to avoid too many problems (where runOnce still needs to be written). It looks like functionality for default gadgets was removed because of a mistake spamming people [1] - gah.... otherwise we could define behaviour toggles in gadgets (but an entire file for that seems a bit nasty to me) or move them to prefs (which I've been meaning to do for a while). Conrad.Irwin 00:56, 29 January 2010 (UTC)

Added most of them (including RHS ToC) as gadgets, except:

• "Translate sidebar" and "Show interwiki link" both use MediaWiki:langcode2name.js. We could do a runOnce() or maybe we could move the language utility to MW:Gadget-langcode2name.js and let the Gadget dependency solve it (not sure if it can). Resolved!
• "patrolling enhacements" ("User:Connel_MacKenzie/patrolled.js") gets the "expert mode" option via WT:PREFS so this will have to be re-written or another, optionless version can be made specifically for gadgets.
• "Color translation links orange" has some disabling logic that should be integrated into the script so that it can degrade nicely in offending browsers (you can't disable gadgets). Resolved
• "Add accelerated creation links" has some logic dealing with Nav Popups that I think should be integrated into the main script as well. Resolved

Thoughts? --Bequw → τ 23:50, 31 January 2010 (UTC)

No real thoughts, but a small anxiety: what can I get rid of in my css and js monobooks? Will anything bad happen if I select a gadget that has duplicate or near-duplicate functionality with what I've gotten used to (one old CM js script "mess with popups", for example) DCDuring TALK 00:34, 1 February 2010 (UTC)

Well, whatever you enable in gadgets can (and should) be removed from your personal javascript, otherwise they will likely conflict. WT:EDIT and WT:ACCEL are "safe" to be loaded more than once (or safe enough for me); other scripts may not be - it's rather hard to tell, unfortunately. Conrad.Irwin 00:53, 1 February 2010 (UTC)

(unindent) I've merged the importScript caching functionality of MediaWiki:Common.js with that in wikibits so it shouldn't matter if you import a script multiple times (whether from Special:Preferences, WT:PREFS, or your own skin.js) it should only get loaded once (unless you specify different versions of the same file). --Bequw → τ 19:28, 4 February 2010 (UTC)

This seems fine except when bits.wikimedia.org timesout before giving out wikibits.js, as that breaks quite a lot of things (I assume?) we can probably live with that. Conrad.Irwin 19:56, 4 February 2010 (UTC)

Template:infl with Grek

Link. How come it doesn't appear in bold? Only other time I've seen it do that, is when the script name doesn't exist. Mglovesfun (talk) 21:13, 29 January 2010 (UTC)

This bug actually occurs with all script templates (except {{Cyrl}}). I don't know why nobody noticed it until now. -- Prince Kassad 22:03, 29 January 2010 (UTC)

Note that {{el-noun}} works totally ok. Mglovesfun (talk) 23:23, 30 January 2010 (UTC)

It is up to individual script templates to support bolding, italics, neither, or both. Some scripts are really hard to read in bold or italics, so we want different templates to be able to handle cases differently (e.g., by not supporting italics at all, and/or by implementing "bold" by using bigger text rather than bolder text). In the specific case of {{Grek}}, I've started a discussion at Template talk:Grek; please comment there. —Ruakh_TALK 23:30, 31 January 2010 (UTC)

I've started a similar one at Template:unicode. --Bequw → τ 17:09, 21 February 2010 (UTC)

Template:zh

I note this now displays Mandarin, but it used to display "Chinese languages" (at least when used in etymologies). Chinese languages is more accurate isn't it? Mglovesfun (talk) 23:22, 30 January 2010 (UTC)

Isn't that what {{etyl:zhx}} is supposed to do? Nadando 23:25, 30 January 2010 (UTC)

Yes, admittedly that doesn't fully answer my question though. Mglovesfun (talk) 23:27, 30 January 2010 (UTC)

Also with {{question}}, it turns questions about Chinese entries into questions about Mandarin entries. Mglovesfun (talk) 15:05, 1 February 2010 (UTC)

Question templates

Have you all noticed {{zh-question}}, {{cmn-question}} and {{yue-question}}? It *seems" to be a good idea to me. If so, they should be generalized to {{question}} with a lang parameter (probably just {{{1}}}) so that people can ask questions about *any* language. I don't think it's redundant to {{attention}} as that's for the entries, not the talk pages. Mglovesfun (talk) 15:36, 31 January 2010 (UTC)

Yair Rand's created the template: zh- and yue- were little used so I updated the links and deleted them, while {{cmn-question}} is marked as deprecated and should be replaced wherever it's found. Mglovesfun (talk) 15:05, 1 February 2010 (UTC)

Long ſ redirect bug

A minor bug: if you enter a word starting in a long ſ, and no entry exists but an entry exists for a term which starts with capital (not small!) S, it will show that entry in the "page not found" box, but it will not cause the auto redirect. This is somewhat weird and I wonder why it happens. (Try, for example, ſänger) -- Prince Kassad 20:52, 31 January 2010 (UTC)

Probably because it's not implemented in the software. Similarly, 𝓐 is not redirected to A. I agree that such automatic redirects would be the best way to deal with this issue. Lmaltier 21:56, 31 January 2010 (UTC)

Interesting! Sänger appears in the "page not found" box because it's the result of {{ucfirst:ſänger}}, but it doesn't cause the auto-redirect, because the auto-redirect code in MediaWiki:Common.js has this check:

pagetitle.toLowerCase().replace(/[^a-z]/g, "") == target.toLowerCase().replace(/[^a-z]/g, "")

which ultimately compares nger to snger and determines that they're not equivalent. We could perhaps improve that check a bit (calling toUpperCase() before calling toLowerCase(), and filtering out non-letters rather than non-ASCII-letters), but instead, I think we should just remove it entirely, and add this check instead:

wgArticleId == 0

That way, we make sure that the user is really viewing a non-existent page (as opposed to a normal entry to which a vandal has added <span id="did-you-mean">[[a disgusting entry]]</span>), and therefore that the displayed entry is pretty much trusted content, rather than having to try to sanity-check what the did-you-mean code produced. —Ruakh_TALK 23:16, 31 January 2010 (UTC)

Since no one objected, I've been bold and made the change that I described. Revert and/or let me know if you object and/or notice any issues. —Ruakh_TALK 01:10, 4 February 2010 (UTC)

Sorry to question the question, but why would you ever input (deprecated template usage) ſänger, looking for Sänger? Did German nouns use not to be capitalised? (I couldn’t find (deprecated template usage) ſänger on Google Books, due to the fact that both (deprecated template usage) Sänger and Fänger exist.) I can understand writing (deprecated template usage) sänger, (deprecated template usage) Sanger, or (deprecated template usage) sanger, but not (deprecated template usage) ſänger. Whilst I agree with the theoretical proposition that (deprecated template usage) ſänger, like (deprecated template usage) sänger, should redirect (deprecated template usage) Sänger, I can’t envision a scenario where, in practice, such a thing would be necessary. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 00:13, 1 February 2010 (UTC)