Several templates (including {{past of}}) have been modified so that wikified links are disrupted. (See (deprecated template usage) microtomed as an example). Can this be fixed please. SemperBlotto 09:21, 5 June 2010 (UTC)

User:Daniel. mistake. Like I say, he really has to discuss these things and work in the interests of Wiktionary, not his own interests to see how good he is at making templates. Were he not an admin, I'd say a short block, maybe three days would be in order. Mglovesfun (talk) 09:26, 5 June 2010 (UTC)

Daniel made a generic definition template ({{deftempboiler}}) and converted many specific defintion templates to use it. Whatever the solution (fixing the generic template or not using it at all), those others should be "fixed" as well. --Bequw → τ 15:29, 5 June 2010 (UTC)

{{alternative spelling of}} is still bad; so is {{misspelling of}} but some people think that these shouldn't be linked. SemperBlotto 16:48, 5 June 2010 (UTC)

Yes I've noticed IPs correcting some of these - little do they know there's still 100 000 to go! Mglovesfun (talk) 16:53, 5 June 2010 (UTC)

Would it be possible to create a bot that would automatically add words in the correct format? Anyone would be able to submit words (or maybe a text file) and the bot would take care of the rest. I have noticed that Latin definitions are lacking in number. Does anyone know how this could be done?

I'd have thought using WT:ACCEL would be one, reasonable option. The use of macrons might cause some problems. Using WT:ACCEL (well) is a good idea for every language, IMO. Mglovesfun (talk) 16:05, 5 June 2010 (UTC)

For new lemma entries, you can create templates like {{new io-n}} that fill out most of the boilerplate. Conrad.Irwin 16:11, 5 June 2010 (UTC)

You would first need to learn a little more about basic Wiktionary format, and the difference between the supine and anf the perfect. --EncycloPetey 16:03, 6 June 2010 (UTC)

A small request: all pages that wrongly use {{fr-adj}} instead of {{fr-adj-mf}}. These can be found by all the pages where the feminine is the same as the page name:

{{fr-adj|sg=même|f=même|mp=mêmes}}

Should be

{{fr-adj-mf|head=même|pl=mêmes}}

Mglovesfun (talk) 16:20, 5 June 2010 (UTC)

Although....it doesn't really seem to matter, does it? The information is still accurate – if anything, the first one is clearer, since most users probably don't know what (deprecated template usage) epicene means. Ƿidsiþ 05:33, 8 June 2010 (UTC)

Virtually every other template uses m and f where this uses epicene - {{ca-adj-mf}} only uses epicene because it's a copy-and-paste job. I'd be happy for us to move to that, although it does link to epicene to explain it. Mglovesfun (talk) 22:57, 8 June 2010 (UTC)

I was looking at Special:GlobalGroupPermissions, and some of the subpages say some strange things. First, Special:GlobalGroupPermissions/Global_sysops seems to say that Global sysops can act as admins here. I thought global sysops was opt-in for large wikis? Second, Special:GlobalGroupPermissions/Global_rollback seems to say that global rollbackers count as autopatrollers here, along with some other odd rights. Are these correct? --Yair rand (talk) 23:59, 6 June 2010 (UTC)

I've asked Razorflame if he minds being part of an experiment to determine whether global rollback gives you autopatrol here - hopefully all it means is that rollbacks are marked as patrolled automatically, other edits shouldn't be here. We can ask Prince Kassad about what the global sysop stuff, I think. Conrad.Irwin 00:06, 7 June 2010 (UTC)

Global rollbackers do get autopatrol. From reading the meta page about global sysops, I don't think they have actual access here, but I don't know how to confirm. Conrad.Irwin 00:26, 7 June 2010 (UTC)

Also disturbing is that they're granted the "nuke" privilige, which we chose not to activate here. Does this mean they can do it anyway? FWIW, I looked around on the page and have no real options to do anything there as a bureaucrat except to edit our localized name for all this (which I did not attempt to change, and therefore only am assuming this is possible based on what I saw there). --EncycloPetey 00:45, 7 June 2010 (UTC)

Would you like me to see if I can just access the Special:Nuke page to confirm this? Nope, can't. Razorflame 00:50, 7 June 2010 (UTC)

Don't worry about global sysops. They won't be able to do anything here. -- Prince Kassad 07:45, 7 June 2010 (UTC)

I have seen revdel used on another Wikipedia and it is clearly apparent (to admins) whenever it is employed, so if someone should ever use it, we will know. —Stephen 14:04, 7 June 2010 (UTC)

Global rollbackers do have the autopatrol right. The rights they have are listed here, these are the only rights they have. Global sysops cannot use their tools here, for a complete list of projects Global sysops can't use the tools on, see here, and scroll down to the section "This group is limited to all wikis except the following 117 wikis." If you want Global sysops to be able to use the tools here, then you may opt-in on community consensus. Maximillion Pegasus 00:18, 8 June 2010 (UTC)

Hm. I think it would make sense for the autopatrol right to be removed from the global groups here if that's possible. Edits are not only patrolled to keep out vandalism, but also to make sure the edits follow the layout policies. As users in global groups might not know the policies, I think that the autopatrol right should be removed from the Global_rollback, steward, and Staff usergroups. --Yair rand (talk) 00:33, 8 June 2010 (UTC)

It's not possible to make that one userright not apply to one particular project, nor is it necessary, as most Global rollbackers, stewards, and staff don't edit here anyway. The only one I can think of off the top of my head is Razorflame, who is autopatrolled anyway. Maximillion Pegasus 00:51, 8 June 2010 (UTC)

Special:preferences allows you to have a banner display at the top of a user and user talk page when that user is blocked from editing. Would it be possible to adjust this banner so that it contains a link to the block log for that user? Thryduulf (talk) 12:16, 7 June 2010 (UTC)

That sounds like a good idea. Done. -Atelaes λάλει ἐμοί 12:43, 7 June 2010 (UTC)

Thanks! Conrad.Irwin 14:06, 7 June 2010 (UTC)

Thank you from me also. Thryduulf (talk) 14:46, 7 June 2010 (UTC)

One of this project's major shortcomings is that we have no way to reference individual definitions. When I write an entry for ], I have no way of specifying which sense of ] I mean. Granted, some have used short glosses after the referenced word (over (on top of, above)), but this suffers from a few problems. First of all, it's messy. The first definition of ἐπί references four English words as its definition, and including glosses for all four would make for a mess of text. Also, it's inconsistent. I could just as easily say "over (on top of)" or over (On top of; above; higher than; further up). These three glosses would all be intended to mean the same thing, and yet they're clearly different, and consequently possibly misleading. However, the biggest problem, in my view, is that they're semantically referential instead of technically referential. What I mean by that is that a person can probably parse such a gloss (albeit with the difficulties already mentioned) and use it to identify which sense is meant, but a computer program cannot. A smart computer program can take educated guesses, and I know Conrad has already done some work which is fairly good at it. But I think that we really need to make it so that a stupid program can parse it. One such program that really needs to be able to parse it is Wiktionary itself, so that a person can link a word in a definition and the link will send the user straight to that particular definition. We can already link to a specific language section of an entry (i.e. over#Latin), but we need to be able to link to a specific sense (i.e. over#English#On top of), which we cannot currently do. This is an issue which has been bothering me for some time, but I have failed to come up with a concrete proposal for a solution. However, I have recently been in contact with one of our downstream users, who noted this deficiency as one of their primary challenges in using our data, and so was spurred into bringing this here, to see if anyone has any brilliant ideas.

Now that the problem has been presented, some more technical thoughts on the matter: I had toyed with the idea of a simple list based reference system, such as sense 1 simply be referred to and linked to as over#English#1 or something like that. However, the obvious problem with that is that our definitions are constantly being added to, deleted, merged, shuffled about, and so on, and so such a system would very quickly become a maintenance nightmare. The decision I've come to is that a gloss based system is ideal, for a few reasons. First, such a system would tolerate shuffling quite well, and would likely degrade gracefully as our definitions change over time. Also, it is similar to, and consequently is easily interconverted with, the various forms already in use, both in entries which use a word as a definition, as has already been mentioned, and within the entry itself, such as in synonyms and translations. If we could figure out a way to encode an "official" gloss into every definition, and encode that official gloss into links, and teach Wiktionary to put the two together, I think it would work. By encoding the gloss into the definition itself, we produce a specific target for references, and an official standard that editors can follow. One problem with this system that Conrad noted is that it would take a lot of work. If we have to encode an official gloss into every definition, and no definitions currently have them, then we have a lot of definitions which have to have some info added to them. However, I think that we could get a very large start on the problem with automation. Since a great many of our entries have glosses already written for them, such as in the translation tables, a reasonably intelligent program could scour entries with translation tables and synonym sections, find the glosses, attempt to match up definitions with their glosses, and then encode those glosses into the definitions, were we to come up with a suitable paradigm for this. Granted, this would still leave a great many entries without sense encoded glosses, but it probably would cover most of our important English definitions, which is arguably the area where they are most needed. As for the linking method, I guess I don't know exactly how the MW program does section links, and so am unclear as to how this could be modified. If anyone knows what the methodology is, posting it here would be appreciated. -Atelaes λάλει ἐμοί 00:36, 8 June 2010 (UTC)

Jeez, long post :p. Links are done by the browser moving the top of the window to level with <a> elements with matching name="" parameters, or to elements with matching id="" parameters. MediaWiki does this (for headings) by running the contents of the heading through a HTML-stripper and then an encoder to make links that "just work" for humans. You can see how to hook into this by looking at {{jump}} (a similar idea to yours).

People already complain at having to include the glosses in translations tables - let alone including it with the definition too. That said, a tool like User:Yair rand/newentrywiz.js could easily propagate the gloss all over the entry (at creation time, and just force people never to update the glosses?). Generating new glosses from definitions is really hard (probably AI complete) - I thought about trying for Category:Translation table header lacks gloss, and haven't yet worked out anything approaching a workable heuristic - so that at least will need to be done by humans.

With no further editing work: for those with javascript enabled I had intended, in the near future, to add a PREF that highlights the linked to definition (and/or the definition associated with translations/synonyms etc. on appropriate user interaction) . For consumers, I can then publish this algorithm, and provide lists (along the lines of ) that match definitions to glosses. This leaves our javascript disabled users at a disadvantage, but it would be possible to add this as a MediaWiki extension if it works, so that it works for everyone. (Hey, we could even get it to colour bad gloss links differently :p). Conrad.Irwin 01:11, 8 June 2010 (UTC)

I would have thought that for most cases, a human-acceptable gloss can be generated by taking the text of the definition up to the first semicolon or period, and removing any initial article for noun defs or initial "to" for verb defs. Not so? -- Visviva 07:03, 11 June 2010 (UTC)

