Wiktionary:Grease pit/2013/June

For a couple of days now, the ability to patrol an edit with a single click has gone away. I can't remember who created the system. Any ideas? SemperBlotto (talk) 06:58, 2 June 2013 (UTC)

Ruakh I think. Mglovesfun (talk) 08:57, 2 June 2013 (UTC)

Yeah, Ruakh. The script in question is ], I think. I assume an update to the MediaWiki software is to blame. - -sche (discuss) 17:42, 2 June 2013 (UTC)

Indeed. The problem is that unpatrolled "diff" links in the UI no longer include the recent-changes ID (&rcid=...), which the gadget needs in order to mark the edit as patrolled (since that's how the API identifies the edit). The good news is, I added support a long time ago for Special:Contributions, which never included the recent-changes ID in the "diff" links, so that support should be mostly transferable to other pages. I'll give it a shot . . . —Ruakh_TALK 18:13, 2 June 2013 (UTC)

 Fixed, I think, but it won't surprise me if there are some cases that used to work and no longer do, or that used to work perfectly and now work less-than-perfectly. If you encounter any, please let me know. —Ruakh_TALK 04:11, 3 June 2013 (UTC)

Oh, one harmed case is Special:Watchlist. The API's list=recentchanges feature doesn't let you filter by whether a page is watched, and its list=watchlist feature doesn't offer a way to retrieve the RCID, so there doesn't seem to be a good way to handle it. This is pretty unfortunate, IMHO, since I think the watchlist is a good way to nudge admins to do a little bit of "easy" patrolling. I'll have to think about this . . . —Ruakh_TALK 04:33, 3 June 2013 (UTC)

Still not working for me. Is there anything I have to do? (I use monobook, with no customization - but "patrolling enhancements" ticked) SemperBlotto (talk) 07:21, 3 June 2013 (UTC)

Ugh, sorry, I made another change after commenting above, and apparently I failed to re-test afterward. It should be good now. —Ruakh_TALK 14:11, 3 June 2013 (UTC)

Thanks. Works a treat now. SemperBlotto (talk) 14:12, 3 June 2013 (UTC)

I seem to no longer have that little toolbox on IP contrib pages :/ Y'know the one with links for Geolocate and all that. User: PalkiaX50 ^{talk to meh} 18:17, 2 June 2013 (UTC)

I still have it. —Angr 06:42, 3 June 2013 (UTC)

I could put in Portugese mercado negro as a translation for black market if I wanted, but for some magical reason I can’t use the same box to put in Galician mercado negro. Explain this shit. --Æ&Œ (talk) 03:02, 4 June 2013 (UTC)

Having a {{trreq}} preceding or following the position of where the translation would be placed causes this bug. — Ungoliant ^(Falai) 03:06, 4 June 2013 (UTC)

I believe MewBot has fixed a load of these; could someone update it so I don't end up trying to fix a load of entries that have already been fixed. Mglovesfun (talk) 10:43, 7 June 2013 (UTC)

MewBot is still running and will be for about a week I predict, there are a lot of entries to be done still (currently 120 thousand). However, I told it to add Category:Context label misused to some of the entries (particularly Romance verbs) so they can still be found. —CodeCat 11:59, 7 June 2013 (UTC)

Once the bot finishes putting {{context}} in front of all context labels, it should be possible to make a list of misused context labels by looking for uses of {{context}} not immediately preceded by (# |#). - -sche (discuss) 18:47, 7 June 2013 (UTC)

Recently {{senseid}} was mentioned in the BP, which brought it to my attention for the first time. It looks like it was made a couple of years ago and hasn't been widely adopted. I like the idea behind it myself so I tried to use it for the senses at field and linked them to those at フィールド. It took quite a long time and added a lot of clutter to the entry. In particular I noticed that it becomes very cumbersome to use when the sense IDs are long, as they were because I was using the translation headers verbatim, as implied (but not stated) in the documentation. So I was wondering:

1. Is the use of this template still encouraged?
2. If so, are shorter sense IDs preferred? I think one-word IDs would be ideal, being perhaps the context when it is present. Putting underscores between each word is very time-consuming.

Perhaps this would be difficult, but would it be possible to add an option to select the sense ID from the wikilink pop-up? --Haplology (talk) 16:21, 7 June 2013 (UTC)

It's not necessary to replace blank spaces with underlines; MediaWiki will do that. You can use {{l/beta}} which has a parameter for senseid BTW. --Z 17:08, 7 June 2013 (UTC)

I have long thought of the senseid as an experiment. It seems incomplete and possibly abandoned. Would the widespread deployment of it make it even more difficult to contribute to polysemic English entries? Would the senseid structure be frequently broken by bad edits? Is those non-issues because those entries are now complete or because only a few experienced contributors are willing to tackle these entries and they can deal with senseid? DCDuring TALK 18:38, 7 June 2013 (UTC)

You can/should use shorter glosses, IMO. - -sche (discuss) 18:40, 7 June 2013 (UTC)

Why? Abbreviating the glosses increases the danger of adding a duplicate ID, which invalidates the page’s HTML and breaks a link. —Michael Z. 2013-06-07 19:02 z

The reason to abbreviate glosses is that a long sense ID adds a lot of clutter for the editor working on it. Take the first sense:

#{{senseid|en|land area free of woodland, cities, and towns; open country}}A land area free of ], cities, and towns; open country.

I suspect that if I were not an autopatroller, my edit to field would be reverted immediately. That's partly why I brought this up here--I thought adding a whole lot of sense IDs would irritate some people. It's hard to say how much risk there would be of broken links. In "field", I don't think that field#English-geology would ever break, but others might be harder to reduce to 3 or fewer words without ambiguity. Am I right in understanding that there is no "What links here" function for these?

I see. I see that you can’t even put a space after the trailing braces }} without it showing up on the page. What if the entire first sentence of the definition was in the braces, so there was no redundant text at all? —Michael Z. 2013-06-08 01:49 z

# {{senseid|en|A land area free of ], cities, and towns; open country.}}

You mean it isn't a template for telling different 先生s apart?. Seriously, though, "what links here" works, but it includes both these, and every other kind of link, and doesn't show which is which. As for the "whole sentence" suggestion: any rewording of the definition would break the links. The link should be free of content that future editors will feel compelled to change. Even using "sense1","sense2", etc., would lead to editors changing the numbers if they reordered the definitions. Chuck Entz (talk) 02:18, 8 June 2013 (UTC)

Quite right. There may be an advantage to going the other way, and giving the ID no meaning at all. Just a random alphanumeric like “LTas2jzH”. —Michael Z. 2013-06-08 03:28 z

There is also {{anchor}}. - -sche (discuss) 18:40, 7 June 2013 (UTC)

I would prefer keeping Sensei D friendly to humans, meaning both that it has the meaning in English and that it's as short as possible to avoid clutter and save typing. I think context labels should be used instead of glosses when possible. I added this one to isolate:

#{{senseid|en|chemistry}}{{context|transitive|chemistry}} To ] a ] in ] ] from a ].

...which is linked to by 遊離, by the way.　--Haplology (talk) 05:20, 8 June 2013 (UTC)

Each sense is a unique sense, while several can have the same usage or grammatical label. Using the label would be a bad habit for editors, and a bad example for newbs. —Michael Z. 2013-06-08 05:41 z

Underscores aren't an issue after all and the assisted gloss addition tool selects suggests senses as you type, so using the full sense would be easy, and much easier than I thought earlier. The only worry I have is people complaining about a situation like this:

#{{senseid|en|chemistry: separation of a component from a mixture}}{{context|chemistry}} The obtaining of an ] from one of its ]s, or of a compound from a ]

But if that's acceptable then using the translation header as a sense ID is fine with me. Yet I don't see why using the context as a means of disambiguation is a bad practice. Sometimes there are multiple senses in with the same context, but often not. The wording of the geological sense of field is more likely to change than the number of geological senses. I doubt it would be a problem in practice.

As for broken links, would there be an easy way to find those if links were made using {{l/beta}}? I assume there would be but I have no idea how it would be done. --Haplology (talk) 13:08, 8 June 2013 (UTC)

Using a label instead of a gloss for an ID means:

• Teaching editors to make a unique sense ID out of a label.
• Teaching them what to do when there is no label (what is that? Use a gloss, I presume.)
• Teaching them what to do when there is a duplicate label (Use a gloss for one, or both?).
• Teaching them not to add a label just to serve as the source of an ID.
• Teaching them to check the IDs when they add a sense with a label, in case it is a duplicate.
• Dealing with the mess when they add labels for IDs.
• Dealing with the mess when they add conflicting IDs for identical labels.
• Living with a system that will break HTML validation predictably, based on the content of the page.

