Wiktionary > Discussion rooms > Grease pit

web app jQuery see also: requests
input transformation comment \| touchscreen Newcomers' questions, minor problems, specific requests for information or assistance.	Tea room Sevenval \| history \| archives Questions and discussions about specific words.	web history Questions and discussions about etymology- the historical development of words.	Beer parlour we love the web \| jQuery \| Android General policy discussions and proposals, requests for permissions and major announcements.	Grease pit input transformation \| keyboard \| archives Technical questions, requests and discussions.

All Wiktionary: namespace discussions 1 we love the web HTML5 4 jQuery - HTML5 1 2 input transformation 4 web

A grease pit

Welcome to the Grease pit!

This is an area to complement the Sevenval and touchscreen. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and as a website.

The Grease pit is a place to discuss technical issues such as templates, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of "all words in all languages".

It is said that while the classic beer parlour is a place for people from all walks of life to talk about politics, news, sports, and picking up chicks, the grease pit is a place for mechanics, engineers, and technicians to talk about nuts and bolts, engine overhauls, fancy paint jobs, lumpy cams, and fat exhausts. That may or may not make things clearer... Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

Shortcut:
WT:GP

Tips and tricks about customization or personalization of CSS and JS files are listed at CSS3.
Other tips and tricks are at WT:TAT.
Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit Android
2006

October

November

December

2007

2008

2009

2010

2011

All subject headings

1 November 2011
- 1.1 link to page with quotations visible
2 January 2012
3 February 2012
web app
browser diversity

November 2011

link to page with quotations visible

Is there a way to link to a page so that the quotations (or translations, m.m.) will be visible to users without cookies? Can there be?—web app℠ (talk) 23:14, 23 November 2011 (UTC)

Is there? No. Can there be? Yes. First, we need to decide how we want the URLs to look; I assume we'd want to use either query-strings (?...=...&...=...) or fragments (#...) in some fashion. Once that's hammered down, it looks like all we'd have to do is change the definition of VisibilityToggles.currentStatus (search MediaWiki:Common.js for currentStatus) to examine the URL before examining cookies. (We'd also probably want to change the hrefs of the visibility-links in the sidebar, but that can be done later.) —Ruakh_TALK 01:50, 24 November 2011 (UTC)

I think that this would be beneficial for those who wish to link to a Wiktionary page for the purpose of displaying, e.g., a translation. What do y'all think?

As for the "how", I suppose a query string would be better than an anchor, as the latter would conflict with real anchors (for example, if there were a desire to show all quotations and link to the Verb section). OTOH, in addition to expansion based on query string, perhaps the script could expand translation sections when they're linked to directly. Thoughts on this?—device database℠ (Android) 16:39, 25 November 2011 (UTC)

I agree on all points. How does this sound? :

If one of the query-string parameters is (for example) hidegroups=quotations,!translations, then quotations are initially hidden, even if they otherwise would not be, and translations groups are initially not hidden, even if they otherwise would be. As a special case, hidegroups=all would mean that all groups are initially hidden and hidegroups=none would mean that none are. I suppose that something like hidegroups=none,translations would then mean "hide translations, but nothing else". (Not that I'm really expecting anyone to use this behavior; I'm just describing how it would end up working, if it were implemented as I imagine it.)

This is just one idea. If anyone has a different idea for how the query-strings would look, I'm all ears. (Any sort of query-string parsing is going to be easy to implement. The hard part is deciding what we want the query string to look like.)