Yeah, I was kind of thinking that too, although if there already is a human added gloss in a transtable or something, then we'd prefer that. The trick really is, assuming we can figure out glosses one way or another, at least in some situations, how can we take that gloss and make it work as a technical reference to the sense? -Atelaes λάλει ἐμοί 08:14, 11 June 2010 (UTC)

I don't seem to have access to the checkboxes on "my preferences". I had also noticed other odd behavior, as {{only in}} not appearing? Is anyone else having a problem of that sort? (I see it only as a blank space in the text above. DCDuring 03:27, 8 June 2010 (UTC)

I'm not having any difficulties at present. Have you tried logging out, clearing your brower's cache, and logging in again? I've had a spate of "lost seesion data" responses of late, which may or may not be related. (but none today) --EncycloPetey 03:45, 8 June 2010 (UTC)

The disappearing templates were weird, but they appear normal now. I had some weird stray lines that showed up in my watchlist, but they had gone. I still have no access to the checkboxes on the first page of my preferences after following your suggestion. DCDuring 03:55, 8 June 2010 (UTC)

No idea what might be happening then. Hopefully it's transient, or else Conrad, Robert, or someone can offer a solution. I haven't done work in editing Preferences to know what might be the cause. --EncycloPetey 04:01, 8 June 2010 (UTC)

For the past week I have not been able to access "Recent changes (by language)" (random-page function) in the sidebar anymore. It still works for languages that use the Roman script, but I get an Internal Server Error (500) when I try to get a random page in any non-Roman script such as Russian, Armenian, Korean, Greek, Thai, or Chinese. I have asked Hippietrail about this, but he is absent for the moment.

Also, the font preferences in MediaWiki:Common.css that we have used for years for Russian, Arabic, OCS, etc., no longer work, and every script is in a sort of Times Roman style (but the increased point size commands still work, so some of these scripts are now too big). I don’t know for certain, but I suspect that all of these problems are related to the appearance changes and new skins that Wikimedia has recently instituted. I still use the old Monobook skin, but even when I try Vector, the problems do not go away. Does anyone else have a problem getting random pages in Russian? It’s very irritating. —Stephen 05:15, 8 June 2010 (UTC)

I have the same "internal server error" for random pages in non-Roman scripts. I tried Russian, Min Nan, and Armenian. For Serbian, I can get either an error or a Roman-script page returned. I suspect the error occurs when the page is a Cyrillic title. --EncycloPetey 05:22, 8 June 2010 (UTC)

I am transiently losing access to editing. The edit box appears with no fonts. I may have to take up another hobby. DCDuring 09:42, 8 June 2010 (UTC)

I've had that problem too in the past, but not on a regular or long-term basis. Usually it happens for one edit in a great while, and the problem disappears with the next edit. Are you able to try logging in from another computer to see whether it's your account/settings versus a particular machine/browser? --EncycloPetey 14:18, 8 June 2010 (UTC)

Another potentially related problem: I've just discovered that, using MS IE on a PC, I cannot compare selected revisions in a page history. The Compare button still appears, but the browser is interpreting it as "Show/Hide Revisions" rather than as "Compare Revisions" and consequently I get an "Invalid target revision" message. --EncycloPetey 19:54, 8 June 2010 (UTC)

Addendum: I do not have this "compare selected revisions" problem in Safari on the Mac I use. --EncycloPetey 02:01, 9 June 2010 (UTC)

The appearance of {{Grek}} and {{Cyrl}} have changed for me, they've become a bit larger. Grek in particular looks boxier, squarer. Mglovesfun (talk) 22:58, 8 June 2010 (UTC)

That's most likely related to changes that have been made to MediaWiki:Common.css. Thryduulf (talk) 08:40, 9 June 2010 (UTC)

• At least part of my problem was peculiar to my PC, affecting many programs. I have rebooted again and all seems OK. DCDuring TALK 23:50, 8 June 2010 (UTC)

Well, at least someone has fixed the MediaWiki:Common.css font problems, but the non-Roman random-page error is still there. I thought the two problems might be related, but apparently not. —Stephen 00:02, 10 June 2010 (UTC)

I believe that a link to Wikisaurus:tooth should appear automatically at Wikisaurus:person. However, it didn't. Apparently, this lack of an automatical link occurred because a limit for quantity of links has been trespassed at Wikisaurus:person - which is an annoying situation, because that page is not near from possible completion, thus it should grow more and therefore include more broken links. --Daniel. 20:02, 9 June 2010 (UTC)

The reason is the huge number of {{ws}} templates on the page. Each instance uses three parser function templates (#switch, #ifeq and #ifexist) so the uses quickly stack up. I don't pretend to understand what these are doing, let along how they functions work, but it might be possible to redesign the template to do the job more efficiently? If it's doing a check to see whether condition A or condition B exists and to do different things in each case, it might be better to make separate templates that don't need to do this check? I don't know whether transcluding each section of the page separately would solve the problem or just make it worse? Moving the grammar sense to a separate page would help a little bit, but not significantly I don't think given the relative proportions. Thryduulf (talk) 22:39, 9 June 2010 (UTC)

Does someone know how to adapt commons:MediaWiki:Gadget-HotCat.js for Wiktionary? (See commons:Help:Gadget-HotCat for documentation.) It needs three main adaptations that I can think of:

1. It needs to sort the categories under the appropriate language section.
2. It needs to disable the feature that automatically capitalizes the category names on the first letter as they are being added.
3. Help:Gadget-HotCat (or equivalent) needs to be created for Wiktionary, and that page needs to be linked to in the edit summary. Usually we just use the talk page of the script for documentation, it seems. It's at Transwiki:Gadget-HotCat for now —Internoob (Disc•Cont) 18:20, 14 June 2010 (UTC)

—Internoob (Disc•Cont) 02:36, 11 June 2010 (UTC)

Hmm....that looks like an interesting interface. The first step would be to import it here, and then we can start trying it out and modifying it to fit our structure. However, Special:Import does not seem to have a Commons option. I suppose that it's assumed that Commons files should be mirrored, and not uploaded. -Atelaes λάλει ἐμοί 03:15, 11 June 2010 (UTC)

I think in these situations one is supposed to just copy the page and link to its original history from inside the edit summary. --Yair rand (talk) 03:59, 11 June 2010 (UTC)

My impression was that we considered transwiki to be vastly superior to such an approach, as it keeps the record of its contributors right there. Granted, as long as we note the original page, which has the contributor list, we're still fulfilling the requirements of the copyleft licenses. If we can't transwiki, then we'll take that approach, but if we can, I think we should. -Atelaes λάλει ἐμοί 04:23, 11 June 2010 (UTC)

Ok, it's at Transwiki:Gadget-HotCat.js. It should probably be moved if it becomes something we use with any regularity. However, you should be able to try it out immediately. Just add

importScript('Transwiki:Gadget-HotCat.js');

to your monobook, refresh your cache, and away you go. I'll start looking at it, but I suspect my betters will beat me to punch on improving it. -Atelaes λάλει ἐμοί 05:14, 11 June 2010 (UTC)

Capitalization support has just been added to the Commons version: . It doesn't capitalize the first letter anymore here at wiktionary; tested through the import in my monobook.js. As to category sorting: I presume that is meant to apply for the actual edits made through this gadget. If someone could explain how this is supposed to work (I don't know your conventions at all), I could probably devise some extension mechanism by which you could just plug in a function that would determine the position where a new category should be inserted. Note that if a category is replaced, the current HotCat just inserts the new category at the place where the old category was. Maybe that behavior would also need to be overrideable here... take a look at function change_category and there in particular the cat_point handling. Lupo 10:36, 15 June 2010 (UTC)

Category sorting works like this: all categories for English words need to go at the end of the English section and before the ---- that separates the language sections if there is one (and likewise for other languages). See Malta for an example, where the German section looks like this:

==German==
{{wikipedia|lang=de}}

===Proper noun===
'''Malta''' {{n}}

# ]

====Derived terms====
* ]
* ]
* ]

]
]
]
]

----

Note that there is no ---- at the end of the very last language section. Editors also sometimes leave it out, but we have a bot, AutoFormat (talk • contribs), that adds it in after a while. —Internoob (Disc•Cont) 17:25, 15 June 2010 (UTC)

Oof. I could probably provide a hook so that you could try to write your own placement function, but writing such a function is not going to be easy with this layout. First, not all categories related to German start with "Category:de:"—in your example, there is already "German proper nouns". (BTW, the "----" doesn't seem to be necessary; using "=="-headings as the separators should also work.) Second, there'd need to be a (hard-coded?) table mapping section titles ("English", "German", and so on) to language prefixes ("en", "de") and/or vice versa. I see no way to infer the mapping from the wikitext source. Third, English appears to have no prefix at all? (Well, there is "enm"... what is that?) Fourth, one would need to consider what to do with category replacements that change the language prefix. Should replacing "Category:de:Islands" by "Category:cs:Islands" be allowed or not? (Anyway, I have trouble understanding the reason for this split. If applied consistently, you'll end up with "Malta" in a multitude of "lang:Islands" categories. It's an island regardless of the language... Why do the contents of Category:de:Islands and Category:cs:Islands differ e.g. in the "M" section? Why is "Malta" not in category cs:Islands, and Mallorca not in de:Islands? Also, a "proper noun" very often is a "proper noun" in many languages. It seems silly to me to categorize it as "English/Finnish/Galician/German/Italian/Norwegian/Polish/Serbo-Croatian/Slovene/Spanish proper noun"—and you left out Dutch/Estonian/Slovak/Swedish... well, you probably have a reason to do it that way...) Anyway, if such a replacement is allowed, shall the new category be inserted at the place where the old category was? Or in the "Czech" section? What if there isn't a "Czech" section yet? And if it should not be allowed at all, some more hooks would be needed such that language prefixes cannot be changed in the input, and wouldn't even appear in the suggestion lists.

Frankly said, I don't think it's worth trying to code a placement function that tried to account for all this. It'd be rather fragile, slow, and full of special cases. I'd propose, at least as a start, something simpler: disable auto-commit in HotCat, forcing a human review of all changes. The human operator then can easily fix misplaced categories as HotCat always edits the whole page, not just a section. Humans are so much better in dealing with irregular structures than computers... Lupo 23:09, 15 June 2010 (UTC)

I can imagine that this would be hard to program. We do, however, have templates for almost all of the language codes ({{de}} produces "German", for example) and codes can be turned into names with the {{language}} template. The part of speech categories take the full language names by convention and the topical categories take language codes, except English, which takes no prefix for topical categories (enm is Middle English). The only exceptions are categories with "derivations"; e.g. Category:French derivations, which is for English words derived from French. I can't imagine why someone would want to change the language prefix, unless someone confused their languages somewhere along the way or forgot the prefix entirely, but if they did, it would have to go under the new section. (The reason why we segregate categories by language is that they're more useful/interesting that way. If we jumbled all the languages together, we'd end up with massive categories in which it would be hard to find words of a particular language. Malta should ideally be in every category (islands, countries, proper nouns) that pertains to it in each of the languages, the reason why it isn't is because categorizing things is a very tedious job, and editors often neglect to do it.) If there's a category for a language section that isn't there, it should probably be either disallowed or added to the end with some sort of a cleanup notice.