The best way to deal with broken links is to not make broken links. Creating a unique ID from a unique gloss makes sense. Creating a unique ID from a label which may be absent or duplicated does not. —Michael Z. 2013-06-09 20:25 z

• Help:Glosses gives a pretty good description of how glosses should be made.
• Using glosses in senseids is recommended, by me at least :) . The senseid adding tool in the definition editing options gadget autocompletes to the existing glosses on the page (from translation boxes, synonyms sections, etc.) to make things easier. One significant benefit of using glosses is that it allows machines to identify other areas that have glosses as being associated with a particular definition.
• The standard linking template, {{l}}, does not yet support an id= parameter for linking to senseids, though I hope it will at some point. Once it is added, I would be glad to add an equivalent of the wikilink pop-up that would allow selecting senseids from a list. --Yair rand (talk) 14:59, 9 June 2013 (UTC)
• I have considerable doubts about senseid. It is likely to make things more complicated, the wiki markup more busy, with not much benefit. If this is to become more widespread, the supporters should better write up how that is supposed to work, what the benefits are, and admit the disadvatanges to the extent to which they are aware of them. Such a write-up does not seem available from {{senseid}} documentation page, nor is it linked from the documentation page. Therefore, I asumme that the benefits are as unclear and as poorly articulated or even unarticulated as they were years ago when senseid was discussed in Beer parlour. --Dan Polansky (talk) 18:02, 9 June 2013 (UTC)
  • One way we could lessen the clutter is by integrating it into {{context}}. That way, a context tag would automatically become a sense id. Would that work? —CodeCat 20:33, 9 June 2013 (UTC)

    A multi-functional template meant for every sense. I would call it {{sense}}, or {{s}}. Each line could look like this:

# {{s|gloss=A gloss of this sense|labels=history, intransitive|lang=en}} The definition of this sense.

• • Is lang useful? —Michael Z. 2013-06-09 20:52 z

    • The language would be necessary for the same reason it's currently needed on {{context}} and {{senseid}}. It specifies the anchor (in case several languages have the same sense id) and it sets the category language for the labels. —CodeCat 21:05, 9 June 2013 (UTC)

    Could also be {{definition}} or {{d}}. What about capitalizing some important class of template as {{S}} or {{D}}?  —Michael Z. 2013-06-09 23:33 z

Thanks for the explanations, I see now why it's better to use glosses than unique labels for sense IDs. I'll look at Help:Glosses carefully soon.

Adding a gloss field to a sense template sounds like a good idea to me. I think human eyes can easily look past a single bracketed blurb, even if it is long. Currently with {{senseid}} you have to delete a space between the hash # and the start of the definition, and it would be nice to avoid that.

For me the appeal of sense IDs is hard to explain, but when writing definitions it always feels like a struggle to get the reader to understand exactly what sense is meant. Usually I do this by lumping glosses together and hoping that the reader sees the senses that they all share, or by putting the usually associated words in parenthesis, but there's something about a linked sense ID that gives it an exact, "snap-in" feel that is very satisfying.

I notice that usually the translations are in the same order as the definitions that they correspond to, but not always: should they always be? --Haplology (talk) 06:30, 10 June 2013 (UTC)