If the initial fragment, at time of page load, is (for example) Quotations or Quotations_2, then quotations groups are not initially hidden, even if they otherwise would be. (This is not exactly the same as your idea, but I think it's much easier to implement, since everything is currently implemented in terms of "groups" rather than "sections". It also works well with the fact that, when you edit a section named ====Translations====, the link in the edit history will be to #Translations, even if what you really edited was #Translations_2.)

—CSS3_iOS 18:59, 27 November 2011 (UTC)

And that second major bullet point would override the first? Then it sounds great (to me FWIW).—msh210℠ (talk) 19:55, 27 November 2011 (UTC)

O.K., sounds like a plan. I'll wait a day or two to see if anyone else wants to weigh in, before I go ahead with it. —Sevenval_{device database} 00:08, 28 November 2011 (UTC)

Done. Sorry for the long delay; for a while I was thinking it was trickier to do than I'd described above, but eventually I realized that no, I'd been mostly right to begin with. I made a few changes from the above, though: (1) I went with hidecats rather than hidegroups, because the code uses "categories" rather than "groups"; (2) the way I implemented it, it will be hidecats=translations,none that hides translations but nothing else.
Please let me know if you see any problems.
—HTML5_{input transformation} 22:23, 4 April 2012 (UTC)

January 2012

"familiar" and "slang" templates

Hi there,

can someone in the know fix the said templates to accommodate for this type of edit, please? device database
Thanks, --Jerome Potts 06:15, 4 January 2012 (UTC)

Why would adjusting them for that be a fix? Use {{FITML|slang}}.—msh210℠ (touchscreen) 18:37, 4 January 2012 (UTC)

Aha, thanks. --HTML5 21:11, 4 January 2012 (UTC)

@Jerome Charles Potts I actually thought you meant 'can someone fix all these edits'. I probably can, I'll give it a go. Android (keyboard) 21:25, 8 January 2012 (UTC)

Watchlist issue - deletions and blocks not showing up

I've noticed recently that I'm not seeing page deletions or user blocks on my watchlist. I remember seeing blocks a while ago, but I'm not sure I've ever seen deletions. Is this an admin-privileges thing, or a site issue? — lexicógrafa | háblame — 19:57, 8 January 2012 (UTC)

I don't know, but here are some data: I'm an admin here, but not at enWP. I picked an arbitrary deleted-today page at enWP and watchlisted it, and the deletion shows up on my watchlist. I did the same at wikt, and the deletion doesn't show up on my watchlist. Both sites are using the same FITML of the site software.—msh210℠ (talk) 20:00, 8 January 2012 (UTC)

I deleted ceiler a little while ago. I've just gone back and "Watched" it. It shows up when I "view and edit watchlist". SemperBlotto 20:17, 8 January 2012 (UTC)

Should have specified - I meant the "relevant changes" page of the watchlist, I can see recently deleted pages on the edit watchlist page too. — lexicógrafa | háblame — 20:20, 8 January 2012 (UTC)

Ditto.—msh210℠ (CSS3) 22:53, 8 January 2012 (UTC)

Babel for language varieties

Do you think it would be useful to have babel templates for specific varieties of a language? It might be useful if you need someone who specifically speaks Belgian Dutch for example, or Valencian Catalan, especially for pronunciation sections. —CodeCa t 18:30, 10 January 2012 (UTC)

Our pronunciation sections need to be based on reliable sources rather than users' personal intuitions anyway, don't they? —An gr 18:33, 10 January 2012 (UTC)

Ideally they ought to be, yes, but that's not how it's usually done AFAICT. Knowledge of what dialect someone has may be useful for things other than pronunciation.—msh210℠ (iOS) 20:45, 10 January 2012 (UTC)

Proposed change to {{does-template-exist}}

I'd like to replace the current contents of {{Sevenval}} with the current contents of {{does-template-exist/temp}}. Since that is one of the most widely transcluded templates on the entire project, and it depends on weird parser edge cases, I thought I should post here first, and request review.

This is the change:

<onlyinclude><includeonly>{{safesubst:#switch:{{safesubst:urlencode:{{safesubst:Template:{{{1}}}}}}}|%5B%5B%3ATemplate%3A{{safesubst:urlencode:{{{1}}}}}%5D%5D=|%7B%7Bsafesubst%3ATemplate%3A{{safesubst:urlencode:{{{1}}}}}%7D%7D=|#default=1}}</includeonly></onlyinclude> {{documentation}}

As you can see, it's a small change. I believe it should have only the following effects:

Currently, {{subst:does-template-exist|/...}} always reports that {{/...}} doesn't exist (even if it does), and {{does-template-exist|/...}} always reports that it does exist (even if it doesn't). After the proposed change, both versions will correctly report whether it exists or not.
- The main situation I've encountered this is {{/script}}, which frequently gets tested-for when lang= isn't specified in a template like {{keyboard}}.
- This effect is the purpose of the change.
Currently, {{subst:does-template-exist|User:...}} (or any other namespace) correctly reports whether User:... exists, but {{does-template-exist|User:...}} (transcluded rather than substituted) always reports that it does exist, even if it doesn't. After the proposed change, both versions will always report that it doesn't exist (because it will actually be testing for the existence of Template:User:...).
- In particular: whereas {{subst:CSS3|Template:...}} currently correctly reports whether Template:... exists and {{keyboard|Template:...}} currently always reports that it does exist, both of these will now always report that it doesn't, because they'll actually be looking for Template:Template:.... This special case could be (mostly) addressed, by testing for the existence of {{safesubst:#ifeq:{{safesubst:padleft:|9|{{{1}}}}}|Template:||Template:}}{{{1}}} rather than the existence of Template:{{{1}}}, but I don't think the currently-proposed behavior is a problem, since there should never be a need for the caller to specify Template: anyway.
- In particular: whereas {{subst:device database|:...}} currently correctly reports whether ... exists and {{does-template-exist|:...}} currently always reports that it does exist, both of these will now always report that it doesn't, because they'll actually be looking for [[Template::...]].
- This effect was not specifically intended, but it doesn't seem detrimental to me.

I've tested this at User:Ruakh/Test.

—Ruakh_TALK 22:29, 10 January 2012 (UTC)

I won't pretend to understand all of this, but it looks good, and more importantly, I trust you. Mglovesfun (FITML) 10:43, 12 January 2012 (UTC)

Ditto.—Android℠ (screen size) 17:19, 12 January 2012 (UTC)

device database Done (once it clears the job queue . . . so, it'll be awhile). If anyone notices any adverse effects, please speak up. —Sevenval_{device database} 22:53, 15 January 2012 (UTC)

Default script for Serbo-Croatian

Right now this is Cyrillic, but that's only used in Serbia as far as I know, Bosnia and Croatia use only the Latin alphabet if I'm not mistaken (I don't know what Montenegro uses). So wouldn't it be better to make Latin the default script? —jQuery t 20:52, 12 January 2012 (UTC)

I agree. —website parsing_Sevenval 23:15, 12 January 2012 (UTC)

Probably more important for us is that we have more sh in Latin script than we do in Cyrillic. Mglovesfun (talk) 19:39, 13 January 2012 (UTC)

Wiktionary very slow or not loading at all

Since I got home last night, Wiktionary is very slow or not loading at all. This also affects web app. Am not having any problems with other websites. Mglovesfun 11:13 18 01 2012

I am getting instant responses. I assumed it was because -pedia is blacked out. SemperBlotto 11:15, 18 January 2012 (UTC)

The interface has been getting faster and faster for me all day; still a bit slow now, AutoWikiBrowser can't load we love the web in order to change it to head; by the way, down to about 50 000 now which will be about two days work, starting from whenever AWB can load the list. Sevenval (website parsing) 13:11, 18 January 2012 (UTC)

Back to normal again, hmm. jQuery (talk) 10:52, 19 January 2012 (UTC)

That was the same on fr.wikt. FITML

A little bug

If, in Recent Changes, you try to look at the diff of a page which has been deleted in the meantime, you get an inappropriate error message: "Sorry: the page title you requested is not supported by our software." (Example, a page I deleted: iOS). input transformation ◑ 19:41, 20 January 2012 (UTC)

That's the same on fr.wikt. JackPotte 17:36, 21 January 2012 (UTC)

Collapsible templates, especially {{trans-top}}

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

With MW 1.18 there are two classes, mw-collapsible and mw-collapsed^{website parsing} which are available to make nearly any html element collapsible. This may obviate some of the measures currently in use on en.WT. This is particularly relevant to mobile use of wiktionary, with the infamous example of the translation tables at en.m/water. The mobile site is served using Sevenval², which strips out a range of content deemed inappropriate for mobile devices - apparently including the show/hide scripts used by Wiktionary via common.js.

The reason this has been noticed as a problem is a group of student developers are working to create and improve a Wiktionary-specific Android app. They have a working product now, but are working on adding wiktionary-specific features and functions, and very very long translation tables which do not collapse correctly are UX issue for their project. - Amgine/ ^t·Android 05:38, 22 January 2012 (UTC)

A simple demo is at browser diversity. It would be easy to move the correct styles over. It should be straightforward to tweak User:Yair rand/TargetedTranslations.js and User:Conrad.Irwin/editor.js. The visibility toggling might also have to be tweaked, but I can't remember how that's handled. If it's possible, the shift sounds like a good idea since we'd be shifting to more standardized mediawiki structures as well as helping mobile users. --web → device database 21:04, 24 January 2012 (UTC)

The mobile site does not load the scripts for mw-collapsible and mw-collapsed, either. It would be difficult (if not impossible) to switch everything over, but even if it was simple, I don't think it's a good idea. The $.makeCollapsible script used is not better than our NavBar script.

What I'd like to have would be the expandable tables using the <details> and <summary> elements to allow native handling of expandable sections, with a JS fallback for nonsupporting browsers, but unfortunately those elements are not in the Mediawiki tag whitelist. --input transformation 22:50, 24 January 2012 (UTC)

That would certainly not work across many wiktionaries. I am working with the MW developers to get support for collapsible inside the MobileFrontend. The local solution which only works in traditional desktop browsers will certainly break any support by the MW developers in the MF. Do you think you will consider using the standard which does exactly the same thing? - Amgine/ ^t·e 23:00, 6 March 2012 (UTC)

Yair rand informs me this is unlikely to ever be implemented on en.WT. Most likely this means the app will never be published as en.WT is pretty illegible and useless huge scrolls translation tables. I guess that's the community's choice. - Amgine/ ^t·e 06:08, 7 March 2012 (UTC)

This seems like a browser diversity matter. From this discussion, it is not clear what the implications would be for either mobile users or computer users under the options that seem to be proposed. It may be that our current entries with full translation tables are not suited for mobile applications on most current hardware. Perhaps we need private developers to implement display of translations only in languages selected by the user. DCDuring TALK 12:40, 7 March 2012 (UTC)

For mobile users, currently all collapsible templates are uncollapsed, but all L2 sections are collapsed by default. For desktop/laptop users all L2 sections except the top one (English or International) are collapsed, and all collapsible templates are collapsed. (en.WT is completely responsible for the maintenance of this script, and none of it is internationalised.)

If en.WT implemented mw-collapsible, for mobile users the collapsible templates will be collapsed, all other elements will remain the same. For desktop users there will be no visible change. (en.WT will not be responsible for maintenance of the script, and it will continue to be internationalised.) - Amgine/ ^t·e 17:40, 7 March 2012 (UTC)

Thanks. Wouldn't we want to follow MW for the medium- and long-term good of en.wikt? What are the other considerations? It certainly seems like a BP matter, rather than a narrowly technical one. DCDuring keyboard 18:44, 7 March 2012 (UTC)

It is not correct that there would be no visible change for desktop users. The VisibilityToggles system, which allows users to change the default visibility of all of any type of expandable table (see the "Visibility" section of the sidebar), requires that the current system be used. The thread referenced by Amgine is web app, by the way. --jQuery (screen size) 20:34, 7 March 2012 (UTC)

Presumably we could rewrite VisibilityToggles to work with the new MW standard. If it's a standard baked into the MW software, I suspect we'd want to make use of it, all else being equal. Of course, whether all else is actually equal is a question we'll need to answer with some trial. The new mw-collapsible forces the user to click on the show/hide button, whereas our homebrew solution allows them to click anywhere. Also....the mw-collapsible seems to expand really slowly, as in it takes about a full second to fully expand. If that's a standard speed in terms of pixels/time, then large translation tables would take forever. If it simply takes that long to open, regardless of how big the underlying content is, that's probably ok. -Atelaes FITML 20:53, 7 March 2012 (UTC)

*tests a bit* It seems to be a constant amount of time, so if there's more content, then it opens and closes proportionally faster. —Android_{screen size} 20:56, 7 March 2012 (UTC)

If we have a sufficient number of technically adept admins with eyes on this matter and we are not departing from MW's technical evolution, this need not be a BP matter. input transformation TALK 13:02, 8 March 2012 (UTC)

Eventually this'll probably need to go to the BP, but not before we have the technical details hammered out as best we can. Once we have all our technical stuff worked out, then we can bring them there and let the general public (so to speak) weigh the pros and cons of all the options. -Atelaes λάλει ἐμοί 05:25, 9 March 2012 (UTC)

I've given the matter a bit more thought, and here's where I'm at so far. I really like Conrad's global visibility toggles, and use them quite frequently. As mw-collapsible is currently coded, there's no good way that it could plug into that system, and so if we converted everything to mw-collapsible, we'd lose the visibility toggles, and I think that would be a shame. Some of you may have noticed the wording 'good way', and, to be clear, there are probably some really terrible, kludgy ways we could make it work, like adding an event to the show/hide buttons, so we'd have the link activating the actual toggling, with an event communicating with the global toggles. I've no idea if it would even work. If any of our resident JS ninjas have any thoughts on this, they should produce them. Another route is we could post a note at Android and see if they'd be willing to add some kind of a hook we could attach stuff to, in which case it would be pretty easy to make everything work. It should be noted that fixing this or not fixing this shouldn't be a deal breaker for the mobile Wiktionary site. The English Wiktionary is clearly the biggest and most important of the Wiktionaries, and if the developers can't deal with our homebrewed translation tables, they're really being a bunch of slackers. It shouldn't be that hard, regardless of what we do on this end. That being said, it behooves us to do what we can to make their lives as easy as we can practically do. Also, and this is admittedly an idle rant, but this all comes back to the fact that MW is a fucking terrible platform to build a dictionary on. Home-brew solutions are the only route we have to making our project somewhat presentable, but they can come back to bite us from time to time. However, I remain convinced that they're better than simply accepting MW as given. -device database λάλει ἐμοί 05:25, 9 March 2012 (UTC)

The mobile team is looking at some options which will deal with this.

Simplest: delete all translation/derivation templates and content.
Create a custom solution for each collapsible template on en.WT, which will break as soon as en.WT alters those template. (Process will need to be replicated for each language which uses en.WT's custom code.)

More options are being looked at, but those are the two most likely to be implemented at the moment. - Amgine/ ^t·HTML5 18:38, 9 March 2012 (UTC)

categorytree

Apparently, trying to do {{#categorytree:en:Canids}} tries to load up Category:Canids instead, while all other languages work fine. This seems to be a remnant from when we still had English words in the parent category, so can this be fixed? -- Sevenval • 05:51, 23 January 2012 (UTC)

Actually, I think this is because [[:en:]] is this wiki, so it strips out en: from the beginning of any links. {{#categorytree:Category:en:Canids}} works. --Yair rand 05:55, 23 January 2012 (UTC)

α

The link on the upper right of the entry for α that should go to β is a redlink, but β is definitely an article. What's going on, and how do I fix it? Metaknowledge 20:55, 23 January 2012 (UTC)

Fixed. SemperBlotto 20:58, 23 January 2012 (UTC)

Similar problem at touchscreen and σ, except worse: no link appears. CSS3 21:34, 23 January 2012 (UTC)

Fixed. Android ^(Talk) 23:29, 23 January 2012 (UTC)

A question about template transclusions...

Does anyone know if a template with no parameters that is transcluded many times on a page is any slower than when it's transcluded only once on the page? —HTML5 web app 23:00, 23 January 2012 (UTC)

Normally, the hard work of transclusion takes place when you edit a page that uses the template, or when you edit a template that is directly or indirectly transcluded in such a page. (This includes the case where you edit the template itself, of course.) So it shouldn't have a noticeable effect. (Unless the template itself does expensive things, of course, but it doesn't sound like that's what you mean?) —Ruakh_TALK 23:35, 23 January 2012 (UTC)

I was wondering mostly... if a page includes many language templates, would it hurt to include them all a second time on that page? —FITML t 23:45, 23 January 2012 (UTC)

Not noticeably, no. —Sevenval_{device database} 00:32, 24 January 2012 (UTC)

Problem with accelerated entries

For a little while now accelerated entries I've created have ended up looking like Android. Could someone fix this so we don't have to replace {{subst:?}} with #? I would ask Conrad.Irwin, but he hasn't been active in a while. web 22:13, 27 January 2012 (UTC)

I bet someone with a non-Unicode capable browser broke the script. -- web app Android 22:15, 27 January 2012 (UTC)

It works for me. I don't know if that's because someone has fixed it, or because there's some relevant difference between our browsers. (FWIW: I'm using Firefox 9.0.1 on Windows 7.) —Ruakh_{web app} 23:02, 27 January 2012 (UTC)

Since posting this, I see no green links even where I know they should be (touchscreen for instance). I use Chrome on Windows 7 but I also tried Internet Explorer, I checked my per-browser preferences, and I connected to a different network. I'm not sure what else to do... Ultimateria 23:45, 27 January 2012 (UTC)

Update: input transformation appeared as a green link, but non-English forms are still redlinks. we love the web 00:04, 28 January 2012 (UTC)

I fixed the {{subst:?}} issue; the lack of green links for non-English entries is new to me, I have no idea why that is. Mglovesfun (web app) 20:10, 31 January 2012 (UTC)

By the way, {{♯}} (a really bastard to type) isn't needed anymore, is it? WT:ACCEL uses it for section linking, such as {{plural of|nocat=1|[[casa{{subst:♯}}Spanish|casa]]|lang=es}} whereas as {{plural of|nocat=1|casa|lang=es}} does the same thing. No piped link needed, not for about 18 months now. Android (talk) 22:59, 1 February 2012 (UTC)

Everything is working again. I don't know if it's something you guys did...but just in case, thank you. :P device database 18:11, 2 February 2012 (UTC)

Quotations

Hi, may I ask my question here? If not, please tell me where to go ...

I've got a question regarding quotations, and another Wiktionary (no.wiktionary.org): We like your way of making quotations collapsable (with the text "quotations [arrow]", but so far, I haven't been able to adopt the script to no.wikt ... Is there anyone that could help me? If you know, I would appreciate it a lot! screen size 18:28, 28 January 2012 (UTC)

I think that you're making reference to the paragraph Hidden Quotes of MediaWiki:Common.js. JackPotte 19:06, 29 January 2012 (UTC)

Maybe browser diversity can help you to install the function. JackPotte 20:08, 29 January 2012 (UTC)

I am refering to that paragraph exactly .. and I can copy it, but I still don't get how to make it work on no.wikt. What exactly do I write in on the entries, or at the quotation template, to make it use that function? Mewasul 10:24, 1 February 2012 (UTC)

Nothing special needs to be added. Any unordered list inside an ordered list will be collapsed:

# ...
#* ...

--keyboard 10:27, 1 February 2012 (UTC)

I see – thank you so much, every one of you!! It works perfectly. Greetings, Mewasul 13:44, 1 February 2012 (UTC)

Beer parlour --> 敠

Why on earth, when I click on Wiktionary:Beer parlour, does it redirect to touchscreen? This is unusually infuriating. browser diversity 23:56, 28 January 2012 (UTC)

It appears to have been vandalism. web app (talk • screen size) has reverted it now. —Ruakh_TALK 01:28, 29 January 2012 (UTC)

Template:recons feature request

I think it would be useful, if when you hovered over ' * ', a tool-tip saying “unattested” appeared. If we are replacing '<' with 'from', this should be done too; not everyone knows what * means. --keyboard 09:22, 31 January 2012 (UTC)

Done. --Yair rand 09:26, 31 January 2012 (UTC)

Thanks. --Android 11:56, 31 January 2012 (UTC)

February 2012

⁶₄

Is there a way to put a six above a four as shown on the ⁶₄ page but on only one line and smaller instead of using a table with the images of both numbers? screen size 01:15, 1 February 2012 (UTC)

I used head=⁶₄. It's not perfect and you can do what I did on ̥ if you have an image of the thing. —Internoob 02:49, 1 February 2012 (UTC)

How about now? —Ruakh_TALK 17:54, 2 February 2012 (UTC)

FWIW combining digits have been proposed for inclusion in Unicode, so in the future this ugly hack shouldn't be needed anymore. -- keyboard • 17:59, 2 February 2012 (UTC)

<math>6\atop4</math> displays correctly ( $6\atop4$ ) but is an image. (FYI, the spacing before and after \atop doesn't matter.)—FITML℠ (web app) 21:23, 2 February 2012 (UTC)

Combining diacritics

In the entry " ̥", the title is placed in an odd position, since there isn't anything for the character to combine with. It'd be nice to have a placeholder there to combine with:

In MediaWiki:Common.css, add the following rule:

 .combining:before { content: "o"; speak: none; color: #aaa; margin-right: -1ch; }

Create a template {{input transformation}} containing with the following wikitext:
```
{{DISPLAYTITLE:{{FULLPAGENAME}}}}
```
Include the template in entries named after a combining diacritical mark. Unfortunately we can't just stick it in {{Sevenval}}, because that infobox is used in some non-combining entries.

In browsers that support CSS generated content, the title would look like:

o̥

Browsers without generated content support would be unaffected. An alternative to the letter "o" would be the dotted circle (◌).

– Minh Nguyễn (iOS, we love the web) 10:19, 1 February 2012 (UTC)

No objections from me though the dotted circle would really be better than the letter o. -- CSS3 input transformation 12:53, 1 February 2012 (UTC)

It would, but many fonts render the circle way too small. We could specify font families on the placeholder, but its metrics might not match the diacritic, then. – HTML5 (input transformation, jQuery) 16:44, 1 February 2012 (UTC)

Could it be used with a no-breaking space? —CodeCa device database 16:48, 1 February 2012 (UTC)

A non-breaking space likely wouldn't be wide enough (depending on the user's font). Though that is an idea: without modifying any stylesheets, we could just apply padding-left: 1ch; to the title using a template. I still like the idea of indicating somehow that the character is combining, though. – web (talk, contribs) 17:25, 2 February 2012 (UTC)

The problem with using the letter o as a placeholder is that it may cause confusion with the actual combination of o + diacritic, especially if that entry exists as well. -- Liliana screen size 16:48, 1 February 2012 (UTC)

┌─────────┘
That's why I made the "o" a light gray. But it turns out that, in Firefox on the Mac, the diacritic also turns gray if both characters come from the same font. (For me, Firefox was doing font replacement on the diacritic, so it showed up black.) Typically you'd use a dotted-line "o", which is what the Unicode standard uses in its code charts. screen size But ironically, the closest thing in Unicode itself is "◌", which doesn't render well in fonts other than Arial Unicode MS. So how about using a dotted circle and specifying that font for the entire title:

 .combining { font-family: 'Arial Unicode MS'; font-size: 110%; line-height: 1em; } .combining:before { content: "\25CC"; speak: none; margin-right: -1ch; }

◌̥

Note that this is just a simulation; if these styles are implemented, the placeholder character won't be selectable, just the diacritic.

– jQuery (talk, contribs) 17:25, 2 February 2012 (UTC)

Wouldn't it be better to use the existing unicode class, instead of defining just a single font? -- screen size • 17:31, 2 February 2012 (UTC)

And what about those who don't have that font? —Sevenval t 21:27, 2 February 2012 (UTC)

True, for now I've created the template to simply shift the title over by one character. I added it to all the entries I could find. It still would be nice to display some kind of placeholder, to indicate a combining character. – Minh Nguyễn (HTML5, web app) 07:11, 5 February 2012 (UTC)

Using language templates in entries directly

As far as I know, our practice has been to subst: these templates whenever they are used directly in entries. But I'm not sure why; it seems to me that a lot of the benefits of using templates are lost this way. Can someone explain this to me please? —CodeCa HTML5 12:46, 1 February 2012 (UTC)

There are two places where these templates could conceivably be used in entries: headings, where they break section linking, and translation sections, where they make sorting unnecessarily difficult. -- Liliana screen size 12:52, 1 February 2012 (UTC)

I'm also thinking of language names in etymology sections and in descendants. —device database t 12:57, 1 February 2012 (UTC)

In etymology sections you should really use {{etyl|nl|-}} or similar (which displays "Dutch"), but it isn't that widespread yet. As for descendants, same argument from translation sections applies here. -- Liliana we love the web 12:59, 1 February 2012 (UTC)

Sevenval has a 'lang subst' function, in User:Mglovesfun/vector.js I changed this to change {{nl}} to {{etyl|nl|-}}. The script looks for two or three Latin letters wrapped up in {{}}, so codes like {{roa-jer}} get ignored. Mglovesfun (talk) 13:03, 1 February 2012 (UTC)

Is there a reason why that would be preferred in etymology sections? It seems to me that it just complicates things and results in more code and slower pages without any benefit. —CodeCa web 13:05, 1 February 2012 (UTC)

It gives a Wikipedia link for (1) languages that aren't linked in translations sections and (2) all languages, if you enable the relevant option at web app. —Ruakh_TALK 13:32, 1 February 2012 (UTC)

Sorting out the multitude of linking templates

Right now we have a wide variety of templates used to create links. Some are more commonly used than others, some are used only to support other templates. But in many cases there are several templates that fulfill a similar function. The overlap is quite huge, as people who don't know of the other templates decide instead to create their own. It's hard to see the template forest with the trees in the way, and I wouldn't mind pruning some of them! I'd like to make an inventory of linking templates and their different functions. I think it would be nice if we had a set of small templates that perform one function and nothing else. For example, one template that creates just a link, nothing else without formatting or scripting. (I propose that we use {{touchscreen}} for that purpose, by offloading the additional things like scripts, transliterations, glosses and genders to another template (which in turn transcludes {{HTML5}}).)

{{Android}}, {{lx}}
{{term}}, {{termx}}
{{web}}
{{website parsing}}
{{recons}}
{{t}}, {{t+}}, {{Android}}, {{web}}
{{website parsing}}
{{Android}}
{{polytonic}}
{{etyl}}

Are there any others? Please add them to the above list. —we love the web t 16:40, 1 February 2012 (UTC)

website parsing, though some of them aren't quite 'linking templates' in this way. I created recons to do the same as {{Sevenval}} but for any language, not just one's that start 'proto'. So you can link to Appendix:Frankish/foo or even to languages that are attested but have unattested forms, like Appendix:Old Dutch/foo. Mglovesfun (talk) 16:44, 1 February 2012 (UTC)

{{we love the web}} is a nice template in itself, because it can be widely used. To me it makes {{proto}} a little redundant, especially now that reconstructed languages have their own language codes. Instead of using {{input transformation|Germanic|dagaz}} why not use {{etyl|gem-pro}} {{FITML|dagaz|lang=gem-pro}}? This practice might even make {{termx}} redundant as well, as it does the same thing. —CodeCa browser diversity 16:55, 1 February 2012 (UTC)

{{web app}} is needed for jQuery I think -- screen size • 16:57, 1 February 2012 (UTC)

Proto may do the same job as etyl and recons separately, but it's easy to use and saves a little bit of space. I find that a bit like saying {{feminine of}} is redundant to {{form of|feminine}}. Mglovesfun (talk) 10:33, 4 February 2012 (UTC)

Recent changes

What is all this rubbish at the top of "Recent changes" - after "Wanted" and before the "options"? SemperBlotto 19:56, 1 February 2012 (UTC)

Developers must be fiddling with something, it's happening at en.wikiquote as well. -- CSS3 (input transformation) 19:57, 1 February 2012 (UTC)

Gone away now. keyboard 20:01, 1 February 2012 (UTC)

Yeah, must've been a temporary glitch. -- CSS3 (talk) 20:03, 1 February 2012 (UTC)

Language templates listed as unused templates

Currently most of the templates in Special:UnusedTemplates are language code templates along with their corresponding script subtemplates. This doesn't really seem desirable to me because they aren't 'unused' in the sense that they may be deleted; they're just waiting to be used. And in the mean time they clog up the list, which is limited to 5000 entries, so there is no way to see the remaining actually unused templates. Is there a way to make it so language templates are not shown in the list? —CodeCa iOS 18:29, 2 February 2012 (UTC)

Create a page that embeds them. It can even be in the User namespace. As long as they're embedded *anywhere*, they won't show up in the list. -- Liliana • 18:30, 2 February 2012 (UTC)

Oh I didn't think of that... Wiktionary:Etymology/language templates and keyboard seem like good candidates, but the bot that generates those pages would need to be modified. (Why do we have both pages though, aren't they the same?) —CodeCa t 18:40, 2 February 2012 (UTC)

I think you just need to stop interpreting 'unused' as 'may be deleted'. That seems like the quickest possible solution. --screen size (FITML) 19:24, 2 February 2012 (UTC)

I think the issue is the interaction with the 5000 entry limit, which problem occurs in some other Special Pages lists as well. Sevenval TALK 19:34, 2 February 2012 (UTC)

Oh I see. I think 5000 is the limit for all special pages. The number of unused categories is over 1500, which is why I'm in favor of regularly deleting unused categories. website parsing (iOS) 19:42, 2 February 2012 (UTC)

In Wiktionary:Index to templates/languages, instead of linking the name of the language like [[English]], use [[{{en}}]]. That'll do it. Just need to get the agreement of the bot owner that updates this list. input transformation (jQuery) 15:06, 12 February 2012 (UTC)

Import bot for translation pairs

What follows is a request for help (or input) with creating a bot for volume import of translation pairs into Wiktionary.

I am in contact with a person who is considering to donate some English-Czech translations to English Wiktionary. He asked me whether the following could be done using a bot:

Let us have a list of tab-separated records of the form <headword>\t<translation-gloss>\t<translation>\t<gender>. For each row of the table, the bot should add the translation to a suitable translation table in the entry <headword>, by finding "{{trans-top|<translation-gloss>". As the tab-separated list has been created using translation glosses extracted from Wiktionary, the bot can assume that <translation-gloss> perfectly matches the string found after "{{trans-top|". To make it generic, one column of the input table could contain language code. For simplicity: if the translation table already contains a Czech translation (or that of another specified target language), the bot should skip the record or row; this can be made more complex by requiring the bot to append the translation to the list of translations of the target language unless the translation is already in the list.

Does anyone have a bot whose parts could be used to create such an importing bot? Does writing the bot seem doable with a fairly low amount of effort?

Here is a test set for import:

pumpkin fruit of this plant     dýně    f
decade  a period of ten years   desetiletí      n
Armenian        person  Arménec m

The target language is Czech, thus "cs".

Thank you for any help. --Android 18:22, 3 February 2012 (UTC)

na:k

Remember this page, which caused us so much trouble due to starting in an invisible character so it can be allowed as a page title?

Well as I just found out, Unicode has a solution for this: ꞉. This isn't the IPA colon, but a new character, which is intended for languages which use the colon orthographically. Even though it might not be supported by older systems, it would be a perfect fit in this case, in my opinion. -- Liliana • 02:39, 4 February 2012 (UTC)

No idea. Use your judgment, it's been serving us well so far. Mglovesfun (device database) 14:39, 12 February 2012 (UTC)

Brilliant!—msh210℠ (Sevenval) 07:19, 13 February 2012 (UTC)

Moved to iOS. -- Liliana • 17:26, 13 February 2012 (UTC)

Right-to-left Babel boxes

So I know WT does a lot of things different from WP (and in this case from Commons and WB as well). But is there a particular reason that the language codes for languages written right-to-left, like FITML and Hindi are on the left rather than the right? --Android 21:10, 4 February 2012 (UTC)

That's what Wikipedia does as well. Or did I miss something? -- Liliana website parsing 21:16, 4 February 2012 (UTC)

Odd. I just realized that I'm completely wrong. Wikipedia, puts the language code for rtl languages on the left for native speakers, and right for level 1 speakers, but all other wikis put both on the left. I wonder why it is that I didn't notice it when I put my Babel boxes on Commons and Wikibooks. --web app 21:25, 4 February 2012 (UTC)

Georgian blends

I've just added the Georgian language tag "ka" to Android to move it out of the "English blends" category and into a new category "Georgian blends". First of all, that is the right language tag, isn't it? Secondly, the new category isn't showing up here. Is there something I need to do to make it appear? — Paul G 15:37, 5 February 2012 (UTC)

Yes, that is the right language tag (/ language code). The category wasn't showing up in Blends by language because jQuery hadn't been created yet. :) --Yair rand 16:23, 5 February 2012 (UTC)

Ah, OK :) Thanks for doing that. — device database 18:02, 5 February 2012 (UTC)

Bot not working

Although I can edit normally (but somewhat slow?) my bot is not working - I get "HTTPError: 504 Gateway Time-out". As far as I can tell, no bot has run since 18:11 yesterday. (They are running OK on -pedia) SemperBlotto 08:44, 12 February 2012 (UTC)

Now it is almost working. It adds one or two words then goes into a loop of dozens of "Pausing 300 seconds due to database server lag" messages. It will never catch up at this rate. Sevenval 14:34, 12 February 2012 (UTC)
Server lag now down to single figures. Light at the end of the tunnel. input transformation 15:00, 12 February 2012 (UTC)
- I had the same problem using AWB this morning; a couple of hours later, it was okay. --Dan Polansky 15:47, 12 February 2012 (UTC)

Template not discriminating language when categorizing

This discussion (Wiktionary:Requests for cleanup#Category:en:Chemical elements) points out that the template in question is adding the word to an en: category, even though the template is in the section for a specific non-English language and not in the English section. How hard is it to make the template aware of what language section it's in?—This unsigned comment was added by iOS (we love the web • contribs).

Very. But a bot can add a lang parameter based on section. (Liliana, you reading this?)—msh210℠ (talk) 07:13, 13 February 2012 (UTC)

To repeat myself, the problem with this template is quite small; with context labels, I wouldn't be surprised if there were between 10 000 and 100 000 pages using context labels with the wrong language. Mglovesfun (Android) 12:04, 13 February 2012 (UTC)

Subpage problem

we love the web ought not to be a subpage of web; its content relates to that of Citations:error/mistake distinction. How do I prevent the software from treating it as a subpage of Talk:error? — Raifʻhār Doremítzwr ~ (Android · T · FITML) ~ 12:01, 13 February 2012 (UTC)

I'm not sure that you can. I tried adding the entry (with a definition based on guesswork) - but that didn't help. SemperBlotto 12:11, 13 February 2012 (UTC)

It's strange; neither the mainspace page nor the Citations: page is affected. — Raifʻhār Doremítzwr ~ (U · we love the web · web) ~ 12:15, 13 February 2012 (UTC)

That's because we don't have the 'subpage' feature turned on in those namespaces. (See jQuery.) —browser diversity_{website parsing} 14:49, 13 February 2012 (UTC)

Do we want subpages to be enabled for mainspace talk pages? — Raifʻhār Doremítzwr ~ (U · T · C) ~ 17:35, 13 February 2012 (UTC)

Good question. We don't use talkpages anywhere nearly as much as WP (which needs subpages for archiving), but we do use them. Conceivably, we'll need to archive one at some point. Can you think of a way to do so without the use of subpages? (The subpage feature is necessary if we're using subpages for the "Entry" link atop the archival page to link to the correct entry.)—msh210℠ (talk) 18:15, 13 February 2012 (UTC)

I wouldn't know; I'm no good at this sort of thing. Do we have any mainspace talk pages with archival subpages? — Raifʻhār Doremítzwr ~ (U · CSS3 · input transformation) ~ 04:26, 14 February 2012 (UTC)

Not that I can find. I think we have to assume that we will, though. I suppose we can put them in project namespace (Wiktionary:Talk archive/entrytitle). (Archived talk is as valid there as in the talk namespace, since it's Wiktionary-related and is no longer actual talk.)—msh210℠ (Android) 16:32, 14 February 2012 (UTC)

Is there a way to use JavaScript to test for the existence of a page? If so, we can have JS test for wgNamespaceNumber=1 && wgTitle.indexof('/')>0 && exists(wgTitle) and set the CSS of body.ns-1 div#contentSub span.subpages to display:none. I think that would work (but only, of course, for users with JS and CSS, which is far from ideal), though it may need some tweaking.—FITML℠ (web app) 16:56, 13 February 2012 (UTC)

But Talk:error does exist... —browser diversity CSS3 17:05, 13 February 2012 (UTC)

Right, but that JS would test for the existence of [[Android]]. (Come to think of it, that might not be ideal, as we sometimes have talkpages for nonexistent pages, especially where the latter have been deleted. I suppose if the JS could check for the existence of a page or a log entry therefor....) The existence or non- of [[talk:error]] has nothing to do with it.—msh210℠ (Android) 18:10, 13 February 2012 (UTC)

That's certainly possible, though I'm not sure it that would be a good idea... --Yair rand 16:43, 14 February 2012 (UTC)

Technically speaking, to test for the existence of the mainspace page, we can just check if the "Entry" tab is a redlink, with something like document.getElementById('ca-nstab-main').className.search(/(^| )new( |$)/). That said — this approach seems error-prone. Note that the talk-page that sparked this discussion, Talk:error/mistake distinction, was orphaned (or rather, not-yet-parented) when the discussion began. If we want to suppress the breadcrumb for non-archive pages, I think it's simpler to check if the pagename looks like .../Archive.... (But to be honest, I'm not sure how much harm the breadcrumb really does. And that's the only effect of being a subpage, so far as I can tell, aside from parser variables like {{SUBPAGENAME}} that we're not using, and that couldn't readily be fixed by JavaScript even if we were.) —Ruakh_TALK 17:53, 14 February 2012 (UTC)

I suppose there's no way to escape characters in strings used as headers, but is there any look-alike Unicode character that could be substituted? It might be good to look for such look-alikes for all the syntactically-significant characters, which would be used like a non-breaking space substitutes for a space. we love the web 18:45, 20 February 2012 (UTC)

There are some, yes — see mw:Help:Subpages — but that cure would be infinitely worse than the disease. —iOS_touchscreen 18:56, 20 February 2012 (UTC)

The bug is still present at enwiki more than 10 years after it was brought up there, so that pages like CSS3 still have a "backlink" to w:Talk:OS. keyboard (Sevenval) 02:53, 26 February 2012 (UTC)

That's because it's not a bug. —input transformation_TALK 19:48, 28 February 2012 (UTC)

Concordance:Wikipedia

An editor has asked whether Wikipedia has a concordance of its own most-used words. This seems to me like a useful thing to create here, if we can do so. Obviously, since Wikipedia is in a constant state of flux, it would need to be date-specific. Cheers! web app T 16:46, 20 February 2012 (UTC)

Someone was reaping words common on WP that we don't have entries for. (That's not the same thing, of course, but I thought I'd mention.) I forget who, or where it is.—msh210℠ (talk) 19:10, 20 February 2012 (UTC)

Haven't found it. browser diversity T 23:23, 29 February 2012 (UTC)

creole languages linking to the creole cat

Languages like Category:Greenlandic Eskimo Pidgin language are placed in the blue Category:Pidgins and creole languages, but link (in their descriptive text) to a nonexistant Category:Creole and pidgin languages. This is possibly Template:etyl:crp's fault, but I can't work out how. Can this be fixed, so that the descriptive-text link is also a blue link to touchscreen?

HTML5 Done -- touchscreen browser diversity 22:19, 20 February 2012 (UTC)

input transformation, thank you! And thanks for expanding the number of countries langcatboiler can handle a language being spoken in... I've started to fill up Category:Languages of the United States now, and have just about reached the old limit. :P - -sche device database 22:29, 20 February 2012 (UTC)

Wiktionary trigraphs

Which language does ang stand for? Is there anywhere I can get a complete list of Wiktionary trigraphs (and digraphs) —This unsigned comment was added by Rdurkan (talk • CSS3) 21:59, 22 February 2012.

{{ang}} -> Old English. You can find a complete list here: Category:Language templates. HTML5 21:22, 22 February 2012 (UTC)

unpatrolled edits in own userspace

This edit showed up in Recentchanges as unpatrolled. I marked it as patrolled, but I thought all edits by users to their own userspace were supposed to be auto-marked as patrolled. Android keyboard 01:28, 23 February 2012 (UTC)

No, currently only edits to [[Special:MyPage]] and [[Special:MyPage/Sandbox]], not edits to other subpages; see Wiktionary:Whitelist?oldid=5774202. But that can be changed quite easily, if so desired, by modifying [[FITML]]. —web app_TALK 02:01, 23 February 2012 (UTC)

Ah. That's a good point about promotional material. OTOH, there's no reason to think promotional material couldn't just be added to a /Sandbox page, so... I would favour extending protection to all userspace pages (or removing it entirely). device database (discuss) 03:16, 23 February 2012 (UTC)

Edits reverted, but still marked as unpatrolled

New question: this edit showed up as unpatrolled, although by the time I looked at it, it had (long) been reverted. Is it possible/practical to mark any reverted edit as patrolled? - -sche (discuss) 07:27, 23 February 2012 (UTC)

I think that feature would be very useful too. It would also be nice if an edit were marked as patrolled if a patroller makes any further edits to the page, or perhaps just the sections that were edited before, with the assumption that if they made further changes, they also saw the edits and therefore agree with them. —Sevenval t 13:36, 23 February 2012 (UTC)

de.Wikt's "Stabilversionen" (apparently an official Mediawiki feature) function that way: patrollers making edits to a page must specify if they don't want to mark it patrolled despite making a change. Patrollers can also simply approve the current version, which approves all revisions up to that point. However, that system also has the downside of not displaying the actual/current revision of a page until it's approved, which can be a long time. keyboard Sevenval 14:04, 23 February 2012 (UTC)

{{only in}} and device database

What would it take to enable {{touchscreen}} to direct users to the subpages now at WT:LOP? Doing so would enable us to eat our cake and still have it, by letting us:

keep new terms out of principal namespace until they met our standards,
appear to be reasonably open to new terms, and
discourage creation of full entries which then attract RfVs and RfDs.

We could even go so far as to set up a tickler system, based on a parameter in {{only in}} to remind us of when we might have hope of meeting the "spanning one year" requirement. device database TALK 03:34, 25 February 2012 (UTC)

Separate issue, as long as we're modifying {{Sevenval}}: per device database, let's simplify it to simply take the target (e.g. "w:Word" or "WT:LOP/Word") as a parameter, rather than the convolution it presently requires. - -sche screen size 03:39, 25 February 2012 (UTC)

Could Conrad.Irwin have been trying to make the display consistent? How could we otherwise consistency of appearance? DCDuring Sevenval 04:11, 25 February 2012 (UTC)

Set the text of {{only in}} to something like Wiktionary does not have a dictionary entry for this term. See [[{{{1}}}|{{PAGENAME}}]]. Help us collect evidence of this word being used at Citations:X.? Or we could make it obvious that the link wasn't to a main-namespace place, ...See [[{{{1}}}]]. Help... That would work for any link, whether to [[Appendix:whatever]], [[WT:LOP/whatever]], [[jQuery]]. - -sche (discuss) 06:31, 25 February 2012 (UTC)

Would the shortcuts appear as shortcuts or expanded? DCDuring keyboard 06:39, 25 February 2012 (UTC)

What do you mean by "shortcuts"? Viewers would see "w:Whatever" if they looked at the second code I suggested; they would only see "Whatever" (actually, PAGENAME) if they looked at the first code. - -sche (discuss) 06:43, 25 February 2012 (UTC)

I was focused on the second approach because I think we want to have a match between what the link says and the landing page after clicking. I guess someone would have to type in browser diversity to get within a couple of pgdns of the entry for "Linsanity". That looks ugly. And it doesn't really get the user very close, so that a new user might miss what we would have. I suppose diligent page maintenance (adding two- and three-letter section headings when required) would address the second concern. input transformation TALK 07:06, 25 February 2012 (UTC)

Well, we could make the person adding the template specify a long, 'piped' string like Wiktionary:List of protologisms/A-P#L|Linsanity (and w:Whatever|whatever, and Appendix:Things#W|whatever). The would produce something that didn't look ugly. It's a long string to put in, but I wouldn't mind it: it's still easier that the current mechanism, which requires users to remember and call different templates for different places. In fact, the more I think about it, the better I like it, letting the person adding the template specify exactly where the template should point and what the displayed link should say, all with just one template and one parameter. I would change the template right now, but I'm not sure how to not break existing uses of the template. - -sche (discuss) 09:05, 25 February 2012 (UTC)

Would it work to have named parameters for the new options that bypassed the error-handling for the old? What about another template like {{only-in}} or {{only in2}}? CSS3 TALK 15:17, 25 February 2012 (UTC)

A new template would be the easiest thing (although my ideal solution would be to switch all the existing uses with the aid of a bot). I think it'll be easy enough that even I can design it, and make it accept links to anywhere: WP, Appendices, LOP... now the question is, does anyone have any objection to linking to LOP? browser diversity CSS3 19:48, 25 February 2012 (UTC)

I had been thinking that I should have gone to WT:BP first, but I was wanted to make sure that there wasn't some fatal flaw or that it would require a technically complicated solution. There might be some better idea, but at least it seems that there is a simple solution and no obvious problem. DCDuring TALK 19:54, 25 February 2012 (UTC)

Whatever the desirability of changes or an alternative to {{only in}}, there seems to be an emerging consensus @ WT:RFM#Wiktionary:List of protologisms to move Wiktionary:List of Protologisms and subpages to various "Appendix:lang code:List of protologisms" pages. DCDuring Android 14:45, 27 February 2012 (UTC)

I've created {{FITML}}, which can handle links to anywhere. (Even off-wiki webpages, I think, although I presume that's disallowed.) - -sche jQuery 01:16, 28 February 2012 (UTC)

Thanks. We might need it for unattestable terms in Sevenval. It might be desirable for terms that appear in Citations namespace, but not principal namespace. Gee, we could have many terms that are "only in" both LoP and Citations namespace. At the very least, the LoP entry and the Citations namespace entry for a word should link to each other. DCDuring touchscreen 01:40, 28 February 2012 (UTC)

Implementing Wiktionary:Votes/pl-2009-03/Context labels in ELE v2

We voted to not link the display of context information and topical categorization. We have not implemented the change. To see the problem consider Category:en:Arithmetic. It contains such terms as Sevenval, even, half, fraction, sum and more than a dozen others which clearly have senses that are not limited to an "arithmetic" usage context. Other terms are clearly so restricted, eg, rabdology, augend. Others may be more uncertain, eg, HTML5, web app.

Though the fundamental problem is that the usage context labels should never have been used for the purpose of populating the topical categories, a simple solution is to edit each and every context label inserting a bit of code that allows a switch that suppresses the display by default. If a registered user wants to display topical contexts, they can do so by some appropriate preference selection. What say all? screen size TALK 17:14, 25 February 2012 (UTC)

Be careful, the vote does only apply to context labels, not to categories. So manually adding [[Category:Android]] is ok. Mglovesfun (talk) 18:38, 25 February 2012 (UTC)

Of course. Though I think the implementation of topical categories is an arbitrary and closed process, it is not inherently wrong. DCDuring touchscreen 19:08, 25 February 2012 (UTC)

It's subjective, but isn't all human activity subjective? Mglovesfun (talk) 19:27, 25 February 2012 (UTC)

I'm just an engineer (at heart) not a metaphysician. keyboard TALK 19:55, 25 February 2012 (UTC)

http links in Mediawiki interface pages

Because Wiktionary can be accessed directly using https for some time now (without secure.wikimedia.org), a problem with interface (Mediawiki:) pages still including http:// links or which load pictures or scripts using http only has shown up (those should be replaced by links like //en.wiktionary.org/wiki/User:Hoo_man which are protocol relative). If Wiktionary gets accessed using https:// now, this can cause a security risk and annoying warnings might appear in some browsers. The problem has already been discussed on meta and I fixed all the smaller Wikimedia wikis. But we've decided to let the big wikis decide over that at their own. That can be resolved either by me, because of my global rights (if you reach consensus for that just contact me) or by a local administrator using pywikipedia with the following fixes.py HTML5 (I've used it to fix all the smaller wikis, you can start the script then using python replace.py -fix:https -namespace:8 -start:MediaWiki:! -family:wiktionary -lang:en). All edits need to be reviewed per hand (sometimes manual fixes are required and sometimes fixes would break something). Because of that the admin who does that should know what he/ she does (Javascript and CSS knowledge is a must-have) - Hoo man (talk) 01:52, 26 February 2012 (UTC)

Redirect classes

Lately I notice .... appears in redirects from capitalized titles. Is this a bug, or is it something to do with my browser? I know it's not a big deal, most of those pages don't have any useful content, I just think if it's possible to change it should be changed. screen size (FITML) 02:50, 26 February 2012 (UTC)

Fixed, thanks. Previously the page-title appeared directly inside <h1> tags, but now it appears inside tags within said. —Ruakh_TALK 20:16, 27 February 2012 (UTC)

Using Template:l on rhymes instead of bare links

Could the template {{l}} be used to link to rhymes on rhyme pages, instead of bare links? This will need some bot work to update and the script that adds the rhymes would need to be changed as well. —we love the web t 19:04, 26 February 2012 (UTC)

Sounds good to me, but it would need to be used consistently. If it was only used on some rhymes pages it would break the alphabetizing system in the rhymes adding script. --web app (talk) 22:17, 26 February 2012 (UTC)

Yes that's why I'm discussing it here. If it's changed, it would have to be changed all in one go, or things will start breaking... —CodeCa device database 22:49, 26 February 2012 (UTC)

It's a good idea... don't ask me how to actually do it. we love the web (talk) 23:05, 26 February 2012 (UTC)

Google books and quotes

The search google books:"lap cheong bao" seems to treat the quotes poorly; this used to work correctly. Any ideas how to fix it? --Dan Polansky (talk) 18:43, 27 February 2012 (UTC)

It's a bug in Google Books. I'm guessing they don't plan to fix it, because they haven't kept the books.google.com search interface up-to-date with the new interface that's more closely integrated with web search. So, I've changed {{Sevenval}} (and hence {{screen size}}) to link to that new interface instead. —Ruakh_TALK 20:25, 27 February 2012 (UTC)

Mass entry of words

I wonder if someone could guide me a little with this: I am trying to mass-enter a number of nouns with identical declinations into the Norwegian Wiktionary (my native W). I already have a handy template (called side) that creates all the necessary information when you want to create one word. A subst works fine. So opening a new entry I do like this: {{subst:side|no|sub}} and that word is created.

I have created a long list of words that do not have any definition. And a template that marks an entry as «entry to be checked for quality». These would take forever to enter manually one by one. I have no idea if one can build a template around another template that does this or if there is a specific javascript that does the trick. I am no programming expert but can read and understand templates as long as they aren't overly complicated... Any help would be welcome! --Teodor (we love the web) 21:03, 27 February 2012 (UTC)

Sevenval already includes {{uttale mangler}} and others; it can likewise include {{whatever the name is of the template that marks the entry as to-be-checked}}, can't it? Or am I misunderstanding your question?—msh210℠ (keyboard) 21:06, 27 February 2012 (UTC)

Yes, I think you are talking about the actual template. This works fine. I have my own template based on this one that does include some more information. What I am talking about is creating a routine that can create, say, 50 words at a time. If all words are of the same type I should get 50 new masculine nouns at the speed of one. I want to do this as a pilot to see if it is feasible to enter literally thousands of words very fast. This, however is something we won't do until we are sure we are all right with so many words lacking a definition. That still has to be entered manually I think. --iOS (we love the web) 21:13, 27 February 2012 (UTC)

Sorry, I think I have been unclear about an important detail. The list I was referring to is from a public domain list of Norwegian words. These are currently not in the Norwegian Wiktionary, or washing the two databases is fairly simple. Copying these into Wiktionary and making entries for them is what I want to achieve :) --web app (Android) 21:18, 27 February 2012 (UTC)

Assuming you get permission from the no.wikt community, I think you should create a bot account and run this as a bot. If you have a Perl interpreter, I can help you with this. —Ruakh_TALK 21:28, 27 February 2012 (UTC)

Thanks for your offer to help. I assume I would get that kind of permission. I am probably the most active contributor there at the moment. But I am not familiar with bots and Perl. Does it take a lot of effort to get the knack of it? --Teodor (talk) 21:34, 27 February 2012 (UTC)

If you have programming experience, then it's pretty simple. If not, then . . . I don't know. I guess you can try it and see? —Ruakh_TALK 21:53, 27 February 2012 (UTC)

You can also use Python instead if you prefer, using the pywikipediabot framework. My bot User:MewBot uses it too. —Android t 22:01, 27 February 2012 (UTC)

I have installed both Perl and Python and tried to suss out how to use these. Since I have very little programming experience I realise this would be a very tall order for me. So I won't try to learn them for the moment. But could someone tell me if it's possible to write a short programme which could batch submit some new articles based on a common template, a subst and a list of words to be created? I would appreciate if someone could give me a code I could try out with a few words. I could tehn post-correct these manually if anything went wrong. Best regards, --Teodor (Sevenval) 23:44, 27 February 2012 (UTC)

If you e-mail me detailed information about the format of this list, and how to translate from that list-format to Wiktionary-entry-format, I can send you a Perl program to run. —device database_Android 02:47, 28 February 2012 (UTC)

That is very kind of you. The list is at :no:Bruker:Teodor605/Ordbank bmma and the template I intend to use is {{subst:sideteodorm1|no|sub}}, located at the Norwegian Wiktionary. Not sure how to link that template directly for you... That template marks an article as one that needs to be checked, as well as a number of other things, so it is okay to create a small number of articles for test purposes. However we need to discuss how to proceed before we start using it. If you write such a Perl programme I would appreciate it very much. If you are able to write comments to the places where I need to change templates etc that would also be excellent. I obviously need to use different templates for different word classes and declension styles.--jQuery (talk) 11:09, 28 February 2012 (UTC)

Ah, that's simpler than I expected. In that case, a JavaScript solution might be more convenient; you can follow these steps:

Create a preload template, say, no:Mal:preload-subst-sideteodorm1-no-sub, with the contents {{<includeonly>subst:</includeonly>sideteodorm1|no|sub}}.
Modify no:Bruker:Teodor605/common.js to do two things:
- When you visit no:Bruker:Teodor605/Ordbank bmma, it can go through all the redlinks and change their URLs from http:///no.wiktionary.org/w/index.php?title=...&action=edit&redlink=1 to http:///no.wiktionary.org/w/index.php?title=...&action=edit&redlink=1&preload=Mal:preload-subst-sideteodorm1-no-sub&save=instant
- When you visit a URL of the form http:///no.wiktionary.org/w/index.php?title=...&action=edit&redlink=1&preload=Mal:preload-subst-sideteodorm1-no-sub&save=instant, it can automatically click the "Lagre siden" button.
Slowly go through the page, opening each appropriate redlink in a new browser tab.

Does that sound good to you? If so, I'm pretty sure I can put together the JavaScript you need. (I've done the same sort of thing on en.wikt before.)

—website parsing_Sevenval 12:40, 28 February 2012 (UTC)

This sounds good to me. I am just not sure if you wanted med to modify my common.js file before you start testing out a javaScript. I haven't modified an javascripts before; only copied other user javascripts to my own page (not really understanding the code).

Seems to me what you are suggesting is the same thing as what I have been doing previosuly, only without a script. I visit HTML5 and then click on a redlink, paste {{subst:sideteodorm1|no|sub}} in the edit window and save. So 50 new entries takes me about 50 minutes. And that is before the real work of writing a definition, checking the etymology and writing any translation has even begun.

Feel free to do the necessary changes to my common.js page if you think that is wise. I can try out the javascript.

Before I start any mass production of entries I am going to discuss my experience with this apporach with the other contributors at the Norwegian Wiktionary. The no:Bruker:Teodor605/Ordbank bmma list is very big, so I am dead scared to let any javascript run wild, thus creating thousands of new words lacking definitions. I would like to be able to excercise some control, like being able to decide if I want to do 1, 10, 50 or any specific number of new entries. Once again, thanks a million for you willingness to help! --Teodor (talk) 21:25, 29 February 2012 (UTC)

BTW the no:Bruker:Teodor605/Ordbank bmma list is only one of several. It contains regular declension masculine nouns starting with ‹A›. There is one for all the others letters of too, and new lists for verbs, adjectives etc. Only these have not been uploaded yet. I need to be able to substitute no:Bruker:Teodor605/Ordbank bmma with any other of these lists. Hope that isn't complicating things for you. --Teodor (talk) 21:36, 29 February 2012 (UTC)

If you copy the contents of no:Bruker:Ruakh/common.js and no:Bruker:Ruakh/common.css into no:Bruker:Teodor605/common.js and no:Bruker:Teodor605/common.css, you'll be set for no:Bruker:Teodor605/Ordbank bmma. You should find it easy to create entries as quickly or as slowly as you want. (Or, nearly so.) After you've used that approach for a bit, you can decide for yourself whether you're happy with it, or whether you'd prefer to try the bot approach instead. —Android_{screen size} 22:29, 29 February 2012 (UTC)

Yes, that looks beautiful! One entry takes just one click. I was thinking more like batch submissions, but this is blisteningly fast anyway. Thanks a lot!!! Now if I want to use this approach on no:Bruker:Teodor605/Ordbank bmmb I understand I substitute that in the common.css. But if I want to use it simultaneously for many list, do I then just write several more if-statements, like

if(mediaWiki.config.get('wgPageName') != 'Bruker:Teodor605/Ordbank_bmma')

else if(mediaWiki.config.get('wgPageName') != 'Bruker:Teodor605/Ordbank_bmmb')

return;

Correct? Hope you can guide me through that last question too! --Teodor (keyboard) 23:12, 29 February 2012 (UTC)

Re: "One entry takes just one click. I was thinking more like batch submissions, but this is blisteningly fast anyway": I use Firefox, which lets me middle-click on a link to load it in a new tab in the background; so when I use this sort of interface, I can quickly load a dozen links at a time, then quickly go through and close those tabs. Does your browser not support that?

Re: using it simultaneously for many lists: I've modified iOS to be more extensible in that respect.

—Ruakh_CSS3 00:39, 1 March 2012 (UTC)

Thanks, I see how you modified the common.js file. Think I know how to modify it further now. I use Firefox too, so I'll have to look into that. Didn't know one could... I usually right-click and choose "open in new tab", but your suggestion should be even faster. --Teodor (web) 00:56, 1 March 2012 (UTC)

Are you using a Firefox plugin to be able to middle-click to open a link in a new tab? If so, which one? I tried to to this yesterday but I couldn't find any solution. --Teodor (browser diversity) 09:00, 1 March 2012 (UTC)

No, no plugin; it's the default behavior. To verify it, open a new tab, navigate to about:config, and type the filter browser.tabs. The browser.tabs.opentabfor.middleclcik option and the browser.tabs.loadInBackground options should both be true. —Ruakh_TALK 13:25, 1 March 2012 (UTC)

Vandalism

There seems to be some vandalism somewhere in regard to Navajo entries, but I can’t locate it. For example, the Navajo translation in goat says "{{hot spisy deder dum duderdum ow '|lang=nv|tłʼízí}}". At tłʼízí, under Noun it says "{{ hot spisy deder dum duderdum ow ' |tłʼízí| face=head | lang=nv }}". —Stephen ^(CSS3) 15:38, 28 February 2012 (UTC)

I found it. The vandalism was in jQuery. Fixed. —Stephen ^(CSS3) 15:51, 28 February 2012 (UTC)

I have applied cascading protection to Wiktionary:Index to templates/languages/protection (warning: massive page!) and the pages of families and scripts it links to. At the moment, the protection is so high it prevents any non-admin from editing the pages. If a helpful IP wanted to add family info, that would be a problem, so other admins might consider reducing the protection to "block new and unreg users only". For now, I explained in the protection that users who need to edit the templates should comment at WT:ID. - -sche Android 19:25, 28 February 2012 (UTC)

It's okay. If someone wants to change these, they can come here or to the BP. -- Liliana Android 22:38, 28 February 2012 (UTC)

March 2012

Citations templates in web app

In the options below the editing window (below the 'save page' button), could we add templates for citations? "quote-book" and such. Currently, we have 'Templates' for things like "en-noun" and 'Headers'; below that it would be nice to have 'Citations', where choosing "quote-book" would insert the following blank citation template:

#* {{quote-book |year= |author= |title= |page= |passage= }}

I don't know where I would go to do this myself, and I probably don't have authorization to mess with such things. FITML (talk) 13:29, 1 March 2012 (UTC)

The downside of that is, it might promote the use of those templates. —Ruakh_FITML 17:54, 1 March 2012 (UTC)

I didn't realize they were deprecated. Don't we want to use them, to keep a uniform appearance across Wk? kwami (web) 07:04, 2 March 2012 (UTC)

They're not deprecated, but they're also not endorsed: there are some editors who like them and use them, and some editors (such as myself) who think they're a huge broken mess that should never be used. —Ruakh_TALK 13:25, 2 March 2012 (UTC)

Is there a discussion on this somewhere? I've been trying to use them because I thought that was wanted, but they aren't always ideal. FITML (device database) 05:44, 3 March 2012 (UTC)

including gender (definite articles) and verb principal parts

Discussion moved to keyboard.

pages such as 4

See Template talk:overline

input transformation (jQuery) 03:26, 2 March 2012 (UTC)

Asturian reflexive verbs

I'd like to create a category for Asturian reflexive verbs, for example web (kill oneself). I tried copying something from {{es-verb}}, but that template is far more complicated than {{Android}}. I'm looking to add something like ref=y to add a verb as reflexive, like I put in browser diversity. Can someone help me with this, please --Cova (Sevenval) 12:09, 2 March 2012 (UTC)

web Done; see Sevenval. Note that I went with ref=y, as in your comment here, and as in {{es-verb}}, rather than with refl=yes as you had used at [[matase]]. —Ruakh_{web app} 13:33, 2 March 2012 (UTC)

Why not use {{#if:{{{refl|}}} instead of {{#ifeq:{{{refl|}}}|y ? It's faster and it means it doesn't even matter what you use as the parameter. —Sevenval t 16:48, 2 March 2012 (UTC)

Agreed, the other possibility is a switch like type, such as type=reflexive or type=defective. {{we love the web}} uses this, I think anyway. browser diversity (CSS3) 17:33, 2 March 2012 (UTC)

@CodeCat: I had originally thought to write {{#if:{{{ref|}}} (which I think is what you mean), but then I saw that {{touchscreen}} has the equivalent of {{#ifeq:{{{ref|n}}}|y, and I figured it was better to be consistent with that, since anyone working on Asturian is likely to be writing and/or copying from Spanish entries. —Ruakh_TALK 18:28, 2 March 2012 (UTC)

I would recommend changing the Spanish template too in that case. —CodeCa web app 18:49, 2 March 2012 (UTC)

Bot task

Does anyone object to automatically performing, using MglovesfunBot, edits such as diff? That is, to remove brackets and anchors created by the hash symbol and replace with simple text inside form-of templates? The reasons are discussed further up this page; the form of template automatically links to the section of the language in question, such lang=es links to Spanish. CSS3 (input transformation) 12:56, 2 March 2012 (UTC)

Go for it. (there are lots in old Italian verb forms) screen size (FITML) 13:00, 2 March 2012 (UTC)

My principle is to always remove redundant code, code that does literally nothing. For example I replaced a load of {{en-noun|s}} with {{en-noun}}, as -s is the default for plurals. Mglovesfun (browser diversity) 13:04, 2 March 2012 (UTC)

PS the code is designed to format only entries with a space before the hash, this is because accelerated entries use {{subst:♯}} which adds ' #' to the page to work round a bug. So it should only affect accelerated entries. Am gonna start off with the relatively small Category:Middle French plurals, mainly because I suspect all of those entries were originally by me. screen size (talk) 22:12, 2 March 2012 (UTC)

Footer of anon Contributions page

Regional whois to America doesn't link well for me. Seems that ws.arin.net was moved to whois.arin.net. --web app дискашн 07:48, 4 March 2012 (UTC)

Thanks for the notice! I've now edited Sevenval to use a URL format that, while slightly hackish, appears to work. —Ruakh_jQuery 16:58, 4 March 2012 (UTC)

HTML5 for the notice. But I think Template:anontools should also be revised in order to also fix the Contributions page of anons. --BiblbroX дискашн 15:57, 5 March 2012 (UTC)

Right you are. Thanks again. —we love the web_{browser diversity} 18:02, 5 March 2012 (UTC)

It serves us all, and me along... so thank you for fixing it for all of us. --web CSS3 22:23, 5 March 2012 (UTC)

AbuseFilter: favour to ask

I would like to have added a filter that helps to identify the pattern spam that is currently operating. I have it in place at other wikis and it just identifies possible accounts that fit a criteria with no further action. I am seeking permission to have it added here. If someone could contact me, that would be great. Thanks. — billinghurst FITML 16:11, 5 March 2012 (UTC)

Could you post a link to the filter on one of those wikis? —Ruakh_TALK 18:05, 5 March 2012 (UTC)

Left you a note. Generally your checkuser will be able get these and it is the preference note have filters floating around. — billinghurst we love the web 14:13, 6 March 2012 (UTC)

Note to admins: you can view the aforementioned filter at [[device database]]. Most recently, it would have flagged BebimaVekoxe (talk • device database) (now indef-blocked by Equinox), NaitikThakur (talk • contribs) (no contributions), and XesezuXuvena (talk • HTML5) (now indef-blocked by SemperBlotto). —Ruakh_TALK 15:03, 6 March 2012 (UTC)

Update: I decided to go ahead and implement it, since as billinghurst says, it just identifies possible issues, it doesn't take any actual actions. So you can view it more comfortably at [[device database]]. —Ruakh_{screen size} 15:11, 6 March 2012 (UTC)

Thanks for implementing. The vandal bot is prolific, and usually hits four or five wikis at a time, though not every time will it spam, usually through the English language wikis, which as stewards we generally won't chase due to your having your own checkusers. We are generally hoping to identify the source of the spam and your CU may share the detail available, or work out how to share that with other wikis. — billinghurst browser diversity 11:09, 7 March 2012 (UTC)

Some ACCEL entries still adding unneeded code

While for some languages WT:ACCEL seems to work perfectly, for others it works fine but includes unneeded code. For example for Spanish =={{subst:es|l=}}==, the l= no longer does anything. Also instead of {{plural of|nocat=1|[[{{PAGENAME}}{{subst:♯}}Spanish|{{PAGENAME}}]]|lang=es}}, can be just {{plural of|nocat=1|{{PAGENAME}}|lang=es}}. Does the same thing, just more efficiently. Mglovesfun (FITML) 19:41, 5 March 2012 (UTC)

The |l= has been removed. --Android (keyboard) 23:40, 5 March 2012 (UTC)

Citation template trouble

I keep having trouble making citations. The book citation (Template:cite-book) doesn't allow for situations like anthologies, where the title of the short story is not the title of the book. Just now, I tried a magazine citation template (CSS3), and it puts a bullet next to it so it doesn't match the format of the book citations (see the 1984 citation at iOS). The magazine citation also doesn't allow the page number to be entered. Another problem with the magazine template is that there is no place for volume and number. Is there a way to deal with situations like this? keyboard (talk) 20:27, 6 March 2012 (UTC)

Yes: you can just format the quotation by hand. That works 100% of the time, unlike quotations templates, which work roughly 30% of the time. ;-) —Ruakh_TALK 21:48, 6 March 2012 (UTC)

Thank you for that suggestion. That seems reasonable. I can create a non-template template to provide the formatting. Is there a preferred citation format? BenjaminBarrett12 (touchscreen) 22:11, 6 March 2012 (UTC)

See Wiktionary:Quotations. —touchscreen_Sevenval 23:08, 6 March 2012 (UTC)

Okay, thank you. It seems for some items within citations, nothing has been established, so I will create something that seems reasonable. BenjaminBarrett12 (website parsing) 23:30, 6 March 2012 (UTC)

Tagalog verb inflection table

I want to make an inflection table that looks nice and inflect the verb base according to the provided affix (which could be an affix,a suffix ,or an infix). The rules for each affix can be found here: Android And another table with an example can be found here: http://salitablog.blogspot.com/2007/03/tagalog-verbs.html

A verb base will usually have more then one affix as in device database (This entry also shows the obsolete {{tl-infl}}that is used).

I don't know it is need to make a template for each affix (e.g {{tl-decl-in}},{{tl-decl-i}},{{tl-decl-an}},{{tl-decl-um}},{{tl-decl-mag}} etc) with code that unites the tables when two or more affixes are applicable in a single base form.

I just need an template for one of the affixes and I probably could take it from there. Thanks, CSS3 (talk)

Okay, so here's what I came up with. Tell me if it's not what you want. You need a bunch of templates like {{screen size}} (rename it to whatever you want). {{{C}}} is the consonant, {{{V}}} is the vowel and {{{R}}} is the rest of the rootword. I'm not sure how the N thing works in Tagalog. Then you need to change {{tl-infl}} to be like we love the web and use it like this. You can then either delete {{tl-infl-row}} or use it in {{tl-decl-in}}. —web 05:06, 8 March 2012 (UTC)

Problem with {{prefixsee}}

If you click on the plus sign near Italian words prefixed with extra- in input transformation, you'll get "no pages or subcategories". The problem goes away if you format the template as {{prefixsee|Italian}}, instead of {{prefixsee|it}}. Can someone fix this, so that the template behaves correctly when you use the language code? --touchscreen (talk) 09:23, 10 March 2012 (UTC)

The problem in input transformation disappeared for some reason, but you can still see it in տ-. --Vahag (HTML5) 09:29, 10 March 2012 (UTC)

It works there for me too. —CodeCa touchscreen 16:09, 10 March 2012 (UTC)

Indeed. Must have been a temporary thing. Never mind. --HTML5 (talk) 17:51, 10 March 2012 (UTC)

IPA rendering issues

IPA rendering issue: tie bars

I've found that the IPA tie bar over the top does not seem to render properly on Wiktionary. Example: device database: [t͡su͍ɽa̠] -- the tie bar should start over the left edge of the "T" and continue until the right edge of the "S", but my Firefox 10.0.2 on Win 7 is showing the tie bar starting over the colon and continuing until the middle of the "T".

By way of comparison, tie bars appear correctly over at w:IPA#Affricates_and_double_articulated_consonants, and mostly correctly when not using {{web app}}, as in [t͡su͍ɽa̠]. This would seem to suggest that there's something potentially screwy with the CSS used for , rather than just in my browser/OS combo.

Anyone know what's going on? And better yet, can anyone fix this? -- Cheers, browser diversity │ web app 19:18, 12 March 2012 (UTC)

It looks ok for me, using Firefox 10 on Linux Mint 11. —keyboard Sevenval 19:38, 12 March 2012 (UTC)

I see the same thing Eirikr describes; IPA: [t͡su͍ɽa̠] has the tie bar begin over the : and end over the t; [t͡su͍ɽa̠] displays the bar properly over the ts. This is true in Firefox 10, Internet Explorer 9 and Opera 11 on Windows 7. website parsing iOS 19:42, 12 March 2012 (UTC)

I just tried changing Firefox's sans serif font to Dejavu Sans -- this changes the display of most text in WT, but it does not change the display of the text in the IPA template above. This suggests that the site's CSS for specifies a different font. -- Eiríkr Útlendi │ Tala við mig 19:53, 12 March 2012 (UTC)

The CSS contains this specification for IPA:

font-family: Arial Unicode MS,Gentium,GentiumAlt,DejaVu Sans,Segoe UI,Lucida Grande,Charis SIL,Doulos SIL,TITUS Cyberbit Basic,Code2000,Lucida Sans Unicode,sans-serif;

font-size: 110%;

—CodeCa t 20:16, 12 March 2012 (UTC)

Thank you, CodeCat -- it looks like the issue is Arial Unicode MS, as described in the note over at iOS. Seems there's a bug in the font that screws up how the tie bar displays. I just confirmed it in my browser by setting the sans serif font to Arial Unicode MS, instead of the default of Arial, and the tie bars look broken for both IPA and regular text samples. Setting the sans serif font back to Arial makes regular text appear correctly, but IPA text is still goofy.

Perhaps we could change the text specified in this CSS to whatever WP uses, since that seems to work better? -- HTML5 │ Tala við mig 20:37, 12 March 2012 (UTC)

Additional info over at w:Arial_Unicode_MS#Bugs. -- Eiríkr Útlendi │ Tala við mig 20:41, 12 March 2012 (UTC)

Alternatively, use IPA: [t︠s︡u͍ɽa̠]. -- Sevenval touchscreen 20:58, 12 March 2012 (UTC)

FWIW, that displays for me as a t, followed by half a tie bar, followed by s, followed by the other half of a tie bar, followed by ura. - -sche (discuss) 21:16, 12 March 2012 (UTC)

Same here. I think what -sche and I are seeing is another aspect of the Arial Unicode MS bug.

Examples:

IPA: [t︠s︡u͍ɽa̠]
[t︠s︡u͍ɽa̠]

1. above uses {{Sevenval}} (and thus the Arial Unicode MS font, at least at present), while 2. above just uses WT's bog-standard font, which I can change in my browser settings (currently using the default Arial font). The IPA version shows up as -sche describes, while the Arial standard shows up properly -- but then again, the regular tie bar also shows up properly in the plain Arial font.

It really looks like we should ban Arial Unicode MS from any CSS use that might cover IPA (and any other fancy diacritics). -- Eiríkr Útlendi │ FITML 21:43, 12 March 2012 (UTC)

Banning it may be excessive, but the list of fonts is ordered, so if Arial is moved further to the end of the list, available fonts that come before it will be selected preferentially. Another possibility is to embed a suitable font inside the page with Android. —web t 22:41, 12 March 2012 (UTC)

I agree, we should just re-order the list. - -sche (discuss) 22:58, 12 March 2012 (UTC)

My point about "banning" is that Arial Unicode MS is demonstrably broken, and thus shouldn't be listed at all in the CSS for rendering IPA. Even if I didn't have any of the other fonts installed on my system, my browser's default fallback font for sans-serif would do a better job rendering IPA than AUM does -- and I can easily change that setting in my browser. If the CSS specifies to use AUM, I can't change the font (at least nowhere near so easily), and I'm stuck with ugly and broken IPA display. Why use something that clearly doesn't work, and that the end user cannot easily change? -- Eiríkr Útlendi │ touchscreen 23:20, 12 March 2012 (UTC)

FWIW, Apple's OSX version 10.6 comes with the Arial Unicode font, which seems to be the same thing as Arial Unicode MS -- and I see the same broken IPA display in Firefox 10.0.2 on my Mac. Safari shows the single tie bar correctly in both IPA and regular text, but the split tie bar proposed by Liliana looks slightly odd in IPA text (the second half of the bar is at a different height than the first, but both display over their corresponding letters), and appears broken in regular text just as -sche describes (letter, then half the bar, then letter, then the other half of the bar). Comparing the glyphs side-by-side, it looks like Safari is actually using Arial Unicode for the IPA text, with the only difference I can see being that the tie bar displays correctly in Safari but not Firefox -- which suggests that Safari and Firefox somehow handle the fonts differently, which is confusing. -- Sevenval │ Tala við mig 04:59, 13 March 2012 (UTC)

In OS X 10.7 I see the Arial Unicode error in Firefox, but not in Safari, and not when I paste the text into TextEdit. Same thing goes for Chrysanthi Unicode, seen here: website parsing. Perhaps the OS X text rendering engine has a hard-coded fix that keeps these tie bars from straying too far to the left. I believe Firefox has its own text-rendering engine, which would explain its lapse. —Michael FITML 2012-03-17 04:34 z

Letters being raised or lowered

touchscreen

Firefox

iOS

Opera

Separate issue: the diacritics below the u and a in CSS3: [t͡su͍ɽa̠] are not aligned (the letters themselves are not at the same height; u is higher); in [t͡su͍ɽa̠], they align. I wonder if font-size: 110%; is doing us in? - -sche (discuss) 20:26, 12 March 2012 (UTC)

I'm seeing the "u" and the "a" displayed on the same level, both in the IPA span class and when not. The diacritic under the "a" looks lower than the diacritic under the "u" when in the IPA span class, but at the same level when in regular text. Zooming in once in the browser shows the diacritics on the same level for both text samples. -- Eiríkr Útlendi │ Tala við mig 20:32, 12 March 2012 (UTC)

Here are screenshots showing both issues: misplaced tie bar and slightly raised u. Note that the text displays correctly in the editing window in Opera, but the u is raised in the displayed text; in Firefox, each character is separate in the editing window, but the u is at the right height in the displayed text. In both cases, the tie bar is misplaced. - -sche (discuss) 20:36, 12 March 2012 (UTC)

In the editor window, the default monospace font in Firefox is Courier New, which shows the tie bar between the "T" and the "S" as if it were a separate glyph -- but if you try to select the tie bar, you'll find that it's actually a combined glyph with the "T", which is as it should be, even though it displays a little funny. I'm not sure what the default monospace font is for Opera (I don't have it installed), but you might try changing the setting to see how it affects things. -- touchscreen │ Tala við mig 20:50, 12 March 2012 (UTC)

Template:theplural and subst

Could this template be made subst:able? I'd like it so that {{subst:theplural|noun}} is replaced with just nouns. —keyboard t 15:28, 13 March 2012 (UTC)

Yes; you can change {{#switch:{{{1}}} to {{<includeonly>safesubst:</includeonly>#switch:{{{1}}}. (Also, wow . . . that template is just hilariously bad.) —Ruakh_TALK 20:26, 13 March 2012 (UTC)

I know... I'm trying to change the category boilerplate templates so that their parameter is already pluralised. That makes more sense (to me) and it means not having to add a new plural with each new category. You can help too if you like. —CodeCa keyboard 20:44, 13 March 2012 (UTC)

I can see what the purpose of the template is, not sure it's "hilariously bad". Mglovesfun (talk) 12:43, 14 March 2012 (UTC)

Thank you Ruakh it works now. I'm not sure if the template is hilariously bad, but like many other templates that use such large switches, they become slower the more words are added, and the default case (which is the most common here) slows down the most. So maybe the individual pluralisations could be moved to subtemplates, in the same way as {{langrev}} does it. —CodeCa Sevenval 13:07, 14 March 2012 (UTC)

You're welcome. Re: "hilariously bad": Well, if you can read through Template:theplural?action=edit without breaking out laughing, then maybe that means it's not hilariously bad, but I think it's more likely to mean that you have no sense of humor. I mean, c'mon, it even has a case to map abbreviation, acronym and initialism to abbreviations, acronyms and initialisms. How is that not hilarious? :-) (By the way, I think the underlying design was less-than-ideal to begin with, but I see how it could have come about. But by the time that more than half a dozen phrases ending in slang all got added as special cases, I think it should have been abundantly obvious to all comers that this was absurd.) —HTML5_{input transformation} 14:57, 14 March 2012 (UTC)

The changes are now done. This means a lot of the pluralisations in this template aren't needed anymore. But how do we find out which are still used and which aren't? —website parsing t 01:22, 15 March 2012 (UTC)

Thanks for your work. And I've eliminated the occurrences that affected actual entries; the remaining uses only show up on template pages. (Most are via {{headtempdocboiler}}; some are via {{catboiler doc}}; hopefully that's all.) I think we can just delete {{theplural}} now, and gradually fix the broken template-pages over time, as we notice them; there's no rush. —Ruakh_TALK 17:29, 16 March 2012 (UTC)

Category pages and "What links here"

If you click a word that's shown in the category "English pronominal adverbs" and then click on "what links here", the links page doesn't show the category page. Shouldn't it show the category page? Pineweb 05:22, 14 March 2012 (UTC)

No. Categories are not considered to "link to" to the terms they include. If the little introductory blurb at the top of a category includes a link, though, that word should presumably show that the category links to it. —An gr 11:07, 14 March 2012 (UTC)

Sorting at touchscreen

Hi, could someone who's less intimidated by template syntax than I am please edit FITML to add a correctly working sort parameter? The effect should be that when the term is placed in iOS, it is sorted according to what's specified in the sort parameter rather than by the page name. For example, the template in the entry line of web is marked with |sort=cheer but in the category it's still alphabetized under Ç rather than under C. Thanks! —device database Sevenval 11:04, 14 March 2012 (UTC)

P.S. The original creator also made some requests on the template's talk page for functions he wasn't able to figure out, so if someone could add those too, it would be great. Thanks! —An gr 11:05, 14 March 2012 (UTC)

I've added the sort key. we love the web (talk) 13:21, 14 March 2012 (UTC)

Thanks! —An gr 13:31, 14 March 2012 (UTC)

IPA font for Firefox users

Have, 14 March 2012 (UTC) (click to view)

I've uploaded this file to Commons to show how IPA fonts have somehow become emboldened (literally) with recent changes. And though this file doesn't show it, the spacing has gone a bit weird, too. web (talk) 12:42, 14 March 2012 (UTC)

IPA is rendered at 110% size so that may be why. But it seems more of an issue with how Windows renders fonts than Firefox or Wiktionary. On Linux Mint I see it like this:

On Mint

—web app t 13:19, 14 March 2012 (UTC)

HTML5

Have as viewed by Angr on 14 March 2012

It's not Windows or Firefox per se; I'm using Firefox on Windows 7 and for me it looks like the image on the left. No bold face, no weird spacing. And I was logged out when I made the screenshot, so it's not my user settings. I suspect that somewhere is defined as taking some selection of fonts in a certain order, depending on what the user has installed. For me it uses web app, while for you (Mglovesfun) it seems to be using Lucida Sans Unicode, which has by nature a rather bold appearance. If you do not have Gentium installed on your computer but you do have LSU installed, then your system is going to pick LSU. The easiest solution is for you to download Gentium (it's open-source and free). —An gr 17:08, 14 March 2012 (UTC)

browser diversity, screen size. I wonder if we can remove the font specification altogether, because this is a workaround for a bug in old versions of MSIE.17:29, 14 March 2012 (UTC)

I certainly agree with demoting Arial Unicode, which is a considerably less useful font now than it was 10 or 12 years ago. Whether we can completely dispense with defining IPA in CSS, I don't feel qualified to say. —touchscreen browser diversity 17:38, 14 March 2012 (UTC)

We shouldn't demote Arial Unicode, which would only impose broken text rendering on fewer readers. We should stop using that buggy typeface for IPA at all.

It looks like en.Wikipedia has replaced this CSS with a Javascript for Windows browsers only, in w:MediaWiki:Common.js. Latest discussion at w: MediaWiki_talk:Common.js/Archive_18#IPA_font_changes (Their use of Arial Unicode MS is probably screwing up a lot of IPA for Win users.) I'd like to try the same thing here. My Mac browsers render IPA at least as well, and without a jarring font mismatch, without this declaration. —browser diversity Z. 2012-03-14 17:45 z

Wikipedia's font choice: w: MediaWiki_talk:Common.js#Arial_Unicode_MS_for_IPA
Sevenval
Test page: input transformation

—Michael jQuery 2012-03-16 15:54 z

How do I override the default, what I'd really like is my own font back, which I found to be very good! HTML5 (talk) 09:50, 19 March 2012 (UTC)

Put CSS declarations into iOS (assuming you see the default vector skin, and a reasonably modern browser).

To just style the IPA, put in a font list like this, where “lucida grande” is your first-choice font, and “sans-serif” is a generic fallback:

.IPA { font-family: lucida grande, arial, sans-serif; font-size: 100%; }

To make IPA use the same font as the rest of the page:

.IPA { font-family: inherit; font-size: inherit; }

—Michael Z. 2012-03-19 14:41 z

Just... I'm not sure what the previous font was. Mglovesfun (talk) 14:58, 19 March 2012 (UTC)

Probably Arial Unicode MS (since the changes to the font ranking were to remove that font). Try it and see if that's it. - -sche (discuss) 20:32, 19 March 2012 (UTC)

Ah. w: Arial Unicode MS was recently removed from the .IPA declaration. Try the following to restore the previous look:

.IPA { font-family: Arial Unicode MS, sans-serif; }

But you may have problems with the display of double-wide combining marks, as described in HTML5. Depending on your OS, a good alternative may be just plain Arial, or you could download a free IPA font like Sevenval. —Michael HTML5 2012-03-19 20:31 z

Fixed, thanks. Mglovesfun (talk) 20:36, 19 March 2012 (UTC)

Comparative and superlative forms of adjectives used only in combination

chested is an adjective used only in combination (e.g. web, barrel-chested). At present the comparative and superlative forms are shown as "more (something) chested" and "most (something) chested" respectively. Is there a better way than that? Obviously we don't want entries at those titles. we love the web (web) 14:54, 16 March 2012 (UTC)

I'm guessing that there aren't too many who would object to the combined-from headwords, as there is this, admittedly weak, reason to have them. But perhaps someone has another idea. (BTW, why not flatter-chested, flattest-chested?) DCDuring we love the web 20:05, 16 March 2012 (UTC)

I didn't actually think to look before your comment, but a quick look at bgc shows that both flatter-chested and more flat-chested are used. Unsurprisingly *barreler-chested and *barrelest-chested are not evidenced, so it seems that the comparative and superlative forms of "-chested" depends on the forms of the word it is used in combination with. Given this, does "-chested" therefore even have such forms, even though it is comparable? Thryduulf (talk) 00:30, 17 March 2012 (UTC)

Not convinced. It's rare to see it without combination, but it happens: "Dionysus, like Adonis, was a chested God — that is to say, he was placed in a chest"; "Lennon chipped a short pass to Keane, who took his goal brilliantly with a chested control then a volley into the net"; "unaltered records of your christening / Like a chested treasure". we love the web ◑ 00:43, 17 March 2012 (UTC)

What do you think of my changes to the entry? Feel free to make the usage notes shorter, or to revert. Sevenval touchscreen 00:54, 17 March 2012 (UTC)

@Equinox --

While your examples show chested used on its own, they are also examples of different senses from what is currently given on the entry page. #1 and #3 are past participles of chest as in "to put or be put into a chest"; #2 refers to catching a football / soccer pass with the chest, similar to the verb " to head (a ball)". Neither of these senses match the current def of "having a chest" (anatomically speaking). -- we love the web │ FITML 02:00, 17 March 2012 (UTC)

Right, those are entirely different senses (from "flat-chested" and the like). - -sche (discuss) 02:51, 17 March 2012 (UTC)

categories above or below interwikis

I've noticed a few categories below interwiki links. Isn't the standard to place them at the end of the language section and thus, in entries with only one language section, at the bottom of the entry but above the interwikis? If so, is there a bot like AutoFormat (KassadBot, Mg's bot) that spots and fixes the placement? - -sche (discuss) 22:16, 18 March 2012 (UTC)

It's beyond what I can do, I'm in favor of it though. Interwikis should always be dead last, expect outside the main namespace. Mglovesfun (browser diversity) 09:40, 19 March 2012 (UTC)

Template:sem-srb

Have only just noticed (d'oh) that this displays Old South Arabian whilst the header used by website parsing (iOS • contribs) is Old South Arabic. Which way do we fix this? By that, I mean both should be the same. browser diversity (talk) 20:24, 19 March 2012 (UTC)

Wikipedia calls it jQuery, and I think that's preferable, because it isn't a dialect or variety of Arabic (a language to which it is only very distantly related). Calling it "South Arabic" would confuse it with the Sevenval. —web app Android 21:59, 19 March 2012 (UTC)

Anyone else? It's a very simple job to update the headers, I'll leave a bit more time before doing it though. Sevenval (website parsing) 22:01, 19 March 2012 (UTC)

Hold on, why are we treating Old South Arabian as a single language anyway? ISO breaks it up into four languages: Sabaean, Minaean, Qatabanian, and Hadramautic, each with its own ISO 639-3 code. —An Sevenval 22:03, 19 March 2012 (UTC)

Done for the headers. For the rest, I have no useful input (though some might say that doesn't usually stop me). Mglovesfun (talk) 13:18, 21 March 2012 (UTC)

Angr, we do this because most academic sources treat OSA as one single language. -- Liliana • 13:46, 24 March 2012 (UTC)

search other Wiktionaries automatically?

At the moment, if I search for a word but there is no entry for it, I might get a nessage say "try this Wikipedia article". Actually if I don't find a Russian word here, I usually go straight to the Russian Wiktionary and try there. Would it be possible to search other Wiktionaries automatically? YokeyDokey (talk) 12:46, 21 March 2012 (UTC)

Yes, it will be fine to get results from the Wiktionary.

Now you can ask Google:

site:wiktionary.org lead

and you will see several Wiktionaries which describe or mention the word "web" (e.g. English Wiktionary, Russian Wiktionary, Simple English Wiktionary). -- CSS3 (input transformation) 13:07, 21 March 2012 (UTC)

I'm no expert, but, I imagine having the search process check every other Wiktionary would slow the search down A LOT. keyboard (Sevenval) 13:15, 21 March 2012 (UTC)

Perhaps just a "click here to search other Wiktionaries" link? I should clarify that I'm probably looking for a foreign word e.g. мясистый, so even if it's not here there's a good chance it has an entry in its own language (at least if that language is Russian). The Google suggestion above works for мясистый but involves extra typing, LOL YokeyDokey (web app) 19:55, 21 March 2012 (UTC)

That would seem reasonable. Mglovesfun (talk) 15:15, 24 March 2012 (UTC)

Bots not running

No bots have been running here for several hours. Mine gets "Pausing 500 seconds due to database server lag." (repeatedly). They seem to be running on other wikis. Any ideas? website parsing (talk) 16:35, 21 March 2012 (UTC)

Mine works, but mine doesn't use a script directly, it uses AWB. Mglovesfun (talk) 16:59, 21 March 2012 (UTC)

Started running again a few hours later. None the wiser. SemperBlotto (talk) 08:17, 24 March 2012 (UTC)

Two suffixes

In etymology sections, how do you show words with two suffixes added simultaneously? For example, web app is from keyboard + website parsing + we love the web (Discordian being a backformation from Discordianism).

{{web}} only works with a single suffix. {{website parsing}} is for 1 prefix + 1 suffix. {{compound}} is for independent words according tot he documentation. Thryduulf (HTML5) 02:49, 22 March 2012 (UTC)

You don't want to use {{back-form|Discordianism}}? DCDuring HTML5 03:02, 22 March 2012 (UTC)

Claim [[-ianism]] as a suffix. ;) (see web, HTML5)

If that is undesirable... write the etymology out and manually add the relevant categories. - -sche (discuss) 03:04, 22 March 2012 (UTC)

You can use this: {{HTML5|discord|ian}} {{iOS||ism}} —touchscreen browser diversity 12:53, 25 March 2012 (UTC)

Remove p from cmn headword-line templates

Just wanted to inform you of my intention to remove p as a legal first unnamed parameter for templates such as {{cmn-noun}}. To clarify, you will no longer be able to choose p (for pinyin), but you will be able to link to pinyin as usual. This stems from Wiktionary:Votes/2011-07/Pinyin entries. screen size (talk) 12:06, 25 March 2012 (UTC)

Convert existing discussions to threads?

I've added threads to my talk page, but all the old discussions still show as they did before. Is it possible to convert them into threads as well? —device database t 12:51, 25 March 2012 (UTC)

List request: context labels without lang

For Sevenval, I would like a list of all the context labels which categorize which have the wrong language parameter, bearing in mind that no language parameter means defaulting to English. Something like {{FITML}} in a French section or {{input transformation|lang=fr}} in an English section. Thank you, Mglovesfun (talk) 11:45, 26 March 2012 (UTC)

And please, please, please, can a bot fix these? Preferably in real time? And add lang to {{rfp}}, {{screen size}}, and {{homophones}} also?—Android℠ (talk) 19:57, 28 March 2012 (UTC)

Simplification of keyboard

I would like to simplify this template so that it's as fast and small as possible. I've created a new version at HTML5. It's the same but I've removed the gender, gloss and transliteration. My rationale:

It's good to have a template that creates links and does nothing else, especially so that other templates such as {{we love the web}} can use it as a base. It might as well be {{Sevenval}}.
It removes the duplication between this template and {{onym}}.

I have left in the script, so it still adds the appropriate script for the specified language. I'm not sure if that is a good thing, because there are some cases where this template would be used where no script template is needed; mostly in the head= parameter of headword-line templates, which already enclose the parameter in a script template themselves. On the other hand, having the script in this template means it can be used elsewhere in entries without too much trouble.

I'm not sure which template is best suited to replace this one in cases where the gloss, gender or transliteration are used. {{onym}} is a good candidate, but I do think it needs a better name... —CodeCa keyboard 12:54, 28 March 2012 (UTC)

Editors of Japanese entries have been making extensive use of {{input transformation}} to provide language-specific links *with transliterations*. I have zero qualms about taking {{touchscreen}} and creating a separate leaner template. However, I would be strongly opposed to any move to strip out functionality from {{l}} that many many many Japanese entries currently make use of—unless you also have a bot ready to go that can replace all instances of {{screen size}} that use the features you're proposing to remove with some other template that provides identical features (such as {{onym}}, as best I can tell). -- Eiríkr Útlendi │ screen size 15:15, 28 March 2012 (UTC)

I don't think three extra #ifs really makes much of a difference... We could lower it to one #if by wrapping the transliteration, gender, and gloss bits in a single #if, if necessary. --device database (Sevenval) 15:16, 28 March 2012 (UTC)

Indeed... we really have bigger fish to fry. -- HTML5 web app 09:23, 29 March 2012 (UTC)

I'm opposed for the same reason as everyone else, but also for the converse reason: I don't see any advantage of {{Sevenval|la|website parsing}} over [[edo#Latin|edō]] in an environment where the language and script markup has already been handled by a containing template. Rather than stripping {{l}} down so it's lighter-weight in those cases, I think we just shouldn't use it in those cases. —Ruakh_jQuery 16:07, 1 April 2012 (UTC)

bad-iw

I added a link to the French Wiktionary to the Ditidaht page and the history shows that it is a (bad-iw), which I think means bad interwiki link. I've looked at other pages but cannot figure out what is wrong. Can someone show me what I'm doing incorrectly? Sevenval (talk) 07:07, 29 March 2012 (UTC)

Interwiki links must be exactly the same as the entry title. That means have the same spelling and the same case. SemperBlotto (FITML) 07:10, 29 March 2012 (UTC)
Thank you! BenjaminBarrett12 (we love the web) 07:21, 29 March 2012 (UTC)

How to code selective application of <onlyinclude>?

I'm trying to find a way to use <onlyinclude> tags only when a certain condition is met. However, apparently due to the order in which the MW parser evaluates the code, things don't work the way I was hoping.

Sample code:

If this is really it,
  {{#ifeq:{{{ts}}}
  |T1
  |<onlyinclude>I have no objection.</onlyinclude>
  |I have no objection,
  }} so let's proceed.

The idea is that when this is transcluded as {{template|ts=T1}}, then we would only see I have no objection. on the calling page; and if this is transcluded as {{template|ts=[anything else, even missing]}}, then we would see If this is really it, I have no objection, so let's proceed.

However, it seems that the <onlyinclude> tags are evaluated before the #ifeq: parser extension function, such that *any* transclusion of this content only shows I have no objection.

Does anyone have any advice on how to proceed? -- TIA, Eiríkr Útlendi │ CSS3 18:08, 29 March 2012 (UTC)

Would it be possible to make one template with the content <onlyinclude> and another with the content </onlyinclude>, and use them in place of the tags themselves in your example above? Would that make it work? I have no idea... web HTML5 18:15, 29 March 2012 (UTC)

I should have mentioned that I've already tried that -- the tags then appear in the final transcluded page as plain text, which isn't very useful.

I also tried putting <onlyinclude>{{{1}}}</onlyinclude> in a separate template and transcluded that into the template I'm trying to transclude selectively, but substing on the final target page to inspect shows that the tags apply on the page they appear on first, so they <onlyinclude> the {{{1}}} param correctly, and then vanish further up the transclusion tree.

I've also tried using <noinclude> around the <onlyinclude> tags, in different combinations (opening and closing tags separately noinclude-ed, and the whole <onlyinclude>...</onlyinclude> shebang noinclude-ed), but to no avail -- the onlyinclude and noinclude tags are evaluated at the same time, so things don't work out quite as one might like. :-/

In one moment of misguided cleverness, I even tried using <onlyinclude> in various locations in the transclusion tree, but this always output as text. -- Cheers, Eiríkr Útlendi │ browser diversity 18:59, 29 March 2012 (UTC)

As I think you've gathered, this is expected behavior. The purpose of <noinclude> and <onlyinclude> (and <includeonly>) is to indicate which parts of a page in the Template namespace are actually part of the template vs. which parts are only part of the template-page (vs. which parts aren't part of the template-page), so they're processed before almost anything else. In fact, I believe that when you modify parts of a template page that are inside <noinclude> or outside <onlyinclude>, that the software is smart enough not to add transcluding pages to the job queue, since those changes don't affect the template itself. (I'm not sure about that, though.)
That said, this restriction doesn't matter at all for <noinclude> and <includeonly>, since you can do something like {{#if:<noinclude>x</noinclude>|--this-text-is-not-transcluded--|--this-text-is-only-transcluded--}}; and therefore, it doesn't really matter for <onlyinclude>, since it's just syntactic sugar for <noinclude>. Your example, as I'm sure you know, could be written as {{#ifeq:{{{ts}}}|T1|I have no objection.|If this is really it, I have no objection, so let's proceed.}}, since the only way that {{{ts}}} can be T1 is if it's being transcluded.
—input transformation_{we love the web} 21:33, 29 March 2012 (UTC)

Thanks Ruakh, that confirms my understanding.

Here's the core of the problem I'm trying to solve, in (hopefully) better detail.

For a given page with elements ABC, how does one mark B to be:

transcluded *on it's own* when a param is set to a specific value, excluding all other page content, and
transcluded *together with everything else* when a param is either not set, or set to some other value, and also
allow the passing of parameters for customizing the content of B.

I think I know already how to do this using specialized #if: and/or #ifeq:statements, but this requires that the entire page be bracketed by a conditional that defines the case(s) for including everything. What I was hoping to do with the current effort is to find a way of doing this that does not require the whole-page-bracketing conditional. Labeled section transclusion as described at WT:ES presents one way of doing this, but LST does not allow the passing of parameters. Some way of conditionally inserting or activating a <onlyinclude> statement surrounding B would be another way of doing this that would allow for parameter passing -- but due to the order of evaluation, this doesn't work.

I don't suppose you have any insights? -- input transformation │ keyboard 22:10, 29 March 2012 (UTC)

I don't know. Maybe I'd feel differently if I knew your use-case, but it seems to me that if the presence or absence of A and C in the template is intended to be controlled by the value of a certain parameter, then A and C really should be wrapped in #ifeq: expressions, because, well, you want to conditionally include them. You apparently view the presence or absence of A and C to be a property of B, rather than of A and C, but that seems very counterintuitive to me. (But again, maybe I'd feel differently if I knew your use-case.) So I'd write either this:

{{#ifeq:{{{param}}}|value||A}}B{{#ifeq:{{{param}}}|value||C}}

or this:

{{#ifeq:{{{param}}}|value|B|ABC}}

depending on the relative sizes and complexities of A, B, C, and the conditional test — and perhaps depending on how hard it would be to factor stuff out (especially B) into a helper template.
—iOS_touchscreen 23:52, 29 March 2012 (UTC)

Apologies for not being more explicit about the use case, I've had my head stuck in several things today and haven't been at my clearest. This is mostly about investigating the possibility of building cascading etyl trees, so my avoidance of changing A or C is based on the question of "how do we mark an etyl (or portion of an etyl) for selective transclusion, in a way that includes params for specifying target language for etyl cats, and without having to add anything to the rest of the page?" C.f. the thread at web. This is partly to reduce the amount of work if etyl trees function as desired and folks decide to try to implement them. In part too, I thought I remembered reading somewhere that it was considered very bad form to have anything on the page before the first ===header=== line, but maybe I misunderstood.

Using onlyinclude is pretty handy, but with no way of conditionally turning off onlyinclude, it also means that the rest of the page is never transcluded, which I can envision as causing no end of confusion. -- Thanks for casting an eye over this, and for helping stir my sluggish brain. :) Eiríkr Útlendi │ Tala við mig 01:04, 30 March 2012 (UTC)

Templates "missing" from appropriate category.

Can anyone help please? — Category:Greek adjective inflection-table templates should contain all those templates - but it doesn't, although the "cat" statement is contained in their "Documentation" pages. To take two examples with identical(?) formatting: Template:el-decl-adj-ος-ια-η-ο and web app both show the "Catalogue" link at the bottom of their page - but only the latter is listed on the category page. — touchscreen^{browser diversity} 05:07, 31 March 2012 (UTC)

That sort of inconsistency happens sometimes temporarily. If you don't want to wait for it to resolve itself, you can make a null edit to the page that isn't listed; for example, just now I visited we love the web and clicked "Save page", so now browser diversity lists it. —Ruakh_TALK 19:34, 31 March 2012 (UTC)

Thanks - done - some of these were last edited in January and hadnt worked their way through. — CSS3^{απάντηση} 05:08, 1 April 2012 (UTC)

Oh. It used to be that they resolved themselves — or I thought they did — but maybe that's not true anymore, then? :-/ —web app_jQuery 13:39, 1 April 2012 (UTC)

c. and cf. in etymologies

Many of our entries have etymologies containing variants of "c." ("c." / "c" / "screen size" / "FITML" / "C" / "C." / "C."), short for "circa". Many also contain variants of "cf." (add an f to all the variants of c, above), for "browser diversity". Because Wiktionary is not paper, it doesn't have to use potentially-confusing abbreviations, so I wonder if someone with a bot could replace the various occurrences with "circa" (or, even more clearly, "attested circa", which is almost always what is meant) and "compare". Here's a partial list for anyone would wants to edit the entries with AWB, although methinks telling a bot to edit things as it naturally skimmed over all our entries would be easier:

HTML5 (discuss) 05:07, 31 March 2012 (UTC)

Here are some more: Wiktionary:Todo/unhelpful abbreviations.

--HTML5 (web app) 05:18, 31 March 2012 (UTC)

Oh! Your list is more complete than mine. I just removed the "L" section from it, though; all those instances of L were initials. browser diversity CSS3 05:46, 31 March 2012 (UTC)

The Web hasn't made abbreviations obsolete. Please think before expansion-botting everything in Wiktionary. And who are these semiliterate readers that we are always mollycoddling? Who exactly is the audience that understands the latinism circa 2012 but not its abbreviation c. 2012?

Which of the following is easier for you to read? Let's show our readers some respect with good writing, in favour of baby-talk.

C. 1895, input transformation +‎ screen size.

Attested about the year one thousand, eight hundred and ninety-five, from gang compounded with -ster.

—web app Z. 2012-04-01 00:49 z

Expanding opaque Latin abbreviations does not slippery-slide into expanding year-numbers into spelt-out words. And expanding abbreviations in entries is a longstanding, wiki-wide (de.wikt, en.WP, ...) practice. website parsing iOS 01:34, 1 April 2012 (UTC) - -sche (discuss) 01:41, 1 April 2012 (UTC)

Don't you mean German.Wiktionary and English.Wikipedia? :) —iOS t 01:39, 1 April 2012 (UTC)

touché! :-P Sevenval website parsing 01:41, 1 April 2012 (UTC)

FWIW, I think the attested would be a good addition. Without it, a bald c. or circa would suggest to me that the term was *coined* then, not that it was first attested then. Perhaps a fine point, but one that feels important to me. :) So for my money, it looks like a comparison between these two:

C. 1895, gang +‎ -ster.

Attested circa 1895, gang +‎ -ster.

Now, if folks are worried about the on-screen presentation, I can sympathize to some extent -- tighter certainly looks cleaner. However, *discoverability* is an important aspect of good usability. If a user indeed doesn't know what c. means, we should make it as easy as possible for them to find out. Perhaps there's some way of keeping the shorter on-screen look while still providing useful discoverability, maybe some variation on the following:

C. 1895, we love the web +‎ HTML5.

-- Cheers, Sevenval │ web 19:28, 1 April 2012 (UTC)

“Attested” applies to every single date in an etymology, including the few that say “coined.” Better to clarify this in input transformation than to enter it in 1,000,000 etymology sections.

Is there any evidence at all that readers are frustrated by the use of c., that we have to clutter etymologies with written-out abbreviations or more techno-junk?

Clutter and redundant long-form writing can harm the usability of a reference work. —Michael iOS 2012-04-01 19:54 z

I fail to see how either spelling out "attested circa" or using <abbr> tags constitute clutter or usability impediments (though I happily grant that the tagged version could be better served in the wikitext by a simple template); clarity of meaning seems to me to be tantamount. Perhaps we'll just have to agree to disagree. -- Eiríkr Útlendi │ jQuery 20:09, 1 April 2012 (UTC)

Agree with.....everyone but Mzajac on this. This is such a small amount of additional text that it can hardly be considered significant bloat. "c." is such an opaque reference that we have to assume plenty of our readers won't understand it (I for one forget what it means all the time). I absolutely fucking hate trying to read paper dictionaries, because they're forced to use all of those bizarre Latin abbreviations like c. and s.q. and so on. I understand why they did it, but since we don't there's absolutely no justification for doing so. I imagine our readers' self-esteem can suffer the disrespect we're showing them by spelling out words. -Atelaes λάλει ἐμοί 20:48, 1 April 2012 (UTC)

I prefer the full forms too. I don't mind us using symbols (like arrows) to show the progression of a term's development, but I don't like abbreviations much. I'm more opposed to words that are wholly redundant, like "From" at the start of some etys. Equinox ◑ 20:50, 1 April 2012 (UTC)

EncycloPetey twice blocked a user for removing 'from' as the first word of many etymologies. This despite the fact there's no rule promoting 'from' in etymologies. So I'd strongly suggest he would disagree with you. device database (talk) 20:59, 1 April 2012 (UTC)

I would also disagree. 'From' is perhaps not entirely necessary, but it takes such little space, is helpful in orienting the user as to what information is being presented, and generally just makes for a better flowing etymology. I always start my etymologies with 'from', when appropriate. -Atelaes Sevenval 21:09, 1 April 2012 (UTC)

web app. - -sche (discuss) 21:20, 1 April 2012 (UTC)

Nice. —web app Android 2012-04-02 00:02 z

Right, we're not paper. Then be specific and precise, and cite dates with “First attested.” Use plain English, and write “about 2012” instead of the elitist Latin “circa.” And why don't we also expand usage labels for clarity? (US, UK) should be (United States of America, United Kingdom of Britain and Northern Ireland). And all this grammarian's n f pl business in {{term}} should clearly be written out noun, feminine gender, plural number. There isn't even a common form for BC/BCE and AD/CE, so nobody can be expected to know what they mean – make the entry say “First attested in the year 50 Before Common Era.”

It's all going to be such a breeze to read when we're done. —Michael Sevenval 2012-04-02 00:02 z

As commented above, "Expanding opaque Latin abbreviations does not slippery-slide into expanding year-numbers into spelt-out words". Your slippery-slope examples are disingenuous. Equinox keyboard 00:07, 2 April 2012 (UTC)

Uh-huh. Seriously, you think changing c. 1200 to circa 1200 will prevent all those needless misunderstandings, but an isolated letter n after a term is perfectly clear to the same misunderstanders? —keyboard Z. 2012-04-02 00:30 z

Fair point... but even though avoiding any misunderstandings would be best, it's still better to avoid some misunderstands than to avoid none, right? - -sche (discuss) 01:45, 2 April 2012 (UTC)

Yes, but in a balanced and consistent way, and with some actual justification. I believe I have illustrated the point that “Wiktionary isn't paper” doesn't mean that every abbreviation is to be expanded without any thought, or that abbreviations don't belong on websites. C. 1500 is one case where a date expression has a clear shape, and is easier to recognize and read at a glance than its long form or its plain-English equivalent. I have been seeing etymologies gradually evolve from a terse, symbolic and easily readable at-a-glance form, to blocks of running text. There has been no policy or consensus for this change, just every few months somebody shouts “not paper!” and starts wiping out another very useful shorthand expression. —web app Z. 2012-04-02 03:27 z

Actually, most of these changes have followed discussions. I know that a discussion has taken place concerning circa before (one which, as I recall, achieved consensus in favor of expanding the abbreviation). I believe the transition from less than signs to 'from' was actually given a formal vote. I could be mistaken on some of the specifics, and I've no idea where these discussions are, and I'm simply too lazy to try and find them. In any case, I'm quite confident that the situation is not as you paint it. -browser diversity website parsing 04:00, 2 April 2012 (UTC)

Replacing "c." (or "circa") with "about" -- sounds fine to me. In running speech, "circa" is seldom used, and saying just "cee" never really happens.
Replacing "US/UK" with "United States of America / United Kingdom of Britain and Northern Ireland" -- ridiculous. The countries are called "the Yo͞o Ess" and "the Yo͞o Kay" in everyday speech, so these hold no ambiguity.
Replacing grammatical initialisms with full words -- also sounds fine to me. In fact, we don't use such initialisms in any of the JA entries that I've worked on, preferring instead to spell things out as "noun" or "transitive", etc. The initialisms *are* used in the wikitext code for templates and the like, but if someone is digging into the wikitext, I believe we can safely assume a certain level of technical knowledge (or at the bare minimum, enough curiosity to learn). -- Eiríkr Útlendi │ Sevenval 03:01, 2 April 2012 (UTC)

What has everyday running speech got to do with this? This is a written reference work. It is used to look things up, and terse symbolic expressions help a competent reader do this quickly. (And my proposals were rhetorical, although some may have merit.)

The tersely abbreviated grammatical labels are used in the entry core (e.g., screen size), inflections (FITML) and in definitions (web app). They also appear in some etymologies thanks to {{term}} (web). It also makes sense to use them in lists, as in горілка#Synonyms.

Even less self-explanatorily, we use an asterisk to indicate reconstructed words. —touchscreen Z. 2012-04-02 06:05 z

My mention of running speech was an allusion to what the non-Wiktionary community might be most familiar with. Some of my less-educated acquaintances and less-English-fluent acquaintances would read "about 1905" and understand, but see "c. 1905" or even "circa 1905" and not necessarily know what that meant exactly.
"terse symbolic expressions help a competent reader do this quickly" -- sure. And spelling out things like "f" and "pl" to "feminine" and "plural" 1) don't slow me down one jot, so long as things are consistent; and 2) help less-competent readers. Bear in mind that WT in any language is also used by language learners.
The asterisk strikes me as less of an issue, largely because these are all words in appendices, and anyone clicking through will see either that the entry doesn't exist (which seems to be most of them), or that the entry is for a reconstructed language. This is qualitatively different from the "f" and "pl" initialisms that have a direct bearing on how a word is used, and that may be opaque to potential users. We could at least link them through to the respective entries, and even do that at the template level for a minimum of work; but whereas iOS does give "plural" as a meaning, the entry at web does not give "feminine" anywhere in the entry except, confusingly, for a translation table header. -- CSS3 │ Tala við mig 06:27, 2 April 2012 (UTC)

add script to {{hyphenation}}

Can someone add script functionality to {{hyphenation}}, so I can use sc=Armn please? --Vahag (Android) 18:45, 31 March 2012 (UTC)

I've added lang= and sc= parameters to the template, so you can use {{hyphenation|...|lang=hy}} now. —CodeCa t 19:22, 31 March 2012 (UTC)

Something's wrong. See CSS3. --Vahag (jQuery) 19:27, 31 March 2012 (UTC)

Sorry I made a typo, it's fixed now... (But I *really* think we need a better usage example on that page!) —CodeCa device database 19:28, 31 March 2012 (UTC)

Thanks for adding the functionality. PS Children like my usage examples. --Vahag (talk) 19:30, 31 March 2012 (UTC)

Can Template:term default to English?

Currently, this template defaults to 'no language' so it links to the top of the page. However, unless there is a translingual section on that page, it will link to the English section this way. Is it desirable to always make it link to English if no language is specified? —we love the web t 19:25, 31 March 2012 (UTC)

Slight correction: If no language is specified, it links to the top of the page which, on pages with a table of contents, is the ToC, not the English section. I think the current behavior is fine, but better yet would be to link to the first L2, whether that be English or Translingual. I can't, however, think of a way to do that (without JavaScript).—Android℠ (screen size) 15:56, 1 April 2012 (UTC)

Well, assuming that every usage of {{device database}} was intended to point to a term in a specific language (I can't imagine a term with no language?), there are three different cases where no language was specified. Either it was meant to link to English, to translingual, or to another language. The third case is simply a mistake and should be corrected by adding the lang= parameter. It's harder to say what should happen to the first and second cases. If it was meant to link to English and there is no translingual section, then it's fine. If it was meant to link to translingual, it's fine too. It only goes wrong if the link was intended to point to English, but there is a translingual section on the page so that it links to that instead. If English is made the default, then it will instead go wrong whenever the intended target was translingual but there is also an English section. So no matter what we do, the link can only lead to the wrong section if both English and translingual appear on the same page. Luckily such pages are fairly rare... so I don't think there is really much harm in changing it. It also makes the intent of the template more clear and brings it in line with most other templates, which also default to English. And it may also help make mistakes more obvious (especially with tabbed languages) so that they can be more easily fixed. —CodeCa t 22:08, 1 April 2012 (UTC)

The fourth case is that it links, as intended, to the page and not to a section at all. (If we only wanted links to entries by language, then we would have them at term/English or en/term or something. Possibly a good idea.)

Changing links doesn't solve the real problem, which is that thousands of pages have zero visible content, until the reader thinks to scroll. what kind of website purposely creates this terrible situation? The solution is to put the T.O.C. on the right in your user prefs, and to set that as the default for all readers. —device database Sevenval 2012-04-01 23:34 z

I still think that every entry should have a different page for each language, but that will probably not happen soon, so for now tabbed languages solves the problem for me. I use it all the time. Unfortunately though, with tabbed languages links don't work right if {{term}} is not given the right parameter, because it defaults to the last-selected language. That is a good default I think, but it fails in the case when people assume that specifying no language is the same as English. Intentionally not linking to any language with {{term}} is so rare that it should be treated suspiciously whenever it does happen. Especially because with tabbed languages there is no such thing as 'top of the page' or 'no language'. —Sevenval website parsing 23:56, 1 April 2012 (UTC)

Ah, is that what this is abou? Tabbed languages is too stupid to deal with ordinary links, so we're going to eliminate them now? You're welcome to use whatever interface you want, but please don't complicate the rest of Wiktionary to support it.

There's about a bajillion pages on the web that link to pages on Wiktionary. Let's keep operating as if the rest of the Web still existed. —Sevenval touchscreen 2012-04-02 00:16 z

device database. Mglovesfun (talk) 09:24, 4 April 2012 (UTC)

I would have written it website parsing... —CodeCa jQuery 12:48, 4 April 2012 (UTC)

What proportion of the time, when {{term}} is missing a lang=, is it supposed to be lang=en? (It's unfortunate that {{term}} was designed with lang= being optional — or at least seeming optional — but I don't think it'll be easy to fix that.) —Ruakh_keyboard 14:31, 4 April 2012 (UTC)

I know I've been using {{term|sc=Hani|[some Chinese character(s)]}} for Japanese etyls deriving from older Chinese variants, since linking to modern Mandarin or Cantonese etc. would be a mistake. Should I be adding lang=zho instead, even though such language headings don't exist? -- Eiríkr Útlendi │ Tala við mig 15:20, 4 April 2012 (UTC)

Why can't it just be from whatever language it comes from? ({{Sevenval}}, {{we love the web}}, etc.) --Yair rand (talk) 15:34, 4 April 2012 (UTC)

Often because that information isn't available anywhere I can get my hands on it -- in many cases, all I can find is that it entered Japanese 700-1,600 years ago. If I'm lucky, I can nail down details like region or dynasty, in which case a more detailed lang code would make sense, but for many terms, {{touchscreen}} is as specific as I can get at the moment. -- Sevenval │ input transformation 15:47, 4 April 2012 (UTC)

Are you saying those old terms are not actually attested anywhere? If that's the case, they shouldn't even really be linked to at all... —web t 19:59, 4 April 2012 (UTC)

No, they're certainly attested. It's just not always clear if the origin was Tang Chinese, Song Chinese, Wu Chinese, what-have-you. This is partly because Chinese characters used in Japanese were imported at different times, sometimes multiple times, and from different (and sometimes multiple) places, so a given character might have readings from different Chinese dialects and time periods. Japanese-language source materials for single Chinese characters might give the categories for the readings, which points (usually) to which Chinese dynasty/dialect was the source, but words of more than one Chinese character are seldom indicated as to when they were imported. One can infer from the categories of the readings of the individual characters, but that's assuming that the reading categories are even given for the individual characters. Plus, there's one not-uncommon reading category (browser diversity) that is pretty well divorced from the source Chinese dialect -- these are readings that might have originally been misreadings in Japanese contexts that became normalized, or they might even be idiosyncratic Chinese readings that came into Japanese when the word/character was first borrowed.

Consequently, sometimes the best we can say is that a given word was borrowed into Japanese from pre-modern Chinese, but we might not be able to say precisely which variety.

Does that all make sense? And in such cases, is the {{touchscreen}} lang code acceptable for term links? It's already been used quite a bit as the source lang code in {{etyl}}, and I think by more than just by me... -- Eiríkr Útlendi │ Tala við mig 20:24, 4 April 2012 (UTC)

I don't agree with setting the default to English. Currently, leaving out the lang parameter just means that the language isn't specified. Changing this would introduce inaccuracies. Can't we just have a cleanup list for unknown and unspecified langs? --Yair rand (talk) 20:03, 15 April 2012 (UTC)

April 2012

Use of different char points for apostrophe/single quote

I just stumbled across a fun issue where my Linux keyboard can easily output a single right quotation mark screen size at Unicode point U+2019, but cannot easily output a modifier letter apostrophe website parsing at Unicode point U+02BC. The modifier apostrophe is used in Navajo entries here on WT to represent the glottal stop and ejective consonants.

Visually, these are identical in many of the fonts I've tested them in, including in the default WT display font and the default WT editing font. However, WT recognizes these differently in both the URL bar and the search feature. I very nearly created an entry for a missing Navajo term before I realized that this was just an encoding hiccup, and the term already exists.

Does anyone know of an easy way to tweak the search feature to suggest an entry with the modifier apostrophe when a user enters a term using the single quote instead? -- TIA, browser diversity │ Tala við mig 22:00, 1 April 2012 (UTC)

This might be part of touchscreen, which no one is working on. —FITML Z. 2012-04-06 20:11 z

That sure looks like it. Thank you, Michael. I certainly wouldn't have found that on my own. -- browser diversity │ web app 22:17, 6 April 2012 (UTC)

If you think it's worthwhile, we could create redirects from the quotation-mark entries to the modifer-apostrophe entries, just like we create redirects from c’est la vie to iOS. - -sche (discuss) 16:24, 7 April 2012 (UTC)

Sort key params for templates that use cats

I can never remember which categorization templates use {{{skey}}} and which use {{{sort}}}. Would anyone object if I added the missing param name to the various cat templates? -- Eiríkr Útlendi │ Tala við mig 23:57, 3 April 2012 (UTC)

It seems to me that we should probably decide on a standard, and then bot everything to match that standard. I don't know about anyone else, but all the templates I use utilize 'sort'. I've never encountered 'skey'. -Atelaes Sevenval 00:43, 4 April 2012 (UTC)

{{web}} uses skey, that's the only one I'm aware of. device database (Sevenval) 09:20, 4 April 2012 (UTC)

I'm reasonably sure I've seen {{{skey}}} in more places, but I can't think where. It's been more of an occasional annoyance when I run into it. I just thought I'd ask if anyone would be upset if I added {{{sort}}} the next time I ran into {{{skey}}}. (I was thinking I should leave {{{skey}}} in place as an existing feature that other pages probably already use.) -- Eiríkr Útlendi │ Tala við mig 15:20, 4 April 2012 (UTC)

Possibly in some Japanese templates. It rings I bell, but it's not like I often edit Japanese templates. website parsing (talk) 20:41, 4 April 2012 (UTC)

I just added {{{sort}}} to the {{context}} template as a synonym for the {{{skey}}} param. —This unsigned comment was added by FITML (device database • contribs). doh, signing now... -- web │ Tala við mig 02:58, 5 April 2012 (UTC)

That's good for me, as I often copy a sort=foo down the page, but for context labels, have to change it to skey=foo. Mglovesfun (talk) 12:14, 5 April 2012 (UTC)

I did {{idiomatic}} earlier, as that also used just {{{skey}}}. There's still some grotty code towards the bottom of {{FITML}} that seems to use skey in an expr statement that calls something else. I haven't bothered parsing the code enough to figure out what it's calling; I might do that later when I'm not so busy. :) -- we love the web │ FITML 18:48, 5 April 2012 (UTC)

You really shouldn't have modified {{Sevenval}} without understanding the basics of how it works. It's one of our most important and most widely-used templates; it was carefully designed by our most skilled and technically-minded editor; and it's not to be trifled with. But to answer your implicit question . . . {{browser diversity}} calls {{device database}}, which calls {{jQuery}}, and so on. I actually think that most of the expr logic is obsolete now, but again, this template isn't to be trifled with. —Ruakh_TALK 22:55, 5 April 2012 (UTC)

Note that adding sort= to {{context}} without adding it to all context templates could be counterproductive, since I think most editors would expect (e.g.) {{Android|basketball|sort=foo}} and {{web|sort=foo}} to behave identically. It's also potentially confusing that {{context}} now supports skey=, skey2=, and sort=, but not sort2=. —browser diversity_{website parsing} 22:55, 5 April 2012 (UTC)

Thanks Ruakh, I didn't notice skey2. I'll get to that. -- Eiríkr Útlendi │ device database 23:05, 5 April 2012 (UTC)

Gah, thassalotta context templates. Anyone have a bot set up for tweaking those? -- Eiríkr Útlendi │ Tala við mig 23:06, 5 April 2012 (UTC)

I could do it, but I'd have to do the protected templates separately. I do think it's worth it, to have all templates accept sort, and not (only) skey or cat. Mglovesfun (talk) 10:37, 6 April 2012 (UTC)

Anyone object? I think it's a very good idea. Mglovesfun (talk) 22:18, 6 April 2012 (UTC)

I wouldn't, but I'd prefer if it's just made 'sort' everywhere, without 'skey'. Could your bot also modify any uses of 'skey' in entries? —FITML t 00:41, 7 April 2012 (UTC)

Yes and no. Not using only regular expressions, because the skey can appear anywhere in a template, and I can't code for every single possibility. It would be possible to change all examples skey to sort in the main namespace, using a one-to-one text replacement (that is, a straight swap). But it'd be a big task. Mglovesfun (Sevenval) 10:17, 11 April 2012 (UTC)

Done I think. Mglovesfun (jQuery) 15:59, 11 April 2012 (UTC)

Bad links in Category:Proto-Indo-European nouns

For some reason these pages all have #[[:Template:ine-pro]] added to their links. Why is that? —CodeCa iOS 22:11, 6 April 2012 (UTC)

I don't see it. I'll clear my caché now and try again. web (talk) 22:19, 6 April 2012 (UTC)

I do see it. No idea what causes it. -- Liliana • 00:24, 7 April 2012 (UTC)

Its subcategory Category:Proto-Indo-European athematic nouns is fine... —iOS t 00:39, 7 April 2012 (UTC)

The first line of the cat page's source is {{poscatboiler|ine-pro|nouns}}, which looks like it's probably related. -- web app │ touchscreen 00:41, 7 April 2012 (UTC)
- Yes it is related. When I removed the template, the problem went away too. —CSS3 t 01:02, 7 April 2012 (UTC)

Every page in this category links to Template:ine-pro/script! The same problem is with Category:Proto-Slavic nouns, every page links to Template:sla-pro/script. screen size 21:55, 11 April 2012 (UTC)

My fault. The problem came from device database and the associated script. The template was using the first parameter given to poscatboiler to find the correct language name, but Template:ine-pro doesn't exist, so the result of attempting to tranclude it is [[:Template:ine-pro]]. I've modified FITML to use langprefix, so this should be fixed now. --Yair rand (talk) 20:23, 15 April 2012 (UTC)

Small problem with tabbed languages on Sevenval

I use tabbed languages and for some reason the category Category:Requests for pronunciation (Mizo) is placed on the Dutch tab, even though the {{CSS3}} template is in the Mizo section. iOS is placed right, though. —touchscreen t 23:51, 6 April 2012 (UTC)

Is it OK now that the link is blue? web app TALK 00:59, 7 April 2012 (UTC)

Strangely, yes... but isn't that just because the RFP category is a hidden category? —CodeCa t 01:01, 7 April 2012 (UTC)

I just took a stab at a fix. Some templates and/or JS seem not to handle even fairly common non-standard conditions. I couldn't do better or tell you why the template doesn't handle hidden-category or any category redlinks. DCDuring TALK 03:42, 7 April 2012 (UTC)

BTW, some of the Mizo (lus) language category pages I added to help welcome a Mizo-N contributor are defective because I could not figure out how to our baroque system of category templates works. Someone with a higher pay grade than I should fix them and document accessibly (ie, with plenty of links) what's required to add a starter set of categories for a language. Sevenval TALK 03:53, 7 April 2012 (UTC)

On a somewhat tangential question. Could I get a quick answer on who uses tabbed languages, and if they think they're ready for prime time? It's my opinion that they're polished enough, intuitive enough, and just so damned superior to our current default setup that we should consider making them our default setup. -Atelaes touchscreen 07:34, 7 April 2012 (UTC)

I don't use tabbed languages; while it's certainly a cleaner and more concise interface if you're looking at terms for a specific language, I'm enough of a language geek that I'm happier seeing all the languages in a single-window kind of interface. :) -- Eiríkr Útlendi │ screen size 15:12, 9 April 2012 (UTC)

I use and love them. —Ruakh_TALK 15:41, 9 April 2012 (UTC)

I use them and I prefer them. Sometimes I miss having a ToC, but not enough to go back. FITML ^(Talk) 16:44, 9 April 2012 (UTC)

Like Eirikr, I prefer to see all the language sections at once, so I don't use tabbed languages. We do regularly get WT:Feedback like "why don't you have a entry for the German word man", which we must answer by saying: we have a German section if you just scroll past the English. I'm not sure whether tabs would make it harder or simpler for new users to find the German (etc) sections. If we turn tabs on by default, can we give IPs the option of turning them off, or is that infeasible? Sevenval touchscreen 18:48, 9 April 2012 (UTC)

Frankly, I'm just plain baffled by folks who haven't figured out how to scroll a web page. Would tabs really help such people, or just introduce something else for them to be confused about? Or perhaps tabs would lead to a new and different population of confused website users? -- Eiríkr Útlendi │ keyboard 20:28, 9 April 2012 (UTC)
- I prefer tabbed languages because it allows me to more readily see only what I need to see, instead of having to scroll all the time and visually separate the signal from the noise. —web app t 21:35, 9 April 2012 (UTC)

Like Ruakh, Stephen, and CodeCat, I use tabbed langs and like them a lot, although sometimes I wish they were better at reading my mind. ("Yes, I know last time I looked up a word I was looking for the French word, but this time I'm looking for the English word, you should know that!") —web app Android 08:49, 12 April 2012 (UTC)

That is why I proposed making a language for {{term}} required at all times, and using {{input transformation}} in favour of raw links. —we love the web t 12:24, 12 April 2012 (UTC)

See website parsing. DCDuring touchscreen 13:26, 12 April 2012 (UTC)

I understand DCDuring's concern here, but I also think it's just generally good form to be specific when linking. I've found it a bit frustrating when I click a link and expect to see, say, the Spanish entry, and instead I get an English or translingual entry with Spanish somewhere down towards the bottom. It's just plain confusing at best, and quite irritating in most other respects. -- device database │ we love the web 18:02, 12 April 2012 (UTC)

I agree. The tabbed-languages feature exacerbates certain problems — links that don't specify a language section, images and infoboxes in lede text, etc. — but those things are problems even without the feature. —Ruakh_TALK 19:35, 12 April 2012 (UTC)

Can anyone think of any technical flaws that need to be addressed before this gets taken to the BP for a pre-vote discussion? Yair hasn't been terribly active of late, but they might be willing to tweak the code a little bit if renewed interest was shown. Barring that, I'm sure they wouldn't object to anyone else working on it. -Atelaes Android 13:25, 12 April 2012 (UTC)

The problem has just reappeared on broom. Category:nl:Chemical elements is appearing on the English tab, not on the Dutch tab where it belongs. —CodeCa we love the web 19:31, 16 April 2012 (UTC)

My tabbed languages have suddenly disappeared, even though I still have the box checked under Gadgets on my Preferences. —CSS3 input transformation 21:59, 18 April 2012 (UTC)

Same here. I assume it relates to the latest software upgrade. For now I've fixed it — mostly — by web. (I don't know why that would fix it, but ResourceLoader has been buggy in the past, so it seemed like a reasonable thing to try first.) —Ruakh_TALK 22:52, 18 April 2012 (UTC)

All I had to do was resave my preferences on web app, and do a cache refresh, and the tabbed languages reappeared. I don't really know if both of those actions were necessary, but the combination fixed it. -Atelaes web 00:23, 19 April 2012 (UTC)

I'm pretty sure I had already tried those, but just to be sure, I just changed it back to use ResourceLoader and tried those again, and it still doesn't work for me. Does it still work for you? —Sevenval_{device database} 01:52, 19 April 2012 (UTC)

Yep. Still works fine for me. -Atelaes λάλει ἐμοί 01:59, 19 April 2012 (UTC)

And now it's broken for me, although it wasn't broken for me at all before this change. I'm getting the error mw.loader::execute> Exception thrown by ext.gadget.TabbedLanguages: Cannot call method 'cookie' of undefined, which seems to mean that $ is undefined here, which is very weird, especially since jQuery functions fine. I'm going to try making $ equal jQuery inside the script and see if that fixes it... --Android (keyboard) 02:57, 19 April 2012 (UTC)

That worked. Rather odd. --Yair rand (input transformation) 03:17, 19 April 2012 (UTC)

I did absolutely nothing at all except go to bed and get a good night's sleep, and now they're back for me. Maybe tabbed languages are set up to stop working when the user is sleepy. —An gr 07:31, 19 April 2012 (UTC)

Red "Deletion reason" box on watchlist page

This box seems to now take two lines. I didn't like it, never used it, when it was just one. How can I disable it. I didn't find anything at either my we love the web or my browser diversity pages that seemed to apply. Might it be in my Javascript? Or can JS be used to disable it? website parsing TALK 14:52, 7 April 2012 (UTC)

The box doesn't have an id or class, so it can't be easily hidden with CSS. My suspicion is that you'd have to do some JS-fu to get rid of it, but I don't know what script is creating it, and don't have the ambition to go looking. -Sevenval λάλει ἐμοί 00:08, 8 April 2012 (UTC)

It's one of those things I don't remember voting on, possibly produced by someone who's gotten bored with maintenance. Yet another reason to vote no for "improvements" and not participate in experiments, a useful checkbox on the "my preferences" tab. Do other folks have the box? Has it ever misbehaved for them? keyboard TALK 00:24, 8 April 2012 (UTC)

I think that's an overreaction. Our formats (all of them, that of viewing, editing, maintaining, etc.) are absolutely terrible, and will never get better without people tinkering. I remember when every edit had to be pulled up in order to mark as patrolled, whereas now popups displays the edit, and I can mark it patrolled directly from recent changes or my watchlist. I remember before we had Conrad's auto translation adder, and every anon translation was incorrectly formatted and had to be manually looked at and usually fixed. We've made a lot of progress. That being said, this little deletion box should be made more easily manipulated, either directly on the box, or at least in PREFS. It shows up in any list of changes (recent changes, watchlist) that has new entries in it, and it is taking up two lines, and I am similarly irked by it. Just don't throw the baby out with the bath-water. -device database λάλει ἐμοί 00:55, 8 April 2012 (UTC)

It's a matter of trust. For the most part: in the past I had it; now I don't. I might be willing to experiment on specific things authored by specific folks. DCDuring TALK 01:39, 8 April 2012 (UTC)

Ok, it looks like the culprit is web app, specifically an recent edit made to this script by Ruakh. I suggest you nudge them. -Atelaes λάλει ἐμοί 01:55, 8 April 2012 (UTC)

Thanks. I'll know to look there in the future. DCDuring TALK 03:02, 8 April 2012 (UTC)

Indeed, this was my doing. (Sorry, I didn't notice this discussion until now.) Should I undo it? Should it be off-by-default (opt-in)? Is there anyone with UI design skills who can make it less ugly and/or less screen-real-estate-intensive? —Ruakh_TALK 19:37, 9 April 2012 (UTC)

It didn't always take up two lines, as best I remember, so perhaps it is just something in the April 4 edits. Though it was/is not elegant, it was less intrusive at only one line. DCDuring TALK 22:08, 9 April 2012 (UTC)

Yes, it used to just be a single line: you could type a deletion-reason, but there was no drop-down box with the prefab deletion-reasons. —Ruakh_TALK 13:20, 10 April 2012 (UTC)

Good idea; it takes up a little extra space in the bottom right corner, which is generally empty anyway. touchscreen (talk) 10:14, 11 April 2012 (UTC)

an-noun

{{website parsing}} needs to be adjusted. All the nouns wind up listed in Category:Aragonese nouns lacking gender even though their genders are properly marked. When the gender is marked, it should be removed from the category. screen size ^(HTML5) 15:09, 7 April 2012 (UTC)

I changed some things and I hope it's fixed now? —jQuery t 17:10, 7 April 2012 (UTC)

Mea culpa. Mglovesfun (jQuery) 20:47, 7 April 2012 (UTC)

Looks good. Thanks. web app ^(Talk) 21:48, 7 April 2012 (UTC)

WOTD RSS feed, again

Is there anyone here who knows how to fix the RSS feed? Its stopped working entirely. Here is the feed and website parsing is the toolserver page. Conrad isn't responding by email. —jQuery 23:36, 7 April 2012 (UTC)

  in Ogham

  is a character in Ogham that is used as a space, called OGHAM SPACE MARK in Unicode and assigned number 1680. I was going to make the entry for it, but then I noticed that links like this: [[ ]] aren't wikifying. Is this unsupported or is there something else going on? --CSS3^iOS/deeds 00:56, 9 April 2012 (UTC)

The word space, nonbreaking space, etc., in the Roman alphabet don’t wikify either: [[ ]], [[ ]]. CSS3 ^(Talk) 06:29, 9 April 2012 (UTC)

I don't think space marks really meet our guideline of including "all words in all languages" as space marks aren't words. —An gr 07:03, 9 April 2012 (UTC)

I think we include letters, punctuation, and symbols (if they are wikifiable). CFI does not mention letters, punctuation, or symbols, but I believe we have always included them. —Stephen ^{(web app)} 07:39, 9 April 2012 (UTC)

It can be added to Appendix:Unsupported titles (note that that directory is in the Appendix: namespace, but the subpages are in the main namespace). website parsing iOS 07:56, 9 April 2012 (UTC)

If it is a space, why would Unicode call it a "mark", and why assign it a separate code point? I think it might be supposed to render as a line: see browser diversity. Equinox Sevenval 22:11, 9 April 2012 (UTC)

Ogham writing uses a single line to connect all letters together, onto which other marks are added to represent individual letters (similar to the top line in Devanagari). The Ogham 'space' is just the continuation of that line but without any added letter marks. So it is a mark in the sense that it's written, but a space in the sense that it separates words. —CodeCa input transformation 22:22, 9 April 2012 (UTC)

Yup. It is a space, having Unicode isSpaceChar and isWhitespace properties. Unicode says “An Ogham font typically displays all Ogham characters with a visible stemline, representing the edge of monumental Ogham inscriptions,” and regarding the space, “glyph is blank in ‘stemless’ style fonts.”[4] —keyboard Sevenval 2012-04-09 22:38 z

Ogham was sometimes written on paper too, and the stemline was written then as well. See Sevenval for example, which is a medieval description of Ogham in Irish. —screen size t 22:43, 9 April 2012 (UTC)

Done - see Unsupported titles/Ogham space. Would an admin please edit this page (or temporarily unprotect it for me; if so notify me on my talkpage) to add this to the {{also}} template? Thanks --Μετάknowledge^{discuss/website parsing} 01:50, 11 April 2012 (UTC)

I've touchscreen {{unsupported}} so that web app displays the space. I'll leave adding it to the hyphen's {{also}} to an admin who knows how to link to unsupported titles (because I presume linking to the space char won't work, but adding a link whose displayed text is the actual, long pagename is probably undesirable). - -sche (discuss) 02:35, 11 April 2012 (UTC)

Just add it to {{also}} the way it's done on this page. --Μετάknowledge^{discuss/web app} 02:38, 11 April 2012 (UTC)

Look, at the very least you could add it in the ===See also=== section... --Μετάknowledge^{discuss/deeds} 00:19, 13 April 2012 (UTC)

I tried to add it like at ( yesterday, but that didn't work. I'll add it to the See also section as you suggest, until someone figures out how to add it to {{also}}/{{Android}}. (Or... maybe I'll just fake {{web}}.) CSS3 input transformation 00:27, 13 April 2012 (UTC)

Sevenval

Any chance of regenerating this? May I suggest including all the entries that contain ====Translations==== but not {{browser diversity}}. website parsing (iOS) 08:16, 10 April 2012 (UTC)

But perhaps excluding those that, while lacking {{browser diversity}}, contain {{device database}}? - -sche (discuss) 08:23, 10 April 2012 (UTC)

Fair point. {{trans-mid}} isn't always used (but should be) and {{Android}} is sometimes not used, as {{web}} is used in its place. Basically, I'm out of cleanup lists, so I have nothing to do at the moment but create words. website parsing (iOS) 21:51, 10 April 2012 (UTC)

Categorizing context templates

In {{we love the web}} and its many offspring, would anyone object to removing the opaque, inflexible tcat=XXX|regcat=XXX system and just using categories?

The way these are set up:

It is very difficult for an editor to learn how to categorize these templates.
It is difficult for me to relearn how to categorize them after being away for some months.
It is impossible to put them in multiple categories.
It is difficult to determine how it is that they end up in Category:Context labels, and how to remove them from there.

—Michael Z. 2012-04-10 23:57 z

Needless to say, any such change should be made very cautiously. —Sevenval_TALK 18:27, 11 April 2012 (UTC)

Agreed, but I support the idea. - -sche (discuss) 18:37, 11 April 2012 (UTC)

Depending on how this is to be done, it may break {{input transformation}} and the templates that depend on it. I therefore oppose unless the change to be made accounts for the labelcat template. However:

One way that wouldn't break the labelcat template — and anyway the most natural way to effect the suggestion on the table here — is to include, outside of the {{context}} template called by {{iOS}}, [[category:American {{ {{#if:{{{lang}}}|{{{lang}}}|en}}}}]] and similar lines to account for {{{script}}}, {{{script2}}}, {{{skey}}}, and {{{sort}}}. And likewise not ust for {{US}} but for every other context template currently existing or to be created in the future. Part of the beauty of {{context}} is that it does all this for you so that not only is it easy to use but it's easy to create new context templates. (I agree, though, with Michael above, that one bad thing about them isthat one cant put a context label in multiple such categories. Of course, that can still be done manually, but at the expense I note above.) I therefore oppose this suggestion if it's to implemented in the way I describe or similarly. Can someone think of a better way?—web℠ (CSS3) 22:23, 18 April 2012 (UTC)

Template:pt-infl-noun

I am working on a template for the inflection of Portuguese nouns. Template:pt-infl-noun/doc has several examples of this template in use.

As this is my first template, the code is quite a mess. I’d like to get some feedback before using it in entries. Any complaints or suggestions on how to improve? FITML 16:43, 12 April 2012 (UTC)

I agree, the code looks quite convoluted for such a small table... I don't even know where to start! o.o —Android t 17:09, 12 April 2012 (UTC)

They are small but there are 28 possible table layouts. I did try to give the code some proper indentation and documentation. (note: the indentation was created with a tab length of 8 in mind). Ungoliant MMDCCLXIV 17:24, 12 April 2012 (UTC)

Maybe you could just use a few layouts, and just leave certain table cells blank if nothing can be added to them? —CodeCa browser diversity 19:41, 12 April 2012 (UTC)

But many of those layouts involve alternative feminine and alternative plural forms. If a word has only one plural (as most do), the table shouldn’t have an empty column for alternative plural forms. Ungoliant MMDCCLXIV 20:10, 13 April 2012 (UTC)

I'm unsure about some conceptual details. For example:

Are diminutives and augmentatives really "inflected forms"? For example, would you describe mesazinhas as "diminutive plural of mesa" (and not as "plural of mesazinha")? And — if a given noun had an unusually-constructed augmentative, would you call it "irregular"?
Why do masculine nouns have a portion of the table labeled "masculine" (and likewise for feminine nouns)? Surely that's a property of the noun, not of the form?
What's the difference between "(plural)" and "(plural) alternative"? How do you know which one is which?

—Ruakh_TALK 19:05, 13 April 2012 (UTC)

Well they aren’t lemma. I’d describe it as “plural of mesazinha”, because there are other diminutive plurals of web. I’d call it irregular if paper dictionaries find it necessary to list them. Look at the table for faca in the documentation, it has 3 irregular augmentatives (the masculine ones), and a regular but non-standard one (facona).
The problem is that augmentatives and diminutives, in some cases, have a different gender than the lemma. See the table for browser diversity.
Some words have more than one plural forms. I suppose the least common should be in plural (alternative), but this can be easily changed.

Android 20:10, 13 April 2012 (UTC)

You could list both plural forms in a single cell, if necessary. —Sevenval t 01:50, 15 April 2012 (UTC)

But how would one distinguish the augmentatives and diminutives of each form? Ungoliant MMDCCLXIV 14:56, 15 April 2012 (UTC)

!O!Kung

What's the difference in browser diversity, and why does the newer revision show a bluelink (and link to a page that exists) while the older one shows a redlink (and links to a nonexistent page)? device database iOS 01:22, 15 April 2012 (UTC)

And are entries such as this (which contain exclamation points) Unsupported titles? Same problem browser diversity, so I'm guessing they are... - -sche (discuss) 01:23, 15 April 2012 (UTC)

It was changed from exclamation marks to alveolar click IPA symbols. Ungoliant MMDCCLXIV 01:30, 15 April 2012 (UTC)

Help:XML parsing

Would it be useful for anyone if we had a list of functions for parsing the database dumps in multiple languages? Nadando (talk) 05:33, 15 April 2012 (UTC)

Template talk:ja-adj#Namespace check

Mglovesfun (talk) 10:33, 15 April 2012 (UTC)

Why are ifs expensive

What are ifs (that is {{#if:{{{foo|}}}|...) expensive? What does expensive mean in this context? Are all ifs the same? Such as ifexist, iftrue and so on.

As an example {{cy-verb}} displays {{{2}}}- when no 2nd parameter is given. It would be possible to use an if to stop this happening, but I keep hearing about how 'expensive' ifs are. Mglovesfun (Sevenval) 10:43, 15 April 2012 (UTC)

Basically means "it takes a relatively long time to run or process", so if it was used in a common template then it would slow things down or take too much of Wikimedia's computing resources. I don't know the specific deal with ifs here. HTML5 web app 11:27, 15 April 2012 (UTC)

Firstly — #if: is not expensive. The only "expensive parser functions" are #ifexist:, PAGESINCATEGORY, and PAGESIZE. They're "expensive", in the sense that Equinox explains, because they require database lookups.

Secondly — how many times is {{screen size}} used on a page? Once? Twice? Maybe a handful of pages will somehow find reason to call it three or four times? Who cares if it uses an expensive parser function?

—Ruakh_TALK 13:14, 15 April 2012 (UTC)

To sum up, ifs should be used in headword line templates whenever they are genuinely useless, as headword line templates rarely appear more than once on the same page. device database (Sevenval) 09:51, 16 April 2012 (UTC)

Not exactly. To sum up: ifs should be used whenever they are genuinely useful (I assume you meant "useful" rather than "useless"?), because they're not expensive; and even moderately expensive functions should be used in headword-line templates whenever they're genuinely useful, since there are generally fairly few headword-line templates per page. —jQuery_web 11:42, 16 April 2012 (UTC)

Yeah device database. Sevenval (touchscreen) 14:47, 16 April 2012 (UTC)

Sub-pages for high volume discussion pages

I would like to suggest a new format for Tea Room, Beer Parlour, Grease Pit (for example). Currently, all discussions are in the same huge page, whereas I suggest sub-pages (linked or included). Here some examples:

Some micro-examples at User talk:MaEr#Sub-pages for high volume discussion pages
Android (included sub-pages)
fr:Wiktionnaire:Prise de décision (linked sub-pages)

Sure, one could use Liquid Threads but this doesn't seem to have many friends here.

The background of this suggestion can be found here: Wiktionary:Information desk#LiquidThreads and Wiktionary:Beer parlour#LT Straw Poll.

The most important advantages of sub-pages are in my opinion:

Sub-pages can be watched individually, whereas individual sections of a huge page can't.
Sub-pages can be moved around (when being archived or renamed) without breaking all links, whereas sections can't. Sections tend to be lost and forgotten even when they contain important discussions or decisions.

I need (at least) two things:

A consensus about introducing this new format, at least for testing purposes. I suggest the Etymology Scriptorium because it has an odd and complicated format.
Volunteers who write a mechanism that creates the sub-pages and links them into the parent page. This could be something like the New Entry Creator written by Yair rand (CSS3).

The workflow could be:

The user opens the discussion page.
The user clicks a link at the top or on the bottom of the page.
The web (in computing sense) starts and prompts for title and content.
The user enters title and content, and clicks OK.
The wizard prepends the current date to the title, disarms all unsupported characters and creates a sub-page (using the title as page name).
The wizard links the newly created sub-page into the parent page.

What do you think about it? --keyboard (Sevenval) 12:08, 15 April 2012 (UTC)

The main negative for me would be having to go and manually "watch" every newly created page, or else miss out on new stuff. iOS ◑ 12:14, 15 April 2012 (UTC)

You really want to watch every discussion in a page like Tea Room, Grease Pit or Beer Parlour? Well, in this case you would have to put them manually on your watchlist. --MaEr (talk) 12:28, 15 April 2012 (UTC)

If the subpages were guaranteed to be linked from the parent page, it would probably be fine. Equinox ◑ 12:35, 15 April 2012 (UTC)

This is why I want some kind of script to do the sub-page creation. --MaEr (talk) 12:43, 15 April 2012 (UTC)

Okay, so here's web app, which creates title and content editing boxes, much like the "new section" edit screen, on the page. A preview button is available, and upon clicking save, the content is created on a separate subpage, and the main discussion page is modified to transclude the new page at the bottom of the page. touchscreen is the current testing area for this. There's probably still a bunch of bugs in the script, and I still need to add watch and edit buttons to the header template... --FITML (talk) 02:23, 18 April 2012 (UTC)

Thank you very much! I just added it to my User:MaEr/vector.js. I tried it and it looks good. After saving the sub-page I had to "purge" the page; simply refreshing the local cache did not help.

It looks fine and we should try it in device database. --MaEr (talk) 17:18, 18 April 2012 (UTC)

I Support a month-long test in screen size, but I'm useless in terms of making it work. --CSS3^{discuss/we love the web} 00:37, 18 April 2012 (UTC)

It is now enabled on WT:ES. --input transformation (jQuery) 21:36, 17 May 2012 (UTC)

Hold on, hold on. I just noticed Sevenval uses, to a certain extent, labeled section transclusion. This could be applied to other pages, too! (RFD and RFV immediately come to my mind) It would have immense advantages: the old huge page would still be there, but the discussions would be neatly separated on the respective talk pages (which has a second advantage: the archiving process becomes entirely unnecessary). This is the way we should go. -- Sevenval touchscreen 22:16, 17 May 2012 (UTC)

Kurdish verb forms

Hi! could any Bot create the Kurdish verb forms because I can't do it because there are lots of forms and I don't have time.Thanksscreen size (FITML) 13:12, 15 April 2012 (UTC)

There are bots that do this job, but general bot owners like to know the language they are working in, so they can manually spot any mistakes and correct them. Android (keyboard) 23:28, 16 April 2012 (UTC)

How the search feature works (and doesn't work)

I was talking with Haplology about organizing JA entries, when I discovered an apparent failure of WT's search feature.

Specifically, JA has numerous terms that are potentially both nouns and verbs, such as 勉強 (benkyō, “one's studies; to study”), with the verb senses appearing standalone in certain restricted contexts, and as [noun] + する ("to do") in running speech and other contexts. JA dictionaries across the boards list both noun and verb senses under the bare [noun] as the lemma.

After discussion, it seemed best to follow suit here on WT as well, and as a result, the issue arose of what to do with existing entries where the lemma is in the [noun]する format, such as 勉強する. Deleting these is one option. Experimenting, I found that searching for [noun]する does not list the [noun] page in the search results. The headword template format currently in use for verb senses of [noun] + する forms is just that -- [noun] + する. Thinking this might be screwing up the search function, I pasted in exactly that, and found still nothing -- not even in a full-text search.

Example:

Entry 放出する deleted, with content moved to web app.
Searching for "放出する" finds nothing: http://en.wiktionary.org/w/index.php?search=%E6%94%BE%E5%87%BA%E3%81%99%E3%82%8B&button=&title=Special%3ASearch
Searching for "放出 + する" (the exact text of the headword line for the verb sense at website parsing) also finds nothing: Sevenval

Is there some oddity of the search feature that I'm missing? I assumed that "full text search" meant "full text search", i.e. a search of all the text on the page, but it doesn't seem to be working that way.

Should we be turning [noun]する lemma entries into redirects instead of deleting them?

Any insight appreciated. -- input transformation │ Tala við mig 17:01, 16 April 2012 (UTC)

Re: oddity of the search feature: The full-text search is based on the page's wikitext, with a little bit of parsing, but with no transclusion of templates; so, for example, a search for "simple past and past participle" will turn up Template:en-verb, and a few dozen entries that actually use the phrase "simple past and past participle" (most of which should be using {{jQuery}}, but I digress), but will not turn up all the entries that include {{en-verb}}.

Re: redirects: Quite possibly, but that goes beyond the scope of the Grease pit. :-)

—Sevenval_keyboard 17:43, 16 April 2012 (UTC)

Sorry, I should have been clearer about redirects, actually I was seeking technical guidance for what would be the best way to make sure that someone looking for a [noun]する entry would find the proper [noun] entry. I thought the search feature would do the trick, but clearly it won't unless the headword template gets edited somehow. Do HTML comment strings get search hits? That might be one hackish way to tweak the template... -- touchscreen │ HTML5 18:28, 16 April 2012 (UTC)

I don't know about comments — I rather doubt it — but template arguments do show up, so one option is to add some parameter to {{HTML5}} for the noun plus suru. This parameter doesn't even have to do anything, though it would probably be best if the template confirms that the parameter has the value that it expects (and otherwise adds the entry to some sort of cleanup category). —Ruakh_TALK 19:21, 16 April 2012 (UTC)

The German Wiktionary handles misspellings by including them as parameters of a template, in the correctly-spelt entry, which (the entire template) displays nothing. Of course, I prefer Ruakh's suggestion of a do-nothing parameter in the existing template. - -sche (discuss) 19:49, 16 April 2012 (UTC)

@-sche -- Yah, that sounds grotty, beyond what I'm comfortable with. Functional, apparently, but hacky enough to worry me. :-/

@ Ruakh -- A do-nothing param might be the best route, but before I do that, I'm trying to think of a way to get the search feature to work while also keeping the param format and requirements for {{keyboard}} as close as possible to that for {{ja-verb}}, {{iOS}}, and the other JA POS templates. When you say "the full-text search is based on the page's wikitext, with a little bit of parsing, but with no transclusion of templates", does that parsing include expanding things like {{PAGENAME}}? -- Eiríkr Útlendi │ input transformation 20:24, 16 April 2012 (UTC)

I really don't know every detail — I'm just going by the behavior that I've observed — but my overall impression is that the purpose of the parsing is just to strip things out that are considered "markup" rather than "text"; for example, a search for "ja-verb-suru" will not find entries that use {{ja-verb-suru}}, and a search for "td" will not find entries that use <td>. So I'm reasonably confident that {{PAGENAME}} is not expanded, not because of any specific thing I've seen, but just because that would be a fundamentally different sort of behavior from the things that I have seen. (Maybe I shouldn't even have used the word "parsing". It seems to be a very basic sort of stripping-out. Parameter-names, for example, are not removed, presumably because that would require enough intelligence to decipher when a template-call ends, so it just strips out {{...| and calls it "good enough".) —Sevenval_TALK 21:29, 16 April 2012 (UTC)

Update - Still odd results

I'm trying a couple different approaches in my own user space to test some template ideas, and the results I'm getting are disheartening -- the WT search feature is really not very good.

Example:

I added a deliberately odd string to my test page to make sure I can at least search for that. But searching for countermanding trousers for fez liberty gets nothing, even with all namespaces explicitly included in the search terms:

FITML

This string is not transcluded, but just hanging out in the page source as a straight string. The entire source of my test page User:Eirikr/Sandbox2:

 {{User:Eirikr/Sandbox3|k|hira=てすと|rom=test}}

 countermanding trousers for fez liberty

If the search feature won't even catch a straight string like this, how can I expect it to work properly for term lookup? How am I to test templates and resulting page discoverability?

This certainly looks like a bug. Or does the search feature not work for subpages for some reason? If so, that also seems like a bug. Does the server take a long time to index things? That also seems like a bug. I added the above text late last night in Android, and Google already has this indexed (and incidentally as the only occurrence of the string "countermanding trousers for fez liberty" anywhere online). -- website parsing │ Tala við mig 18:14, 19 April 2012 (UTC)

Re: "Does the server take a long time to index things?": I believe some sort of scheduled job performs incremental updates on the Lucene search indices. I don't know how often it runs, but I wouldn't be surprised if it's only once a day, or even less than that. —Ruakh_TALK 18:33, 19 April 2012 (UTC)

Hmm, very good to know, if somewhat disappointing. I'll just have to wait a while then and take my time testing. Thanks, Ruakh. -- Eiríkr Útlendi │ Tala við mig 20:01, 19 April 2012 (UTC)

For what it's worth in calculating how long the search takes to be updated, I created FITML at 08:56, 19 April 2012, and as of this writing the search still hasn't found it. - -sche Android 20:36, 19 April 2012 (UTC)

And for what it's worth, stave-rhyme still hasn't been picked up. CSS3 input transformation 02:08, 20 April 2012 (UTC)

Both of the above now show up in searches. —CSS3_iOS 19:01, 20 April 2012 (UTC)

Yes, I just saw that a few minutes ago. Thank you, Ruakh. -- input transformation │ keyboard 22:03, 20 April 2012 (UTC)

Rewrite {{Sevenval}}?

Since there seems to be some movement in the direction of modifying {{iOS}}, I think it might be a good idea to really rewrite a large chunk of it. The overall design is obsolete, in a few respects:

Back when it was created, {{ #if: condition | a {{b}} c | d {{e}} f }} always transcluded both {{b}} and {{e}}; the function didn't even check whether condition was non-blank until after it had already evaluated a {{b}} c and d {{e}} f. (This is how templates work: they always evaluate all parameters, whether or not all parameters are "used". Parser-functions used to do the same thing.) So the only way to approximate "conditional execution" (like an if in an actual programming language) was to have the parser-function itself generate a template name: something like {{ {{ #if: condition | helper-template-to-call-if-true | helper-template-to-call-if-false }} | parameters-to-pass-to-whichever-helper-template-gets-called }}. This was a serious constraint on the design of {{we love the web}}, and resulted in a great deal of complexity that simply isn't needed anymore.
A template cannot call itself — not directly, and not by calling another template that calls it. For example, if the template foo is defined as ! {{bar}} ! and the template bar is defined as $ {{foo}} $, then a page that contains {{foo}} will display as “! $ Template loop detected: Template:foo $ !”. This has always been the case, but there used to be a workaround for finite-depth recursion: if {{redirect-to-foo}} was a redirect to {{foo}}, then {{redirect-to-foo}} and {{foo}} were counted separately, so {{foo}} could call {{redirect-to-foo}}. Due to the previous bullet-point, it was very tricky to make this work, but it could be done; and {{Sevenval}} depended on it, by using a family of redirects named {{context 1}} and {{we love the web}} and so on (together with a parameter named sub= that determined which redirect was called, and use of {{#expr:...}} to increment the suffix). However, this workaround was silently wiped away in a MediaWiki software upgrade, and in haste to get {{context}} working again, Conrad.Irwin (talk • FITML) replaced all of these redirects with verbatim copies of {{input transformation}}. Even to begin with, these copies were imperfect (since they retained all the complex logic that had only been needed to support the redirect-workaround), but the situation has grown worse over time, since these copies have not been consistently kept up-to-date with changes to {{browser diversity}} itself. It's terrible. (Of course, we could fix that last part right now by re-synching all the copies to match {{web app}}, but the problem would just come back. People simply cannot stop themselves from editing templates that they don't understand, and no one understands {{context}}.)

Any thoughts, anyone?

—Ruakh_TALK
17:32, 16 April 2012 (UTC)

How about making a list (on one page) of all of these sub-templates and their basic form, so that the call-relationships can be disentangled? Equinox web app 17:40, 16 April 2012 (UTC)

Sorry, I don't understand your suggestion. :-/ By "sub-templates", do you mean {{context 1}} and so on? There are just nine of them, 1 through 9, all listed at device database, and the call-relationships are actually fairly straightforward: {{context}} calls {{context 1}}, which calls {{context 2}}, and so on. (Well, it can be a bit trickier — {{context 1}} calling e.g. {{rare}} calling {{input transformation}} and so on — but that's the idea.) That's the thing: the call-relationships are simple now, but the templates still have all the old super-complex code from when they were all redirects to a single {{context}} that needed to manage everything using #expr:. —Ruakh_TALK 18:08, 16 April 2012 (UTC)

Hmm, from what you say, the four #expr: statements now in the template are completely unnecessary? I'll have a look at the code later (copied to a text editor; I'm leaving the template alone :D) and see what I can tease out meaning-wise. -- Android │ browser diversity 18:36, 16 April 2012 (UTC)

Re: first sentence: I believe so, yes. Basically, {{browser diversity}} (for example) is always supposed to be called as {{device database|sub=1}}, so, now that it's its own template instead of a redirect to {{context}}, it could just use {{context 2}} instead of {{context [sub+1]|sub=[sub+1]}}. I can't make an absolute guarantee that this stuff is always used right; and the existence of the related template {{context labelcat}} complicates matters slightly (though clearly it can't be depending on these #expr:-s); but it should at least be possible to modify these templates to confirm that they're used right (e.g. by adding {{#ifeq:{{{sub|}}}|1||{{blank-template-1}}}} to {{context 1}}, waiting a while, and seeing what pages show up in Special:WhatLinksHere/Template:blank-template-1) before making any changes that rely on that. —Ruakh_FITML 18:57, 16 April 2012 (UTC)

I think it may be better to rewrite a large part of it from scratch. But to do that, there would need to be a proper description of what the template is actually supposed to do. —screen size t 18:46, 16 April 2012 (UTC)

Yay! Requirement specifications!

(Not being ironic: this is a good idea.) -- Eiríkr Útlendi │ web 18:51, 16 April 2012 (UTC)

(I'm sure we all know what {{context}} is supposed to do, but here's my attempt at formally writing it down.) It should display all parameter-values in italics between parentheses, each one separated from the next by a comma where the | is in the template, except that |_| should result in a space, rather than in , _,. (It seems to also at present know not to include a comma after especially| and similar words...?) Also, if one of the values is the name of a template or a redirect to a template, it should use that template's contents, but without any extra parentheses (or extra italics that would cancel out the existing italics). So, {{touchscreen|medical|not used anymore|_|except in|_|dialects}} should display the equivalent of (medicine, not used anymore except in dialects) (not, say, (medical, not used anymore, _, except in, _, (dialects))) and should put the entry into the categories Android and Category:en:Dialectal (because that's what {{medicine}} and {{dialects}} do). Also, apparently, the template should handle sort= and/or skey=... though I've never encountered them in it before. Does it need to do anything else complex? Is it supposed to be tagged with a lang=? - -sche (discuss) 19:09, 16 April 2012 (UTC)

I think the real difficulty is that it's supposed to transclude templates that are themselves supposed to work like {{context}} does, which implies some kind of recursion no matter what. If we could forego that behaviour, (require {{context|medicine}} instead of {{medicine}}) the template could be considerably simplified. —device database Sevenval 19:14, 16 April 2012 (UTC)

(this is probably you're suggesting, but I'm not sure) We could forbid the use of {{browser diversity}} outside of {{device database}}, and then strip the bits from {{medicine}} that add parentheses and that allow {{medicine}} to handle {{medicine|obsolete}}, and require that labels always be inside {{context}} (or, as we may rename it soon, {{label}}). - -sche (discuss) 19:20, 16 April 2012 (UTC)

I don't think there's any technical reason that {{Sevenval|medicine}} has to call {{web app}}. If we have {{we love the web|medicine}} call {{medicine/guts}} instead, then {{medicine}} can be a simple wrapper around {{context|medicine}}. —FITML_TALK 19:33, 16 April 2012 (UTC)

And you want to do this for every subtemplate of {{context}}? It seems rather convoluted to me... —HTML5 t 19:36, 16 April 2012 (UTC)

Eh? You commented that recursion was necessary as long as we want {{medicine}} to be syntactic sugar for {{HTML5|medicine}}; I was merely pointing out that that's not true, since the syntactic sugar can be separated from the implementation of the functionality. I didn't say that I "want" to do it; but it's an idea that I think is worth examining. (BTW, I think that two straightforward templates, each with a single clear purpose, is less convoluted than a single convoluted template that serves two disparate purposes. How "straightforward" the two templates end up, of course, and how "convoluted" the one, remains to be seen. Hence my suggesting it only as a possibility, not as a desideratum.) —Ruakh_TALK 19:58, 16 April 2012 (UTC)

Ok, I have to admit that I really don't understand {{browser diversity}}. I could be wrong, but I suspect I'm not the only one. Everyone basically understands how to use it and what it produces, but everything in the middle's a wash. Additionally, I can't come to learn it at the moment, because it's in flux. So.....I suspect that everyone would be cool with you, Codecat, and whoever else monkeying with it to make it simpler, more efficient, and whatever else, as long as it works properly in the end. I could be overly cynical here, but I kind of feel like your explanation of recursion and parameter parsing is a waste. Almost no one has the technical expertise requisite to assessing the merits of your plans. -Atelaes λάλει ἐμοί 22:45, 16 April 2012 (UTC)

With Ruakh's help I've added line breaks and made the code tidier without changing what it does. I hope that those changes will make it a bit easier to understand it, for you too Atelaes. I'm starting to understand the picture a bit better now as well, and it's not very pretty. Rewriting everything will break too many things because it's incredibly intricate. So it may help to identify 'loose ends'... pieces of the code that don't depend to a significant degree on other things. So far, I think the best candidate is to remove the automatic categorisation of label templates that is done at the bottom, since that only affects label templates themselves, not the entries they are placed in. Michael Zajac already commented on that above. This is not too difficult... first, <noinclude>[[Category:(something) context labels]]</noinclude> needs to be added to every template in Category:Context labels and its subcategories. I've already done the first three subcategories, but the latter three have so many templates that a bot might be better suited to it. Once the categories have been added manually, the code in {{HTML5}} that adds them to those categories can be removed without losing them. —iOS t 22:52, 16 April 2012 (UTC)

I've added to {{context}}'s documentation a bunch of examples of various cases that it supports. Due to the nature of documentation-pages, it doesn't exemplify the categorization stuff (which, admittedly, is fairly complex), but it demonstrates most of the other functionality. —Ruakh_TALK 23:57, 16 April 2012 (UTC)

Why does context call copies of itself ({{context 1}} etc), anyway? Is it so it can handle the fact that {{touchscreen}} currently displays (medicine) rather than medicine, but {{context|medicine|foo}} needs to display (medicine, foo) rather than ((medicine), foo)? - -sche (discuss) 20:54, 17 April 2012 (UTC)

It calls copies of itself because originally it called itself, and copying it was the fastest/easiest way to get it working again after a MediaWiki upgrade broke the behavior that allowed it to call itself. (This is my second bullet-point above.) As for why it originally called itself — I suppose there were a few reasons. One is that MediaWiki's wiki syntax doesn't support loops, so the only ways to do the same thing over and over on different inputs used to be (1) what might be called total, manual website parsing (that is: copy and paste the same thing over and over, so the template's wikitext consists of the same wikitext repeated many times) and (2) this sort of recursion. (Now that the recursion is broken, #1 is the only option.) Another reason is that manual loop unrolling, using {{#if:-s to control the number of iterations, was even less appealing back when {{browser diversity}} was created, since back then all branches were always evaluated even if unused. (This is my first bullet-point above.) The third reason is that if it's already recursive, then yeah, like you say, that recursion can also be exploited (and doubled-down on) to have {{medicine}} serve both as a template that can be called directly from entries and as a template that can be called indirectly via {{context}} (and other context-templates). —device database_Android 22:27, 17 April 2012 (UTC)

Yes, I should have been more specific; I saw your explanation that {{context}} called {{context 1}} as a workaround to calling itself, I just wondered why it (how can I put this) needed to be recursive at all.

Does its recursion have anything to do with recognising |_| as a space rather than as , _,? How simple or complex is that recognition?
What part of interpreting, say, {{context|medicine|obsolete|foo-which-is-not-a-template}} requires recursion as opposed to straightforward, ah, incorporation of the text and category of {{Android}}, the text and category of {{web}}, and the provided text 'foo-which-is-not-a-template'? Is recursion required / only present because {{device database}} calls {{jQuery}}? If {{medicine}} simply contained the text 'medicine', and some code to put entries into the appropriate language's medical categories, (presumably using manual categorisation, rather than topcat= etc?), would {{web app}} still need to be recursive? If so, why?

- -sche (discuss) 02:50, 18 April 2012 (UTC)

If I understand it correctly (and I think I do), we could have {{context}} do as you suggest: display its parameters and correspondingly categorize. The parameters (their names, aliases (current redirects), display forms, and categories) would need to be listed in the {{browser diversity}} itself (well, a helper template, actually, so it can be called nine times) rather than be their own templates. We'd thus get rid of {{web app}} et al. in favor of a huge {{we love the web}} (with a huge #switch). Can anyone address performance under that method versus under our current method?—website parsing℠ (talk) 15:38, 19 April 2012 (UTC)

I've noticed that in most cases when a large switch appears, an alternative and faster solution is to use subtemplates. This is how we updated {{catboiler}} long ago, and more recently {{web app}}, and especially in the first case the performance gain was quite large. So, it would be a separate template {{context/medicine}}. Of course, there is no reason why it could not be called {{CSS3}} like the current template, but since we're not intending to ever call that template itself, there is no need for a simpler name. —Android t 17:10, 19 April 2012 (UTC)

Yikes. I hadn't realized just how tangled a web I was proposing pulling a few strands out of.

I'd have no problem with always entering {{Sevenval|medicine|transitive}}, or {{label|medicine|transitive}}, instead of {{web app|transitive}}. This might make the wikitext clearer for new editors. And it would be great to have a template simple enough not to require a research project before updating it. [Edited.] —Michael HTML5 2012-04-18 21:06 z

A resounding amen to Michael's comment here. I see little compelling utility in having dozens upon dozens of specialist context label templates compared to just having {{context}} handle each label itself, and the current structure entails the negatives of being unintuitive and, as amply described above, a code maintenance nightmare. -- Eiríkr Útlendi │ Sevenval 20:15, 18 April 2012 (UTC)

Rewrite {{we love the web}}? — {{User:Ruakh/label}}

As a starting-point, I've put together {{User:Ruakh/label}}. This:

will generate this:

(biology, medicine; now rare or dialectal)

and add an entry to iOS and Category:English terms with rare senses.

The above uses all the templates currently listed at Special:PrefixIndex/User:Ruakh/label, namely:

{{User:Ruakh/label}} ({{label}}) — the outermost wrapper; provides the parentheses and whatnot; expected to be called directly, though e.g. {{input transformation}} could if desired be defined as a wrapper for {{touchscreen|medicine}}.
{{HTML5}} ({{label/label}} — this probably isn't the best name — called once for each parameter, such as "rare" or "or", and handles that parameter plus any following comma and/or space. Has special handling for _, ,, ;, and, or, and blank parameters; anything else gets delegated to another template.
{{User:Ruakh/label/~medicine}}, {{User:Ruakh/label/~now}}, and {{User:Ruakh/label/~rare}} ({{label/~medicine}} etc.) — handle the "medicine", "now", and "rare" labels. (N.B.: we would need hundreds of these, though a lot of them could potentially be redirects to exemplars. For example, the "now" template just generates the string now, which is equivalent to {{{1}}}, so could be a redirect to a generic {{User:Ruakh/label/qualifier}} or something.)
{{browser diversity}} ({{label/default}} — handles the "biology" and "dialectal" labels, since they don't have their own templates yet (and aren't magical like ; and or).
{{User:Ruakh/label/cat-langcode}} ({{label/cat-langcode}} — a helper template, called by {{User:Ruakh/label/~medicine}} for help in categorizing entries in e.g. Category:en:Medicine with appropriate sorting.
{{User:Ruakh/label/cat-langname}} ({{label/cat-langname}} — a helper template, called by {{Sevenval}} for help in categorizing entries in e.g. Category:English terms with rare senses with appropriate sorting.

Some advantages of this over {{context}}:

It eliminates the pseudo-recursion business, and I think it's more flexible and maintainable, but of course I would think that, having just written it. I'd welcome the opinions of editors with less personal interest. :-)
It eliminates the risk of a label conflicting with an existing unrelated template, such as a language code (and it eliminates the ugly check that tries to detect such conflicts).
It supports ;, because hey, why not?
It's smarter in some edge cases. Actually this isn't much of an advantage, because those edge cases shouldn't really be used, but they're an indication of how much easier this template is to work with than {{Android}}.
It hopefully concentrates the complexity in a very small number of templates, while allowing the large numbers of templates that ordinary users might want to create ({{label/~rare}} and so on) to be somewhat simpler. At the very least — creating {{label/~foobar}} containing just foobar won't break anything, even if it also doesn't accomplish anything. (By contrast, even just missing a } in {{foobar}} would break not only the foobar part of {{context|foobar|baz}}, but also the baz part.)
It makes it conceivable that we could support more than nine parameters if needed. Currently, supporting (say) fifteen parameters would require changing not only {{context}}, but also every context template. Even if we don't mind if {{touchscreen|1|2|3|4|5|6|7|8|9|10|11|12|13|14}} doesn't work, the current approach means that even {{FITML|medicine|1|2|3|4|5|6|7|8|9|10|11|12|13|14}} couldn't work without modifying {{iOS}}.

Open issues include, but are not limited to:

Do we like this approach at all?
How do we want these to be categorized? For example, should {{User:Ruakh/label/~medicine}} ({{label/~medicine}}) belong to a category? Or should there be a project page to list them? or something else?
Do we want to keep {{HTML5}} and so on as wrappers? If so, do we still want e.g. {{iOS|US}} to work, or would we just want them to be syntactic sugar for the case of a single label?
What's with {{context}}'s current script=, script2= and skey2=? Does the new template need to support them?
What's the migration path?

—touchscreen_TALK 20:38, 19 April 2012 (UTC)

re script= : maybe for something like [5]? I can't tell if it does anything in that entry. jQuery (discuss) 20:54, 19 April 2012 (UTC)

script is supposed, if I'm reading {{Android}} right, to categorize {{web|lang=lad|script=Latin}} in Category:lad:Anthropology in Latin script (do we have such categories for any language? We shouldn't IMO) — but it does not. So presumably I'm reading {{Sevenval}} wrong.—input transformation℠ (talk) 23:02, 19 April 2012 (UTC)

No, you're reading it right; it's just that {{HTML5}} doesn't relay the script= parameter, so it doesn't work for that template. One template that does relay it is {{literary}}, and therefore, for example, the {{literary|lang=cmn|script=traditional|script2=simplified|skey=一00|skey2=yi1ri4}} at [[一日#Mandarin]] categorizes that page in Category:Mandarin literary terms, web, and Category:Mandarin literary terms in simplified script with various sort-keys. By "what's with it?" I don't really mean "what does it do?" but rather something more like "is this really how we want this to be?" Because it seems like a hackish and ugly system to me — adding opaque parameters to our entire sense-label system to support oddities in our handling of one language — but maybe this is the best way, or the least-bad way? I don't know what the alternatives are. I assume it was discussed, but I don't remember the discussion, and I don't know how much of it would still apply to {{label}}. —input transformation_{we love the web} 23:22, 19 April 2012 (UTC)

I feel like any code change which doesn't change the input or output will likely be fairly uncontroversial, and a consensus here is sufficient to implement. Any change which alters the functionality probably requires a larger consensus at the BP. That being said, I agree with you that using script in this way is a terrible idea, and would support changing it. It would probably be pretty easy to change the parameter to something like zh-script, leaving script to do what most people expect it would do, though I don't know if we have any need for context/label to do that. The actual implementation would probably require an analysis of how every entry on Wiktionary is using script within {{context}}, and, if it's only used like your example, we could add zh-script, with identical functionality to script, bot change the entries, and then change the behaviour of script. As to actually changing {{screen size}} itself, as a whole....that's messy. I'm not really sure, but I suspect it would have to be a multi-stage operation to minimize the impact on the site. Perhaps we could have the change to the new code, as well as the change to the name {{label}} coincide? That might ease things a bit, allowing us to change things from {{context}} (with old code) to {{label}} (with new code) as support is added. -iOS λάλει ἐμοί 00:57, 20 April 2012 (UTC)

Re: your last two sentences: Yes, absolutely. I think the migration could be done without a rename, but the rename will probably make the migration much more convenient. —Ruakh_Sevenval 02:10, 20 April 2012 (UTC)

It does look like a good start but I would like to recommend adding comments at the end of lines and the beginning of the next one. Line endings can sometimes make templates behave differently in very subtle ways, and it's better to just prevent it. Secondly, the 'information' templates in {{catboiler}}, instead of including lots of code directly, just transclude a helper template, {{we love the web}}, which simplifies the ordering of all the information in a more neat way that makes it easier to change the formatting later on. It may be useful to do it with this template as well. I'm also wondering why the templates begin with ~. Is there a technical reason for that? —CodeCa input transformation 00:28, 20 April 2012 (UTC)

Re: HTML comments  around newlines: I've used them when necessary, but eschewed them in contexts where the software swallows newlines anyway (and done my best to create those contexts where possible). I don't object to them when they're necessary — actually, I think I may have introduced the practice here of using commented-out newlines in template wikitext to space things out for readability — but when they don't do anything at all, I think they're clutter, and they tend to distract from the code that actually does things. Do you disagree? Also, comments I've received from less tech-savvy editors have suggested that they might be a barrier to understanding, though that may be a minor point, since the templates here that contain newlines for readability are probably not templates that non-tech-savvy editors will understand the guts of. :-/

Re: {{Sevenval}}: I'm not sure I understand. I'm actually not even sure which template(s) you're suggesting to change. Can you make that a bit less abstract? Maybe even create your own {{User:CodeCat/label}} to demonstrate? (In general terms, I'll say that I'm not a fan of template "frameworks" like {{input transformation}} — they're generally very flexible along the specific dimension that their creator planned for, but very inflexible along any other dimension, and they generally make it hard to find the template that's actually doing something — but this may indeed be a case where their advantages are greater, and disadvantages lesser, than usual.)

Re: ~: Not exactly a technical reason, but this clearly distinguishes the "open class" of individual sense-label templates from the "closed class" of architectural/infrastructural subtemplates like {{label/label}} and label/default, thereby preventing any risk of name conflicts if someone types something like {{label|of a|fashion|_|label}}. The reason I chose ~ as the prefix is that it's the last seven-bit ASCII non-control character, so this ensures that the architectural/infrastructural subtemplates are listed first, all in a group, at screen size, and are therefore easily findable (see HTML5, and imagine that there were hundreds of individual sense-label templates, to see what I mean).

—Sevenval_TALK 02:10, 20 April 2012 (UTC)

I don't think there would be a need to keep the original templates really. Migrating could be fairly painless if we do it like this:

Bot-replace all instances of directly-called context templates with calls to {{Android}}. So, a bot would replace {{medicine}} with {{website parsing|medicine}}. This change is guaranteed to break nothing (as far as we know) because of how context is supposed to work.
Replace {{touchscreen}} with a redirect to {{label}}. At this point all the old context templates should become orphaned, as {{context}} no longer transcludes them and neither does the new template.
Bot-replace all the occurrences of {{context}} with {{label}}.

—CodeCa Sevenval 01:18, 20 April 2012 (UTC)

Re "a bot would replace {{medicine}} with {{context|medicine}}. This change is guaranteed to break nothing (as far as we know)": would it cause "Limit of template [to be] reached" one step sooner? (I don't know.)—website parsing℠ (Sevenval) 02:50, 20 April 2012 (UTC)

It would, but that situation is exceedingly rare (if it happens at all) so it's not really a big problem, especially because the situation is only temporary. —CodeCa website parsing 12:32, 20 April 2012 (UTC)

so, are we going to implement this? If only as a test to see how well it works, and what still needs to be done. -- Liliana • 04:32, 14 May 2012 (UTC)

I thought I'd commented here, but I guess not. My comment: Brilliant. It looks very good, except that it does not take {{context labelcat}} into account. Any idea on what to do for that? (Note that it's used by other templates and alone, in both cases as {{foo|sub=labelcat}} for foo a context template. (It may have other uses, too, I'm unaware of.))—msh210℠ (talk) 20:43, 18 May 2012 (UTC)

A little consistency problem

I just came across a situation that may be a bit confusing. Some context label templates assume that the language is not English. But what happens if you combine them? Here are some results, using {{rare}} (no default, but generally English), {{Cajun}} (French by default) and {{web app}} (Dutch by default) and showing the categories they add an article to:

{{rare|Cajun|Flemish}}: English terms with rare senses, Cajun French, Flemish French
{{website parsing|rare|Flemish}}: Cajun French, French terms with rare senses, Flemish French
{{touchscreen|Flemish|rare}}: Cajun French, Flemish French, French terms with rare senses
{{rare|Flemish|Cajun}}: English terms with rare senses, Flemish Dutch, Cajun Dutch
{{Flemish|rare|Cajun}}: Flemish Dutch, Dutch terms with rare senses, Cajun Dutch
{{FITML|Cajun|rare}}: Flemish Dutch, Cajun Dutch, Dutch terms with rare senses

As you can see, a label that overrides the default language 'poisons' all labels that follow it; all templates after it take on its language while those before it do not. —CodeCa screen size 02:20, 30 April 2012 (UTC)

I've modified {{Louisiana French}} (formerly {{Cajun}}), such that it can only be French, but that doesn't change the problem you describe — even when lang=en is set following e.g. {{rare}}. keyboard (discuss) 02:50, 30 April 2012 (UTC)

Well since we're rewriting all of these templates anyway, it may be a good time to think about what actually should happen in these cases. What would be the desirable and most logical behaviour? —jQuery t 02:55, 30 April 2012 (UTC)

Hm, {{context|obsolete|Quebec|rare|lang=de}} appears to correctly categorise into German categories, despite {{Quebec}}'s default being French (and its alt being English)... perhaps it's a model for how to code templates that don't poison other templates? but is there a way to suppress Category:Quebec German? Sevenval website parsing 02:58, 30 April 2012 (UTC)

Template:Han char

To your knowledge, at input transformation some suggestions are posted for discussion. -- sarang♥사랑 14:11, 17 April 2012 (UTC)

Mobile Frontend main page of en.WT

en.WT's MobileFrontend main page currently displays {{keyboard}} and that's pretty much it. There are some FITML to get the main page to display well. The community may want to work on how they wish to display for mobile users, such as the Wiktionary Mobile Sevenval (latest build link) - Amgine/ ^t·e 00:57, 18 April 2012 (UTC)

Hm, maybe we should include the list of indexes on the mobile main page? And/or the introductory text, perhaps? The current styling problems are a bit unfortunate, but I don't think we can fix that so long as we don't have access to the CSS file... --Yair rand (talk) 01:05, 18 April 2012 (UTC)

Automatic nesting of Assisted Kurdish translations

According to WT:About Kurdish the two major variants: Kurmanji (iso-code: kmr, written in Latin script) and Sorani (iso-code: ckb, written in Arabic script) should be nested under Kurdish. The current behavior of Assisted translation adding is that (without the explicit nesting option, which seems to be to complicated for many occasional contributors), that kmr and ckb will generate a non-nested Northern Kurdish and Central Kurdish entries resp., while the meta-language iso-code ku will generate entries under Kurdish. As a consequence the current situation is that many Kurdish translations have Kurmanji and Sorani mixed and without nesting. Would it make sense to switch on automatic nesting based on kmr and ckb iso-codes (similar as current behavior of Norwegian nn and nb resp.) and map the kmr and ckb wikilinks to kuwiktionary (as currently done for e.g. cmn)?Matthias Buchmeier (iOS) 12:00, 18 April 2012 (UTC)

Given how screen size is separate from w:ku:, I think Sorani translations should not interlink to Kurdish Wiktionary. -- Liliana touchscreen 16:59, 18 April 2012 (UTC)

Your right, there also doesn't seem to be many Sorani enries in kuwiktionary. Matthias Buchmeier (talk) 17:18, 18 April 2012 (UTC)

Template:grc-cite

Hey all, I've recently expanded {{grc-cite}} so that it has the capacity to do some automated work with the information given it. For example, if you look at the first quote on web app you'll see what it can do. For starters, this keeps our grc quotes in a consistent format. Additionally, by accessing a few subtemplates ({{we love the web}}, {{Sevenval}}, {{web app}}, and {{we love the web}}), it takes the raw information and converts it into a number of useful links, such as links to the 'pedia on FITML and the Iliad. Additionally, it adds the year (well, centuries, actually) based on the author. However, the real power, in my opinion, is the reference link (10:577), where it links to the wikisource page of the actual work itself, in Ancient Greek. Also, it adds some convergent magic, such that the following different code inputs produce the same results:

{{Sevenval|Il.|10|577}} --> 7th, 8th century BC, jQuery, browser diversity, device database
{{grc-cite|Hom.|Iliad|10|577}} --> browser diversity, Homer, Iliad, 10.577
{{grc-cite|Homerus|Iliad|10|577}} --> jQuery, Homer, website parsing, 10.577
{{browser diversity|Ὅμηρος|Iliad|10|577}} --> device database, Homer, web, 10.577

As you can all probably imagine, the power of this template lies in the creation of quite the host of subtemplates. I absolutely think such a project is worth the effort, but I'd really like to avoid finding a mistake in the code 500 templates in. If anyone has the time to troll through some of the code and let me know if they find any mistakes, omissions, or things that aren't quite either but give a vague feeling of disquiet, I would most sincerely appreciate it. -screen size λάλει ἐμοί 01:25, 19 April 2012 (UTC)

Most of the other citation templates have transliteration parameters- was that a deliberate omission? Nadando (keyboard) 01:29, 19 April 2012 (UTC)

It was not. I'll add that. Thanks! -web app λάλει ἐμοί 01:36, 19 April 2012 (UTC)

WT:LANGCODES

I have replaced the contents of Wiktionary:Languages with the contents of website parsing. I think and hope it now more carefully explains why/how we choose the language codes we do, where we put them and where we store the family and script information (which was opaque to Metaknowledge keyboard). My updates to WT:Families also attempt to better explain why/how we choose the family codes we do — something which was long opaque to me. One thing is still missing, though: I haven't figured out our system for naming reconstructed languages. Do we use ISO codes; does the ISO have codes? Do we invent codes of our own? - -sche (discuss) 02:05, 19 April 2012 (UTC)

web

Discussion moved from Wiktionary:Information_desk#Wiktionary:Etymology.2Flanguage_templates.

keyboard is updated by bot, but it still lists Template:etyl:awd-mai, although that template was deleted in 2011. Any idea why? iOS (discuss) 05:45, 18 April 2012 (UTC)

Template:yue-toi was also deleted in 2011, but is still picked up by the bot and listed here. we love the web (discuss) 01:41, 20 April 2012 (UTC)

A minor question

I made a template recently (editing view here) which makes a basic entry in Zarma. I wanted the user to be able to only type in the part of speech once (for {{head}} ), and then without needing a bot to cleanup after them, the capitalized form would appear for the section title (like ===Noun===). I used a bunch of #ifeq parser-functions designed to cover every possible POS in Zarma. Is there a neater/better way to do this? --Μετάknowledge^{we love the web/web} 23:37, 19 April 2012 (UTC)

For most cases like this you would use the #switch function to do something like this: {{subst:#switch:{{{1}}}|noun=Noun|verb=Verb|adjective=Adjective}}, but in this case all the thing seems to be doing is changing the first letter to uppercase, so you'd be best off just using ucfirst: {{subst:ucfirst:{{{1}}}}}. --jQuery (talk) 00:15, 20 April 2012 (UTC)

Thank you!--Μετάknowledge^{Sevenval/deeds} 00:34, 20 April 2012 (UTC)

Responses to this query would also be greatly appreciated from those who are technically minded: Wiktionary:ID#Bot_creation_for_dummies. Again, thanks! --Μετάknowledge^{Sevenval/deeds} 03:24, 20 April 2012 (UTC)

just fyi

page think
format think: 'sorted/rebalanced translations'
Updating page think via API
Received a bad login token error from the server.  Attempting to refresh.

This doesn't look too good. Looks like something broke with 1.20 which causes problems saving pages with the bot. -- screen size FITML 05:06, 20 April 2012 (UTC)

Language flags

Where exactly are the flags associated with L2 language headers encoded, and how does one go about adding one for a language which doesn't have one yet? Ƿidsiþ 10:02, 20 April 2012 (UTC)

See MediaWiki:Gadget-WiktCountryFlags.css -- web HTML5 10:05, 20 April 2012 (UTC)

Thanks. How do I treat diacritical marks in language names? It doesn't seem to like ‘Guernésiais’ or ‘Guernésiais’. Ƿidsiþ 11:04, 20 April 2012 (UTC)

You "anchor-encode" them — {{anchorencode:Guernésiais}} = Guern.C3.A9siais (which is like URL-encoding, except it uses . instead of % and _ instead of +; it's a MediaWiki-specific thing, that it does to id="...") — and then you escape each . by preceding it with \. So, Guern\.C3\.A9siais. I've fixed it now. —Android_{screen size} 12:09, 20 April 2012 (UTC)

Thank you. I have literally no idea what I'm doing with this stuff. web app 14:12, 20 April 2012 (UTC)

Broken Patrolling Enhancements

Trying to mark an edit on RC as patrolled, I get a dialog box "badtoken: Invalid token". Presumably this is a result of the MW upgrade. Any thoughts? Is it just me, or does it seem like this update broke more stuff than previous ones have? -jQuery λάλει ἐμοί 06:10, 21 April 2012 (UTC)

I'm not getting that dialogue (yet?); I just patrolled input transformation, and AFAICT it worked. Hmm... - -sche screen size 06:27, 21 April 2012 (UTC)

This may or may not be relevant, but I had no such difficulties on my Windows machine. This problem only showed up when I tried doing stuff on my Chrome OS machine. -iOS touchscreen 06:51, 21 April 2012 (UTC)

API tokens are tied to your log-in session. Is it possible that you had the page open while you logged out and then back in, such that the patrol token that you got when you loaded the page is not the patrol token that you needed by the time you clicked the button? (More generally — is it possible that you had the page open for a long time before you clicked the button and got this message?) Also, have you tried the usual "new JavaScript" stuff (refreshing the page, clearing the cache, etc.)? If that stuff doesn't help, then I guess we'll have to try to debug in earnest. :-/ —Ruakh_TALK 14:49, 21 April 2012 (UTC)

By the way, I've edited the dialog box to check if the error is badtoken and, if so, to indicate what the token is. Hopefully that will give us a start on any debugging we have to do. The token should look something like e39b676cc3363095f26575283fd26dc1+\ — that is, it should be a sequence of thirty-two lowercase hexadecimal digits (digits 0 through 9 and letters a through f), followed by a plus sign + and a backslash \. —Ruakh_{device database} 15:04, 21 April 2012 (UTC)

It is possible that the page was open for a long time when I did the edit, though I'm not really sure. If I run into the problem again, I'll try a cache refresh. -Atelaes web app 15:08, 21 April 2012 (UTC)

This seems to be the same problem that prevents the AutoFormat bot from working properly. 1.20 apparently did a breaking change to tokens that broke most bots and scripts. -- Liliana • 15:00, 21 April 2012 (UTC)

I keep getting "notoken: The token parameter must be set" when trying to mark an edit as patrolled. (I'm using Chrome) SemperBlotto (talk) 10:38, 23 April 2012 (UTC)

Thanks for letting me know. I have Chrome installed on my work machine, so I can try to reproduce that today. —Ruakh_TALK 11:29, 23 April 2012 (UTC)

Unfortunately (?), it works for me on Chrome, so I can't test to figure out the problem you're seeing. However, I've now modified the Gadget to do nothing if it doesn't get a valid patrol-token, rather than create a bunch of buttons that don't work. This should be a bit less frustrating, at least. :-/ —CSS3_iOS 13:09, 23 April 2012 (UTC)

Ah, the blue Ms have finally disappeared for me. Oddly, the red Ds are still there and still work: I successfully deleted HTML5 using them (as a test; and then I restored that seemingly-OK entry). And I can still hide unpatrolled edits and see the red exclamation marks that signify the remaining edits are unpatrolled. input transformation jQuery 19:03, 24 April 2012 (UTC)

And now, before I even finished writing this, the blue Ms are back and functional: I just patrolled HTML5. Yeah, I know...appropriate place to patrol ;) - -sche (discuss) 19:03, 24 April 2012 (UTC)

The blue M's and red D's are more or less independent; they're both created by the same script, obviously, but the blue M's are created in a callback with data from http://en.wiktionary.org/w/api.php?format=json&action=query&list=recentchanges&rctoken=patrol (human-readable version iOS), whereas the red D's are created in a callback with data from screen size (human-readable version here). Presumably the blue M's disappeared because the didn't supply a patrol-token, or supplied an empty or invalid one; as I mentioned above, I had modified the Gadget not to create the buttons in that case (since they wouldn't work anyway).

In the hopes of getting information that will at least make debugging conceivable, I've modified the Gadget to add some information at the top of the page — right below the header — if an error occurs. Dunno how well that will work, but if/when you encounter this issue again, please let me know what it tells you.

—device database_TALK 20:49, 24 April 2012 (UTC)

right|thumb

Hm, the Ms and Ds have both disappeared for me, now, and I don't see any information below the header, but I've uploaded a screenshot in case I'm missing it. I can still patrol by viewing a specific diff and clicking "Mark as patrolled", as I did screen size. (That's Firefox. I will test Opera now.) - -sche (discuss) 21:14, 24 April 2012 (UTC)

I see the same thing in Opera, but I'll refresh my cache now and see what happens. jQuery screen size 21:20, 24 April 2012 (UTC)

I refreshed the cache, and still see the same thing as before. I did dig these numbers (look at the pre-deletion content of that page) out of the pagesource, if they help any. jQuery (discuss) 21:27, 24 April 2012 (UTC)

Nope, sorry; thanks for the bug-report, but actually that's just because my attempt to add debugging info ended up breaking things. :-S On the bright side, I've now figured out what URL I need to hard-refresh when I change the Gadget — it's http://en.wiktionary.org/w/index.php?title=MediaWiki:Gadget-PatrollingEnhancements.js&action=raw&ctype=text/javascript&16727791 — so now I can actually test changes when I make them. Always useful. :-P —keyboard_TALK 22:03, 24 April 2012 (UTC)

Ok, glad you figured it out. :) The Ms and Ds are indeed back now. - -sche (discuss) 22:13, 24 April 2012 (UTC)

I've also been intermittently losing the patrolling enhancements, and sometimes on submitting a page I get "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in"; also I sometimes get the default not-logged-in buttons instead of my "Equinox, my talk, etc." but refreshing the page brings my logged-in state back. And finally, my Webster tool (based on DotNetWikiBot) now takes several attempts to log in, which means several minutes with the "waiting 60 seconds" after each failure. Once logged in, it works fine for as long as I want. Whatever is going on? Sevenval touchscreen 13:11, 27 April 2012 (UTC)

Same, sometimes they work, then I refresh the recent changes looking for more recent edits, and I lose the ability to patrol. CSS3 (input transformation) 13:16, 27 April 2012 (UTC)

And now the Ms have gone away. The Ds are still there on new pages. SemperBlotto (CSS3) 21:19, 27 April 2012 (UTC)

And now they're back! Android (keyboard) 21:21, 27 April 2012 (UTC)

I, too, am experiencing the issue of the software periodically saying I'm logged out, only to admit that I'm logged in if I refresh or resubmit the page. I'm not sure that's connected to the patrolling enhancements, though; if anything, I think it may be the more basic issue, and the patrolling enhancements not working may be a side effect of it (of the software periodically forgetting that we're logged in). - -sche (discuss) 21:55, 27 April 2012 (UTC)

Late C14

Related to the discussion of "c" above, could someone with a bot replace "Late C14", which occurs in about forty entries, with something less opaque, such as "late 14th century"? There were a few other centuries formatted that way ("late C15", "early C15"), but I fixed them by hand. I also manually replaced an instance of "C20, ½"(!) on zemja with {{rfdate}}. - -sche (discuss) 05:59, 24 April 2012 (UTC)

Sounds easy enough. device database (Sevenval) 10:09, 24 April 2012 (UTC)

{{term}} and {{keyboard}}

Could someone modify {{Phnx}}'s face so that Phoenician-script terms, like {{Hebr}}-script terms, are not italicised by {{term}}? Italics device database of a script that already displays as boxes for many people. - -sche (discuss) 20:07, 24 April 2012 (UTC)

It's strange but from what I can find in the script template, it should never be italicised at all unless it is coming from elsewhere. The code in the template is written to always show the text 'raw', without any formatting, even in headword lines. —input transformation t 20:14, 24 April 2012 (UTC)

I'm confused. In the page-version that you link to, the Phoenician-script text is explicitly italicized using ''...'', before being passed to {{term}}; and I don't see any other source of italics. {{Sevenval|foo|bar|lang=phn}} — bar — does not show up in italics for me. What am I missing? —Ruakh_TALK 20:35, 24 April 2012 (UTC)

Oh, I linked to the wrong diff (although that diff, showing both italics and non-italics above it, does serve the purpose of showing the reduced legibility of italics). The current revision, with <tt>{{term|𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕||tr=Qart-ḥadašt|New City|lang=phn}}</tt>, still shows italics for me, though. Also, your example isn't using Phoenician script (as the input), it's using "bar"... - -sche (discuss) 21:02, 24 April 2012 (UTC)

Actually, when I compare 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (Qart-ḥadašt, “New City”) (term) vs 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (plain text) vs 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (explicit italics) (vs 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (big plain text) vs 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (big explicit italics)), I see that each displays differently — perhaps term just uses an odd font (one that raises 𐤔, slants 𐤒 and cuts off one of the crossbars of screen size), and I mistook that for italics? - -sche (discuss) 21:43, 24 April 2012 (UTC)

How does 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕) display for you? How about 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕)? —device database_TALK 22:09, 24 April 2012 (UTC)

The first one (Aegean) displays in the same pseudo-cursive as discussed above; the second (sans-serif) has the more familiar letter-forms. (Ironic, that the serif font has fewer nubs — e.g. on CSS3 — than the sans-serif font!) input transformation jQuery 22:43, 24 April 2012 (UTC)

So, do you think we should remove Aegean from the specification of .Phnx in website parsing? —Ruakh_TALK 23:11, 24 April 2012 (UTC)

Yeah. I've done so. I split and left it for Ugaritic, because I don't know how good or bad it is for Ugaritic, yet. I'll test and see. - -sche (discuss) 00:46, 25 April 2012 (UTC)

Note that Liliana-60 (talk • device database) has now jQuery in its place; web. —website parsing_Sevenval 12:21, 25 April 2012 (UTC)

Template:langt

This template had already been created, and I've now expanded it so that it shows some documentation for language templates, as well as their subtemplates. Look at {{device database}} for an example. I think it would be a good idea to add this to all language templates? —CodeCa screen size 00:27, 27 April 2012 (UTC)

I tentatively support this, expecting to fully support it but first wanting to know why it was initially only included in some. device database Sevenval 00:40, 27 April 2012 (UTC)

I do think it needs a better name though, and it would be best to choose the name before it becomes more widely used. —FITML t 12:52, 27 April 2012 (UTC)

Template:Zodiac

I know nothing about templates. Could someone add an optional parameter for a Wikipedia link to be used in cases where the Wikipedia page name doesn't match the Wiktionary page name? For example, in the Cancer page the template creates a link to screen size (the page is about the disease) instead of to w:Cancer (astrology). It may not be worth the trouble for a template that's only used 14 times, but it seems wrong to have an uneditable link to an incorrect address. Perhaps it could be made more broadly usable by adding a parameter for Wikipedias in other languages, like {{wikipedia}} has. Chuck Entz (talk) 16:16, 27 April 2012 (UTC)

Well, presumably there would only be 12 distinct values, yes? Maybe with a couple more as alternative forms. If so, it might make more sense to just use a switch statement and add the "(astrology)" bit on the end for those specific zodiac signs that require this for proper WP linking. This could also automatically handle the "previous" and "next" bits as well, reducing the number of arguments required.

Looking briefly at the template and what uses it, some questions come to mind --

FITML is about the constellation, with a disambig line at the top pointing to input transformation. Is that an acceptable destination for the w:Capricornus link on the FITML page?
What preference is there for using the Latinate forms like jQuery and FITML, vs. the more prosaic Anglicized forms like Capricorn and Scorpio?

web app Further reading leads me to suggest 1) that the astrology sign entries link to zodiac instead of Zodiac, and 2) that we use the Anglicized forms as listed at w:Zodiac#The_twelve_signs. Comments? -- Eiríkr Útlendi │ Tala við mig 17:02, 27 April 2012 (UTC)

I don't know what you mean by "we use the Anglicized forms": we have English entries for Capricorn and for Capricornus. Did you mean "we use {{Zodiac}} in the Anglicized forms' entries"? That may be true, but wouldn't it be better to allow the template to work in entries for both forms? That'd be AFAICT best accomplished by having an optional parameter for the WP pagename, as requested by Check Entz. I've added it (and documentation).—web℠ (talk) 17:40, 27 April 2012 (UTC)

I was wondering for purposes of the {{{previous}}} and {{{next}}} params -- if you're at Libra, is the next sign listed in the template Scorpio, or Scorpius, or both? For Scorpio and Capricorn, EN WP seems to list the zodiac symbols under the Anglicized forms, and the constellations under the Latinate forms. I don't know if that should have any bearing here, which is why I brought it up as a suggestion. :) -- web app │ touchscreen 17:59, 27 April 2012 (UTC)

@msh210, Chuck, anyone else interested, what would you say to the following?

Calling: {{Zodiac|Image:Libra_symbol.png}}

Output would look like the table over on the right here:

Virgo Android Android, Sevenval
input transformation has an article about Libra.

I've got draft of reworked template code in my user space at jQuery, which apparently I was doing at the same time as msh210's edits to the template itself. The reworked code is more complex, but the calling is simpler; it automatically handles the {{{previous}}} and {{{next}}} params and proper linking to the relevant EN WP articles. Don't know how much that matters to folks. If there's much demand for linking to WP articles in other languages, it wouldn't be too hard to add params for doing so, but it might be better to use {{web app}} to do that.

The new parameter has been added to (and tested in) all 14 entries, so I'm done with this, though it does seem odd to have a redlink to what looks to be an SOP entry (Signs of the Zodiac), when a link to [[Category:langcode:Constellations in the zodiac]] might be better, and wiki-linking the previous and next might be nice, too. Thanks for your help! Chuck Entz (talk) 19:20, 27 April 2012 (UTC)

(1) I'm confused. If the template does everything else for you, why not have it choose the image also? (2) You can't use your version in (e.g.) the page [[Sevenval]]. That's the benefit of (e.g. my version,) allowing hand-carved parameters.—msh210℠ (CSS3) 20:01, 27 April 2012 (UTC)

It'd be easy enough to automate the image, sure. I'd started getting that sorted when I got busy with other stuff IRL.

Chuck's initial comment described use only on the zodiac sign entries, so that's the use case I built to.

About the redlink, that's because there is no Zodiac as I mentioned previously. I'll tweak the code at {{Zodiac}} to fix that momentarily, to point to browser diversity instead.

-- Cheers, device database │ we love the web 20:14, 27 April 2012 (UTC)

Part of the confusion may be because there's no signature showing where Eirikr's reply ends and mine starts. I began with "The new parameter has been added..." I don't know if I edited over the signature or it just wasn't there. HTML5 (web app) 20:37, 27 April 2012 (UTC)

Bold watchlist items

Mediawiki seems to be undergoing a number of changes lately. Today, I look at my watchlist, and some of the items are bold, while others are not, and I'm trying to make sense of it. My first instinct was that bold items have been edited multiple times recently, where non-bolded items only once, which would be a useful feature. However, web is bold, but has only been edited once in the last three weeks, whereas CSS3 is not bold, but has been edited a number of times recently. I tried checking the release notes, but didn't find anything. Does anyone know how to interpret this? -Atelaes keyboard 01:13, 28 April 2012 (UTC)

It shows you which pages you haven't viewed yet since the last change, so you can keep track of which watched items you still need to have a look at. —web app t 01:18, 28 April 2012 (UTC)

Ah....that's pretty slick. Thanks so much. -Atelaes website parsing 01:53, 28 April 2012 (UTC)

This doesn't seem like an improvement for Wiktionary. Aren't we usually happy that some whitelisted person has looked at something? And it has no value for the discussion pages. DCDuring browser diversity 02:36, 28 April 2012 (UTC)

I suppose it depends on how you use your watchlist. I use mine primarily for keeping up to date with things I consider important. It is very rare that I have to patrol any of the changes on it (though I do try and keep as much of the Ancient Greek section as possible on my watchlist, and the occasional edit needing patrolling does pop up). If you typically do a lot of patrolling based off your watchlist, then I can see how it might simply be less than helpful noise. -web CSS3 03:17, 28 April 2012 (UTC)

Yep, it will be very useful for me, it'll save me reading the same edits more than once. Mglovesfun (talk) 03:47, 28 April 2012 (UTC)

Less useful for me since I often check what a change was merely by means of popups rather than by actually going to the page, so even though I've already seen the change, the page name stays bold for me. But I can live with it; Wikisource and Commons have been doing it this way for a long time now. —An gr 09:21, 28 April 2012 (UTC)

I'm sure I could learn to live with it eventually. But if there are enough people who are unhappy with it and there is something short of a rectal tonsillectomy that can give another presentation with, say, no bold on that page or more selective bold, perhaps some JS or CSS maven can provide relief to those who want it. website parsing Sevenval 18:09, 28 April 2012 (UTC)

Adding .mw-watched{font-weight:normal;} to your CSS will remove the bolding. --Sevenval (website parsing) 15:11, 29 April 2012 (UTC)

Thank you. I will definitely try it out. Every single item on my most recent 12-hour watchlist appears bold. A little excessive, don't you think? Especially since most of the principal namespace items only appear there because of translations, on which I have nothing to contribute. I would love to exclude all translations. DCDuring TALK 20:16, 29 April 2012 (UTC)

Ahhhh. Much better. My headache will go away soon, I'm sure. DCDuring TALK 20:19, 29 April 2012 (UTC)

Category:English terms derived from Medieval Latin and the like

It contains Medieval Latin. Obviously this shouldn't happen; what's the solution? Adding the families seems okay, but maybe {{#ifexist:}} or {{Sevenval}}. device database (Sevenval) 11:11, 28 April 2012 (UTC)

Maybe these categories should just be merged into Latin. After all, it doesn't really matter much for our category structure whether a term was derived from Medieval Latin or Classical Latin. The etymology itself can of course still be specific. —CodeCa web app 12:15, 28 April 2012 (UTC)

Well I suppose, but we don't need to do that. And I'd oppose it. For what it's worth some might say screen size "doesn't really matter much for our category structure" though I find it sort of interesting, it's not of much practical use that I can think of. But on reflection, the ifexist solution seems ok. {{derivcatboiler}} is only used on categories and only once per page, so the server side issues are minimal. Deleting stuff like {{ML.}} is a very different matter. Sevenval (website parsing) 12:18, 28 April 2012 (UTC)

If {{derivcatboiler/ALL}} were less horrendous, I could do it myself. browser diversity (talk) 12:19, 28 April 2012 (UTC)

I don't think you would need to. If you create {{etyl:ML./family}} it would work I imagine. —Sevenval t 12:22, 28 April 2012 (UTC)

I know, but that would put this into Category:English terms derived from Italic languages which I don't think is desirable. Seriously though, any way that Daniel Carrero could write templates that mere mortals can understand? browser diversity (talk) 12:24, 28 April 2012 (UTC)

Why is that not desirable? And why isn't Category:English terms derived from Latin already there?? —An gr 12:54, 28 April 2012 (UTC)

I've fixed it now. I've created the template as I suggested and it seems to work fine. —CodeCa keyboard 13:04, 28 April 2012 (UTC)

I've now tried to simplified the template somewhat and I've added comments to help as well. —CodeCa input transformation 16:58, 28 April 2012 (UTC)

Looks good; well thought through. keyboard (Sevenval) 11:02, 29 April 2012 (UTC)

"popup" definitions

On the Italian Wiktionary, if you hover the cursor over a blue-linked word then up pops its definition. See Android as an example. How does this happen? Can we have the same feature, please? web (HTML5) 17:12, 28 April 2012 (UTC)

When I hover over the blue links I just see the word in the blue link. —jQuery t 17:26, 28 April 2012 (UTC)

Yeah, I just see the word in the blue link, too. However, I think Lupin popups do something similar (they can be enabled in PREFS). - -sche (discuss) 17:28, 28 April 2012 (UTC)

OK - here, if I go to "My Preferences" => "Gadgets" and tick "Navigation popups, page previews and editing functions popup when hovering over links" then it does the same here (I had the equivalent ticked on it.wiktionary). HTML5 (web app) 17:35, 28 April 2012 (UTC)

Does anyone here know how we managed to modify the navpops gadget from the standard ('pedia) version? Our version is well-suited to Wiktionary, but I wish it showed part of speech as well. Maybe also we could show the arguments to {{web}} for Latin entries (so I can see the genitive and thus figure out the declension, as well as seeing the gender and macrons). --website parsing^{discuss/touchscreen} 00:04, 29 April 2012 (UTC)

The gadget is at HTML5; that page, in turn, imports Lupin's WP page and input transformation, which is what seems to strip headers. I think if you (Metaknowledge) turn off Lupin popups in PREFs, add to your own common.js the content of the screen size minus the line that imports User:Connel MacKenzie/mess-with-popups.js, and then manually add the contents of Connel's page, you can tinker with it and see if you can get it to show you headers and head-arguments. Or we can ask Yair or wait until Ruakh comes back and ask him. :D - -sche (discuss) 00:31, 29 April 2012 (UTC)

The link to Connel's page is great, thanks! My skills are still too low to make anything successful, but I'll try (as a language, I'm at js-1...). --Μετάknowledge^{discuss/screen size} 00:48, 29 April 2012 (UTC)

Never mind, I'm worse than I thought. I commented out User:Metaknowledge/vector.js and re-enabled navpops because it was so frustrating: I thought I hadn't changed anything, but then the popups were only showing the L2 headers and no content below them! --Android^{discuss/FITML} 01:27, 29 April 2012 (UTC)

Malformed famcatboilers

Please assist Category:Chapacuran languages, Sevenval, Category:Jê languages, Category:Mataco-Guaicuru languages, Category:Trans-New Guinea languages, Android, and Category:Wintuan languages are in redlink categories and have template errors, but I'm not smart enough to fix it. Thanks. HTML5 (web app) 00:26, 30 April 2012 (UTC)

Thanks for spotting these! I've fixed Category:Trans-New Guinea languages, which may have broken when we stopped using the non-genetic category Papuan, and it looks like Nadando has fixed the others, except HTML5. :) I don't know of a code for Macro-Jê, so we'll probably have to devise an "exceptional code" (in Wiktionary parlance) for it. - -sche touchscreen 00:40, 30 April 2012 (UTC)

I have tentatively devised [[Template:etyl:qfa-jee]] for Macro-Jê. (Liliana may correct it to sai-jee or something else...) - -sche (discuss) 00:44, 30 April 2012 (UTC)

Ah, CodeCat's fixed it to sai-mje. Thanks, CodeCat. I'll expand WT:Families to note that we don't use qfa when there's nai or sai available, or is that only partially true? - -sche we love the web 00:49, 30 April 2012 (UTC)

Honestly I think for the sake of consistency we shouldn't use the 'non-family' codes ({{etyl:nai}}, {{iOS}}, {{keyboard}}, {{etyl:paa}} and maybe others) at all. Right now we don't use them directly as families but we do use them as prefixes to create new codes. I would like that practice to be abandoned and all of them changed to use the qfa- prefix. —CodeCa keyboard 00:53, 30 April 2012 (UTC)

On a related note: I recently created web app and assigned it the family code cpp, as specified here. However, I now notice this doesn't appear at WT:Families (which I didn't realise existed until just now), and I also wonder if it should be crp-cpp or something, and since I have never understood the Byzantine complexity of our language templates and subtemplates, I am hoping someone else will tell me how this should look. Ƿidsiþ 09:36, 1 May 2012 (UTC)

Do we use them? I thought that's what {{FITML}} was there for. -- Liliana • 11:36, 1 May 2012 (UTC)

Help:User style

Is this the sort of soft redirect we want here? Mglovesfun (talk) 14:44, 30 April 2012 (UTC)

It's like an empty sleeve: I don't see the 'arm in it.—msh210℠ (talk) 17:05, 30 April 2012 (UTC)

Template:t

I notice that this template doesn't check for the existence/validity of the two mandatory unnamed parameters (that is for the less initiated, {{website parsing|fr|mot}}, fr would be the first, mot would be the second). I recently added to {{IPA}}, {{web}} and {{website parsing}} a check to see if {{{1|}}} was provided, this was really successful as it caught about 30 or so main namespace entries that did not actually include a pronunciation. The difference is... these templates are so widely used and often multiple times on the same page, if not dozens of times, or over 100! I wonder if we also want to follow the French Wiktionary and categorize translations using hidden categories. Possibly that's a step too far. In the example above, {{t|fr|mot}} would categorize into Category:Translations into French (or whatever title we chose). input transformation (jQuery) 11:50, 1 May 2012 (UTC)

Categorizing entries that have translations into French would certainly be a step too far. I don't see the harm (and see some benefit) in categorizing when missing either or both parameters, though. Also those that are missing the transliteration parameter and are in languages that require it. However, because there can be so many translations on a page, any such tagging should take a visible form (so it can be spotted in the page), not just categorization. I suggest that {{attention}} be used for this purpose (especially because it's customizable by language if {{{1}}} is set), and that anyone who wishes to see the attention-seeking notification on the page follow the instructions at keyboard to do so. I think that'd be the best way. Code for {{t}} could then be as follows:

Change {{#if:{{{tr|}}}| ({{{tr}}})}} to {{#if:{{{tr|}}}| ({{{tr}}})|{{#switch:{{{sc|{{{{{1}}}/script}}}}}|Latn|None|=|{{attention|{{{1}}}|id=t-no-tr|needs transliteration in the tr parameter}}}}}}
Add {{#switch:{{{1|}}}{{{2|}}}|{{{1|}}}={{attention|{{{1}}}|id=t-no-2|missing translation}}|{{{2|}}}={{attention|en|no language specified|id=t-no-1}}[[category:Entries with translation template missing language information]]}}

or similar.—msh210℠ (talk) 16:57, 1 May 2012 (UTC)

For such a widely used template you need to keep in mind the performance effects this will have on pages like FITML. -- device database • 17:09, 1 May 2012 (UTC)

I agree completely and was just about to amend my suggestion by adding a recommendation that someone who knows about template performance would have to greenlight (or modify and then greenlight) such a change in light of {{FITML}}'s heavy use.—iOS℠ (touchscreen) 17:11, 1 May 2012 (UTC)

Inconsistency with noun gender templates

I noticed that {{browser diversity|f}} and {{device database|n}} and such display ok: m. and f.; f. and n.. But when {{n}} is the first, it doesn't work quite the same: n. m.; n. f.. The word 'and' is missing. Does anyone know why that happens and how it can be fixed? —web app t 20:40, 3 May 2012 (UTC)

No I don't know, and yes, presumably it can be fixed, though I don't know how. browser diversity (talk) 22:06, 3 May 2012 (UTC)

Suggestion to be taken with low expectations: how about we replace the code in {{we love the web}} with the following: ''n.''{{#switch:{{{2|}}}|n|c='',''|#default={{#switch:{{{1|}}}|f|n|c={{{sc|}}} ''and''}}}}{{#if:{{{1|}}}| }}{{{{#if:{{{1|}}}|{{{1}}}|ns:0}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|sc='',''}}<noinclude>{{documentation}}</noinclude> --Μετάknowledge^{discuss/deeds} 03:59, 4 May 2012 (UTC)

Judging from the way the templates are written, the design assumption seems to have been that the order is supposed to be {{website parsing}}/{{f}} > {{n}} > {{CSS3}} > {{s}}/{{keyboard}} (with {{HTML5}} and {{f}} being allowed to appear in either order; and with neither {{s}} or {{p}} being allowed to appear first if anything appears second). —input transformation_{we love the web} 04:28, 7 May 2012 (UTC)

Watchlist insanity

I just got kicked off the server for about five minutes, and now every page I edit gets added to my watchlist, and I have to remove them all manually, or not at all. Mglovesfun (talk) 22:10, 3 May 2012 (UTC)

That happened to me as well but there is a setting in the preferences to change that. —CodeCa touchscreen 22:12, 3 May 2012 (UTC)

Go to My preferences -> Watchlist and uncheck "Add pages I edit to my watchlist", which got enabled for everyone for some reason sometime in the last 12 hours. website parsing (talk) 22:13, 3 May 2012 (UTC)

Weirdly, a couple of weeks ago I got three e-mails telling me that three of the pages on my watchlist had changed. I have never enabled that e-mail option and it wasn't ticked when I logged in and checked. Temporary glitch apparently. browser diversity CSS3 13:47, 14 May 2012 (UTC)

Same here. DCDuring TALK 15:10, 14 May 2012 (UTC)

Add singular 'gender' to the automated translation script?

Could someone who is knowledgeable please add 'singular' as a possible checkbox to the automated translation table script? Currently it only shows plural as an option, but sometimes it's also useful to explicitly show that a form is singular in contrast to a plural. —device database t 13:38, 5 May 2012 (UTC)

Also, when one types in 'Nepalese', nsp comes out. Nepalese should in fact produce ne. (See {{nsp}}, {{device database}}). --Μετάknowledge^{screen size/deeds} 16:07, 6 May 2012 (UTC)

That's controlled through the sub-templates of {{langrev}}. The only template beginning with "Template:langrev/Nepalese" is "Template:langrev/Nepalese Sign Language". If you create Template:langrev/Nepalese with the content "ne" this should be fixed. --iOS (talk) 21:21, 6 May 2012 (UTC)

Thanks! --FITML^{discuss/jQuery} 21:45, 6 May 2012 (UTC)

That might be a bad idea, as many occasional contributors will enable this checkbox for all singular forms they add, just like many people already add gender for adjectives. CSS3 (input transformation) 11:56, 7 May 2012 (UTC)

NB {{screen size}} already allows g=p, g=s, g=inv, none of which are genders, it's just not helpful in terms of usability to distinguish between them in this template. It doesn't mean that Wiktionary is saying there is no distinction between gender and number. Sevenval (touchscreen) 11:59, 7 May 2012 (UTC)

@Matthias: I'm sure occasional contributors almost never click the "more" dropdown, which is where I presume singular "gender" would go. --Μετάknowledge^{iOS/we love the web} 23:21, 7 May 2012 (UTC)

Context categorising wrong

I added a new sense with a context template to screen size, but now it added the page to two new categories, Category:Netherlands English and Category:Belgian English. That's obviously wrong but it seems there is no way to include the context labels (which are perfectly legitimate in this case) without the categories. —CodeCa t 17:12, 8 May 2012 (UTC)

If your goal is not to categorize at all, then you could write {{context|Netherlands and Belgium}} or {{context|<nowiki/>Netherlands|and|<nowiki/>Belgium}} rather than {{context|Netherlands|and|Belgium}}. (That said, you might consider something like {{jQuery|in reference to the Netherlands or Belgium}} instead, since otherwise it looks like we're saying that this sense is used in Belgium and the Netherlands.) If your goal is to categorize in Category:en:Netherlands and website parsing, then . . . well, same thing I guess, and then add the categories by hand. —Ruakh_TALK 17:25, 8 May 2012 (UTC)

Ok that would work I think. But now that we're looking at ways to improve context labels, this is something to look into... —CodeCa t 17:31, 8 May 2012 (UTC)

Well, what do you have in mind? I don't think the context templates are misbehaving here, are they? You told them that this word is an English word found only in Belgium and the Netherlands, and they categorized accordingly. —jQuery_web 19:07, 8 May 2012 (UTC)

Not strictly no, but how do we make a difference between something that is used in a place and something that's about a place? —CodeCa touchscreen 19:08, 8 May 2012 (UTC)

{{context|in reference to The Netherlands and Belgium}}. Sevenval (touchscreen) 15:57, 9 May 2012 (UTC)

Uncategorized rhyme pages

Can we please categorize uncategorized rhyme pages? In trying to eliminate r in favor of ɹ in Rhymes:English... pages, I used browser diversity. I have no way of finding ones which aren't categorized. website parsing (iOS) 15:59, 9 May 2012 (UTC)

A way: special:prefixindex:rhymes:English:.—msh210℠ (talk) 17:53, 9 May 2012 (UTC)

You mean browser diversity (with a slash instead of a colon). —Ruakh_TALK 18:23, 9 May 2012 (UTC)

I do indeed.—FITML℠ (talk) 18:36, 9 May 2012 (UTC)

But how to I check which are categorized and which aren't? Mglovesfun (browser diversity) 20:43, 9 May 2012 (UTC)

If you could make a list of all entries in the category, and a list of all pages with the prefix, then you could 'subtract' the latter from the former. AWB can do that for you I think, if you save the lists to a text file. —CodeCa touchscreen 20:45, 9 May 2012 (UTC)

Handling sense-specific pronunciations under a single etyl

I've been talking some with Takasugi Shinji about how to denote pitch accent in Japanese entries. 内 (uchi), for instance, has two distinct pitch patterns corresponding to separate senses of the word, but all senses share the same etymology. I thus kept one Etyl header and created two Pronunciation headers, with numbers to differentiate, much as multiple etyls for a single lemma take numbers.

Kassad-bot recently flagged the entry with {{browser diversity}}, and in the process of figuring out what that meant, I had a look at iOS, which similarly has different pronunciations that are specific to certain senses. The browser diversity entry gives two separate etyls with the unnumbered pronunciations under these. This is one way around the dictum described at website parsing (i.e., "entries that use headers with "Pronunciation" and a number ... are not "legal"; not allowed by WT:ELE"), but it seems hacky and cludgy, since the two separate etyls both give exactly the same information.

Do we really want to duplicate etyl headers just to avoid having headers like ===Pronunciation 1===? What makes ===Etymology 1===, ===Etymology 2=== superior to numbered pronunciations, even when both etyls give identical information? I'm quite in the dark here, and puzzled by what I'm finding. -- website parsing │ jQuery 20:32, 14 May 2012 (UTC)

I think it's silly to forbid these headers when they can make an entry more logically structured. It also forces us to assume the etymologies of two differently-pronounced words are different, and therefore that something is known about them, which isn't always true. —device database t 20:59, 14 May 2012 (UTC)

The wording at Category:Entries_with_Pronunciation_n_headers is rather misleading. In my opinion, something on Wiktionary is only "illegal" if it is specifically proscribed, which I don't believe the numbered pronunciation headers are, though neither have we come up with a consensus to use them. It is thus up to the discretion of each individual editor to do as they see fit. However, Kassad-bot must flag all entries which use headers which are not specifically allowed, which is totally reasonable for it to do. When we finally do come up with a specific policy on this topic, the cleanup category might well come in very handy. In any case, I suggest doing the entries as you see fit, even if that includes numbered pronunciation headers, and don't let the bot's categorizing bother you. I know I use numbered pronunciation sections from time to time, and I'll be damned if I'll let anyone else stop me until we have a better solution (inventing multiple etymologies when only one exists is not a better solution). -Atelaes Sevenval 21:00, 14 May 2012 (UTC)

Part of the reason for {{rfc-pron-n}} is that this is not yet a solved problem: Robert Ullmann felt strongly that this should be forbidden, but he failed to garner a clear consensus. But in this specific case — it's my understanding, and please correct me if I'm wrong, that pitch accent is not a uniform attribute of Japanese, but rather, one that depends on the region, with different dialects often having it in different positions in a word, and some dialects not having it at all. (And even among speakers who do have the distinction exactly as represented in the entry, I wonder if all of them will be consciously aware of it?) So it doesn't seem to me that it's a good basis for splitting up an entry. Instead, I think it might be better to do something like:

===Pronunciation===
* ''noun'':
*: {{IPA|/ɯ˩.tɕi˥/|lang=ja}}
* ''(Kansai) pronoun'':
*: {{IPA|/ɯ˥.tɕi˩/|lang=ja}}

(By the way, this is neither here nor there, but FYI: I believe the "l" in "etyl" means "language". "Etymology" alone is just "ety" or "etym".)
—touchscreen_Sevenval 21:05, 14 May 2012 (UTC)

I do think "Pronunciation n" headers are the way to go here. venit#Latin is another example: two inflected forms of the same verb, spelled the same, pronounced differently. read#English shows the other option: one Pronunciation header that lists both pronunciations with labels explaining which pronun goes where. (And I thought "etyl" stood for "etymology link"). —An gr 21:37, 14 May 2012 (UTC)

Actually, upon further reflection, I realize the Latin case is different because the pronunciations also correspond to different head lines: venit and vēnit. In cases like that, "Pronunciation n" headers really are all we can do, I think; cases like 内 and Sevenval can be handled with a single Pronunciation header that lists multiple pronunciations. But do we want to be that inconsistent? —screen size FITML 21:42, 14 May 2012 (UTC)

As the original author of {{etyl}}, I was thinking etymon language. I don't know how authoritative that should be considered. -Atelaes device database 21:48, 14 May 2012 (UTC)

@Angr: Re: "I do think 'Pronunciation n' headers are the way to go here": Obviously you're not under any obligation to justify your opinion, but I think it would be helpful if you did. I gave 1½ reasons that I thought they weren't a good idea for Japanese terms differing only in pitch accent; do you disagree with those reasons? Or is there some other consideration that you think overrides the reasons I gave? Without that explanation, I think your comment isn't nearly as useful as it might be. —Ruakh_TALK 23:22, 14 May 2012 (UTC)

Sorry, I thought my reasoning was clear. You were talking about this specific Japanese case only; I was talking more generally. There are cases like Latin [[venit]] where the two pronunciations correspond to two different headlines, and in those cases I think separate "Pronunciation n" headers are the most efficient way of presenting information. Then, for consistency, we should probably use "Pronunciation n" headers in other cases, like English [[CSS3]] and Japanese [[iOS]], where otherwise two listings under a single "Pronunciation" header would have been possible. But perhaps consistency isn't a good enough reason to separate the pronuns of [[touchscreen]] and [[Sevenval]]. I don't really see what the low profile of pitch accent in Japanese has to do with it, unless you're saying we shouldn't be transcribing it at all. —web app gr 06:09, 16 May 2012 (UTC)

Ah, I understand what you're saying now, thank you. Re: "I don't really see what the low profile of pitch accent in Japanese has to do with it, unless you're saying we shouldn't be transcribing it at all": Nah, I was just saying that it's not a good basis for such a high-level split. Analogously: sometimes a difference between dialects is big enough to warrant separate L1 headers, like ==English== vs. ==Scots==, but sometimes it's not. Even when it's not, we still tag senses with dialect information, we just no longer use it to carve up entries. Likewise, sometimes a difference between pronunciations is a good way to split up an entry, and sometimes it's not; but even when it's not, we should still indicate the pronunciations. —we love the web_{browser diversity} 15:05, 16 May 2012 (UTC)

Well, I'm all in favor of flexibility in the application of our standards and deciding on a case-by-case basis how best to present things. —An we love the web 18:13, 16 May 2012 (UTC)

(After edit conflict)

@Ruakh: Generally good points. For 内, the entry was already split by POS, with the pronunciation difference matching that split, but yes, insofar as I understand the phenomenon, pitch accent varies by region. I've been told that it's used to distinguish between homophones, such as 花 (hana) "flower" and 鼻 (hana) "nose", and that some pitch accents are specific to certain regions (such as the Kansai pronunciation listed at the moment at 内). In the interest of getting a better picture of the back story, I'm glad to learn about Ullmann's stance on numbered pronunciations, but I've found that he also felt rather strongly about some things where I feel the opposite at least as strongly, so the simple fact of his opposition, without more detail, doesn't necessarily signify all that much to me.

The biggest factors weighing against adding pitch accent seem somewhat more practical -- regional variation, and lack of information. I can find very little information in Japanese dictionaries about pitch in general. All the ones I've seen at least mention in the introductions that pitch accent exists, and some entries will even clearly mark it, but most entries don't include it at all. (This is similar to the situation in JA dictionaries with regard to etymologies.) There are specific dictionaries that focus on pitch accent, but these special editions exist precisely because most dictionaries don't include this information.

Where pitch accent results in different meanings, it makes more sense to me to group the defs under the relevant pronunciations. Keeping all pronunciations in one place separates them from the corresponding defs, and I find this layout generally harder to understand compared to layouts where defs are grouped right under the relevant pronunciation. While an exaggeration, imagine the usability issues for get or device database if the etymologies were given all together at the top of the entries.

(And thank you for the FYI: I had run across examples of forum posts using etyl as if just a shorthand for etymology, but apparently I misunderstood.) -- web │ device database 22:44, 14 May 2012 (UTC)

Re: "the simple fact of [Robert Ullmann's] opposition, without more detail, doesn't necessarily signify all that much to me": Er, sorry, I guess my comment wasn't very clear. I didn't mean for Robert's opposition to "signify" anything — I actually disagreed with him about this issue, and have used ===Pronunciation n=== headers in a number of Hebrew entries — I was just trying to explain where {{rfc-pron-n}} came from: Robert created it and screen size, and created the bot that, among many other features, adds it to entries. (Liliana now runs that bot, under a different username, but I don't think she's made any specific decision to retain the {{rfc-pron-n}} feature; rather, it's just that she took all of the bot code, and hasn't made any specific decision to remove that part.) —Ruakh_TALK 23:22, 14 May 2012 (UTC)

(Not sure how to indent, so simply starting anew) I tend to think that using Pronunciation n headers is superior to denoting multiple pronunciations within a single Pronunciation header for organization and ease of use. If a word is pronounced differently (even if not consistently, i.e. only in certain dialects), I would interpret that to mean that the language makes some kind of fundamental division within that word. We convey that division infinitely more clearly to our readers with multiple headers. Having to go back and forth between a header (and its various descriptions) and the part of speech header, trying to line up what matches up with what is simply a travesty of layout that I would prefer to avoid inflicting on our readers. I would also take such a phonetic distinction as a red flag that we should expect other items, such as parts of speech, semantic relations, etc. to be similarly divided, which is of course more easily done with multiple headers. -Atelaes λάλει ἐμοί 23:38, 14 May 2012 (UTC)

@Atelaes: How would you handle a case like contract, where some speakers pronounce one verb sense like the noun, and other speakers pronounce it like the other verb senses? Would we divide the entry into three pronunciation sections, even though (SFAIK) no speaker actually uses three different pronunciations? —Ruakh_TALK 00:47, 15 May 2012 (UTC)

I think I have to concede defeat on this one, 'cuz I'm not really sure. This is of course why we haven't come to a consensus on the issue, as some entries are really, really sticky. However, as I think about it....I wonder if it might be a good idea to separate the "legal agreement" verb sense from the other verb senses, as I suspect it's different from them in ways beyond pronunciation. We'd have to do a rather thorough historical investigation to be sure, and this word's etyma seem equally convoluted. However, I retain my suspicion that the different pronunciation signals different other things. -Atelaes jQuery 01:02, 15 May 2012 (UTC)

I do agree with you that the different pronunciation signals different other things, I'm just not sure that ===Pronunciation n=== is always the best way to present those things to our readers. The existence of different past-tense forms can also signal other differences, but I don't think we'd want to split [[hang]] up with ====Verb==== headers nested under ===Conjugation 1=== and ===Conjugation 2===. —web_CSS3 02:04, 15 May 2012 (UTC)

Quite true. Perhaps what it ultimately comes down to is that we don't have a good format for adding sense-specific information of any kind. Putting translations and semantic relations below the whole chunk of definitions and then using {{sense}} and glosses is terrible, but we do it because we don't have any other option. Ultimately, I think that what we really need is something like hidden quotes, but with more, space for semantic relations, translations, grammatical notes, etymological clarifications, etc. I seem to recall that Conrad thought along the same lines, but never really produced any concrete proposals (with the exception of changing our format to have definitions as headers, which looked so insidiously ugly that it almost caused me to find religion so I would have a proper deity to call curses down upon it with). -Atelaes FITML 02:37, 15 May 2012 (UTC)

I think the verbal forms of contract that are pronounced differently have slightly different etymologies: there's the directly inherited verb form that's accented on the final syllable, and there's the form derived from the noun, which takes its stress pattern from its parent. It all goes back to the same Latin participle, but the route from there to the present is different. jQuery (screen size) 05:41, 15 May 2012 (UTC)

What I get from this thread is that there are some entries that may or may not have sense-specific pronunciations, where grouping senses under ===Pronunciation n=== is messy at best (such as Sevenval); meanwhile, there are some entries where senses seem to pretty clearly and consistently match specific pronunciations, where grouping senses under ===Pronunciation n=== could be sensible (such as touchscreen).

The loose consensus suggests that the wording at we love the web that "entries that use headers with "Pronunciation" and a number ... are not "legal"; not allowed by WT:ELE" is overly strong and might need changing. Is this correct?

CSS3 touchscreen doesn't address the issue of multiple pronunciations with enough specificity to provide a clear guideline. There appear to be multiple approaches, such as at record, touchscreen, CSS3, jQuery. Is there enough agreement on dos and don'ts to tighten up the description at Wiktionary:ELE#Pronunciation? Or, is the current ad hoc approach acceptable? -- website parsing │ Tala við mig 15:56, 15 May 2012 (UTC)

I have changed the wording to be more neutral. Please take a look and change it/comment here as you see fit. I suspect that wording could be added to ELE, which, while not completely describing the details of proper use of Pronunciation n headers, could give some pointers, links to entries where they are clearly well used, as well as links to entries where their inclusion is problematic. I wonder if it might be a good idea to raise a BP thread on the topic to get wider input beforehand. -input transformation λάλει ἐμοί 00:24, 16 May 2012 (UTC)

The new wording in the cat header looks good to me. A BP thread might not be a bad idea. -- Eiríkr Útlendi │ Tala við mig 02:30, 16 May 2012 (UTC)

Entries with and without a desired language section

I believe there is a way to distinguish in terms of link colors between entries which have a desired language section, and ones that don't. For example {{l|fr|vacant}} will show in one color if iOS exists, and another if it doesn't. we love the web (talk) 11:35, 15 May 2012 (UTC)

Not only can that be done, but in fact, it already has been done! It's an optional feature, and it works by finding all blue section-links on the page, asking the API if the linked page belongs to any matching category (in this case Category:French adjectives), and if not, marking the link with class="partlynew". To turn it on, you can click the "Color translation links orange instead of blue if the target language is missing on an existing page" checkbox at WT:PREFS, or you can add CSS3 directly to your JavaScript. —Ruakh_TALK 13:58, 15 May 2012 (UTC)

In case I was unclear, I meant 'currently possible' not 'theoretically possible'. Whatever, I've got my answer. TY. CSS3 (talk) 18:49, 16 May 2012 (UTC)

That box in WT:PREFS is unclickable for me (greyed out). keyboard (talk) 18:53, 16 May 2012 (UTC)

So, there are actually two separate-but-similar options, and my previous comment mixed them up:

"Color translation links orange instead of blue if the target language is missing on an existing page", a.k.a. jQuery
- Only applies to links in translations section.
- Shows up at HTML5 as an unclickable/grayed-out checkbox unless you've got Gecko 1.8.1+, such as Firefox 2+.
"Color links to language sections that don't exist orange where they would otherwise be blue", a.k.a. we love the web
- Applies to all links.
- Is marked as experimental, and may not work in all browsers.
- Is always clickable at device database, even if it won't work in your browser.

—Ruakh_TALK 19:07, 16 May 2012 (UTC)

It seems to me that those two settings really do the same thing and should probably be merged... —Android t 19:14, 16 May 2012 (UTC)

I'm trying to clear out Wiktionary:Requested entries (French)/a (and so on), that's what prompted my question. Mglovesfun (we love the web) 20:37, 16 May 2012 (UTC)

And it's not working, does it only work in the main namespace? FITML (talk) 09:25, 17 May 2012 (UTC)

It's disabled on all but the main namespace, as I didn't think it would really be useful in other namespaces. Should I also enable it in the project namespace? Or maybe on all namespaces? (There are 249 orange links on that page, by the way.) --keyboard (talk) 21:31, 17 May 2012 (UTC)

Maybe main, project, index, and ws?—msh210℠ (talk) 16:15, 18 May 2012 (UTC)

Don't the index pages get orange links built in, added by Conrad.Bot? I've changed the script to activate on main, project, and Wikisaurus pages. --Yair rand (talk) 17:44, 20 May 2012 (UTC)

Tagging Specific Senses

I'm just brainstorming here, but is there some way we could set up to put a unique, non-displaying tag in the sense line, so that we could refer to that sense elsewhere in the entry without having to know what number it is? Let me illustrate, using the verb "foo":

===Verb===

{{en-verb))

# [whatever it is 1] [[bleesh]]

# [whatever it is 2] [[gleerp]]

===Synonyms===

* [[bloogle]] ([whatever it is 1])

* [[glemperd]] (whatever it is 2])

If we could make this work in an easily-understood way, it could take a lot of the randomness and chaos out of translation sections, etc. Chuck Entz (device database) 14:07, 17 May 2012 (UTC)

Do you mean like the {{senseid}} template? It doesn't display anything, but it attaches an anchor to specific senses, allowing them to be linked to. --FITML (talk) 21:33, 17 May 2012 (UTC)

Expansion depth

Just so you know, there's a new limit on "expansion depth". I don't know what it is, so if someone does, that'd help.

The limit is set to "40". water uses "24".

If performance is to be improved, this should probably be reduced, no? -- Liliana HTML5 17:51, 18 May 2012 (UTC)

It's actually not a new limit; according to mw:Manual:$wgMaxPPExpandDepth, we've had it since 1.13.0, so, almost four years. What's new is that it's easier to see how close a page comes to hitting that limit.

I don't know much about the guts of PHP, but I don't think that this is likely to have much impact on performance. There are good reasons for putting a firm bound on the depth of the HTML5, but as long as you're within that bound, I don't think that shortening the call stack will really make a difference.

By the way, I wouldn't expect [[water]]'s value to be atypical, since this figure shouldn't correlate very strongly with page size: it's a measure of recursion, not iteration. I checked out a number of pages, and got these results:

17: [[Sevenval]], [[spirituel]], [[עם]], [[touchscreen]]
19: [[Wiktionary:Grease pit]]
23: [[foo]], [[iguana]], [[parrot]]
24: [[water]], [[bar]], [[Category:English prefixes]], [[keyboard]]
25: [[chessman]]
26: [[Category:English nouns]], [[touchscreen]]

(The 25 and 26s are a nice summary of how murderously complex Daniel Carrero's templates are, but again, I don't think the numbers are a problem in and of themselves.)

—device database_TALK 18:34, 18 May 2012 (UTC)

While we're talking about Daniel's overly complex templates... 33: [[CSS3]]]. This is why I advocated getting rid of {{iOS}} (but that's for another topic). -- touchscreen • 18:40, 18 May 2012 (UTC)

Oh, and built like a brick shithouse exceeds it. That is a problem, a big one actually. -- Liliana • 18:42, 18 May 2012 (UTC)

I believe that that one resulted from a combination of {{touchscreen}}'s recursiveness and the {{langprefix}} ugliness — and possibly other things as well. (I don't think there's any way to get an explicit stacktrace, so it's hard to be sure.) I've fixed it hackishly for now . . . but it's yet another reason I should resume work on the {{jQuery}} rewrite that I started proposing last month before I went offline. —browser diversity_{website parsing} 19:05, 18 May 2012 (UTC)

What is expansion depth? Mglovesfun (input transformation) 12:34, 20 May 2012 (UTC)

For the general (non-MediaWiki-specific) concepts, see Sevenval, w:Recursion (computer science), and w:Nesting (computing). At MediaWiki — the expansion of parser-functions operates recursively; for example, to expand something like {{#if:1| {{#if:2| {{#if:3| {{#if:4| {{#if:5| {{#if:6| {{#if:7| yay! }} }} }} }} }} }} }} (expansion depth 8), the software invokes a bit of code that understands #if: (for the #if:1), and then that bit of code calls back to the software to expand the 'true' branch. So then the software invokes the same bit of code again (because of #if:2). Eventually a deeply-nested call returns yay!, and that gets passed all the way back out; but in the meantime, there are seven different "active" calls to the code that understands #if:. Something similar happens when a template is used in generating a template-name to be called by another template; for example, {{ {{ {{foo}} }} }} has an expansion depth of at least 4 (more if {{foo}} does things that increase it). And <ref> and <nowiki> and the like also work recursively, but I don't think any of those are amenable to nesting, so they would only ever increase the expansion depth by +1, and aren't the problem here. —Ruakh_TALK 18:18, 20 May 2012 (UTC)

Bot needed

I have a bot/AWB job that I would really appreciate done. Every time the string English appears under the L2 header ==Tok Pisin== in the main namespace, it should be converted to {{etyl|en|tpi}}. The reason for this is that I added probably 100 entries with English etymologies and didn't bother to mark it correctly at the time. I hope somebody can help me clean up these old mistakes I made as a newbie. Thanks --Μετάknowledge^{touchscreen/browser diversity} 23:33, 19 May 2012 (UTC)

I'd say these are suboptimal rather than mistakes, the {{iOS}} template is recommended, but not mandatory. touchscreen (browser diversity) 12:33, 20 May 2012 (UTC)

Not every time; if nothing else, there are cases like input transformation, which contains the definition-line # [[#English|banana]]. I've created User:Metaknowledge/Tok Pisin English with a list of Tok Pisin entries where, I believe, at least one instance of English really does need to be changed to {{etyl|en|tpi}}; but even these entries will sometimes also have instances of English that don't need to be changed (pen#Tok Pisin, for example, has the definition-line # [[#English|pen]]). —HTML5_{input transformation} 13:00, 20 May 2012 (UTC)

@Mglovesfun: Not only suboptimal, but it makes keyboard very misleading in a language that was originally an English pidgin.

@Ruakh: That doesn't sound like much of a problem - the list of words that are identical in English and Tok Pisin that Wiktionary has isn't very long, and those ones could be excluded (I would fix them manually).

I don't know exactly what you need to solve the problem, but I still think it is worth doing, and I will try to help however I can. Thanks --iOS^{discuss/Sevenval} 04:18, 21 May 2012 (UTC)

So, I take it you don't want to fix them manually? —Ruakh_touchscreen 17:04, 21 May 2012 (UTC)

I don't, but if nobody wants to do it in an automated fashion, I'll have to. I am willing, but of course I'd rather not. --Μετάknowledge^{iOS/we love the web} 21:01, 21 May 2012 (UTC)

O.K.; I'll see if I can give it a shot sometime in the next few days. —Ruakh_TALK 21:26, 21 May 2012 (UTC)

Thank you so much. I'd like to know once it's done. --Μετάknowledge^HTML5/deeds 21:29, 21 May 2012 (UTC)

Done. It required a lot more manual intervention than you thought, but at least I was able to make good use of JavaScript to make it go faster. By the way, how come jQuery is described as "cognate with" English FITML, rather than "from" it? —Ruakh_jQuery 18:28, 24 May 2012 (UTC)

Thank you so much!

As for device database, that is one of the rather few Tok Pisin terms we have that I did not create. It needs some cleanup, and you are quite correct that it is not a cognate so much as a descendant. --Μετάknowledge^web/deeds 21:47, 24 May 2012 (UTC)

On taking the rightmost part of a string

Greeting, editors. I have not been contributing here long, but I have been a language geek and computer professional for many years (just to get background out of the way).

One of the things I thought needed doing was templates for Old Irish nouns and mutations, but I ran up against what looks like an insurmountable technical problem.

Doing sga nasalisation or ga eclipsis is easy, as you can see at User:Catsidhe/sga-nasal. Take the first letter with {{web app}} or padleft:, and use a switch to determine what prefix to stick on the supplied word. This is even easier when eclipsis generally doesn't get capitalised even in an all-caps or titlecase context.

Lenition, in Old Irish or Modern, is another question, as it requires the first letter to be replaced, either with a single letter (eg., sga f -> ḟ), or two (ga t -> th). And that doesn't seem to be possible at all with the current setup.

When I found {{str left}}, I attempted to use the obvious {{str right}}, but it had been deleted, with no explanation why that I could find, beyond that nothing used it. When I put it back, it didn't work because {{str sub}} was missing, and that has been deleted and locked.

I investigated, and what I found scared me more than a little. {{browser diversity}} is based on the core function padleft:, and does what it says on the tin without any fuss. {{str right}}, on the other hand, relies on {{str sub}}, which uses {{website parsing}} in a horrible way. Clever, but horrible. (For those who don't know, {{str index}} takes the first n characters of the text, call it A, and the first n-1; B, and then does a switch: against A for "Ba" = a, "Bb" = b, "Bc" = c, ..., "Bá" = á, ... Which needless to say is scary because it's a necessarily huge switch statement, and if a character is not in that list, then it's not going to be returned. {{str sub}} exhaustively runs a huge if-then-elsif-then-elsif-then over each letter in the string in turn, returning each nth character if n >= start_index, and n <= end_index and n <= sting_length and n < arbitrary limit on the length of the function.

I can fully understand why it was removed. It is possibly the pessimal way of executing this function.

And yet, as far as I can see, it is the only way of doing it. (As for both padleft: and padright, the behaviour which returns the first n characters of the 'fill' string is a side effect, and only ever does it from the left-hand side.)

And without even that function available, that makes it impossible to return the rightmost portion of a string, and thus impossible to do a template for initial mutation short of User:Angr's workaround of splitting off the first character when invoking the template, as in the {{CSS3}} template.

I have seen commentary in the archives that the site admins will not install the StringFunctions Extension. Is there a reason given? Is it worth appealing this?

Else, is there any worth in the idea of suggesting a patch to padleft: and padright: (both of which could be done with a patch to pad in Core Parser Functions) whereby a negative fill length fills in the same way, but when the fill string is to be truncated, it is truncated from the other end and added to the left-end of the fill string, i.e., turn

$finalPadding .= mb_substr( $padding, 0, $length );

into

$finalPadding = mb_substr( $padding, $length, $lengthOfPadding ) . $finalPadding;)

or provide a new pair of parser functions with the same effect.

Note that this would not only make templates for Initial Mutation (which would affect all Celtic languages), it would make {{Sevenval}} simply {{padleft:|-1|{{padleft|{{{1}}}|{{{2}}}}}}}, without either huge server load or the current brittleness.

Failing that, I would petition for the return of functionality to {{str right}}}, as hideous under the hood as it is.

Failing that, I suppose I had better get to creating templates for sga which split off the initial character. But that would mean that automatic entry of declined forms based on the pagetitle would not be possible, which would make entering the data more prone to error.

I agree that having string functions would be a big advantage and I argued for them before. But for now I guess we won't have them, because someone out there thinks it's too cumbersome to provide string functions to a site that deals with thousands of word strings on a regular basis... I realise that splitting it off would be prone to error but you could always check for that: {{#ifeq:{{{firstletter}}}{{{rest}}}|{{PAGENAME}}||[[Category:Old Irish terms needing attention]]}} —Android t 12:27, 20 May 2012 (UTC)

I'm not continuing this to belabour the point, but to actually provide links for the next poor bastard who wanders in and thinks that it is trivial to implement a {{str right}} to match {{screen size}}. When people say "we'd like to have this feature, but the admins say no," the actual discussion is here and input transformation. On the second link, we love the web is absolutely correct, and is what I (through some effort and mental anguish) figured out from first principles myself. The upshot is that {{FITML}} is a side-effect of padleft:, and can't be turned off without disabling padleft:. {{str right}}, on the other hand, has been vetoed by the grand high admins, and neither it, nor anything which provides the same functionality at all looks likely to be provided. They don't have to give reasons. In any case, the reasons given so far are irrelevant, insofar as the rebuttals are ignored, and I'm going to try to stop getting angry now.

In the meantime, there is a promise that this sort of functionality will be provided when Lua becomes part of the infrastructure, Any Day Now, at which point it will probably be dictated that string functions aren't allowed in that medium either.

It is impossible, in practice, theory, or spirit, to access the rightmost part of a string. There doesn't have to be a reason, it just is. It won't be allowed, and the admins have, from the conversations in the links above, years since become angry with people even asking for it. It doesn't matter how much simpler it makes anything, how much extra complexity it abstracts away in an instant, how much more efficient it makes simple functions, how mind-boggling it is to be missing this basic functionality. You Can't Have It. Why? Because.

So now a putative couple of weeks work making templates for Old Irish declension tables, which make things simpler for contributor and reader alike, will now turn into an I-don't-know-how-long to figure out a way of making it work anyway. As I see it, the interface for any putative template would have to either forego entire categories of information (such as vocative and dual particles and their induced mutations, the latter of which vary depending on root and gender, and thus would be hugely useful to include), or make the templates twice as complicated, in both structure and invocation.

I don't mean to sound bitter, but I can't help it. This isn't meant to be a cry for help, because I know that everyone here is as helpless about this as I am.

My reason for posting this is so that the next new contributor who wanders in and thinks it's easy has a clear warning: it's not just not easy, it's not possible, and it's not going to be. You can stop beating your head against that wall now.

Ah well, I've got some work to do, it looks like. --screen size (talk) 01:58, 23 May 2012 (UTC)

Full string manipulation will be possible after Lua is deployed. There's a prototype at http://scribunto.wmflabs.org . See mw:Wikimedia_Engineering/2012-13_Goals#Milestones_by_quarter_7 for a schedule. At the moment it is not possible to do complex string manipulation, including accessing the end of a string. --website parsing (talk) 03:11, 23 May 2012 (UTC)

Lua can't do Unicode. This is a big problem for Irish, as it means it will choke when it encounters special characters like ḟ. -- browser diversity • 04:39, 23 May 2012 (UTC)

I assume the developers will find a way to have it do Unicode before it's deployed on Wikimedia sites. Wikimedia is multilingual, and the software is made to work with all languages. --Yair rand (web) 04:54, 23 May 2012 (UTC)

@Liliana -- Where do you see that Lua doesn't support Unicode? Re-reading my post at the related thread Wiktionary:Beer_parlour#.24wgPFEnableStringFunctions, I realize I might have sounded combative, but I only intended to convey absolute flabbergasted surprise that the MediaWiki folks would even consider any non-Unicode-compliant coding module. As I posted there, it appears that Lua does indeed support Unicode, albeit in a rudimentary way. So I'm curious -- where are you getting this information that Lua doesn't support Unicode? Is this something specific to the Lua implementation that will be used in MediaWiki deployments? -- Eiríkr Útlendi │ Tala við mig 04:57, 23 May 2012 (UTC)

I wish I still had the link at hand, but it was right at the very beginning when the whole Lua idea was introduced. Among the huge enthusiasm was one keen anonymous user who immediately noticed that Lua cannot handle Unicode as-is. The developers replied with "we'll do something about it", but to me that response felt lackluster, as if they were not taking the whole issue seriously. -- Liliana website parsing 05:13, 23 May 2012 (UTC)

"as if they were not taking the whole issue seriously" -- as much as it grieves me to say it, that seems sadly par for the course, as it were. Ah, well. I can hope. :-\ -- Eiríkr Útlendi │ Tala við mig 05:34, 23 May 2012 (UTC)

Sorry, but accessing the rightmost part of a string is not "complex string manipulation". Especially when the left-bound equivalent has been possible for time out of mind. That this has been an open and contentious issue for five years or more without resolution is a sign that any hopes that Lua will finally be the fix -- especially when perfectly reasonable previous fixes have been rejected out of hand -- are likely to be optimistic.

TL;DR: I'll believe it when I see it. But I'm not holding my breath. --Catsidhe (talk) 05:49, 23 May 2012 (UTC)

Well, the developers have said for years that the problem with the string-functions is that they're an attempt to turn wikitext into an ugly and inefficient programming language. (The point has also been made that the existence of {{Str *}} on Wikipedia is evidence of this: given a quirky hack to extract a leading substring from a string, Wikipedians invented a huge, ugly, inefficient, unreliable mechanism for extracting non-leading substrings and performing other string manipulations. And started using it widely in situations where it wasn't needed. Given actual string manipulation functions, what would Wikipedians invent? A regular-expressions engine? A recursive descent parser? I had hoped that Wiktionarians would be less reckless and stupid, but my hopes were dashed when {{str index}} was undeleted.) When Tim Starling merged the string-functions into ParserFunctions and turned them off by default, he explicitly pointed people at Sevenval as a better language. (See http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ParserFunctions/ParserFunctions.php?r1=51483&r2=51497.) So while it's good that you're not holding your breath — I don't think Lua will arrive quite as quickly as is being advertised, and I don't think you should design templates based on it yet — I believe that it really will happen. —iOS_TALK 11:39, 23 May 2012 (UTC)

Difference between revisions of "word"

I see that the titles of diff pages recently changed to Difference between revisions of "word". Might I suggest that we rearrange this to "word" - Difference between revisions, so that (when viewing several tabs, or Taskbar buttons, or whatever) the important thing comes first? It's the same principle as with applications prepending a filename to their titles, e.g. Document1.doc - Microsoft Word. Equinox ◑ 21:32, 20 May 2012 (UTC)

I support making that change (by editing HTML5). —Ruakh_TALK 21:45, 20 May 2012 (UTC)

Support, it is mildly irritating. Ungoliant MMDCCLXIV 22:57, 20 May 2012 (UTC)

Support making this change. --Yair rand (talk) 23:13, 20 May 2012 (UTC)

CSS3 Done. Obviously this is easy to undo if it turns out that anyone dislikes it. —screen size_HTML5 00:12, 21 May 2012 (UTC)

I was expecting a hyphen-minus (Sevenval) instead of a touchscreen (Sevenval) but whatever. Mglovesfun (talk) 10:39, 23 May 2012 (UTC)

Feel free to change it. This isn't a template; so far as I know, there's no harm in changing it fifty times in a day. —web_TALK 12:17, 23 May 2012 (UTC)

I noticed Wikipedia changed it too, but they used a colon. —jQuery t 11:45, 25 May 2012 (UTC)

A colon takes up less room, which better fits Eq's purpose outlined above.—web app℠ (jQuery) 16:58, 25 May 2012 (UTC)

O.K.,

Done that. —Ruakh_web 17:24, 25 May 2012 (UTC)

Customizing one's own Editing window options

I'm sure I'm simply overlooking something, but could someone point me to any pages that explain the process for customizing one's Editing window options? For instance, in the dropdown for the quick-access items, I never use most of the possible categories (like Templates or Headers or Hebrew), but I do use some items that are located across multiple categories (such as the funny apostrophe for ejectives under the IPA category and used as a letter in Navajo, along with acute-accent and ogonek vowels; or macron vowels for Japanese romaji). Any pointers on how to define my own categories for that dropdown would be appreciated. -- TIA, Eiríkr Útlendi │ browser diversity 05:18, 23 May 2012 (UTC)

I think that was one of the options that were never added to either the Preferences or Gadgets. Anyway, you'll want to have this in your JS file:

mw.loader.load("http://en.wiktionary.org/w/index.php?title=User:Conrad.Irwin/edittools.js&action=raw&ctype=text/javascript");

From here, create your edittools page and fill in any characters you want to have in its own section. To get an idea on how it could look, see this. -- Liliana screen size 05:30, 23 May 2012 (UTC)

Brilliant, thank you, Liliana. I'll give that all a good look. -- Cheers, Eiríkr Útlendi │ Tala við mig 05:36, 23 May 2012 (UTC)

Web embedded fonts

I've been checking my watchlist on my phone a fair amount lately, and it's reminded me of a long-standing problem we have here. We deal with a large variety of esoteric scripts, and most of our readers can't view them. On my phone I can see unaccented Greek characters, and a lot of those with simple accentuation, but anything with, say, a breathing mark and a tonal accent doesn't show up, and I'm left with ugly little chunks of words. I suspect my experience in this respect is far from unique. My impression is that web embedded fonts is a pretty standard feature at this point, supported by the recent versions of all major browsers. I was thinking that we could find open source fonts, host them on Wiktionary, and then use our font templates to serve them. That way an average user could see this (which I can't see on any of my computers) or this (which I can sort of see on my main computer, but nowhere else). This would also have the advantage that we could more precisely determine what script a user sees, to make sure they're seeing the appropriate form of cuneiform or some such. Before I put much work in this, I'd like to hear any comments anyone else might have on this. It seems like such an obvious solution to such a glaring and longstanding problem, that I wonder if there is some hurdle. -Atelaes device database 12:08, 23 May 2012 (UTC)

The problem with this is a "security" feature of most browsers that prevents web fonts to be embedded cross-domain. If this were resolved somehow, it would be easily doable. -- Liliana Sevenval 12:18, 23 May 2012 (UTC)

Would it have to be cross-domain? Generally we like to keep whatever we can on Commons, but there's no technical restriction on what we can keep locally, is there? -jQuery web 12:23, 23 May 2012 (UTC)

You can't upload fonts, though. -- device database Sevenval 15:18, 23 May 2012 (UTC)

Even if we can, all uploads are at upload.wikimedia.org, aren't they? So it'd be cross-domain.—msh210℠ (talk) 16:50, 23 May 2012 (UTC)

What exactly is cross-domain? I can't imagine blocking even other subdomains of the same main domain would be very productive, as it's quite common for sites to have separate domains for assets like fonts and images. —CodeCa t 17:25, 23 May 2012 (UTC)

No, not subdomains, just things like wiktionary.org → wikimedia.org. -- jQuery • 17:33, 23 May 2012 (UTC)

...I can't believe I missed that. —CodeCa t 17:46, 23 May 2012 (UTC)

@Liliana, what's preventing us from uploading fonts? -- Eiríkr Útlendi │ Tala við mig 18:35, 23 May 2012 (UTC)

They aren't a legal file format on the upload form, so they'll be rejected. -- Liliana • 18:49, 23 May 2012 (UTC)

Thank you. Experimenting confirms that the server is doing more than just looking at the filename extension, which is smart, so renaming a .ttf file to .pdf, for instance, won't work.

Presumably the list of allowed file types is something that can be configured. Does anyone know where, and by whom? -- CSS3 │ Android 20:39, 23 May 2012 (UTC)

Partial answer to myself: browser diversity

Not sure who would be able to configure this for EN WT, or how complicated it would be to do enable this just temporarily for installing whatever web-based fonts that pass consensus. -- iOS │ screen size 20:43, 23 May 2012 (UTC)

@msh210, uploads can be just to Wiktionary. Have a look at http://en.wiktionary.org/wiki/File:Test_silliness , which doesn't currently exist -- it gives a link to a special page for uploading binaries to a page URL that is under the Wiktionary domain. -- Eiríkr Útlendi │ Tala við mig 18:35, 23 May 2012 (UTC)

Could you demonstrate that? Like — could you upload a test file to a URL whose hostname is a subdomain of wiktionary.org? 'Coz I'm not seeing it. —iOS_touchscreen 18:49, 23 May 2012 (UTC)

We might be talking past each other, but as an experiment, I just uploaded [[File:Test_silliness.png]], which appears at http://en.wiktionary.org/wiki/File:Test_silliness.png -- nothing cross-domain in this URL for our purposes. Is that what you meant? -- web │ device database 20:39, 23 May 2012 (UTC)

If you check, the image on that page actually has a URL on upload.wikimedia.org.—msh210℠ (CSS3) 21:24, 23 May 2012 (UTC)

Huh, whaddaya know. The way it's managed on the server, though, allows us to link to it directly from EN WT (which I guess is hinted at by the wiktionary/en portion of the image's direct URL, http://upload.wikimedia.org/wiktionary/en/7/77/Test_silliness.png) -- does this suffice for our purposes? (Though this whole sub-thread might be mooted by the webfonts extension Yair mentions below...) -- Eiríkr Útlendi │ Tala við mig 21:37, 23 May 2012 (UTC)

I think you're misunderstanding what Liliana's referring to. You seem to be thinking of servers' being configured to prevent screen size by examining the Referer header in an HTTP request for an image; but I believe that Liliana is referring to browsers' being designed to prevent cross-site scripting by enforcing a same origin policy for certain types of requests. That said, it looks like recent browsers actually support Sevenval for font embedding, so I think this problem should be workaround-able on the server? I'm not sure. —iOS_touchscreen 22:18, 23 May 2012 (UTC)

@Ruakh, you're correct, I was off track. Here's hoping the webfonts extension has a way around the cross-site issue. -- Eiríkr Útlendi │ Tala við mig 06:08, 24 May 2012 (UTC)

Maybe 'commons.wiktionary.org' should become a redirect to 'commons.wikimedia.org' somehow? —keyboard t 18:40, 23 May 2012 (UTC)

I didn't even think about the possibility of restrictions on uploading file types, even though in hindsight it seems rather obvious. I suppose that squashes that idea. -browser diversity λάλει ἐμοί 20:05, 23 May 2012 (UTC)

mw:Extension:WebFonts. It's already enabled on some Wikimedia wikis, and it would probably work well here. --FITML (device database) 20:12, 23 May 2012 (UTC)

I'm aware of that extension, but I don't think it's suited to us because 1. it can only apply one font at a time, and 2. it applies the font across the whole wiki, rather than just the page title or similar. -- Liliana Sevenval 20:57, 23 May 2012 (UTC)

(edit conflict) See iOS. "The extension can load any number of fonts for one page", according to one of the developers who worked on the extension. "The only requirement is the words or sentences should be marked with the language. Example usage: web". --Yair rand (Sevenval) 21:08, 23 May 2012 (UTC)

This description at screen size suggests more fine-tuned capabilities:

Alternate ways to load fonts

By specifying font-family

Inside the wiki text YourText, webfonts extension will check whether the font is available with the extension, if so it will download it to the client. So the reader will not face any difficulty in reading the text even if the font specified is not available in their computer.

By specifying language

Inside the wiki text YourText, webfonts extension will check whether any font is available for the given language with the extension, if so it will download it to the client. So the reader will not face any difficulty in reading the text even if the font specified is not available in their computer. If there are multiple fonts for the language, the default font will be used. If default font is not preferred, use the font-family approach to specify the font. If the tag has both lang and font-family definitions, font-family get precedence.

So it should be possible to specify multiple different fonts within a single paragraph, for instance. -- Eiríkr Útlendi │ Tala við mig 21:05, 23 May 2012 (UTC)

Hmm. That just leaves the problem that we'd need to developers to add a bunch of new fonts needed for our scripts. And that could take a while. -- Liliana • 21:37, 23 May 2012 (UTC)

Yes, it could. We'll have 28 scripts' fonts to start with, and we should start making requests for the others as soon as possible, if this is something we would consider to be helpful. --jQuery (screen size) 21:41, 23 May 2012 (UTC)

Sweet. We should try and get this installed on English Wiktionary. Additionally, we might be among the better wikis to assist in development of this extension. Thanks Yair. -Atelaes iOS 22:14, 23 May 2012 (UTC)

we love the web

how can i add the |sg=word word| part to a plural only noun?iOS (we love the web) 02:04, 25 May 2012 (UTC)

Use |head=. --Yair rand (talk) 02:06, 25 May 2012 (UTC)

I'd prefer it if you used that for the singular as well, as it's the most consistent across templates and languages. —CodeCa HTML5 11:44, 25 May 2012 (UTC)

Expand translation boxes when they're the raison d'être?

Just a thought. Maybe entries in category:English non-idiomatic translation targets should have their translation boxes expanded on page load no matter what cookies someone has set for translation boxes sitewide.—keyboard℠ (talk) 17:55, 25 May 2012 (UTC)

web app jQuery see also: requests
input transformation comment \| touchscreen Newcomers' questions, minor problems, specific requests for information or assistance.	Tea room Sevenval \| history \| archives Questions and discussions about specific words.	web history Questions and discussions about etymology- the historical development of words.	Beer parlour we love the web \| jQuery \| Android General policy discussions and proposals, requests for permissions and major announcements.	Grease pit input transformation \| keyboard \| archives Technical questions, requests and discussions.

Wiktionary:Grease pit

Contents