Anyway, HotCat works really well for entries of only one language, and thank you for adapting it for us. —Internoob (Disc•Cont) 03:10, 16 June 2010 (UTC)

Well, templates like {{de}} or {{language}} don't help much. A JavaScript doesn't know what they expand to; it would have to make extra API requests to get them in expanded form. I'd really go with disabling auto-commit and fixing placement errors by hand. If someone modifies the local HotCat copy such that it does the placement as is needed here, we can then consider how to factor this code out into appropriate hooks, and then change the Commons "master" version to provide these hooks. Just ping me (preferably over at the Commons) when anything like that is ready. Lupo 07:34, 16 June 2010 (UTC)

I don't think placement matters that much as AutoFormat moves all categories to the correct language section anyway. Thryduulf (talk) 08:29, 16 June 2010 (UTC)

Really? I did not know that, but so it does. —Internoob (Disc•Cont) 16:19, 16 June 2010 (UTC)

(unindent) Thinking a little more, I think the simplest solution would be for HotCat to add new categories at the end of the page, and add a {{rfc-auto}} to trigger AF to do the sorting. Slightly more complicated would be:

• If there are other categories on the page with the same prefix or first word as the category being added, then place the new category on the line above or below that one (depending on alphabetical order).
• If there are no other categories with the same prefix or first word, place at the end of the page, and add {{rfc-auto}}

for example, if the added category is Category:French verbs, sort with other categories starting "Category:French" if they exist, otherwise add to the bottom of the page. The same for e.g. category:fr:Flowers - sort with other "Category:fr:" lines. However category:French verbs wouldn't auto-sort with Category:fr:Flowers (until AF turned up).

For modifications of categories:

• If the prefix or first word of the old and new categories are the same, leave where they are
• If the prefix or first word is not the same, then do follow the process for new categories.

I'm not a programmer at all, so I don't know how feasible it would be? Thryduulf (talk) 18:11, 16 June 2010 (UTC)

FYI: Language code <-> name conversions can be done in JS using MediaWiki:langcode2name.js. Also there are several English-only categories that begin with the name of a foreign language (examples). --Bequw → τ 05:21, 17 June 2010 (UTC)

Hmm, so how does AF know that, e.g. Category:Latin letter names should be in the English section and e.g. Category:Latin verbs in the Latin section? Thryduulf (talk) 08:15, 17 June 2010 (UTC)

It has a hard-coded exceptions for "<lang name> derivations" (and a more recent version also probably has one for "<lang name> letter names"). --Bequw → τ 17:20, 17 June 2010 (UTC)

To keep things simple then, I think there should be only two rules: (1) if a category is added, place it at the bottom of the page, (2) If a category is amended leave it where it is. With everything else left to AF. Thryduulf (talk) 21:44, 22 June 2010 (UTC)

See also . Thryduulf (talk) 21:44, 22 June 2010 (UTC)

I'm looking for a template that returns the number of links to a page, similar to {{NUMBEROFARTICLES}}. This is more for cleaning up than for vanity, but it can be for that too. ~ heyzeuss 05:29, 11 June 2010 (UTC)

The Finnish entry (deprecated template usage) koillinen, and presumably all the other Finnish cardinal direction entries, contains the following table: Cardinal Directions

It seems to me that this is the sort of thing the list templates were designed for (so this would become template:list:cardinal directions/fi. However, I can't see how to create a list template with a table layout? Thryduulf (talk) 10:33, 11 June 2010 (UTC)

Oh, you found my ugly little table. The template {{list}} doesn't accomodate tables, but this one could definitely be improved. The cells on the right column need to be aligned right and the cells in the middle column need to be aligned center. Anybody know how to do that in a wikitable? I have made it into a template, {{compass-fi}}, and put it into those eight entries. It's my first template ever! ~ heyzeuss 13:52, 11 June 2010 (UTC)

I've made the changes to the alignment as you suggested, see this edit to see how it's done. I've also added an image to the central cell, feel free to revert or change if you don't like it.

Cardinal Directions

luode	pohjoinen	koillinen
länsi		itä
lounas	etelä	kaakko

What would be good is if someone could create a generic template:compass that took a lang= parameter to incorporate the defined words for that language. That's way above my skill level though. Thryduulf (talk) 17:33, 11 June 2010 (UTC)

I've made {{compass}} because it was requested, but I have to say I do not like the idea of using a table for this, mainly for two reasons: (1) HTML tables are meant for tabulated data, not for arranging words into a pretty picture. (2) The template (necessarily, for neatness' sake) leaves out ENE, et al. (as someone else has pointed out).​—msh210℠ 19:21, 11 June 2010 (UTC)

I think this is a good arrangement for the simplest 8 points. If you can come up with an arrangement for the 32 points, that links to all the terms then that would be good though. Thryduulf (talk) 21:22, 11 June 2010 (UTC)

It looks better. I could use it for English entries, only English has terms like north by northeast. Wikipedia:Boxing the compass names 32 compass points. BTW is there a guide to wikitables someplace? ~ heyzeuss 18:45, 11 June 2010 (UTC)

The guide I use to wikitbales is w:Help:Table. If you are familiar with html tables then there are several websites that can convert between the formats automatically (search for: convert html table to wikitable or similar). Thryduulf (talk) 21:22, 11 June 2010 (UTC)

If you are interested, try the cardinal directions templates on French Wiktionary that I have made:

• fr:Modèle:rose des vents/en
• fr:Modèle:rose des vents/fi

- TAKASUGI Shinji (talk) 08:30, 27 June 2010 (UTC)

That is much nicer that the basic ones we have here at the minute. Do you think you could copy them across and translate the parameters and documentation, please? My template knowledge isn't up to the task I'm afraid, or I'd do it myself. Thryduulf (talk) 10:31, 27 June 2010 (UTC)

Since for years people have been praising {{poscatboiler}} for its functions but criticizing its complexity, I've developed a project to make editing its back end easier.

I'm going to convert the Template:poscatboiler/theList into individual templates, like Template:poscatboiler/noun and Template:poscatboiler/personal pronoun, simplify their functions and create the backend documentation. Related templates like {{tempcatboiler}} and {{affixcatboiler}} would undergo these changes too. May I start? --Daniel. 13:00, 11 June 2010 (UTC)

Yes please, that seems like a step in the right direction. Conrad.Irwin 17:24, 17 June 2010 (UTC)

These disappear and I have to use external links instead. I'm trying to add something to the Etymology scriptorium. Any suggestions? Thank you in advance. ~ heyzeuss 13:33, 11 June 2010 (UTC)

I don't understand the question, I suspect that <noinclude> and <includeonly> should feature in the answer, though. Mglovesfun (talk) 19:24, 11 June 2010 (UTC)

Depending on what you're trying to do and what templates you might be using, it could also be the result of not being in the main namespace. Some templates check the namespace to determine whether or not to display. --EncycloPetey 21:13, 11 June 2010 (UTC)

The problem seems to have gone away by itself. Interwiki links no longer disappear when transcluded into the Etymology Scriptorium. ~ heyzeuss 10:08, 16 June 2010 (UTC)

I lack the technical kung fu to do this, so any help would be appreciated.

I have found five expansive public domain dictionaries of medical terminology:

• The american illustrated medical dictionary Dorland (1922)
• A practical medical dictionary Stedman (1922)
• The practitioner's medical dictionary (1919)
• The American illustrated medical dictionary (1919)
• Appleton's medical dictionary (1915)

What I would like to do is, first get a separate list of all words appearing in each dictionary, second, boil those individual lists down to words that are missing from Wiktionary, and third, group those words by the number of these dictionaries they appear in (along with some notation of which dictionaries contain them). Presumably, a word that is missing from Wiktionary, but appears in all five of these dictionaries, should be a high priority to add, while a word that appears in only one of these dictionaries is more likely to be obscure, or a scanno. Can someone set this up? Cheers! bd2412 T 15:34, 11 June 2010 (UTC)

• By the way, is this the right place for such a request? I put it here because it poses technical challenges beyond my capacity to undertake. bd2412 T 18:23, 11 June 2010 (UTC)
• Not me, but, just to satisfy my curiosity (and because anyone who can answer your request will need to know), do you mean headwords or all words?​—msh210℠ 18:31, 11 June 2010 (UTC)

I have to assume that he intended headwords, and I would say that we should start with headwords, finish them off, and then perhaps look at all words. Oh, and this is definitely the best place we have for such a request. I'll take a look at the books when I have some time, but I strongly suspect that it'll be above my skill level. Hopefully my betters can do something. -Atelaes λάλει ἐμοί 18:50, 11 June 2010 (UTC)

It's easier to just look at all of the words, I think. One problem is the use of ' to separate syllables as well as to mark possessives in the first dictionary (haven't looked at the others). Nadando 19:31, 11 June 2010 (UTC)

I mean all words. First, we probably already have most words used in definitions, so those will get sorted out quickly. Second, if there is a word used in a definition line that we don't have, we should get that as well. In terms of apostrophes as separators, we could ignore pieces of text separated by apostrophes altogether if they are not going to yield actual words. bd2412 T 19:43, 11 June 2010 (UTC)

I can't see anything but a summary when I visit those links (perhaps because I'm in the UK?). Is the full text supposed to be available? Equinox ◑ 19:49, 11 June 2010 (UTC)

Full text for all is available in the U.S. What is it with Google Books in the UK? bd2412 T 19:54, 11 June 2010 (UTC)

I had the same problem when I was in Korea. I expect it is because the handy "anything-before-1923" rule doesn't apply in most (any?) other countries, so for early-20th-century works especially it is probably prudent for them to avoid the possibility/appearance of infringement. -- Visviva 06:05, 12 June 2010 (UTC)

Are you aware of any non-b.g.c. copies? I ask because Google instructs users, "Do not send automated queries of any sort to Google’s system: If you are conducting research on machine translation, optical character recognition or other areas where access to a large amount of text is helpful, please contact us. We encourage the use of public domain materials for these purposes and may be able to help.", and the only downloadble version seems to be an image-only PDF. Failing that, does anyone have decent OCR software they can use to extract the text from the PDF? Scanners frequently come with OCR software, though it's not always possible to apply that software to external PDFs. —Ruakh_TALK 20:30, 11 June 2010 (UTC)