Perhaps one contributor to the lack of use of {{senseid}} is that it doesn't really play well with things like redirects, AFAICT. It would be very handy to be able to use redirects to get people from an expression like "our butts" to butt#English-body, self. I thought it could be done, but I tried several approaches that didn't work at one's butt. Many of the entries for highly polysemic English terms are very hard to sift through without something better than the very poor section-level granularity that we can achieve. We know what definition would help a user interested in a given SoP expression, but can't direct her to it, AFAICT. (I hope I'm wrong about this.) — This unsigned comment was added by DCDuring (talk • contribs) at 21:15, 14 June 2013 (UTC).

Redirects to senses seem to work fine... --Yair rand (talk) 17:00, 24 June 2013 (UTC)

Maybe I should have waited longer. Many cross-entry things don't work right away. My first attempt was well-formatted and didn't work right away, so I fooled around with alternatives, thinking I'd forgotten what redirects were supposed to look like.

This could enable the creation of a lot of helpful redirects for failed RfD items. DCDuring TALK 19:37, 24 June 2013 (UTC)

There are a lot of spambot using the code <br> (for break, linebreak). Can we block these edits to save time? I'm spending more and more of my time deleting spam. Mglovesfun (talk) 20:31, 7 June 2013 (UTC)

I wish there were a way to block user-page creation by accounts with no mainspace edits- though it might just encourage garbage edits. Chuck Entz (talk) 02:27, 8 June 2013 (UTC)

Although the prefix search (Special:PrefixIndex) comes in handy at times, I would dearly love to have the equivalent for search words with a common ending string, like what Perseus has for its "Dictionary Entry Lookup" tool. Is there any way to do that here? Chuck Entz (talk) 03:51, 8 June 2013 (UTC)

I just use, as an example, *ization in the Search box. You just get unformatted search results, but that's often what you want. SemperBlotto (talk) 07:01, 8 June 2013 (UTC)

Do we really need to have script errors for using {{term}} with a language family name? See chigoe. DCDuring TALK 16:07, 8 June 2013 (UTC)

What alternative do you suggest? —CodeCat 16:17, 8 June 2013 (UTC)

How would I know what's possible? Can I insert sc=Latn? DCDuring TALK 16:49, 8 June 2013 (UTC)

Apparently, I can. The error message is somewhat less dramatically ugly. Good enough for me. DCDuring TALK 16:50, 8 June 2013 (UTC)

As far as I know we don't have entries for entire language families, so I don't know why it should be linked. DTLHS (talk) 16:52, 8 June 2013 (UTC)

That's why I asked. Such terms shouldn't actually exist, neither in a dictionary, nor in real life. So they don't actually meet CFI and should probably use {{recons}} instead. —CodeCat 16:57, 8 June 2013 (UTC)

The term is from an unknown member of the family, probably from a time when those in contact were not particularly interested, probably from a language that was and remains little attested. I guess that makes it a nonword. It is obviously not reconstructed by linguists. DCDuring TALK 17:42, 8 June 2013 (UTC)

But if it's not reconstructed then it must be attested, right? And if it's attested, wouldn't we also know the language? Or is there a kind of "gap" in CFI in this case? —CodeCat 18:12, 8 June 2013 (UTC)

Of course there's a gap. In the real world there can be terms that are not attested and not "reconstructed". The reporting is simply not sufficient to merit inclusion as far as we know. I can't say for sure whether this term is attested in one of the five language that are recognized members of the family. I can say that we will be slow to find out if we make it hard for an interested person to find references to the putative term. Taxonomic names are chock full of names that provide some early evidence of words from native languages. I don't understand whey we don't use term to generate lists of missing words in each language. Such lists would be at least as good as the pages at WT:RE. DCDuring TALK 19:38, 8 June 2013 (UTC)

(edit conflict) I've run into this kind of thing with California Indian languages: early sources may be the only record of extinct languages, but the missionaries, explorers, etc. who wrote these things down didn't know/say what language they were recording (at least not with the kind of precision suggested by use of a language code). Evidence from related lects and comparative work may narrow it down to a given group of languages, but that's it. The terms are definitely attested, but their exact language isn't known. In some cases, it's different enough to assign its own language name (Crimean Gothic may be an example of this, for instance), but often the evidence is too fragmentary to be sure it's not a variety of something already known. While linguists are debating back and forth over the decades about the identity of such fragments, you can't pin a language name on it, but it's not a reconstruction, either. Chuck Entz (talk) 20:03, 8 June 2013 (UTC)

I suppose we could allow {{term}} to use family names then, but only on the condition that the first parameter is blank (no link)? —CodeCat 20:10, 8 June 2013 (UTC)

Alternatively, what I had started doing was writing {{etyl|afa|en}} {{term|foo|lang=und}}. - -sche (discuss) 20:48, 8 June 2013 (UTC)

Both solutions lose the possibility for using term to generate categories of missing terms by language/language family in the way that {{taxlink}} does for taxonomic names. DCDuring TALK 22:04, 8 June 2013 (UTC)

What exactly do you mean by "missing term"? Do you mean that the template should check if the link target page exists? —CodeCat 22:05, 8 June 2013 (UTC)

Requesting permission for these edits. This is at the request of User:Bumm13. The bot will upload approximately 4557 pages (skipping any pages that already exist). It will also skip any characters without definitions. Test / example edits: 㔫, 㨀, 㨁. I can also provide a file with all of the pages I intend to create upon request. DTLHS (talk) 22:02, 8 June 2013 (UTC)

Would it make more sense to put the definitions in the Mandarin section? (See this short discussion of 佦.) - -sche (discuss) 04:14, 10 June 2013 (UTC)

Not necessarily, some characters simply don't exist in Mandarin, and certain meanings may be restricted to certain languages (e. g. Cantonese), so just putting everything in Mandarin doesn't work. -- Liliana • 04:28, 10 June 2013 (UTC)

See WT:Information_desk#PhD_research_-_inclusion_dates.

She seems to looking for the date when entries were first created - for all entries - or is that all L2 sections? DCDuring TALK 16:38, 11 June 2013 (UTC)

Is anyone able to make an inventory of all redirects that point to a context label template, along with the template they point to? A list of pairs, in other words, like: Template:UK - Template:British. Alternatively (perhaps better), could a category be added to them instead, like Category:Context label redirects (yes, you can categorise redirects!)? That would be very helpful in converting them to a module at some point, and it would also give us an idea of which labels actually exist (in case we want to weed some of them out). —CodeCat 17:03, 11 June 2013 (UTC)

User:Robert Ullmann/Context labels covers this, just it hasn't been updated for a long time. Mglovesfun (talk) 17:21, 11 June 2013 (UTC)

{{rel-top}} does not seem to function outside of principal namespace, eg, in Appendix space and User space. This seems like yet another regression. Can it be fixed? DCDuring TALK 18:11, 11 June 2013 (UTC)

I can't see anything about it that would make it not work. It should just be fine... —CodeCat 18:13, 11 June 2013 (UTC)

I know that it should be. Have you tested it in any space other than principal namespace? Try User:DCDuring#Taxonomy. On my PC (Win 7, FF 21) the all-important unhiding icon is not visible and the unhiding functionality is absent on that page and on a test I ran in Appendix space. DCDuring TALK 18:20, 11 June 2013 (UTC)

Also, as my computer is rarely off and keeps several windows open continuously, including to my main user page, this behavior need not have been caused by a recent change, but could have been caused by something days or even weeks ago. As I am neither a CSS nor a template maven, I have no idea of what the cascading consequences of changes to classes might be or even where to find the various class definitions. DCDuring TALK 18:25, 11 June 2013 (UTC)

The "show" button is visible for me and works as normal. I think it must be on your end? —CodeCat 18:28, 11 June 2013 (UTC)

Aarrgghhh. I have not changed by CSS or JS in a long time. What could make a difference in any of the preferences (though I don't remember making a change there either)? DCDuring TALK 18:31, 11 June 2013 (UTC)

I can't unhide the above. DCDuring TALK 18:34, 11 June 2013 (UTC)

And can make trans and rel unhiding work as normal in principal namespace. DCDuring TALK 18:37, 11 June 2013 (UTC)

I'd always wondered what kind of thing would finally get me to stop spending time here. This would be an example. DCDuring TALK 18:58, 11 June 2013 (UTC)

In both Firefox and Opera, on a PC running Windows 7, the above rel-box works for me. :/ A while ago, some users complained that the "show quotations" button was missing, and I found that it was indeed taking a while longer than usual to load. That problem seems to have cleared up, but perhaps some of the elves/hamsters that run javascript call in sick from time to time? Because it's javascript that collapses the boxes in the first place, you could temporarily disable javascript, which would have the effect of making the boxes display open (and uncollapsible). - -sche (discuss) 19:15, 11 June 2013 (UTC)

What's strange top me is that in principal namespace it works fine, but not in User, Appendix, and Wiktionary spaces. How would JS become inoperable, 1., by mistake, and/or 2., only in some namespaces? DCDuring TALK 19:57, 11 June 2013 (UTC)

It happens to me on Chrome to, but only when I am logged in, not as an anon. That seems to be a diagnostic help. DCDuring TALK 20:02, 11 June 2013 (UTC)

"Doctor, whenever I use the monobook skin (both in Firefox and Chrome), I can't use rel-top. What should I do?"

"Stop using monobook."

It's an old joke. Was I the last one using monobook? DCDuring TALK 20:25, 11 June 2013 (UTC)

For the purposes of this thread, I just switched to Monobook, and I am still able to open the rel-top in this thread. You and I seem to be using the same system (Monobook, Firefox 21, Windows 7). I'm stumped. - -sche (discuss) 00:08, 13 June 2013 (UTC)

I still have the problem in Monobook, not Vector. I have no skin-specific JS. I assume that the problems is somewhere in the JS created by the selection of preferences for gadgets, in the interaction with some feature of the Monobook skin, which may not have been as thoroughly tested. DCDuring TALK 01:31, 13 June 2013 (UTC)

It seems to have had to do with selecting "translate sidebar interwiki links into English" in gadgets for Monobook, but not Vector. I really do prefer Monobook. DCDuring TALK 02:57, 13 June 2013 (UTC)

My watchlist seems to be now permanently broken: it always times out (since several weeks ago). Perhaps this is because of a large number of bot edits recently? What can I do about it? I would even consider wiping the entire list back to nothing, if this can be done. Please respond by talk page since I cannot watch this page. Equinox ◑ 12:09, 12 June 2013 (UTC)

Okay, hiding bot edits seems to have fixed it (for now?). Equinox ◑ 12:40, 12 June 2013 (UTC)

If you ever do want to wipe your watchlist clean, the quickest way to do it is to go to Special:EditWatchlist/raw, select all, and delete. —Angr 12:54, 12 June 2013 (UTC)

Actually, that page times out too, and did so long before my actual watchlist started timing out. Equinox ◑ 12:57, 12 June 2013 (UTC)

Well, that sucks. How many pages you got on there? Does the nonraw Special:EditWatchlist work? 'Cause if you can't access either of those pages, the only way I know of to reduce the number of pages on your watchlist is one by one (slightly faster if you're using pop-ups than if you open each page separately). —Angr 13:02, 12 June 2013 (UTC)

Is this worth a bug report? I find the watchlist to be hard to manage in a way that enables me to keep track of what I'd like to and not too much else. It is easy to forget to watch individual pages and watching every page one edits by default leads to glut. If high-volume contributors don't watch pages, that places even more burden on recent-change patrollers.

Also, doesn't this connect to #One-click patrolling gone away? Ruakh made changes and refers to Special:Watchlist as possibly being adversely affected. DCDuring TALK 13:10, 12 June 2013 (UTC)

No — I meant only that the use-case of one-click patrolling at Special:Watchlist is adversely affected by recent MediaWiki changes, in that even after my compensatory changes to the Gadget, some unpatrolled edits on Special:Watchlist will continue to have the red exclamation point instead of the blue button. —Ruakh_TALK 14:43, 12 June 2013 (UTC)

— does this page time out too? If not, there is a possibility you can wipe your watchlist with mw:API:Watch. Keφr 18:15, 12 June 2013 (UTC)

Vote for this bug at bugzilla. DCDuring TALK 22:55, 12 June 2013 (UTC)

Hi, I don't know if a discussion has already been had on this, but I think we need a template for approbative. We already have {{pejorative}}, but not its antonym. I'm happy to make the template if one doesn't already exist under some name that I haven't already looked for. Thanks! --Person12 (talk) 23:38, 14 June 2013 (UTC)

What kind of words would it be used for? There is {{politically correct}}. — Ungoliant ^(Falai) 23:58, 14 June 2013 (UTC)

E.g. awesome (adj) sense 2, cool (adj) senses 6&7, hot (adj) senses 6&10, positive (adj) sense 18, and many others. "Politically correct" wouldn't work at all: for one thing, it's such a subjective and loaded term, and for another, it's not the grammatical opposite of pejorative, which, I believe, is "approbative".--Person12 (talk) 00:26, 15 June 2013 (UTC)

I see. In that case, would an approbative label really be necessary? Isn’t the fact that the relevant definitions of awesome, cool, etc. are approbative made clear by the definition (unlike pejorative, which is not obvious in cases like gringo)? — Ungoliant ^(Falai) 00:42, 15 June 2013 (UTC)

I think an approbative label would still be really helpful. I don't think the definitions necessarily make it clear enough for all possible readers, and I think it would be worth having the associated category/list (I'm assuming a category is automatically created when a label is used - is that right?). --Person12 (talk) 10:07, 15 June 2013 (UTC)

Yes, as long as you create the template and it has poscat= parameter. — Ungoliant ^(Falai) 11:19, 15 June 2013 (UTC)

We do not label words like bad or evil as "pejorative". Why would we label good as "approbative"? Why would we label any adjective more-or-less synonymous with good as "approbative"?

Furthermore, approbative is not a word I would want to be subjecting our users to. Many would probably have some trouble with pejorative. Approbative is used less than 0.5% as often as pejorative in BNC+COCA.

If we are going to do something like this, we should probably start with an Appendix of such terms to iron out the conceptual problems before rolling it out. DCDuring TALK 14:22, 15 June 2013 (UTC)

Great, the Appendix idea sounds fine.

Labelling certain words 'approbative' would make it clear that the word is being used to express approval when that might not be sufficiently clear otherwise. E.g. the (New Age jargon sense) of positive could (in my opinion) benefit from another label to further distinguish its (much more subjective) usage from the (much more objective) scientific senses/usages.

As for those who personally dislike the words 'approbative' and 'pejorative', they are more than free to express their opposition. In the case of the latter, though, wouldn't that suggest starting a discussion here?

(p.s. You ask "why would we label good as "approbative"?" I actually didn't suggest labelling 'good' as 'approbative', or 'bad' and 'evil' as 'pejorative', for that matter. Just for the record.)--Person12 (talk) 03:47, 16 June 2013 (UTC)

I don't intend for the Appendix to necessarily be the exclusive home for these permanently. Marshall some examples, spanning the range of possibilities. Provide some rationale for selection or for exclusion of words that a naive observer might believe should be so labeled, eg, like good, youthful, energetic. As far as I'm concerned, give a month for objections or a week after comments negative or qualifying comments stop flowing in and start rolling it out into entries.

An additional question is whether these words should be categorized. I believe not, at least if you do not intend to include in the category all words that are "approbative", which would at least arguably include good. To me categories always imply that the goal is to include all terms that have meet the criteria or have the attribute. DCDuring TALK 08:27, 16 June 2013 (UTC)

Do we have a usage rationale for Template:pejorative? The usage rationale for an 'approbative' (or whatever term that might be agreed upon) template would be the same.

(p.s. one particularly interesting example would be sense 9 of bad.) --Person12 (talk) 09:01, 1 July 2013 (UTC)

That example reminds me of the fundamental conflict between what should be in a category to make the category as complete as possible and what should appear in an entry to make it as useful as possible. We might want to mark the positive/approbative sense of bad for the benefit of users. I can't imagine the user value of marking every other sense of bad as "pejorative". But I could see that someone might believe it desirable to include ] in both categories, if there are to be such categories.

Also, see Category:English contranyms, in which ] should be categorized. DCDuring TALK 13:42, 1 July 2013 (UTC)

Do we have a usage rationale for Template:pejorative?--Person12 (talk) 11:00, 2 July 2013 (UTC)

It's used for words that have a negative meaning or connotation that might not obvious to at the very least a foreign learner. emo and gay have acquired pejorative meanings that ought to be marked if only for that reason. Some duplication is unneeded, though (e.g. banana doesn't need the pejorative mark when it's already noted as an ethnic slur!). I agree that approbative might be useful for terms that can be used as both insult and praise, adding punk and wicked to the above example. A category without template would still be useful. After all, we have a category for English contranyms... (some of which would get the approbative template, mind you) Circeus (talk) 16:04, 6 July 2013 (UTC)

Thanks, but I guess what I meant was wouldn't it be worth having the usage rationale explained at Template:pejorative?--Person12 (talk) 04:35, 26 July 2013 (UTC)

These three entries have errors because the language uses a script code that we don't actually have, Jurc and Lina. This should probably be fixed somehow, either by creating these codes or by changing the script for these languages. —CodeCat 23:39, 14 June 2013 (UTC)

The entries are in Latin script, so I guess their languages’ script should be changed to Latn until the actual script is included in Unicode. — Ungoliant ^(Falai) 23:56, 14 June 2013 (UTC)

Indeed. Mglovesfun (talk) 10:58, 15 June 2013 (UTC)

I'm not able to edit these entries. I can view them, but when I make an edit, I get a wikimedia error when I save it. Is anyone else able to? —CodeCat 21:24, 15 June 2013 (UTC)

I can't either. Is your bot able to edit them? DTLHS (talk) 21:26, 15 June 2013 (UTC)

Both pages begin with U+FEFF (ZERO WIDTH NO-BREAK SPACE). Unfortunately even if I remove this character in a text editor I still can't save the pages. DTLHS (talk) 21:34, 15 June 2013 (UTC)

My bot isn't able to either, it gets an error. —CodeCat 21:52, 15 June 2013 (UTC)

I tried moving it around, didn’t fix the problem. Oddly enough, I got the error message when moving, but the page was moved anyway. — Ungoliant ^(Falai) 22:06, 15 June 2013 (UTC)

I was able to revert to a version from 2008 (the latest I could view in the history). I still can't view any of the diffs from then until now. DTLHS (talk) 22:06, 15 June 2013 (UTC)

These entries working fine in my mirror (from the latest dump). — Ungoliant ^(Falai) 22:11, 15 June 2013 (UTC)

Actually no. I added one character and the diff says +1,761 bytes! — Ungoliant ^(Falai) 22:14, 15 June 2013 (UTC)

If I copy the content of ] as it was at 03:07, 10 February 2013 into another page, I can edit that page, and save it, and edit it some more... but I can't edit ] itself. - -sche (discuss) 22:56, 15 June 2013 (UTC)

OK, I just updated the page. If you compare these diffs, you'll notice the dismal nesting of {{term}} that I fixed (thanks to Ungoliant for the assist). - -sche (discuss) 23:08, 15 June 2013 (UTC)

Nesting of another template inside {{term}} seems to have also been responsible for breaking the Hebrew page. - -sche (discuss) 23:09, 15 June 2013 (UTC)

The bad formatting was introduced by Doremítzwr in this diff (you can view the diff if you turn "do not show page content below diffs" on in your preferences), but the page was often edited after that, so it must be only a recent change to {{term}} or to MediaWiki software that causes such bad formatting / nesting to actually break the page. - -sche (discuss) 23:24, 15 June 2013 (UTC)

Is all nesting inside {{term}} a problem? I may have inserted some instances of {{taxlink}} in {{term}}.

Is the problem due to recent changes in {{term}} or something {{term}} uses? DCDuring TALK 23:27, 15 June 2013 (UTC)

Might be a result of Luaisation. My mirror has the latest MediaWiki and no Scribunto, and these entries are working fine (the byte amount bug was unrelated.) — Ungoliant ^(Falai) 23:34, 15 June 2013 (UTC)

This apparently depends on namespace- I can't reproduce the bug on my own sandbox. DTLHS (talk) 00:07, 16 June 2013 (UTC)

So one minimal way to reproduce the error is {{term||{{various templates}}}}. Templates that fail in this context include {{asdfg}}, {{test}}, {{term}}, {{soplink}}, {{lang}}, {{diff}}. Templates that do not fail include {{temp}} and all language templates. DTLHS (talk) 00:32, 16 June 2013 (UTC)

Pretty sure it fails simply if the offending template directly calls any other templates. DTLHS (talk) 00:38, 16 June 2013 (UTC)

Hi all. I saw this earlier today and didn't respond then because you all were able to work around it. But now that I'm back on my computer, could I ask one of you to report this as a bug so we can take a look at it? Our bugtracker and mw:How to report a bug. Thanks! Greg (WMF) (talk) 05:04, 16 June 2013 (UTC)

Bug reported here. DTLHS (talk) 19:28, 16 June 2013 (UTC)

The problem lies with Module:term cleanup, probably specifically to the containsRange function and with mw.ustring.gcodepoint. DTLHS (talk) 17:50, 16 June 2013 (UTC)

{{taxlink}}, probably because it is extremely simple-minded, apparently does not have a problem when used in the second parameter of {{term}}. Of course, it conspicuously fails in the first parameter. DCDuring TALK 18:35, 16 June 2013 (UTC)

As we specify language for templates like {{rfv}} and {{rfv-sense}}, can we not have the section header on WT:RFV link back to the right language section on the entry? Or, better, the location of the RfV tag (or the first RfV tag) with the right language? DCDuring TALK 01:15, 18 June 2013 (UTC)

BTW, it wouldn't hurt to display the language of the RfV in the header, especially for non-English terms. DCDuring TALK 01:17, 18 June 2013 (UTC)

Sure, though I'm not strongly in favor of it either. Mglovesfun (talk) 10:21, 18 June 2013 (UTC)

Done for {{rfv}}. Is there a specific reason you requested that and {{rfv-sense}} but not the other templates ({{rfd}}, {{rfd-sense}}, {{rfd-redundant}}, {{rfc}}, {{rfc-sense}}, {{rft}}, {{rft-sense}}, {{rfv-etymology}}, any others I've missed)?​—msh210℠ (talk) 17:28, 18 June 2013 (UTC)

Oh, you said "templates like". Sorry.​—msh210℠ (talk) 17:29, 18 June 2013 (UTC)

Done for {{rfv}}, {{rfv-sense}}, {{rfv-etymology}}, {{rfd}}, {{rfd-sense}}, and {{rfd-redundant}}.​—msh210℠ (talk) 18:03, 18 June 2013 (UTC)

There probably are other templates that would benefit, but none more than these. Thanks. I hope others find it as useful as I do. DCDuring TALK 02:26, 21 June 2013 (UTC)

I see that Conrad.Bot hasn't run to rebuild language indexes for over a year. Does anyone have the time/expertise to take over this really useful task? SemperBlotto (talk) 14:53, 18 June 2013 (UTC)

There is a proposal to add two fields to the watchlist database, one a timestamp, the other a hundred characters for input by user, which could support customized to-do-list-like watchlists. The second might enable a user to express a preference for watching only one or more section(s) of the entry (eg, language sections !!!), which preference might be used by some enhanced watchlist software to serve up only entries that have such changes to one watchlist page. The timestamp could facilitate editing one's watchlist based on when one started watching, in addition to whatever was in the 100 character field.

There might be some momentum because this is a change to support "editor engagement", which seems to be a strategic thrust at MW: They are trying to do things to get/keep editors involved in the basic work at all the projects. I've made some comments, but more technically proficient folks should weigh in at MW. We don't have to have a united front at this stage, so feel free to disagree. DCDuring TALK 02:22, 21 June 2013 (UTC)

Hi,

Does someone know why the first user who had suppress this page hasn't name?

Thanks by advance, Automatik (talk) 14:59, 23 June 2013 (UTC)

If you look at the page history, the move was done by the conversion script that implemented the change from all upper case to lower case for entry names. From User:Conversion script, it would seem that it's a special type of account that doesn't show up in some logs- but I have no clue as to the technical details. Chuck Entz (talk) 15:33, 23 June 2013 (UTC)

That was way back in '05. I wonder how many technically adept folks remain who were here then. DCDuring TALK 15:39, 23 June 2013 (UTC)

Paul G. seems to have made the same move later in the same year, but if you are an admin and you view the delete revisions, there's only one, the one by Paul G. I have no idea but it also doesn't matter so it's purely an exercise in satisfying our own curiosity. Mglovesfun (talk) 15:45, 23 June 2013 (UTC)

As Chuck says, the first move was made by the Conversion script, which was not a user or even an account in the usual way, but a script that was run (by the developers? directly on the database?) when the decision was made to make Wiktionary case-sensitive (and it was realised that it was easiest for all pages to be moved to lowercase and the few capitalised words to be moved back, than to try to decapitalise all the appropriate words by hand for the sake of not erroneously moving ] to ]). Prior to that, pagetitles were automatically capitalised, as they are on Wikipedia. - -sche (discuss) 17:05, 23 June 2013 (UTC)