Let's ask Google for help, then. bd2412 T 20:52, 11 June 2010 (UTC)

Sounds good. I'll leave that to you. :-)   —Ruakh_TALK 21:05, 11 June 2010 (UTC)

Well, I wrote them. We'll see if they answer, but if not, they are the ones putting this public domain material out there on the Internet, I do not see that they should have any say in how it is accessed and used. bd2412 T 21:09, 11 June 2010 (UTC)

Eh? Putting public domain material online is perfectly legitimate. Their terms about automated queries relate to use of their hardware. Equinox ◑ 21:21, 11 June 2010 (UTC)

Then they shouldn't make their hardware amenable to such inquiries. If it is technically possible for us to take this information, we should take it. bd2412 T 21:25, 11 June 2010 (UTC)

I disagree. The information is in the public domain, meaning that as far as copyright laws are concerned, Google can do almost anything with it — including making it available to human browsers but not to automated queries. Morally, it may have other obligations, but legally, they're on solid ground, and if we violate their terms of use by launching automated queries that they don't allow us to launch, I think we'd find ourselves on the wrong side of unauthorized access ("hacking") laws. Wiktionary, similarly, releases all of its content under various public licenses, but we still get pissy if someone tries to mirror that content by mass-querying our API (or worse, screenscraping our HTML interface) rather than by downloading our database dumps. —Ruakh_TALK 21:32, 11 June 2010 (UTC)

Automated queries just don't work on Google books - you get a nasty error message if you try using (for example) the python "urllib" calls. SemperBlotto 21:35, 11 June 2010 (UTC)

You'd need to change the User-agent string and pretend to be a specific Web browser. Not that I'm advocating it. Equinox ◑ 21:36, 11 June 2010 (UTC)

The line between automated and merely frenetic queries is rather fuzzy. It's amazing what a person can do with a tabbed browser, a few common extensions, and just a dash of hand-coded HTML. I posted some instructions for this approach a while back, somewhere or other. Importantly, I think there is a clear line between this and the kind of behavior the policy is aimed at; since the setup and execution takes actual effort for each book, this would not scale well to any sort of mass downloading initiative. -- Visviva 06:05, 12 June 2010 (UTC)

Data is on its way. -- Visviva 06:05, 12 June 2010 (UTC)

No servers were injured in the preparation of this data: 5, 4, 3, 2. The list of those appearing in only one dictionary is almost entirely chaff (47000 (non-)words of chaff), so omitted. I can provide the underlying data to anyone who is interested, but it seems a bit too bulky to post on-wiki. -- Visviva 07:18, 12 June 2010 (UTC)

Now, would it be possible to find any of those words which are actual entries in any of those dictionaries and post the defs for them? Or better yet, simply create the entries for them? Oh, and did I mention that I think Visviva would probably be able to tackle this project with ease? Well, I was thinking it when I first responded, anyway. -Atelaes λάλει ἐμοί 10:59, 12 June 2010 (UTC)

Why does it matter at all if words "are actual entries", if they are words that appears anywhere in multiple of those dictionaries? Missing words? We define 'em! Also, incredible work, Visviva! bd2412 T 15:03, 12 June 2010 (UTC)

It would be possible to post the definitions - but we don't copy definitions from other dictionaries, we figure them out for ourselves. I've made a start - why don't you join in. SemperBlotto 16:32, 12 June 2010 (UTC)

Why don't we copy definitions from other dictionaries (at least initially)? There are no copyright concerns with these public domain dictionaries. We could batch copy and paste, mark them for cleanup, and then reword at our leisure. bd2412 T 16:41, 12 June 2010 (UTC)

Given the OCR issues, I'm not sure this would be as much of a timesaver as one would hope. In this case we don't have the advantage of Webster 1913, where the entries had already been painstakingly restored by someone else. -- Visviva 17:06, 12 June 2010 (UTC)

Actually, they all are -- that is, they are all words that appeared at the head of a line, before the first period, parenthesis or bracket. Apparently I misunderstood BD's intent in this regard (see above); however, I would not expect the alternative technique to yield very much new material. -- Visviva 17:06, 12 June 2010 (UTC)

That's fine, I agree there is probably virtually nothing to be found in definition lines which will not either be found in a headword somewhere, or already contained in Wiktionary. Don't sweat it. :-) bd2412 T 17:18, 12 June 2010 (UTC)

Alternative prioritization here: User:Visviva/Medical/By links. -- Visviva 19:48, 12 June 2010 (UTC)

What I'm saying is, even if auto-creation is not a good idea, if you took the definitions from every dictionary which includes a given word, and then put its text below the word in that section, creating it would be a far faster process. Or if you set up some sort of automated process which allowed a person to pull that info up when they were ready to create the word. -Atelaes λάλει ἐμοί 20:11, 12 June 2010 (UTC)

Well, it gets a bit bulky, so has to be broken up, which creates something of an organizational issue. How does User:Visviva/Medical/By_links/A look? Could be templated so as to load the text of the definitions into the editintro, but that would make it about twice as bulky. NB, some definitions are missing from this, as I didn't correct for comma-separated headwords this time around, nor run the same heuristics that I did the first time for Appleton's. -- Visviva 03:16, 13 June 2010 (UTC)

Exactly what I was hoping for. Thanks. -Atelaes λάλει ἐμοί 13:15, 13 June 2010 (UTC)

Most of list #5 has now been completed manually. It's not that difficult. I'll let somebody else do the other lists. SemperBlotto 11:31, 13 June 2010 (UTC)

• This has now been set up to be about as easy as possible, short of a script actually writing the entry for you. Top-priority stuff is at User:Visviva/Medical/WN -- those are words in at least two of the dictionaries, with at least one prior incoming link, that also have entries in the small, largely nontechnical WordNet lexicon. Non-WordNet words with incoming links and multiple dictionary presence at User:Visviva/Medical/By_links/A et seq. Click on "load" to have the definitions and some helpful links included in the editintro.

  In the unlikely event that we run short of redlinks, I can do a more aggressive pass through the data. Please pitch in -- Visviva 02:32, 15 June 2010 (UTC)

  • Thanks to you, my friend, we are on the way to being a world class medical dictionary. I'll attack the list this weekend. bd2412 T 03:26, 15 June 2010 (UTC)

    Go for it. Once imported, one of the most useful things would be to link each obsolete or archaic entry to an entry for its modern equivalent. DCDuring TALK 11:45, 15 June 2010 (UTC)

    • I'm going to start up a Wiktionary:WikiProject Medicine to parallel Wikipedia:WikiProject Medicine, and hopefully draw some Wikipedians from that project into helping fill out our coverage. bd2412 T 16:25, 16 June 2010 (UTC)

Confused by mis-matched listings on Commons, I started this thread. The discussion may be of interest to some users here, as it seems our case-sensitivity affects operations on Commons. The consequences of this are not entirely intuitive since Commons is not case-sensitive for the first letter of a file name. --EncycloPetey 15:13, 13 June 2010 (UTC)

Our CSS specs currently set the height of the NavHead (the visible portion of the NavBar) to 1.6em. This prevents any content present from wrapping. Up til now, this hasn't been a problem, as the sole contents of the thing were the gloss and the show/hide button. However, I am running into problems with my customized translation script in regards to this. In certain cases, when a language has a very long translation, or multiple translations, the last bit can get clipped. Additionally, I've been toying with the idea of allowing multiple languages. Would anyone have a problem if we changed this specification from "height: 1.6em" to "min-height: 1.6em;", which would keep it at this height, but allow for more if needed? -Atelaes λάλει ἐμοί 12:55, 15 June 2010 (UTC)

Providing you have something that works for browsers that don't support min-height (just IE6, I think, which treats height like min-height under some situations), that should be fine. Conrad.Irwin 13:00, 15 June 2010 (UTC)

What sort of solution would there be for non-compliant browsers? Sorry, my CSS is very weak. -Atelaes λάλει ἐμοί 13:04, 15 June 2010 (UTC)

Actually, now that I think about it, the only problem that would happen is that IE6 wouldn't have a height declaration at all. I've looked at NavHeads which don't, and they work fine, they just look a little different. I have no ethical qualms about making our content just a teensy bit uglier for IE6. -Atelaes λάλει ἐμοί 13:13, 15 June 2010 (UTC)

Would it be possible for a bot to fix the thousands of entries that have links inside the form-of templates (i.e. {{plural of|]}})? The extra links are completely pointless, and also break the section links. --Yair rand (talk) 23:17, 15 June 2010 (UTC)

They are not completely pointless, as they affect our statistics. What section links do they break? Could you give an example? --EncycloPetey 02:40, 16 June 2010 (UTC)

They actually don't affect the statistics, ever since Autoformat started adding {{count page}} to entries. The links break all section links unless the section is deliberately specified inside the link (]). {{plural of|]}} or {{plural of|]|lang=es}} would just link to the page, but {{plural of|foo}} and {{plural of|foo|lang=es}} would link to English and Spanish sections, respectively. --Yair rand (talk) 02:59, 16 June 2010 (UTC)

The catch is that some of these do have the section link spelled out because (unless something has changed in the template I don't know about), the various templates do not all allow for an alternative display, and the alternative display is necessary for some languages. Whatever fix is employed would need to check for, and allow for, that possibility. --EncycloPetey 03:06, 16 June 2010 (UTC)

I think these templates should have the same parameter style as templates like {{term}} (allow for a lang= and a display parameter). I hate having to remember which styles is used by each template. --Bequw → τ 03:41, 16 June 2010 (UTC)

It looks like almost all the form-of templates have allowed an alternative display as the second parameter basically since their creation. --Yair rand (talk) 03:49, 16 June 2010 (UTC)

Which form-of templates have you checked? There are a lot of them, including some that are language-specific and so do not need a lang= parameter. --EncycloPetey 04:05, 16 June 2010 (UTC)

I believe that more than ten templates listed here use the parameter style from {{term}}, since I've introduced their standardization. The documentations have not been created or updated yet, however. --Daniel. 04:41, 16 June 2010 (UTC)

In preparation for the site-wide rollout of "Hidden Quotes", I've been thinking about its interaction with other elements already in play. Some users have expressed concerns about hidden content in general, and I've been thinking about how to address them. I was wondering what people's thoughts would be on creating a universal "show" button in the toolbar, to replace the "show all quotes" button currently added by Hidden Quotes. This would allow users a quick and efficient way to display all hidden content on the screen, including quotes, translations, inflections, and anything else which we might build hiding capabilities into in the future. To make this scalable, I was thinking that it would be better to have the "show all" function simply send out an intent, and have each JS piece which does hiding have its own hide/show all function which responds to it. However, this would involve some relatively advanced coding (truth be told, I'm not quite sure how to do it off the top of my head), and it might simply be easier to have it call each item's "hide/show all" function itself. We'd then have to add each item to the master list whenever we create them. Admittedly, we don't have that many hiding scripts currently. Thoughts? -Atelaes λάλει ἐμοί 01:25, 16 June 2010 (UTC)