Interesting. Thank you all for your answers :) Automatik (talk) 21:42, 23 June 2013 (UTC)

Would someone less intimidated by template syntax than I am please edit Template:inflected form of so that it accepts the lang= parameter in the usual way, i.e. so that it links to the specific language section of the page in question? Thanks! —Angr 15:46, 23 June 2013 (UTC)

Will mw:User:Remember_the_dot/Syntax_highlighter help with your anxiety? I would have done it, but that would probably need some editing of {{wlink}}, which I cannot do, and I am actually unsure if that matches the intention of whoever made that template. Keφr 16:43, 23 June 2013 (UTC)

Probably not, no. Keeping track of closing brackets is the least of my problems. Maybe someone else can do it? —Angr 17:11, 23 June 2013 (UTC)

Done. I did not add script support, however.​—msh210℠ (talk) 21:22, 24 June 2013 (UTC)

Undone. What I did should have worked AFAICT but added an uncalled-for linebreak, breaking things (besides lines).​—msh210℠ (talk) 21:27, 24 June 2013 (UTC)

Redone, including script support. Nothing seems to break. Keφr 12:16, 26 June 2013 (UTC)

I want to try to convert the form-of templates to Lua and make a single common module for them. Then issues like this should no longer happen because they share the same code. —CodeCat 12:20, 26 June 2013 (UTC)

Sure, why not. Keφr 18:41, 27 June 2013 (UTC)

There's a great concept behind Template:etymtree, but something goes wrong on this page: Appendix:Proto-Balto-Slavic/wandō. - -sche (discuss) 18:50, 23 June 2013 (UTC)

Looks fine to me. What's the problem? —Angr 21:24, 23 June 2013 (UTC)

It was only showing up as a script error, but Yair fixed my erroneous invocation of it. - -sche (discuss) 21:37, 23 June 2013 (UTC)

I've been chewing for a while on the issue of discoverability, and by extension, of whether to go about creating entries for the various inflected forms of Japanese terms. I tried searching for 誓って (chikatte), the conjunctive inflection of verb 誓う (chikau, “to swear, to make an oath”). Our Search feature comes up with nothing. I click through to the 誓う page and expand the Conjugation section, and there it is, 誓って, staring me in the face.

This leads me to my questions:

1. Why is Search not finding 誓って? Is it because this form is supplied by a template, and is not actually present in the wikitext of the page itself? Is there any way of fixing how Search works to also find strings supplied by templates?
2. Somewhere along the way, I came by the understanding that we shouldn't be adding in entries for inflected forms in Japanese. (I cannot recall how or where I gained this impression, and I'm perfectly happy to change my m.o. in this regard.) I see, however, that we do have entries of inflected forms in other languages, such as quiero or isst or amat, or apples or tāngata or kerkje. Given the failures of the Search feature, should we likewise create entries for inflected forms of Japanese terms?

I look forward to your insights and advice. -- Eiríkr Útlendi │ Tala við mig 19:29, 23 June 2013 (UTC)

I don't see why we shouldn't have Japanese inflected forms, regardless of whether the search is fixed. —CodeCat 19:36, 23 June 2013 (UTC)

Indeed the search only parses the source and doesn't take templates into account at all. But you can use Google Search for that. -- Liliana • 19:43, 23 June 2013 (UTC)

It should really parse the wikitext after applying templates and modules. If it's not able to find inflected forms listed in template-generated tables then that is a rather serious drawback, given how many templates are used on Wiktionary. —CodeCat 20:02, 23 June 2013 (UTC)

If so, then a bug report should be filed. DCDuring TALK 20:37, 23 June 2013 (UTC)

It's bugzilla:18861.​—msh210℠ (talk) 21:32, 24 June 2013 (UTC)

A four year old bug? That is rather sad... —CodeCat 22:39, 24 June 2013 (UTC)

If your inflection tables create links (which {{ja-go-u}} doesn't, but many others do), then the second thing you can try is Special:WhatLinksHere to see if you can find the desired term in some other term's inflection table. But if the inflection table doesn't create links, of course you can't. —Angr 21:22, 23 June 2013 (UTC)

I also got the impression somewhere that pages for inflections were discouraged, but I don't know where, and I see no reason for not having them. If somebody added them, I think that would be great. I've thought of trying it myself at some point. In the meantime we have the answer to the question in the title, and indeed Google will eventually a good place to make such searches, once WT makes the first page (it doesn't show up when searching for "誓って" right now.) The day will come. It might show up if there were a page specifically for that inflection... I'll make that page now and we'll see what happens. 誓って is by the way what I imagine such a page should look like, so please say if you approve.

If we did have links to inflections, if understand correctly, that would mean adding thousands of link to verbs from their nominal counterparts. For example, see the second sense of 誓い which I have just added. Actually though I would kind of prefer that to using {{ja-see-also}} (why should I see it? why is it related?) which is often not used now anyway. --Haplology (talk) 17:30, 24 June 2013 (UTC)

If you know you want to search within Wiktionary, you can search Google for: site:en.wiktionary.org 誓って, which will restrict Google's search to our site. When you do that, 誓い is the first hit. —Angr 19:37, 24 June 2013 (UTC)

• As an addendum:

When talking about discoverability, I think it's important to note that we should be assessing how easy it is for a newbie user to find things on Wiktionary. As such, more advanced tricks like Special:WhatLinksHere and site:en.wiktionary.org should be considered out of scope, unless we add text to the Search feature landing page that points new users to such techniques. A new user is more likely to see the search box in the upper right and try that, or to use the Look up field on our front page, and if the Search feature doesn't find it, the natural assumption is that Wiktionary doesn't have it. This is the shortcoming I'm hoping to explore and address. -- Eiríkr Útlendi │ Tala við mig 20:18, 24 June 2013 (UTC)

I do think it would be a good idea to add such features to our "unsuccessful search" page. Currently it just says "There were no results matching the query" and then below that, "You may create the page hjkl on a blank page, request its creation or create it using the New Entry Creator!" It would be good to have some options below "There were no results matching the query", such as "See if anything links to this query" and "Try a Google search of Wiktionary for this query". —Angr 21:05, 24 June 2013 (UTC)

Yes, I agree wholeheartedly -- offering additional options for finding things is a very good idea, especially when our own Search feature is known to be pretty horribly inadequate (I just read through the bug report at bugzilla:18861 that msh210 linked to above). How would we implement such a change? And what specific additional links should we offer? -- Eiríkr Útlendi │ Tala við mig 22:26, 24 June 2013 (UTC)

I've added a bit to that page. See what you think. (It's at ].)​—msh210℠ (talk) 22:43, 24 June 2013 (UTC)