I'd prefer categorized shows to be honest - I'm never interested in translations, but sometimes in quotations. I suggest creating a function so that: toggle.onclick = registerVisibilityToggle(category<String>, show<function(e)>, hide<function(e)>) can be used, and we can then have category's "translations", "quotations", "inflections" et.al. We could then make this a toolbox in its own right, or use a bar at the top of the entry like the OED. I'm planning to rewrite the NavBar stuff in the next few days so that my latest project (accelerated translation tables) can work properly. If you'd like me to give this a go at the same time, I'm happy to. Conrad.Irwin 10:42, 16 June 2010 (UTC)

That seems reasonable. I wonder if sidebar buttons would be better, as I just don't know how where we'd properly put them on top. Oh, and that code snippet you posted? Completely over my head. -Atelaes λάλει ἐμοί 12:31, 16 June 2010 (UTC)

This is now done, and below is the (slightly beta reduced) snippet of code that the translations tables use. The category name is displayed verbatim in the Visibility toolbox. As part of registering the toggle, either the show() or the hide() function will be called (depending on the user's current preferences); it's thus important to ensure that either could be run at the time you call register. Conrad.Irwin 02:43, 18 June 2010 (UTC)

    navHead.onclick = VisibilityToggles.register("translations", // category name
        function show() {
            navToggle.innerHTML = NavigationBarHide;
            if (navContent)
                navContent.style.display = "block";
        },
        function hide() {
            navToggle.innerHTML = NavigationBarShow;
            if (navContent)
                navContent.style.display = "none";
        });

Just letting watchers of this page know of an ongoing discussin at ].​—msh210℠ 19:55, 16 June 2010 (UTC)

Someone please help removing the white space generated by Nadando's {{suffixsee}} template; he doesn't know what's the problem. See it used in -ուն (-un). --Vahagn Petrosyan 16:19, 18 June 2010 (UTC)

If no one here can help, try http://www.mediawiki.orghttps://dictious.com/en/Extension_talk:CategoryTree maybe.​—msh210℠ 17:25, 18 June 2010 (UTC)

Should be fixed now. This is a MediaWiki "bug" - but probably not one that can ever be fixed now that it's relied upon. and may be of technical interest. Conrad.Irwin 18:09, 18 June 2010 (UTC)

Thanks, cirwin. I'll root for England today because of you. --Vahagn Petrosyan 18:23, 18 June 2010 (UTC)

Moving a page also moves it's talk page - but doesn't move the citations page. Can that be fixed? SemperBlotto 17:31, 20 June 2010 (UTC)

Not properly, it may be possible to rig up a javascript thingy. Conrad.Irwin 12:33, 22 June 2010 (UTC)

We wouldn't always want to.​—msh210℠ (talk) 17:14, 23 June 2010 (UTC)

I've just found this template and am wondering what the point of it is? It's presently only used on three pages, man, avokado and pronomen and all the inflections it produces have seemingly been manually linked on these three pages anyway.

I know pretty much nothing about Swedish, but at first glance I can't see these three words have anything different about them than the five or six other Swedish nouns I picked at random from the category? Thryduulf (talk) 10:57, 22 June 2010 (UTC)

Suppose that we want to show "mannar (män, man)" in once space, as it currently is on man. That's not possible with sv-noun, as far as I know, but I could be wrong, of course. Smiddle 12:05, 22 June 2010 (UTC)

Well, instead of ] and so on, {{sv-noun}} could use {{#if:{{isValidPageName|{{{1}}}}}|]|{{{1}}}}} and so on. Then it would linkify a parameter like man, but would not alter a parameter like ] (], ]). (If you do go that route, I'd recommend wrapping that bit of code in a helper template, that all the Swedish inflection templates can share.) —Ruakh_TALK 12:24, 22 June 2010 (UTC)

Good idea. Smiddle 06:44, 25 June 2010 (UTC)

Why do some entries use the 'IPA symbol' (if it is one) ɡ rather than the standard Unicode Latin 'g'. Are the actually different? Until recently I've always seen the Latin letter g used, but we have ɡ on our toolbar. Mglovesfun (talk) 13:40, 22 June 2010 (UTC)

They are actually different and the IPA ɡ should always be used in IPA transcriptions (and also the rhymes template). The IPA character is always rendered as an "opentail" ɡ (image: ) whereas the Latin character can be rendered as an opentail or "looptail" g (image: ) depending on the font. As the Latin character is not a valid IPA symbol, it should be possible to bot replace it with the IPA character. Because of the visual similarity though (the standard Wiktionary font renders both as opentail) we can expect the Latin character to continue being added by users who don't know the difference, so it might be worth making this an AF task. Thryduulf (talk) 13:54, 22 June 2010 (UTC)

It's very unusual however, for IPA to reject a Latin letter and replace it with its own version which is almost visually identical. Looking at the toolbar, this seems to be the only one of it's kind. Mglovesfun (talk) 15:08, 22 June 2010 (UTC)

Indeed, and despite looking I've not been able to find anything to say why this is the case (I did find someone's idea for IPA Scrabble though...) Thryduulf (talk) 15:41, 22 June 2010 (UTC)

I would have to assume that IPA's "rejection", as you, Martin, call it, of Latin g was not their intent at all. Originally — again, this is my assumption/guess — IPA chose Latin g as the symbol, but the open-tailed one rather than the loop-tailed one. Once computers came into the picture and it was clear that the character encoding could not specify the shape of the tail, it became necessary to do so by means of another character code.​—msh210℠ (talk) 16:22, 22 June 2010 (UTC)

I expect that if the digitization has been executed better, fonts would automatically display the open-tail g whenever the environment was specified as IPA, just as good Cyrillic fonts display differently depending on whether the language is specified as Russian or Serbian. kwami 22:16, 22 June 2010 (UTC)

So (if I've understood) it is actually a Latin g, just not one that is currently in use? Mglovesfun (talk) 16:25, 22 June 2010 (UTC)

No, it's a character based on the Latin g that has the same form as one of the two forms that the Latin g can have. Thryduulf (talk) 18:19, 22 June 2010 (UTC)

There's around 1200 pages using the Latin character, so g→ɡ is definitely a job for automation (maybe WT:RFFF?). --Bequw → τ 21:35, 22 June 2010 (UTC)

Go ahead, as long as the replacement is restricted to {{IPA}}, {{IPAchar}} and {{rhymes}} templates in the main namespace. When that's done we can assess if there are any other cases that need doing. I've made a request at User talk:AutoFormat for AF to handle the ongoing case, as people will still almost certainly continue to add g rather than ɡ, and also there will be existing ones that become templated as part of the ongoing pronunciation exceptions work. Thryduulf (talk) 22:03, 22 June 2010 (UTC)

In French Wiktionary, we have found some pages wrongly use the Greek ε instead of the Latin ɛ (fr:Wiktionnaire:Bot/Requêtes#ε → ɛ). You might have the same problem. - TAKASUGI Shinji (talk) 11:31, 27 June 2010 (UTC)

Good suggestion. I've added it to the AutoFormat request, although Robert Ullmann (who operates it) doesn't appear to be around at the moment. Thryduulf (talk) 12:05, 27 June 2010 (UTC)

Also ǝ -> ə -- Prince Kassad 11:30, 28 June 2010 (UTC)

Ok, that added to the AF request also. Does anyone know what's happened to Robert? Thryduulf (talk) 13:04, 28 June 2010 (UTC)

Did we mention suprasegmentals, like ː (check the edit toolbar for all of them). Mglovesfun (talk) 09:47, 12 July 2010 (UTC)

Non-Latin-script languages' examples sentences are supposed to be transliterated into English (WT:ELE, WT:USEX), and quotations are often also transliterated. This is currently AFAICT done with nothing indicating that the text is anything other than English. If we tag these as <span lang="langcode-Latn">, then any sophisticated enough search engine will handle them better (as will screen readers), and, as a side benefit, formatting becomes customizable through CSS. Thoughts?​—msh210℠ (talk) 18:07, 23 June 2010 (UTC)

Sounds good to me. How do you propose that that be done? Doing it in JavaScript wouldn't help search engines; and it doesn't seem like something we can expect editors to add manually. Would there be some sort of {{xlit}} template? (BTW, maybe we should do the same thing in {{term}}, {{onym}}, {{l}}, {{infl}}, and so on?) —Ruakh_TALK 18:22, 23 June 2010 (UTC)

I was thinking of a template, yes, so people would add, below a usex, #::{{xlit|lang=he|some transliteration goes here}}. AF could add missing lang codes as it does to other templates, if RU would be so kind. And, yes, we should definitely IMO do the same in term et al.​—msh210℠ (talk) 18:44, 23 June 2010 (UTC)

Naturally some consensus should exist before changing the format people type for transliteration lines across the project, but I suppose this can be set up as an optional thing for now?​—msh210℠ (talk) 17:12, 25 June 2010 (UTC)

I think a VOTE is in order: technically it doesn't contradict the current text of WT:ELE (which doesn't even mention that transliterations are italicized), but it definitely contradicts the status quo. —Ruakh_TALK 17:27, 25 June 2010 (UTC)

Okay, I've started Wiktionary:Votes/2010-06/Setting lang attribute for transliterations (and created template:xlit, and added rules to mediawiki:Common.css to style xlit).​—msh210℠ (talk) 05:20, 29 June 2010 (UTC)

How would these integrate with out quote templates? Would we add transliteration= and lang= parameters? --Bequw → τ 20:03, 2 July 2010 (UTC)

At least one of the quote templates already has a transliteration parameter (though I forget which template and what the parameter name is), and, yes, we can add it to the rest, and add lang.​—msh210℠ (talk) 03:51, 4 July 2010 (UTC)

I've made a template for usage examples ({{usex}}). It takes tr= and lang=. If we find a way to wrap the transliterations without messing up the display, then we can retrofit this one. --Bequw → τ 03:39, 14 July 2010 (UTC)

Could anyone here possibly help me create a noun template for !Xóõ? I was using Tswana's existing noun template as a base (http://en.wiktionary.orghttps://dictious.com/en/Template:tn-noun) but I'm scared I'll end up messing something up. I need a template with which I can list for every noun its plural, diminutive, diminutive plural, tone class (1-2) and noun class (1-5). Can anyone help me to do this? I'd be so grateful! Perhaps diminutive plural can be left out if that would be too cumbersome. Xoolanguage 21:46, 23 June 2010 (UTC)

{{nmn-noun}} now takes 5 parameters- tone_class, noun_class, pl, dim, and dim_pl. It would be a good idea to create some kind of appendix for !Xóõ nouns so that tone class and noun class can be linked to there from the template. Nadando 22:04, 23 June 2010 (UTC)

(@Nadando) Wow! Thank you so much! It's perfect! It feels like Christmas now! :) Could you possibly explain what you mean by creating an appendix for the nouns, though? I apologise for being so ignorant. I am still learning the ins and outs of wiktionary. Xoolanguage 00:47, 24 June 2010 (UTC)

The numbers by themselves don't mean anything the way I coded the template, which is why I suggested linking them to a page which explains the various classes. See {{ro-verb}} and the accompanying Appendix:Romanian fourth conjugation. Nadando 02:21, 24 June 2010 (UTC)

Thank you! I was successful in making some appendices. Xoolanguage 18:45, 24 June 2010 (UTC)

I have another question though, for anyone to answer if they can. I notice on the !Xóõ noun category page (http://en.wiktionary.orghttps://dictious.com/en/Category:!X%C3%B3%C3%B5_nouns), there are a lot of links to noun pages that have since been deleted, and that the page is also for some reason not displaying a lot of nouns, such as for example !ùm (http://en.wiktionary.orghttps://dictious.com/en/!%C3%B9m) which is categorised as being a !Xóõ noun but does not show up in the category. So basically the page is displaying what it shouldn't and not displaying what it should. Can any of this be fixed? Xoolanguage 18:45, 24 June 2010 (UTC)

That's strange. The problem seems to have fixed itself. Perhaps I was just looking at an old cache for some odd reason. Nevermind! Xoolanguage 18:48, 24 June 2010 (UTC)

Wiktionary does some caching on the server side, so this sort of thing happens a lot. And it has a lot of servers, so if a series of requests goes to different servers, the glitch might look like it goes away and comes back and goes away again. Categories, specifically, seem to be the worst offenders. But it usually ends up right within a day or so. :-)   —Ruakh_TALK 18:54, 24 June 2010 (UTC)

I don't know if this is something that is fixable here or needs to be taken elsewhere, but popups don't seem work in the edit window when writing posts on a liquid-threads enabled talk page (on a standard edit window, selecting and then mouse-overing a link, e.g. ], gives me the popup preview of that page. I get nothing in liquid threads). Thryduulf (talk) 00:43, 25 June 2010 (UTC)

Copied from: User_talk:Bequw#Dangling_tearoom_templates:

Per my most recent comment at WT:BP#Archiving, there are (probably) lots of tea room templates lying around the main namespace long after the discussion has ended. Sorting this out should be possible in two stages - find them and delete them:

1. Generate a list of all main namespace pages that link to Wiktionary:Tea room
2. Compare the list with the subject headers currently on the tea room page, removing from the list any that match
3. Pass the list to a bot, AWB or other automated process
4. Remove any instances of {{rft}}, {{rft-sense}} and Template:temp:tearoom on the page
5. Make a note of the list somewhere so when someone clever than me works out how to find the old discussions in the archive they can be linked to from the article talk page.

I'm asking you, because I don't have the skills necessary to do this and your work with cf(r) -> compare indicates that you do. Thryduulf (talk) 00:38, 25 June 2010 (UTC)

How would we know that someone didn't add the template to the entry, but forgot to create the TR section? Bequw?

Hmm, if the template was added recently (say within the last week) we should probably drop a note on the talk page of the user who added the template. Other than that we should just get rid of it, if can be added again after all. I say this because we can't know why the template was added. It's not like an rfv where it's clear what is being asked, and especially on large entries listing it on the rft page without will not lead to much (if anything) more useful than "huh?".

We could parse the archives and see if there is a match to the title there, but I don't know much effort that would be (there would only be a need to look in the archive covering the period ~4 months after the tag was placed if that helps). We could list any that don't match separately, and try and figure out why they were listed, however I'm not sure how successful we'd be with that (per my previous paragraph). Thryduulf (talk) 01:16, 25 June 2010 (UTC)

It's a good idea, but I'm not setup to scan page histories. Try the GP. Bequw

(copying markup and signatures from liquid threads is seemingly not possible, so apologies for the slight mangling)

Is this something that anyone else can take on? Thryduulf (talk) 08:54, 25 June 2010 (UTC)

All you have to do to find them is look at Special:WhatLinksHere/Template:rft (there are less than 500) and compare that to the list currently at the tea room. Nadando 09:25, 25 June 2010 (UTC)

I know that, but I was thinking that the job of removing them would be one for automation of some sort. And there are also {{tearoom}} and {{rft-sense}} templates to consider too. Thryduulf (talk) 10:07, 25 June 2010 (UTC)

If a user has implemented Liquid Threads and I opt out of following threads at preferences, would I still be able to see changes to the user page in question on my watchlist page? I find the liquid threads notification quite intrusive. DCDuring TALK 16:07, 25 June 2010 (UTC)

I'm trying to get the categories to work. For some reason, you can uses switches to display content, but not to include categories. I certainly can't see a problem, and trying to combined two switches into one also should work, but doesn't. Mglovesfun (talk) 19:13, 26 June 2010 (UTC)

I've fixed the templates. In future, please get templates working, and get input from the editors whom you expect to use them, before you use AWB to substitute them for existing templates. —Ruakh_TALK 20:47, 26 June 2010 (UTC)

That's what I did. I added them to a few pages (10 I think) as a test. I actually copied the code from {{fr-noun}} and the more I look at it, the more it looks correct. Is there some sort of bug where switches work for visible content, but not for categories? Or is it intentional i.e. not a bug? Mglovesfun (talk) 11:12, 28 June 2010 (UTC)

More importantly, thanks! Brilliant! Mglovesfun (talk) 11:15, 28 June 2010 (UTC)

New option at WT:PREFS. Feedback, bugs wanted. yada yada. To clarify, this was not my idea. hippietrail did it on wiktdev, and Conrad.Irwin did it on Paper View. However, my version might well be the prettiest I've seen, especially if you're using Vector, where I've appropriated their tab format. However, my CSS is not terribly strong, so any help with making it even prettier is welcome. Also, a few folks who were using hidden quotes before it was pushed site wide might have it fed to them without their consent. To any who suffered this, I sincerely apologize. -Atelaes λάλει ἐμοί 08:35, 27 June 2010 (UTC)

Known bugs can be seen at in, where the language section edit link is crushed to death, and the "most common words" bit overlaps with the wrapped languages if you're using Vector. I'm working on them, but any assistance is appreciated. -Atelaes λάλει ἐμοί 08:54, 27 June 2010 (UTC)

Also, if you have a section specific link (i.e. ]) with a language which doesn't exist on that entry, or a language which has a space in it, like Ancient Greek, you get a blank page. -Atelaes λάλει ἐμοί 09:45, 27 June 2010 (UTC)

Ok, overlap and section specific linking problems should be taken care of. Crushed edit section, however, is still crushed (I am just so inept at CSS). Also, I now realize that some of our dimmer browsers will have to have some of my functions defined for them. So, if you're on IE.......you should just switch to a competent browser. I will however, define them later today. -Atelaes λάλει ἐμοί 12:34, 27 June 2010 (UTC)

Does this default as checked??? How long has the option been available? I don't recall checking it.

I don't go for:

1. the apparent side-effect of disabling navigation by TOC
2. the loss of content space on the landing page
3. the appearance of the tabs at the very bottom of the page for entries with a Translingual section.

-- DCDuring TALK 17:05, 27 June 2010 (UTC)

It wasn't checked for me, and I haven't checked it as the intended design change doesn't sound like an improvement to me. Also the focus on prettiness rather than utility is completely arse about face (and what makes Vector so wrong in pretty much every important way). You get things working, then you make the look nice, not the other way around. Thryduulf (talk) 17:16, 27 June 2010 (UTC)

My thoughts as well. I thought that hideable quotes solved a problem citation space was an earlier attempt to solve. The problem those who edit or use sections other than the top-language section on multi-language pages experience (not getting to the desired L2 section quickly) needs another solution, less costly to other users. DCDuring TALK 17:26, 27 June 2010 (UTC)

You probably see the tabs at the bottom because you have your ToC on the right (which on narrow screens pushes the tabs below the ToC). --Bequw → τ 21:21, 27 June 2010 (UTC)

Again, I apologize for what must have been a rather jarring experience. The issue is that all the preferences at WT:PREFS are numerically encoded, and if we don't reuse numbers dead space accumulates in the cookie. I now realize that I should have simply waited for a month after the number was last used to avoid this problem. I am somewhat perplexed by your complaints about the interface, and would greatly appreciate any clarification you can give. The removal of the table of contents is not strictly necessary, but I thought it beneficial. With tabbed languages you're not seeing nearly as much content at a time, and the utility of the table of contents is thus diminished. Since it ate up a lot of space at a place where space was now more needed, especially in entries with many languages, I gave it the axe. I'm not quite sure how to interpret the complaint of "loss of content space on the landing page". For the vast majority of entries, the initial page should hold just as much content as before, as the tabs should all fit onto the initial L2 header. I've looked at a few translingual entries, and the tabs all show up at the top, just like they are supposed to on every page. If you could give me a link to a problematic page, I'd very much like to see what's happening. Finally, while I do think that aesthetics are important, the primary point of this script was usability and parsability. It was intended to make entries easier to navigate. If you could elaborate on how this is costly to users, it would help me out immensely, as I am utterly at a loss to see it. -Atelaes λάλει ἐμοί 21:23, 27 June 2010 (UTC)

1. For me, I got the rhs TOC but could not navigate using it.
2. The tabs seem to take up more space than the L2 headers, but I could be wrong about that.
3. The tabs-at-bottom problem is the result of rhs TOC interacting with the tabs as Bequw mentioned above.

For my personal "use cases": I use/edit almost entirely English. Almost all the edits I do below the English section involve correcting structure problems. I use the hidden categories to find which language section has the structure problem and the ToC to get to the section for very long entries. For shorter entries I use the ToC directly to identify the structure problems. IOW, TOC saves me time. I'm sure I could get used to a new interface> (They say you get used to hanging, too.) Is this something that it is anticipated can be opted out of/into or will it be mandatory? DCDuring TALK 22:59, 27 June 2010 (UTC)