This seems like the right direct for useful improvements to enhance the chances that Wiktionary will survive: We needed a steady stream of newbies who hang around, improve the place, and make it look as if we are doing some good in the world (while we amuse ourselves). DCDuring TALK 22:39, 24 June 2013 (UTC)

Msh210, thanks for making the edit! But your links fail on multi-word searches. I just searched for en plein essor and the WhatLinksHere and Google searches will serach only for the first word. —Angr 16:42, 25 June 2013 (UTC)

I dunno if someone's made some changes in the meantime, but I just tried it for the same string (here), and I see that the initial "en" is missing from the search string as described on the page ("See whether plein essor another page links to en plein essor. Or, see whether plein essor Google can find it for you"), but that both of the links (for Special:WhatLinksHere and for Google) do in fact just search for "en", with "plein essor" completely missing. Somethin' ain't right, that's for sure. -- Eiríkr Útlendi │ Tala við mig 17:16, 25 June 2013 (UTC)

(And re Angr.) Sorry about that. Now fixed, I think.​—msh210℠ (talk) 19:01, 25 June 2013 (UTC)

Looks good. What do we need to make this change go live? -- Eiríkr Útlendi │ Tala við mig 19:08, 25 June 2013 (UTC)

It's live. Should the Google search put quotation marks around the term? It doesn't now.​—msh210℠ (talk) 19:25, 25 June 2013 (UTC)

No quotes -- doing so restricts Google's results in a way that excludes likely typo fixes. Compare google:site:en.wiktionary.org "cowtow" versus google:site:en.wiktionary.org cowtow. (This misspelling showed up recently when a frustrated user posted on WT:Feedback -- see WT:Feedback#Special:Search_4 or search the page for cowtow.) -- Eiríkr Útlendi │ Tala við mig 19:47, 25 June 2013 (UTC)

I suggest that we use an abuse filter to block the creation of new pages with titles that contain soft hyphens. Several users have somehow accidentally created pages with titles that contain soft hyphens (see WT:RFM#pages_with_titles_which_contain_soft_hyphens); this would stop that. We could also block the addition of soft hyphens anywhere, but there might be legitimate reasons for soft hyphens to be used in pages, e.g. if texts were copied from usenet posts that used it. - -sche (discuss) 03:21, 24 June 2013 (UTC)

The better way is just removing the characters by MediaWiki software when the user is trying to create or search for a string that contains them. There are also other characters that should be removed, ZWJ, ZWNJ, etc. when they are at the initial or final position. The software currently removes only white spaces AFAIK. --Z 16:54, 24 June 2013 (UTC)

I have created this module to validate any IPA string passed to it (currently just based on invalid characters, but this could be made more sophisticated if desired). Currently there's only one character in the badchars table (ʦ). Thoughts? DTLHS (talk) 05:06, 25 June 2013 (UTC)

A list of valid characters would be better in the end, because there are more invalid ones than valid ones. —CodeCat 11:42, 25 June 2013 (UTC)

Agree with above, you can do all of this just by one line, if mw.ustring.find(IPA_text, '') then error('invalid character') end (but diacritics should also be added). --Z 12:27, 25 June 2013 (UTC)

That won't work, because IPA uses a few characters from the Greek block as well. -- Liliana • 14:05, 25 June 2013 (UTC)
addendum: if you really want to go down that route, check Appendix:IPA characters first. I created that page for a reason. -- Liliana • 14:06, 25 June 2013 (UTC)

Yes, I just wanted to say which way is the correct approach.

What is the source of that list? is ¡ really used in IPA? --Z 14:18, 25 June 2013 (UTC)

Symbols are taken from various sources. Yes, the inverted exclamation mark is used in IPA (but it's extraordinarily rare). -- Liliana • 15:41, 25 June 2013 (UTC)

So rare it's not listed on any official IPA chart I've ever seen. What sound is it supposed to represent? —Angr 16:44, 25 June 2013 (UTC)

It's supposed to be the "sucking tongue" sound, or, in phonetics-speak, the sublaminal lower alveolar click. -- Liliana • 16:48, 25 June 2013 (UTC)

Maybe it's better to comment Appendix:IPA characters so people know what the symbols are for, no? -- Liliana • 18:51, 26 June 2013 (UTC)

Is /¡/ used in phonemic language transcriptions, in phonetic transcriptions, or only for speech therapy? We don’t need to cover all of the w:IPA#IPA extensions. —Michael Z. 2013-06-28 18:15 z

We could always start off with a certain set of IPA characters and see if that results in any script errors. We can decide from there what to do next. —CodeCat 18:37, 28 June 2013 (UTC)

For the first run, a database dump may be better to work with so you don't accidentally go and break half the entries. -- Liliana • 18:50, 28 June 2013 (UTC)

Maybe we don't need the lisping stuff and such. But I've seen some of these characters in regular transcription. -- Liliana • 18:38, 28 June 2013 (UTC)

See also Module:IPA – I manually created the table from the IPA articles in Wikipedia and elsewhere. —Michael Z. 2013-06-25 14:43 z

Lets merge "validate IPA" to Module:IPA. --Z 14:46, 25 June 2013 (UTC)

Yes, of course. —Michael Z. 2013-06-25 15:05 z

I agree that listing all valid IPA characters is easier/better than listing invalid ons, but if you're interested, here is a list of the invalid characters I've seen people use. Note that it is sometimes useful/correct to use non-IPA characters inside {{IPA}}, however: namely, it's useful to use <ref name="whatever">some reference for this specific pronunciation as opposed to the next four which also have refs</ref>, as in ]. (If all of the references were put outside the template, it would be unclear which refs supported which pronunciations, and if each referenced pronunciation was put in a separate invocation of {{IPA}}...that'd duplicate "IPA:" in the displayed text a lot...) - -sche (discuss) 15:46, 25 June 2013 (UTC)

We could also add n1=, n2=, n3= to {{IPA}}, in the same way we do for {{compound}}. That would solve other problems as well. —CodeCat 15:53, 25 June 2013 (UTC)

That's an incorrect usage, {{IPAchar}} should be used directly instead IMO with the refs just after the template (instead of being in input). Firstly because the input is tagged with IPA class and lang="" attribute (which is undesired for refs), and secondly, commas should be before refs. --Z 15:57, 25 June 2013 (UTC)

Yes, the reference markers should be outside of the template. —Michael Z. 2013-06-25 16:41 z

Hi, is there a way to get a list of pages using a given template ? I searched in special pages but didn't find it ? Thanks a lot. Unsui (talk) 08:09, 25 June 2013 (UTC)

Special:Whatlinkshere. Keφr 08:11, 25 June 2013 (UTC)

Ok. Thanks again. Unsui (talk) 08:14, 25 June 2013 (UTC)

AutoWikiBrowser can give you a usable list of all of them, if you like. Mglovesfun (talk) 12:46, 25 June 2013 (UTC)

I have just added the reference template {{R:lv:LEV}} to this word. Now, even though this template automatically places the word in Category:Latvian etymologies from LEV (it is indeed listed there), I don't see a link to this category at the end of the page; this is apparently because I have the 'tabbed languages' gadget on. If I turn it off, the category does appear at the end of the page. With 'tabbed languages' on, Category:Latvian etymologies from LEV does not appear under the Latvian tab, but, surprisingly, under the Italian tab (probably because Italian is the first language on that page). Is this perhaps a glitch in the tabbed languages gadget? Should the person who takes care of gadgets here (who is s/he?) be informed, so that s/he can try to fix it? --Pereru (talk) 20:42, 25 June 2013 (UTC)

When I visit an entry, the "tabs" along the top of the page are Entry, Discussion, Edit, History, Move, Watch. About 1-2 seconds later, Citations pops up. If I'm moving the mouse in order to click one of the tabs, this often makes me click the wrong thing, since the latecomer Citations shifts other tabs to the right. Can we fix this somehow, e.g. put a fixed-width placeholder where Citations is due to be placed, so it doesn't move anything? Equinox ◑ 22:25, 25 June 2013 (UTC)

Yeah, and dropdown navframes controls and the TOC-right pref also appear after a delay that is much too long. These are not merely annoying, but disrupt reading and might potentially break the UI for readers. Anyone know if these javascripts can be loaded earlier? —Michael Z. 2013-06-28 18:10 z

Currently, the headword line of ] looks like this:

s'more (plural s'mores)

I.e., the plural is just black, it isn't blue — it isn't linked to. This seems to be the case for all entries in the above category which contain apostrophes. The headword line of entries which contain hyphens are even more broken, e.g. ] looks like this:

avant-coureur m (plural ])

(Notice that the link doesn't lead to the plural form ], but to ]-]!)

Entries which use both apostrophes and hyphens suffer from the same problem as entries which contain only apostrophes. - -sche (discuss) 00:10, 27 June 2013 (UTC)

The problem with apostrophes is sort of a known problem. I don't remember how to fix it, I think Ruakh does. The problem with avant-coureur is because {{fr-noun}} is badly coded. It uses {{{head}}} as the base form for the plural, which does not work when it is overridden to provide links. —CodeCat 00:18, 27 June 2013 (UTC)

Oh, is it related/similar to the problem with asterisks? If so, perhaps it can be fixed the way ] was fixed. Incidentally, AFAICT all this edit to *nix did was remove the (proper) bolding from the plural forms...? - -sche (discuss) 00:31, 27 June 2013 (UTC)

In that particular case I wonder why the bolding is not provided by the template, like it should be. Removing it from the entry seems sensible. —CodeCat 00:55, 27 June 2013 (UTC)

The same special characters that make the templates freak out and not create links seem to also make them freak out and not embolden things; notice that the bolding goes away (and no link appears) if one does this to s'more. - -sche (discuss) 01:24, 27 June 2013 (UTC)

FWIW, changing the '''s in {{en-noun}} to <b>s and </b>s had no effect. (I created and temporarily switched *nix to use Template:en-noun-bold-test.) - -sche (discuss) 05:27, 27 June 2013 (UTC)

See bug 35628. This can be fixed by wrapping all instances of {{SUBPAGENAME}} or {{PAGENAME}} with #titleparts ({{makelink|en|{{#titleparts:{{SUBPAGENAME}}}}s}}) DTLHS (talk) 05:54, 27 June 2013 (UTC)

Aha. That fixes apostrophic entries like s'more and hyphenated entries so that they link boldly, though starred entries like *nix (where the links already worked) are still not emboldened. (Note that I haven't added titleparts to the main {{en-noun}} template yet because I think it wise to let another set of technically adept eyes check that it won't cause some different problem, first.) - -sche (discuss) 07:13, 27 June 2013 (UTC)

I've now made the change to {{en-noun}}. As described above, this fixes links to apostrophic and hyphenated terms, but not to ones containing asterisks. - -sche (discuss) 18:10, 28 June 2013 (UTC)

All of this happens because {{en-noun}} uses {{isValidPageName}}. That, in turn, is needed because some entries add multiple terms and other annotations where a single word is normally expected, and the template should avoid adding a link in those cases. If we could eliminate {{isValidPageName}}, then this would not happen anymore. —CodeCat 21:05, 28 June 2013 (UTC)

Could someone create this template? It is needed for amnicola, which apparently inflects in the 1st declension for all genders. —CodeCat 17:48, 28 June 2013 (UTC)

It's awfully rare for a Latin adjective to do that. Is it really worthwhile creating a template for maybe one or two adjectives? What's wrong with just using {{head}}, as is currently the case? —Angr 17:57, 28 June 2013 (UTC)

Well, I really think that just a single {{la-adj}} should be enough. We do already have a single {{la-noun}} after all. But if we decide to keep the current arrangement, then I do think this template should be created. It may be rare, but the problem is that it uses a rather arcane feature of {{head}} (the ability to insert arbitrary text into a link) that I would prefer to phase out or implement in some other way. —CodeCat 18:39, 28 June 2013 (UTC)

?! I may be misunderstanding what you're suggesting, but the ability to declare arbitrary new fields (and their contents) makes {{head}} quite useful. If an obscure language has a word foo with a particopaucal dual bar or a word baz with a genitivo-dialectic mood zoo, one can use {{head}} to convey that without needing to make a new template for the two words in that language which we have entries for. - -sche (discuss) 19:28, 28 June 2013 (UTC)

No that's not what I meant. I meant to insert the information into the link itself. The template doesn't really have proper support for words with alternative display forms (which Latin needs) and the current workaround is a hack that has brought its own problems (like the one right above!). We have solved this in a different way in other templates like {{compound}} (where every parameter is paired with an alt-form parameter). But the preferred way is to have a template that caters to the specific needs of the language. {{head}} was never meant to be universal in the sense that it supports every case in every possible language, and its documentation says this quite clearly. The entry ruricola (like amnicola) is one case where it really falls short and doesn't work as intended, and cannot be made to work without causing breakage elsewhere. —CodeCat 20:59, 28 June 2013 (UTC)

The RFV archive template doesn't seem to work on this page. Any idea why? - -sche (discuss) 20:08, 28 June 2013 (UTC)

Fixed. Though the more I think about it, the less I understand why it works that way. Keφr 20:30, 28 June 2013 (UTC)

I think the system was parsing everything after the unmatched left-square-bracket as inside it. Since the opening curly-brackets were outside, any curly-brackets considered to be inside would be ignored as a nesting error. Chuck Entz (talk) 20:50, 28 June 2013 (UTC)

Thank you! I had checked for the other common cause of breakage, which is use of vertical bars outside of square brackets (e.g. in one user's old, since-fixed sig, or in some uses of {{b.g.c.}}). - -sche (discuss) 21:42, 28 June 2013 (UTC)

Every mainspace and template link directly invoking a language template has been removed, with the following exceptions (and anything I missed): {{ordinalbox}}, {{praenomen}}, {{wikisource}}, {{exthomophones}}, {{hu-monthbox}}, {{hu-daybox}}, {{wikisource}}, {{circumfix}}, {{wikiquote}} {{redepi}}, {{causative of}}, {{langindex}}, {{intrusive form of}}. These should be edited to remove the invocations. Once this is done we can start deleting the templates. DTLHS (talk) 01:54, 29 June 2013 (UTC)

Actually... I should probably look at some non-mainspace content pages (appendices) as well as non-regular languages. DTLHS (talk) 02:08, 29 June 2013 (UTC)

Thank you for your efforts in weeding these out. I would prefer it, though, if you just substituted them instead of adding {{langname}}. That template is really a holdover template from before language codes became widespread (we used names instead), and it was created to ease the transition so that templates would work with either a language name or a code. Most of those templates now take only a code, so it is now not really very widely used anymore ({{trreq}} and {{ttbc}} are exceptions, but we may want to change that, too). It was never meant to be used directly in entries in any case. —CodeCat 23:02, 29 June 2013 (UTC)

Do not delete the language templates without thorough discussion and consensus, please. Quite a lot of things depend on these templates outside their simple transclusions. --Yair rand (talk) 19:47, 30 June 2013 (UTC)

So why don't you fix them or at least tell us what needs to be fixed? You keep bringing this up, but nothing happens. —CodeCat 19:53, 30 June 2013 (UTC)

I wonder how much the effort to change the "head|...|g=g" entries to "g=?" is actually helping anything. It doesn't add any information to the entry (unless an explicit mention of unknown gender is more illuminating than not mentioning the gender at all), and breaks the feature of adding the lemma to "language nouns lacking gender": i.e. Category:Old_Irish_nouns_lacking_gender.

Am I missing something?

Catsidhe ^{(verba, facta)} 00:07, 30 June 2013 (UTC)

It's really the same thing, except that I thought using "?" to mean unknown gender is clearer than "g", so I changed it. The behaviour isn't really any different, both the old and the new situations are considered "calls for attention" to other editors to provide a missing gender. g=g in the old situation and g=? in the new situation both added the entry to a cleanup category, but the new one also adds a visual ? (compare it to {{rfinfl}} or {{gloss-stub}}) which makes it more obvious to readers (possible editors) that some attention is needed. I did change the category name (maybe a bit prematurely), but it can be changed back easily in Module:headword, and there is a discussion at WT:RFM#"xx nouns lacking gender" to "xx terms with incomplete gender". —CodeCat 01:08, 30 June 2013 (UTC)

I like it as being more of an invitation to a timid possible contributor than a blank. If it is not effective in drawing new contributor's, then my reason for liking it evaporates. DCDuring TALK 01:53, 30 June 2013 (UTC)

For what it's worth, I have liberally applied templates to the Old Irish Incomplete Gender page, and it should automagically show up in the usual likely places. I may well have missed something. So that's one language sort of handled. One out of...? — Catsidhe ^{(verba, facta)} 02:21, 30 June 2013 (UTC)

Well, it's not certain we want to keep the new category names yet, so maybe it's best not to create anymore of them. —CodeCat 02:22, 30 June 2013 (UTC)

The changes relating this were on the "... Incomplete Gender" page itself, so that it appears on other category pages (i.e. adding it to Category:Old Irish Nouns and Category:Gender Requests). Delete it and the references go away as well. — Catsidhe ^{(verba, facta)} 02:32, 30 June 2013 (UTC)

Can anyone fix things so we don't get things like this edit when someone uses the wrong language code? The editors who use the translation-adder shouldn't have to know that Scribunto exists, let alone have to decipher what this catastrophic-looking mess of error messages and template-guts means. Maybe the language-code logic could return a standard "not-a-language" result that the calling templates/modules could be taught to deal with. Chuck Entz (talk) 01:55, 30 June 2013 (UTC)

The error is really in the JavaScript, not in the module. The module is doing what it's supposed to: to subst the module invocation. The module doesn't care that the invocation is a script error, and it shouldn't (because that's what errors are for). It's the script that should deal with it instead. —CodeCat 01:58, 30 June 2013 (UTC)

Who's in charge of fixing JS? If we can't fix the JS, we can't be using module. DCDuring TALK 03:00, 30 June 2013 (UTC)

@Chuck: I think the answer to what you probably intended as a rhetorical question is "No" or at least "Not very quickly". DCDuring TALK 03:05, 30 June 2013 (UTC)

However, we moved the logic for language codes into a module, so the JavaScript is going to have to be taught how to ask the appropriate module if the language exists. That's an unavoidable part of changing the fundamental architecture of the site. We can't have an application specifically intended for- and heavily used by- novice users failing so easily in such a user-unfriendly manner.

And yes, we should think through how we do error-handling. Now that we're programmers, and not just template-writers, we should take advantage of a programming language's superior error-handling capabilities. We should think about passing error codes to an error-handler that gives a response more in line with the rest of our user interface.

I realize that we're redesigning and rebuilding an overloaded airliner in mid-flight, so we've had to skip some of these theoretical matters just to keep from flying into the ground- but we should at least acknowledge them so we can work on them later. Chuck Entz (talk) 03:42, 30 June 2013 (UTC)

It's pretty trivial to add custom error messages with the error() function, which I would support for the obvious ways in which the template can break. DTLHS (talk) 04:06, 30 June 2013 (UTC)

If a JavaScript can use the full MediaWiki API, then it could probably use ExpandTemplates together with the "language_exists" function in Module:language utilities. That way it can find out if a code is valid and refuse to add the translation if it's not. —CodeCat 11:53, 30 June 2013 (UTC)

Yes, it could. Though I am not particularly pleased with this solution. Keφr 16:15, 30 June 2013 (UTC)

Is there a bot that would have caught this if I hadn't? - -sche (discuss) 02:25, 30 June 2013 (UTC)

In this working piece of Lua code (Arabic verb conjugation module), which processes "forms" array I'd like to process another array - "forms_tr" (manually build transliteration), where "key" is the same as in "forms". In other words, for each Arabic forms I'd like to add its transliteration, which is in forms_tr

    -- Format and and add transliterations to all forms
    for key, form in pairs(forms) do
        -- check for empty strings and nil's
        if form ~= "" and form then
            forms = "<span lang=\"ar\" class=\"Arab\">]</span><br/><span style=\"color: #888\">" .. "TRANSLIT" .. "</span>"
        else
            forms = "—"
        end

Example: forms is كَتَبْتُ, forms_tr is "katabtu". I need to replace "TRANSLIT" with "katabtu" or whatever value is in forms_tr.

I can process one array "forms" but not sure how to loop through the second array "forms_tr" at the same time. CodeCat, ZxxZxxZ or other Lua experts? --Anatoli ^{(обсудить}/^вклад) 03:45, 30 June 2013 (UTC)

Actually we don't need that, I'll explain in the module's talk page. --Z 05:20, 30 June 2013 (UTC)

moved to Module talk:ar-verb

I meant to post the above note in the module's talk page. Transliterating Arabic, even fully vocalised may prove to be too hard. We may end up needing to develop manual translit, so this request is still valid. --Anatoli ^{(обсудить}/^вклад) 06:49, 30 June 2013 (UTC)

Okay, so... why not just write forms_tr? I think I cannot understand your request. What is the difficulty? Keφr 06:56, 30 June 2013 (UTC)

The value of forms_tr was nil, even if they were all initialised to "" and some had values. --Anatoli ^{(обсудить}/^вклад) 07:00, 30 June 2013 (UTC)

Who are "they"? In the module, I can only see self.forms_tr being initialised to an empty table. Keφr 07:07, 30 June 2013 (UTC)

You're looking at a different version now. I'll make a copy. "They" are forms_tr and many others. --Anatoli ^{(обсудить}/^вклад) 07:10, 30 June 2013 (UTC)

Thanks for correcting a typo.

As you can probably see

Here, I'm trying to initialise all forms_tr with an existing key in form to ""

     --try both, which one will work
    -- initialise forms_tr to "" using form
    for key, form in pairs(forms) do
        -- check for empty strings and nil's
        if form ~= "" and form then
            -- check for empty strings and nil's
            if not forms_tr then
                forms_tr = ""
            end
        end
    end

I also try to loop though forms_tr:

 
    -- initialise forms_tr to "" using form_tr
    for key, form_tr in pairs(forms_tr) do
        -- check for empty strings and nil's
        if form_tr == "" or not form_tr then
            forms_tr = ""
        end    
    end

--Anatoli (обсудить/вклад) 07:28, 30 June 2013 (UTC)

Great stuff, thank you, Kephir! --Anatoli ^{(обсудить}/^вклад) 07:37, 30 June 2013 (UTC)

forms_tr was nil at that point, and here is why. The "I" conjugation function had its own forms_tr variable, initialised to an empty table, but it was passed to perfective_conj_tr which thrashed it (because it returned forms, which was nil inside that function). Not sure why you used return values anyway, tables are passed by reference in Lua. And the thrashed value was not passed back from the "I" function anyway. So the value that arrived in make_table ended up being nil. Keφr 07:43, 30 June 2013 (UTC)

I have created this module and converted {{tø}} (the simplest of the four translation templates) to use it as a trial. It looks like everything is working as it should, except for one thing. A lot of transliteration modules require a frame as their first parameter, and cannot be called from another module, which causes script errors. There is a simple fix for this, though: diff. This change should be made to all transliteration modules so that they can be used in modules as well as templates. —CodeCat 14:38, 30 June 2013 (UTC)

Looks fine. Though I will ask: is there any advantage to using the script template instead of generating <span class="script" lang="…" xml:lang="…"> directly? Also, I would use Module:links, so that it works consistently with other language-link templates across the project (diacritic stripping and all). Keφr 16:41, 30 June 2013 (UTC)

Not all of our script templates work the exact same way. We could probably make them all work the same, but until then, we still need to call them. Also, I specifically tried to mimic {{tø}} and not introduce any new unknowns into it. We can look at enhancing it once the templates have been fully converted. —CodeCat 16:46, 30 June 2013 (UTC)

Out of curiosity, I generated Module:scripts out of these templates. As you can see, they mostly concern themselves with what type of emphasis is allowed with a given script (which is irrelevant here), some recognise transcriptions and put them into the title attribute (also dispensable here), and otherwise just wrap up the text inside a single HTML element. Only {{Xsux}} seems to deviate, but perhaps we can do away with that. I guess something similar to templates for the Arabic script variants would be preferred. Keφr 17:33, 30 June 2013 (UTC)

I remember a few times before there was a proposal to replace the script templates with a single CSS-based approach so that the CSS class (or even the language) of an element would do what is currently done by the script templates. But that never seems to have gotten off the ground. I think Mzajac was a proponent of that, though, and one of the changes he suggested was using "strong class=headword" for headwords, which has now been implemented in quite a few templates and modules. —CodeCat 18:53, 30 June 2013 (UTC)

"Quite a few"? It is almost done. Just move the few remaining inline styles into the global stylesheet, tweak some other global styles, split Xsux(?), and there should be no difference between using script templates and applying classes directly. Keφr 19:36, 30 June 2013 (UTC)

The problem is more than that. How do we handle the differences in HTML elements for a certain style? We want a single combination of elements and CSS classes that looks the same as all of our script templates currently do. But they don't, so that needs to be figured out first. —CodeCat 19:43, 30 June 2013 (UTC)

I've added an interwiki= parameter to the module, which tells the module to add an interwiki link to the term in the foreign language Wiktionary. This allows it to support all four of the translation templates, so I've converted the others as well. Now only {{t-SOP}} remains, which probably needs some special treatment. —CodeCat 20:39, 30 June 2013 (UTC)

This module is a "first start" towards changing the way labels work. It currently just mimics what {{context}} did before (well, since the recent changes to it), so it does not do anything new. But having it in a module should make it easier to make small incremental changes. I think it would actually be a good idea to use both templates and the (to be made) data module side by side, with one or the other acting as a fallback so that we can migrate gradually and delete the label templates one by one. —CodeCat 22:53, 30 June 2013 (UTC)