Ah, I can see how, if tweaking header levels is a common task of yours, the lack of the TOC could be problematic. Yes, the TOC does not work well with tabbed languages, as, in an important way, much of the content that it refers to is no longer there, and thus can't be linked to. Putting the TOC back in (floated right) I now see some cases where the tabs end up well below where they should. I must admit I removed the TOC before I did my more thorough testing, and thus missed that issue. The tabs do, admittedly, take up more space when there are a lot of languages, or when the user is viewing the site on a very narrow monitor (and the problem is exacerbated when the two coincide). As for the future of the feature, there are currently no plans of any kind. I quickly grow more and more tired of trying to implement improvements to the site's interface, as nearly everyone seems convinced that our current setup is perfect. I think that I will resign myself to creating and improving my own interfaces. If people like them and want to implement them, either for themselves or for the site as a whole, then more power to them. However, creating consensus on these issues is a task I have lost my liking for. In any case, I strongly suspect that if anyone intends to push this feature site-wide, they will announce it on the BP at the very least, and you will have ample warning beforehand. In the meantime, it might be easiest to simply uncheck the box on WT:PREFS and go about your business. Again, I apologize for the inconvenience. -Atelaes λάλει ἐμοί 23:56, 27 June 2010 (UTC)

Well, yes, I've unchecked the box. As you can see, the change would do little for me and be slightly inconvenient. The surprise made me grouchy. Finding bad news with respect to my idiosyncratic use of previous improvements (rhs TOC) made me grouchier.

As far as I am concerned, the hideable quotes improvement (especially original version) gets you several free passes. So, I don't accept your apology and instead apologize for not determining that it was not you before venting my spleen.

I don't know how this would strike non-contributing users, whether or not cursed with being accustomed to the way things have been. I could see benefit in resolving the bugs and testing it on them. If registered users can opt out, I see little reason for complaints, not that there won't be any. DCDuring TALK 01:00, 28 June 2010 (UTC)

I don't think that many people (if anyone) thinks our current interface is perfect, in that they think it cannot be improved. The difficulty in improving it comes from the fact that there is no agreement on what is good and what is bad. This probably comes from the fact that there are so many different tasks we do, and so many different ways of doing things that we each have our own perspective on what works and what doesn't. Because of the way I personally interact with the site, I want to be able to see at a glance an overview of what an entry contains and to be able to jump to any part of the article with a single click - so for me the current numbered TOC at the top of a single page containing everything is ideal. For you it's obviously not, and that is equally valid. Part of the problem with developing new interfaces is that when existing functionality is removed (and this is especially true of the Vector skin) through ignorance of what others do. What may be so trivial to one person as to go unnoticed might be at the heart of what someone else does. Thryduulf (talk) 00:34, 28 June 2010 (UTC)

(following comment moved by Atelaes)

I like the idea. It does look "integrated" in Vector. A working ToC is good (or were you thinking to disable the ToC with this feature)? Will it get pushed down by images on the right hand side (sometimes images are above the first L2?--Bequw → τ 21:27, 27 June 2010 (UTC)

I moved your comment here, so as to facilitate any continuing conversation with DCDuring. I hope I was not overly bold in doing so. The TOC of contents is, in fact, hidden by this feature. However, that hiding is overridden by having the right-side-TOC preference checked in Special:Preferences. I think that, in most cases, the TOC is rendered useless by this feature, however, if everyone is up in arms about it, I may change that. I'm not positive that this will work properly on every page, but my intention was to make the tabs line up with the initial L2 header, so as to give the visual illusion that there is a single L2 header on the page, which now contains every language, instead of just one. However, the tabs are floated left, and I can see how they might be improperly offset by images on the right, above the initial L2. If you run into any pages where this happen, please let me know so I can take a look and perhaps make improvements to the code. -Atelaes λάλει ἐμοί 21:36, 27 June 2010 (UTC)

It gets pushed down by images (see euro), but we should move the images down into the first L2 anyways. The same issue, however, affects the {{character info}} templates (see my favorite usability test page a), which should be above the first L2. --Bequw → τ 18:15, 29 June 2010 (UTC)

I just thought of a solution to this, one so obvious that I feel a little stupid for not having thought of it til now. Unfortunately, my free time during the week is significantly more scarce than my free time on weekends, so it might just take me a little while to implement it. -Atelaes λάλει ἐμοί 00:38, 30 June 2010 (UTC)

You mentioned section specific links above, but they still seem to be broken- go#Czech, go, go, all just take me to the bottom of English. Nadando 02:03, 28 June 2010 (UTC)

Ah...after trying it a few times I see what's happening. Basically, it's a function of how quickly everything happens. There are a number of things which happen when the page is loaded, and they appear to be variable in the order that they happen. The relevant things which are happening include the following: 1. the html engine is building all the content based on the html, 2. the JS is looking at the html, sorting it into language sections, 3. the JS hides all the language sections except the first one, 4. the JS looks at the hash target (in this case, it's #Czech), looks to see if there is a language section which matches that hash, and if there is presses the button to switch to that section (to unhide it, and hide everything else), and finally 5. the html engine looks to see if there is an element with an id matching the hash, figures out how far down it is on the page, and scrolls down that far.

Now, ideally, everything happens in that order. If it does, the page functions as expected. You arrive to see the Czech section. However, if #5 happens before #4, then the JS still switches to the Czech section, but the window has already scrolled way down, so you're looking at a bunch of dead space below the Czech section. I wonder if, perhaps if #5 happens really early, it throws away the hash target, and the JS consequently doesn't have access to it, and consequently can't switch to the right section (in which case you're looking at the bottom of the English section). I'll have to do some investigation, and see if I can get the script to disable the window's native hash processing, to fix this. However, I also notice that clicking the ] link in the Czech def does not switch over to the English section like it should. So.....I suppose I'll need an event listener or something. Give me some time, and I'll work on this. Sorry. -Atelaes λάλει ἐμοί 02:34, 28 June 2010 (UTC)

Ok, I think I've got this nicked, and the fix actually clears up a number of minor issues which existed. However, this adds yet another function which outdated browsers can't handle. Refresh your cache and let me know how it goes. -Atelaes λάλει ἐμοί 04:48, 28 June 2010 (UTC)

Still no change for me. Also, an error when the language name is wikilinked- öv. Nadando 05:46, 28 June 2010 (UTC)

Really? How odd. Wikilinked language headers should have been good to go from the very first revision. Could I ask what browser you're using, and perhaps for a copy of any error messages you're getting? -Atelaes λάλει ἐμοί 05:58, 28 June 2010 (UTC)

FF 3.3.6. What I'm seeing is the HTML around the link- <a href="https://dictious.com/en/Lombard" title="Lombard">Lombard</a>. It still functions, though. Nadando 06:02, 28 June 2010 (UTC)

Ok, I think I've got that resolved. Try it out and let me know. -Atelaes λάλει ἐμοί 07:21, 28 June 2010 (UTC)

Ah, my solution implements a very cutting edge function (window.onhashchange), which was only introduced in FF 3.6. It looks like there might be some open source homebrew implementations. I'll see if I can import one of them. In the meantime, you might consider updating your browser. -Atelaes λάλει ἐμοί 12:30, 28 June 2010 (UTC)

Is there a possibility of this being able to work with HotCat so that the currently selected tab is the section that new categories go into? --Yair rand (talk) 19:08, 28 June 2010 (UTC)

I haven't worked with HotCat yet, so I have no idea. I'll give it a whirl, and take a look at the code, and see if I can come up with an answer for you (could be awhile). -Atelaes λάλει ἐμοί 12:02, 29 June 2010 (UTC)

Could someone with the requisite technical ability please add a "quotee=" parameter to {{quote-magazine}}, {{quote-journal}} and {{quote-news}} in the same manner as it is implemented in {{quote-book}}.

Thank you. Thryduulf (talk)

Done. {{quote-news}} uses a slightly different layout than the others. Should we standardize? --Bequw → τ 06:39, 28 June 2010 (UTC)

If it can be done without breaking anything, then yes definitely imo. Thryduulf (talk) 08:58, 28 June 2010 (UTC)

Sure, but which is preferable? --Bequw → τ 05:17, 29 June 2010 (UTC)

I'd say standardise on the format used by quote-book, as that's the most widely used. Thryduulf (talk)

{{quote-news}} has two quotee situations. When there exists an author's name, I've made it now the same format as {{quote-book}}. When there isn't (and there's just a title) it will still look like it did. --Bequw → τ 14:44, 29 June 2010 (UTC)

The default listings in my Edittools have stopped working altogether. I click, nothing happens. --EncycloPetey 21:16, 27 June 2010 (UTC)

They still seem to work fine for me. Could you perhaps try refreshing your cache, and then, if you still have problems, list the page you're editing and the character set you were trying to use, so we could attempt to duplicate your problem. -Atelaes λάλει ἐμοί 21:39, 27 June 2010 (UTC)

Mine is all right but because of my manually too much installed fonts, sometimes I can't see all the characters. I suggest to dig toward User:EncycloPetey/monobook.js. JackPotte 22:18, 27 June 2010 (UTC)

It's working for me now, but I've no idea why. I haven't changed anything at my end at all. The cache made no difference at the time. --EncycloPetey 04:23, 1 July 2010 (UTC)

Would it be possible to make the space between the word "quotations" and the adjacent ▼ or ▲ arrow a non-breaking space? It looks very odd when it gets split over two lines (e.g. it does for me at ecology). I'd just do this myself, but I don't know where the necessary code is.

Also, what do people think about making the always right aligned? Thryduulf (talk) 14:21, 28 June 2010 (UTC)

It would be nice to act on Point (1). On point (2) if I understand your suggestion - wouldn't the LH margin become very ragged if quotations were very short ? —Saltmarsh^{απάντηση} 14:57, 28 June 2010 (UTC)

Non-breaking space is in place (let me know if it doesn't work for some reason). For future reference, I do believe that all site-wide javascript written by us is at Mediawiki:Common.js . I would argue against making the buttons right aligned, as I think users with wider monitors would have trouble lining the buttons up with their defs, as well as simply being more apt to overlook them entirely. -Atelaes λάλει ἐμοί 15:03, 28 June 2010 (UTC)

nbsp worked form me (after I had forced a page reload) —Saltmarsh^{απάντηση} 05:58, 29 June 2010 (UTC)

Yes, I take the point about wide monitors. Is lining up with the right hand edge of the text if on a second line possible? My thinking is that when the entire def and fit on one line the latter is towards the right hand end of the line. When the latter is wrapped onto a second line it's towards the left. For my preference it would be good if it were consistently at the right hand end of the line - does that make sense? Thryduulf (talk) 15:35, 28 June 2010 (UTC)

Ah, that is a good point. That is trickier, but perhaps still possible. I'll think about it for a bit. However, I do worry that, now that usexes are not hidden along with quotes, defs with both will have the buttons sort of floating off to the right haphazardly. Then again, I suppose that the current placement isn't exactly great in those cases. -Atelaes λάλει ἐμοί 15:40, 28 June 2010 (UTC)

So long as this topic is active: Why is it that example sentences aren't hideable, even if they do have to be shown by default? Wouldn't it make sense to have a little at the end of the definition line, with a "Hide example sentenes" button in the sidebar, for those who want them hidden? --Yair rand (talk) 06:05, 29 June 2010 (UTC)

The technical obstacles to such a thing aren't even worth mentioning. The tricky part is getting consensus to implement such a change. If someone can accomplish the latter, I can most certainly accomplish the former. Such a person would, of course, have my full support. -Atelaes λάλει ἐμοί 11:59, 29 June 2010 (UTC)

I certainly wouldn't object to making them hideable, as long as the default is to have them expanded. Thryduulf (talk) 13:37, 29 June 2010 (UTC)

I'll ask "why?" rather than "why not?" The point of initially hiding content is to aid the visual search for desired content. Why initially show content but allow it to be hidden? We don't do that with any other content. Do you just want to enable it so someone's prefs could hide it initially as well? --Bequw → τ 14:24, 29 June 2010 (UTC)

The "Visibility" section in the sidebar allows users to set their own defaults for what is hidden. As more areas become hideable, I suspect that more users will use the Visibility buttons, and a "Hide example sentences" button would be quite widely used. I can't imagine why anyone would object to this, so long as the original default is to show usexes. --Yair rand (talk) 19:07, 29 June 2010 (UTC)

Agreed. I'll do some work on this when I got a chance, unless someone beats me to it. -Atelaes λάλει ἐμοί 12:20, 30 June 2010 (UTC)

Ah, OK. Great reason. --Bequw → τ 14:26, 30 June 2010 (UTC)

I think a "hide example sentences" button would be largely useless unless it persists from page to page (with a cookie). Who will keep hitting it each time? (An exception is those who wish to print the page, and don't want to print the example sentences. (Is our hidden content hidden on printing also? I've never AFAIR tried printing from enwikt.))​—msh210℠ (talk) 17:16, 30 June 2010 (UTC)

The Visibility settings do persist from page to page with a cookie. --Yair rand (talk) 18:46, 30 June 2010 (UTC)

They don't seem to for me.​—msh210℠ (talk) 18:52, 6 July 2010 (UTC)

You seem to be having the same problem as Stephen and Vahagn. See below. That really needs to be fixed. --Yair rand (talk) 21:09, 6 July 2010 (UTC)

Perhaps I am. I'll state my user-agent header, then, in case it helps someone debug: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19) Gecko/2010040116 Ubuntu/9.04 (jaunty) Firefox/3.0.19.​—msh210℠ (talk) 00:40, 7 July 2010 (UTC)

In my almost totally futile attempt to use {{t}} instead of bracketed links ] or script templates in translation sections, a lot of Arabic translations use {{IPAchar}}. I assume these should be removed, they don't seem to be transliterations. In short, information in translation tables should be kept to a minimum - this is why foreign language words are allowed their own entries, with pronunciations, etymologies, inflections (etc.) Trying to get all that into just a translation table would make the actual translations hard to find. Mglovesfun (talk) 12:01, 29 June 2010 (UTC)

{{IPAchar}} is used a lot more widely that it really should as there are better templates for almost everything it is used for in the main namespace (usage notes in pronunciation sections being about the only exception I can think of, and even then there are sometimes better ways). Removing them from the translation tables has my support, especially as some of the times I've seen them used they don't even appear to be pronunciaitions. Where they do appear to be pronunciations, and there is no pronunciation section on the entry for the Arabic word, then you might want to create such a section and wrap them in a {{rfv-pronunciation|/blah/|lang=ar}} template. Thryduulf (talk) 13:44, 29 June 2010 (UTC)

2 things:

1. I noticed that {{quote-book}} displays ed. or eds. for the editor parameter- can this be expanded to editor / editors?
2. Is there consensus to add a translation parameter? I see little use in citing non-English works in the English Wiktionary without a translation. Nadando 05:57, 30 June 2010 (UTC)

I agree with both of those suggestions, they should also be added to {{quote-news}}, {{quote-book}} and the translation parameter to {{quote-newsgroup}} (no need for an editor there). I also noticed that the volume parameter of {{quote-book}} is not displaying anything (volume_plain is, so it might be from when that was added a short while ago). Thryduulf (talk) 08:36, 30 June 2010 (UTC)

Abbreviations expanded. All the quote templates (except {{quote-us-patent}}) accept translation= now ({{quote-book}} actually already did). Why would we want to add the editor to {{quote-news}}? --Bequw → τ 20:05, 2 July 2010 (UTC)

I just posted a suggestion about Wiktionary on the Village pump, here. Not sure it was the right place, so I thought I'd mention it here... 83.134.216.150 14:51, 30 June 2010 (UTC)

What do you mean by "allow labelled images"? Mglovesfun (talk) 14:59, 30 June 2010 (UTC)

One way would be download an image, edit it to add numbers (with or without arrows) then upload it again. Another way might be some wiki markup to allow numbers of be superimposed over the image. 83.134.216.150 15:17, 30 June 2010 (UTC)

Right, I mean what is a labelled image? Mglovesfun (talk) 15:21, 30 June 2010 (UTC)

I'd describe a labelled image as an image with various parts labelled with a number. Underneath there'd be a legend where each number has a corresponding entry in either Wiktionary or Wikipedia. See here for some examples: Merriam-Webster Visual Dictionary and Oxford Picture Dictionary 83.134.216.150 15:34, 30 June 2010 (UTC)

I believe you can skip a step and add link directly to Wiktionary entries. My only concern with images is that they can (in some cases) take up too much space. When they're smallish and appropriate, I'm all for them. Mglovesfun (talk) 15:40, 30 June 2010 (UTC)

A bit like this. Mglovesfun (talk) 15:41, 30 June 2010 (UTC)

True, I'm not sure how the space issue would work either. Take for example spices, it could take quite a few images: , , , . On the Wiktionary definition page it might be quite cluttered. Similarly I can't see the Wikipedia article containing these images either. It sort of falls in between. (Spice@Wiktionary, Spice@Wikipedia) 83.134.216.150 16:09, 30 June 2010 (UTC)

It might be better to have a separate "Wikipicture" page that contains labelled images and a legend. Wiktionary/Wikipedia could then link to it. What do you think? 83.134.216.150 16:20, 30 June 2010 (UTC)

Wouldn't that be at WikiCommons? DCDuring TALK 16:22, 30 June 2010 (UTC)

Interesting, Spice@Commons shows various images of spices, some with links to Wikipedia. Unfortunately, clicking a different language doesn't give the same images with their translations. Also I think a picture dictionary / visual dictionary is more than a collection of images. Looking up "house" should give more than pictures of houses, but a house's component parts, e.g. the various rooms, the garage, the roof, garden, stairs, doors and windows etc. It seems to me all the raw material is already available: images on commons, definitions and translations on Wiktionary, more details on Wikipedia, but a picture dictionary presents the information in a different way. Do you guys think this is more appropriate over on Wikicommons that here on Wiktionary? 83.134.216.150 16:48, 30 June 2010 (UTC)

It does really fall between the projects - we've got the infrastructure for definitions, translations, synonyms, etc but we're not really set up to handle large (numbers of) images. Similarly Commons is designed around the management and display of lots of pictures and has limited translations support, but I don't imagine that all the other dictionary functions would go over well there. Perhaps it might work as a dedicated Wiktionary - picture.wiktionary.org or somesuch. However this would need high-level approval (Foundation level I guess, but I don't know) and how well you'd get the critical mass of editors needed to make it worthwhile I don't know. I was also wondering about whether it would work at Wikibooks, but that's a project I know very little about. More thinking is definitely required! Thryduulf (talk) 17:06, 30 June 2010 (UTC)

See Wiktionary:Picture_dictionary for the most recent previous thought on the subject. DCDuring TALK 17:28, 30 June 2010 (UTC)

Thanks for the additional information DCDuring. Thryduulf: picture.wiktionary.org sounds a good name to me. I don't know, the idea has clearly been around for a while but is there enough support to get it off the ground? I'd support any initiative to do this, but I'm not influential or connected enough to get the ball-rolling. 83.134.216.150 23:49, 30 June 2010 (UTC)

On the space issue, Visviva had done some work on the gallery functionality. We have deployed it only for some "Symbol" entries, as best I can remember.

Generally, the effort seems to need an easy-to-use method to add labels to images. I suspect that different languages have some differences in the availability of terms for the components of a real-world object. The technical skills to facilitate such work with images may be more abundant at Wikicommons than they are here.

We are still at a point where we need images from Commons to illustrate basic entries. We use {{rfphoto}} and {{rfdrawing}} to mark entries with such need. BTW, it would be handy if you operated with a username. Why not become a registered user. DCDuring TALK 09:26, 1 July 2010 (UTC)

ok have registered. One possibility might be to extend the ImageMap extension to add text labels to images. This thread briefly raises the issue. The ImageMap extension is already installed on Wiktionary. Pgr94 16:10, 1 July 2010 (UTC)

The ImageMap extension looks a little rough for getting ordinary contributors to help, but it is promising. Perhaps if we had a few images with two or three rectangles as starter examples, we could get people accustomed. I can see some value in inserting a rectangle around a feature in an image and linking to a section of a request page to ask "What is this called?". Wouldn't the images themselves have to be on en.wikt to allow us to use ImageMap or does it work on images that are housed on Commons (or elsewhere)? DCDuring TALK 16:35, 1 July 2010 (UTC)

Is this the right place to have this discussion? Perhaps it would be useful to have different threads/sections to discuss the various issues. Would Wiktionary:Picture_dictionary and its talk page be a suitable place? Some points that spring to mind: implementation, how to get encourage others to get involved, perhaps putting together a proposal as suggested here. (PS I agree with you about ImageMap - it's not ideal but what are the other options? Where is the best place to ask for suggestions? The Mediawiki mailing list?). Definitely lots that needs fleshing out! Pgr94 11:30, 2 July 2010 (UTC)

Over the past days I created a few templates that can be used to build a Picture dictionary in 4 different ways.

Picture dictionary
The sun Mercury Venus Earth Moon Mars Jupiter Saturn Uranus Neptune comet asteroid belt
Click on labels in the image
hypernym: heavenly body

The templates are

• Template:picdic
• Template:picdicimg
• Template:picdiclabel

What can be improved in these templates? I am not 100% pleased with the way to add clickable image(s) describing a hypernym of the entry. Any suggestion is welcome. See further at Wiktionary talk:Picture dictionary#New templates usable in four different ways. HenkvD 17:50, 17 July 2010 (UTC)

Great progress. I have replied on the project talk page. Pgr94 08:43, 25 July 2010 (UTC)

I like this. This is awesome. bd2412 T 01:22, 28 July 2010 (UTC)