Wiktionary:Grease pit/2012/August

As per WT:BP#Monthly subpages for the current (BP, GP...) discussion page, I'm starting a trial run of this scheme on the Grease Pit. There are probably some technical details to work out to make this work more smoothly. In the meantime, please use the subpage WT:Grease pit/2012/August for any new discussions, don't add any to WT:GP itself. Maybe the latter should be protected as a 'hint'? —CodeCat 11:08, 1 August 2012 (UTC)Reply

No, because people may still want to contribute to pre-August threads. —Angr 17:49, 1 August 2012 (UTC)Reply

That's a good point... —CodeCat 18:31, 1 August 2012 (UTC)Reply

Two comments:

• One complication with the monthly-subpage approach is that people will need to add each new subpage to their watch-list. However, there is a hackish way to address this. You see, when you move page X to page Y, all people who had page X on their watchlist will now have both page X and page Y on their watchlist. Even if you then move page Y back to page X with no redirect, all those people will continue to have page Y on their watchlist. So, if page X is Wiktionary:Grease pit and page Y is ], then we can use this approach to add ] to the watch-list of everyone watching Wiktionary:Grease pit.
• We may also want to create a MediaWiki:editnotice-4-Grease pit to warn people against editing the top-level Grease pit. Unfortunately, that notice will appear not only in the top-level Grease pit but also in all subpages, so the warning will have to be worded carefully to avoid scaring people off. (Alternatively, it can be augmented with JavaScript that checks for the specific page.)

—Ruakh_TALK 21:13, 1 August 2012 (UTC)Reply

Once all the 'old' discussions have been archived, we can protect the main GP page. Then those who can still edit it will all be administrators, who hopefully know better. :) I'm a bit confused about your idea for watchlists though. Do you mean that whenever a new monthly subpage is created, an admin moves the GP to that new page, then moves it back again over the redirect, and then turns the new page (which is now a redirect back to GP) into a proper page? —CodeCat 21:17, 1 August 2012 (UTC)Reply

Re: administrators knowing better: I'm sure that will eventually be the case, but there will be a long transitional period. The more help we give, the better. Re: watchlists: Yes, exactly. —Ruakh_TALK 21:33, 1 August 2012 (UTC)Reply

Is it technically possible to make it so the "Add topic"/"+" button on the main GP page creates a new topic in the current month's subpage? —Angr 20:42, 2 August 2012 (UTC)Reply

It's more than technically possible: it's already done. (But it requires JavaScript. And you may need to hard-refresh, or even to clear your cache, in order to see it.) —Ruakh_TALK 20:57, 2 August 2012 (UTC)Reply

By the way, you write of archiving the old discussions, but why not just split them onto monthly subpages right now, just like August? I think that makes more sense than the current split approach. —Ruakh_TALK 20:41, 2 August 2012 (UTC)Reply

I wanted to be cautious in changing everything around until we are more certain we want to stick with this. —CodeCat 20:57, 2 August 2012 (UTC)Reply

I support being cautious, but changing June and July is actually a much smaller deal than changing August, because people don't need to add new sections to June or July anymore, so they can just use the "edit" link for whatever section they want to contribute to. And, of course, it's quite reversible. —Ruakh_TALK 21:01, 2 August 2012 (UTC)Reply

Ok I will try to move the GP first to make sure the new subpages appear in everyone's watchlist. I hope it works. —CodeCat 21:25, 2 August 2012 (UTC)Reply

Done. I hope it worked out right. I had to move the talk page around separately because it got lost half-way through the moving. What should we do with the old archives, which are all subpages of Wiktionary:Grease pit/timeline? They follow the same naming as the new scheme as far as I can tell, so moving them to a new 'base' page should work. I don't know if that's possible, though. —CodeCat 21:36, 2 August 2012 (UTC)Reply

Why not? When you move WT:Grease pit/timeline, you can check a box to make sure the subpages come along obediently as well. --Μετάknowledge^{discuss/deeds} 21:39, 2 August 2012 (UTC)Reply

But we don't want to overwrite the current Grease Pit page... —CodeCat 21:40, 2 August 2012 (UTC)Reply

@CodeCat: The moving-GP-first thing worked perfectly. All of the pages are now on my watchlist. Thanks. :-)   Re: talk-page: it may be best to just not move the talk-page. Note that talk-pages don't appear separately on watch-lists; to watch a given page is necessarily to watch its talk-page, and vice versa.   Re: "archive" naming scheme: I actually think we should continue the scheme whereby archived pages are named accordingly. As long as June is on WT:GP, it's fair game to contribute to those discussions, but once we remove it from WT:GP, it should be considered "archived", and the only way to add to those discussions should be to move them to the current month. But the archiving will be much smoother: we just rename to Wiktionary:Grease pit/2012/June — keeping the redirect — and add some boilerplate text on the top. All existing links to June discussions will still work fine, thanks to the redirect. —Ruakh_TALK 21:51, 2 August 2012 (UTC)Reply

The big advantage of the new approach though is that there is no need for archiving at all. In particular, we could allow old discussions to be continued or just leave them where they are. Is there an important reason why old discussions should be moved to a separate page, as opposed to kept as-is? If we really need a criterium to judge when a discussion is 'old', we can just go by what you said: a discussion is old if it no longer appears on the GP main page. —CodeCat 21:58, 2 August 2012 (UTC)Reply

Re: "there is no need for archiving at all": Sure there is. We still need to remove old months from WT:GP.   Re: "a discussion is old if it no longer appears on the GP main page": I don't think it's reasonable to expect people to keep track of which months are and are not on the main page. —Ruakh_TALK 22:16, 2 August 2012 (UTC)Reply

Even removing old months can be automated now, though! We could use code like this three times to always transclude three months: {{Wiktionary:Grease Pit/2012/{{#expr:{{CURRENTMONTH}}-1}}}} It would need to be extended a bit so that it handles the wraparound at the beginning of a year, but it's very feasible. :) —CodeCat 22:24, 2 August 2012 (UTC)Reply

Done! See WT:GP now! :) —CodeCat 22:59, 2 August 2012 (UTC)Reply

Now that the GP page no longer needs to be edited at all, should it be fully protected? —CodeCat 14:31, 3 August 2012 (UTC)Reply

Do we document somewhere what order we want interwiki-links to be in? Somehow I'd thought we put them in alphabetical order by prefix (so, e.g., fi: before fr:), but recently I've seen some indications otherwise. —Ruakh_TALK 01:40, 2 August 2012 (UTC)Reply

It seems certain pages have it alphabetised by language name (in English). --Μετάknowledge^{discuss/deeds} 01:42, 2 August 2012 (UTC)Reply

We really should, we have Help:Interwiki but no WT:Interwiki. I'd prefer alphabetical order by interwiki code (so nl is alphabetized as nl, not as Dutch nor as Nederlands). Mglovesfun (talk) 08:52, 2 August 2012 (UTC)Reply

Ordering them by order in the native name seems more user friendly, because then people looking for suomi will find it under S and not under F. —CodeCat 10:56, 2 August 2012 (UTC)Reply

But then the person organizing them needs to know not only that fi is Finnish, but that Finnish in Finnish is suomi. Moreover, how are you going to alphabetise non-Latin language names, like עברית, ελληνικά, or 한국어? --Μετάknowledge^{discuss/deeds} 16:16, 2 August 2012 (UTC)Reply

Well, they are already alphabetised according to m:Interwiki sorting order, and that seems to work fine, so why change it? —CodeCat 16:23, 2 August 2012 (UTC)Reply

Thanks for that link. If that page is accurate, then en.wikt does put them in alphabetical order by prefix. In that case, we should edit Help:Interwiki linking, because it currently implies otherwise. —Ruakh_TALK 17:18, 2 August 2012 (UTC)Reply

I believe Wikipedia uses a different order, because Finnish is listed under S at w:Finnish language. Maybe we should adopt the Wikipedia order if we haven't already? —CodeCat 17:21, 2 August 2012 (UTC)Reply

If the document you linked to is accurate, then the English Wikipedia uses the native-languagename ordering, which seems to mean that the links are sorted in approximately the order that you'd get if you transliterated each native name to English and then alphabetized them. —Ruakh_TALK 19:11, 2 August 2012 (UTC)Reply

I don't see how alphabetical order by language code helps our users, most of whom, I assume, don't know language codes. Unicode order by language name seems to me to make the most sense.​—msh210℠ (talk) 17:57, 2 August 2012 (UTC)Reply

I assume that most of our users don't know Unicode order, either. :-P   (In particular, I imagine that most users would find it counter-intuitive if Zeêuws preceded aragonés.) —Ruakh_TALK 19:11, 2 August 2012 (UTC)Reply

Ah, true; good point. So by Unicode order of the lowercase of the name then? (FWIW, personally, I'm all for displaying the names in English (this is English Wiktionary!) and putting them in English-alphabetical order. But I doubt that'll happen.)​—msh210℠ (talk) 19:44, 2 August 2012 (UTC)Reply

We currently use alphabetical order by native language name, please see water. Unicode order would mean all non-Latin languages be moved to the very bottom. That is painfully ugly. -- Liliana • 21:07, 2 August 2012 (UTC)Reply

Re: "We currently use alphabetical order by native language name": .   Re: "Unicode order would mean all non-Latin languages be moved to the very bottom: I'm certain that msh210 is aware of that, and I infer that he doesn't share your aesthetotactile judgment. (For that matter, I don't share your judgment, either.) It might help if you could add some less-subjective support to your view. —Ruakh_TALK 21:23, 2 August 2012 (UTC)Reply

Re "citation needed", see User:Interwicket/FL status -- Liliana • 03:26, 3 August 2012 (UTC)Reply

Oh, ha. I read that page before starting this discussion, but I couldn't figure out what the default sort order was for wikts that didn't have anything in the "notes" column. I didn't notice that en.wikt wasn't such a wikt. :-P   Next question (1): is that page correct?   Next question (2): what does sort alpha by language name mean? I mean, fine, you say it means "alphabetical order by native language name", but if that's true, then what does that mean? How do I determine whether a native language name in (say) Cyrillic script comes before a native language name in (say) Hebrew script? —Ruakh_TALK 12:50, 3 August 2012 (UTC)Reply

I think the list is pre-defined in the code (but I have absolutely no idea where it is). -- Liliana • 18:22, 4 August 2012 (UTC)Reply

Sorry for the late intervention. The interwiki order is alphabetic by language name. The actual order used for the English Wiktionary can be consulted at http://svn.wikimedia.org/viewvc/pywikipedia/trunk/pywikipedia/family.py?view=markup line 25 (variable self.alphabetic). Malafaya (talk) 12:42, 6 August 2012 (UTC)Reply

Thank you! :-D   —Ruakh_TALK 15:39, 6 August 2012 (UTC)Reply

I'm all for keeping the native names in order by prefix. Yes, we could choose to use the approximate order of English transcription that the English Wikipedia uses, but that's not going to be universal and will therefore cause problems for bots that add interwiki. The easiest for bots and editors is in order alphabetically by language code. That will also generate a consistent order across all Wiktionaries. I for one would hate to find that each Wiktionary was displaying the language names in their native language. It would mean that I'd first have to know their name for English in order to follow the link here. But if the "en" link always displays "English", then I can always find it. After all, who besides editors and bot users make much use of the interwikis on Wiktionary? Who comes to the English Wiktionary's entry on water and thinks, "Gee, I'd rather read about this English word in Finnish"? --EncycloPetey (talk) 21:45, 2 August 2012 (UTC)Reply

How does this affect bots, though? I don't see how... —CodeCat 21:59, 2 August 2012 (UTC)Reply

Where will a bot place the link if the order here is determined internally by approximate English transcription, but the bot is adding the same interwiki link across multiple Wiktionaries, and the order varies by Wiktionary? --EncycloPetey (talk) 22:03, 2 August 2012 (UTC)Reply

The order of the wikilinks within the page source code doesn't actually matter. The mediawiki configuration mentioned above causes the software to rearrange all the interwiki links into the given order, independent of the order in which they were given on the page. So we could (and IMO should) order the interwiki links within the page source by language code. —CodeCat 22:08, 2 August 2012 (UTC)Reply

It doesn't cause the software to display the links in the right order; it tells bots (and humans who care to look at it) what order to sort interwiki links in. If humans sort one way and bots sort another, the links will be out of order until the bot comes along and sorts them again. Then no one will ever know where to find anything, because there's no knowing whether the page you're looking at had its interwiki links last sorted by a human or a bot. —Angr 22:12, 2 August 2012 (UTC)Reply

I just tried it out and you're right... I'm rather surprised! In any case though, we can't rely on anything being 'universal'. Interwiki links are necessarily a point where different practices across Wiktionaries will clash. There isn't really much we can do about that. All we can do is choose what fits best for us. —CodeCat 22:17, 2 August 2012 (UTC)Reply

Well, I'm in favor of keeping the current alphabetical order by (virtual transliteration of) native name. Sorting by code benefits editors, not readers. —Angr 22:29, 2 August 2012 (UTC)Reply

As, as I pointed out above before this became sidetracked, I disagree with you on both issues. (1) We're not "keeping" anything because there is no current standard. Most editors I've seen add them alphabetically by ISO code. (2) Readers don't benefit from either order, because the interwikis on Wiktionary are used mostly by editors and not by readers. --EncycloPetey (talk) 22:38, 2 August 2012 (UTC)Reply

Even if readers use interwiki links less than editors do (and that seems like a pretty bold claim—why wouldn't they use them?), those readers who do use them will benefit from having them ordered by the words that actually appear in the list rather than by invisible language codes. It's far more intuitive for everyone, both editors and readers, to have a list in which Suomi appears between Српски / srpski and Svenska than one in which it appears between فارسی and Français. And I think there is a de-facto standard here: the way interwiki links are ordered on the Main page is the same as the way they're ordered on most other pages. I don't think there are really very many exceptions. —Angr 13:29, 4 August 2012 (UTC)Reply

This is currently set to 'Latn'. Is this a mistake or is there a reason why it is not set to 'Hani'? —CodeCat 17:03, 3 August 2012 (UTC)Reply

Ugh, changed, looks like a pure error to me. Mglovesfun (talk) 17:07, 3 August 2012 (UTC)Reply

It's not a "pure error", we have lots of entries for Min Nan words in Pe̍h-ōe-jī, which is a form of the Latin alphabet. We even have at least one Min Nan entry in Hiragana. Template:nan/script should be multiple choice, like Template:sh/script. —Angr 17:30, 3 August 2012 (UTC)Reply

But what is the actual official/canonical script for Min Nan? The multiple choice only affects what is shown on Category:Min Nan language, all of our other templates use the first choice as the default (and are overridden with sc=). —CodeCat 17:48, 3 August 2012 (UTC)Reply

See w:Written Hokkien (Hokkien being the most widely used dialect of Min Nan). Short answer: it doesn't have an official script, being primarily a spoken language. —Angr 21:30, 3 August 2012 (UTC)Reply

Oh that's interesting. Pe̍h-ōe-jī mixed with Chinese characters reminds me of Japanese Kanji mixed with Kana. :) Looking through our current Min Nan entries, it seems that most of our entries use Chinese characters, but some use Latin writing. So Hani is probably a sensible default. I don't know if that reflects the actual practice in writing, but at least it lets us get away without a sc= parameter most of the time. The second script should probably be {{Latinx}}, although I am not really sure how much that differs from regular Latin. —CodeCat 21:40, 3 August 2012 (UTC)Reply

How is POJ any different from Pinyin? Last time I checked, Chinese's script isn't set to Latn just due to the existence of Pinyin. -- Liliana • 20:41, 4 August 2012 (UTC)Reply

Pinyin is rarely used in running text intended for Mandarin speakers. POJ is used in running text intended for Min Nan speakers. Both the Min Nan Bible and the Min Nan Wikipedia, for example, are written in POJ. See w:Pe̍h-ōe-jī#Texts. The impression I get from the Wikipedia articles is that most people who write Min Nan at all, write it in POJ, although the majority of native speakers of Min Nan can't read POJ (but neither can they read Min Nan in any other writing system; all they can read is Mandarin in Hanzi). —Angr 21:08, 4 August 2012 (UTC)Reply

Could a bot maintain {also} templates by adding existing pages to them? And would anyone be willing to run this bot? I've always wondered about this but it wasn't really important to me because I could just search for a page with special characters by typing the name and hitting search and finding it in the results. But now that I've switched to Vector (I was feeling like a Luddite.) I'm automatically taken to the page without special characters if it exists. It often does.

I don't know anything about bots, but if you type "libro" in the search box and then scroll down to the bottom where it says "containing... libro" you'll be taken to the search results page. —Angr 21:50, 3 August 2012 (UTC)Reply

Thank you! I still think the bot is a good idea. Ultimateria (talk) 22:54, 3 August 2012 (UTC)Reply

I wanted to add to User:Mglovesfun/vector.css overrides so that {{nv-Latn}} and {{pjt-Latn}} have the same faults as {{Latn}}. But I don't know what those defaults are, as usually I check MediaWiki:Common.css but it doesn't list Latn at all. Mglovesfun (talk) 09:15, 4 August 2012 (UTC)Reply

Try font-family:inherit !important;. I'm not positive it works but it's by best guess. -- Liliana • 10:38, 4 August 2012 (UTC)Reply

Out of interest, why would it? It doesn't even mention any fonts. Mglovesfun (talk) 11:17, 4 August 2012 (UTC)Reply

The keyword inherit resets all font declarations, so your browser's defaults are used. -- Liliana • 11:19, 4 August 2012 (UTC)Reply

Not quite... it causes it to inherit the value from the HTML element that contains it. Which itself may be overridden, causing the inherited value to change too. —CodeCat 11:25, 4 August 2012 (UTC)Reply

But I don't want to reset all font declarations, just for nv-Latn and pjt-Latn. Mglovesfun (talk) 11:30, 4 August 2012 (UTC)Reply

I'd like the answer to this too. If you look at the history of User:Angr/vector.css for 8 July 2012 you'll see all my attempts to get Navajo to appear in the same font and at the same size as all other languages, with no success. —Angr 12:00, 4 August 2012 (UTC)Reply

Works for me. -- Liliana • 12:41, 4 August 2012 (UTC)Reply

That worked for me too. Thanks, Liliana! —Angr 12:51, 4 August 2012 (UTC)Reply

Hi all, finally I found out how these templates and the linking works :) I created two new templates out of old ones and appended v2 as I didn't want to break any existing bots/code code:

Demo link 1: User:SebastianHellmann/sandbox#English-visible

Demo link 2: User:SebastianHellmann/sandbox#English-invisible

Template 1: sensidv2: Template:senseidv2

Template 2: trans-topv2: Template:trans-topv2

Features are:

• Link is visible now at the definition number 2, which allows you to click on it and go right-click & copy
• Translations are perfectly aligned with definitions ;)

How it works:

• standard html anchors (or section links) such as this one to the next section
• User:Yair_rand made the blue css highlighting (don't know how he did it)

It finally seems to work smoothly. What do you think? ( By the way there is an over two year old discussion, about this with no working solution and no consensus back then. SebastianHellmann (talk) 08:14, 6 August 2012 (UTC)Reply

I don't understand how it would be helpful to have the translation tables link to the definitions. If the definition lines are to link to themselves, I don't think it would be best to do that by writing out a # followed by the full gloss. Maybe a small image would be better? --Yair rand (talk) 20:59, 9 August 2012 (UTC)Reply

I never thought about that. Don't get me wrong, I am not saying what I made is perfect (I removed the # already), I am just happy, I came that far ;) . An image would be better, but I couldn't figure out how to do that. I tried the following, however:

1. If you go to house and look at the translations, I tried to pick one and then find the definition for it as fast as possible. It worked well for some (when exactly the same words are used), but for example not for these: "archetypal structure of a human abode" (which might be 2 or 4 ?) and also "the theatre itself .

2. Here is another thing that didn't work so well for me: I went to the French house (in the sense of genre of music) ) added a gloss and then I tried to link it to the English: house (in the sense of genre of music). I was only able to do this, because I used the dev tool Firebug to find the id/gloss in the html. "Right click" -> "copy link" on a link like this also feels suboptimal, because, when you insert it and try to make a wiki link again you have to remove "http://en.wiktionary.orghttps://dictious.com/en/" . The easiest for me was to click on it and then copy it from the browser address bar, hence I added the visible links to the definition themselves (and everywhere else). SebastianHellmann (talk) 06:43, 10 August 2012 (UTC)Reply

Hello, I was wondering if anyone would mind if I archived the Etymology scriptorium discussions. There are conversations dating back to 2009 and the page is very long. It would be archived in the same format as the Beer parlour. Any comments? Riley Huntley (talk) 06:38, 6 August 2012 (UTC)Reply

The format of the ES has changed a lot, and I think that the old ones are transclusions, but whatever. Have fun. --Μετάknowledge^{discuss/deeds} 17:24, 6 August 2012 (UTC)Reply

The links in Wiktionary:Random page don’t work any more. User:Hippietrail's toolserver account at HTTP server at toolserver.org - [email protected] has expired after six months, but I don’t think Hippietrail is in a place where he can do anything about it. I believe that someone else got it going again about six months ago, but I don’t remember who it was. —Stephen ^(Talk) 11:03, 7 August 2012 (UTC)Reply

Could we make some kind of request to Wikimedia to have this feature hosted within Wiktionary itself? It seems to me that this is too valuable a feature to have it hosted externally. —CodeCat 11:06, 7 August 2012 (UTC)Reply

Hippietrail wrote at User talk:Hippietrail#Toolserver (2) that he believes the solution is more wiktionarians involved in it, so that when someone is gone, someone else can do it. He said he’s happy to mentor some volunteers. —Stephen ^(Talk) 20:58, 7 August 2012 (UTC)Reply

I don't know how to change the predefined block reasons... Can this be added? —CodeCat 20:25, 7 August 2012 (UTC)Reply

You mean edit warring? —Stephen ^(Talk) 21:00, 7 August 2012 (UTC)Reply

To Stephen: Yes, I do, sorry. —CodeCat 21:42, 7 August 2012 (UTC)Reply

Wouldn't either "Disruptive editing" or "Stupidity" cover edit warring? (God, I wish "Stupidity" were a reason for blocking at Wikipedia.) —Angr 21:46, 7 August 2012 (UTC)Reply

Re: "I don't know how": When you go to block a user, there's a link to "Edit block reasons". That link points to MediaWiki:Ipbreason-dropdown.
Re: adding 'edit warring': We don't actually have a rule against edit-warring, per se. That said, I'd like it if "Re-adding previously deleted entries" were generalized to something like "Re-adding invalid content".
—Ruakh_TALK 21:58, 7 August 2012 (UTC)Reply

Oh, there it is! Thank you! Disruptive editing is rather vague, and might be interpreted as an excuse, whereas edit warring is more objective. Stupidity is even worse, I never use it. —CodeCat 22:03, 7 August 2012 (UTC)Reply

Now that I found it, I wonder if there is any point in making a difference between 'spamming promotional material' and 'spamming links to external sites'. Aren't they the same in practice? —CodeCat 22:05, 7 August 2012 (UTC)Reply

It's possible to make a distinction between the two, but I don't think it's useful. Mglovesfun (talk) 22:19, 7 August 2012 (UTC)Reply

Second point, 'edit warring' always involves more than one person; you can't rage an edit war against yourself. Mglovesfun (talk) 22:20, 7 August 2012 (UTC)Reply

Sure stupidity sounds bad but it seems fair/appropriate IMO, in cases such as stupid kids inserting crap like penis jokes and attacks on peers. :p User: PalkiaX50 ^{talk to meh} 22:23, 7 August 2012 (UTC)Reply

Surely that can be called "Vandalism". —Angr 22:47, 7 August 2012 (UTC)Reply

I don't use "stupidity" often, but I have used it. It's not simply a question of whether such things can legitimately be described as "vandalism"; it's also the connotations associated with the word. Like it or not, there's a young population out there for whom a charge of "vandalism" is a badge to be worn proudly. Call it "stupidity" instead, and they're more likely to get the hint. Some kids will brag about the "vandalism" they did, but they won't brag about their "stupidity". The terminology is as preventative as it is descriptive. --EncycloPetey (talk) 01:15, 8 August 2012 (UTC)Reply

Edit warring, at least to me, is repeatedly undoing someone else's edits/reverts to 'force' particular information into or out of an entry, without engaging in discussion about the issue after being reverted. A user I just blocked for this had been reverted for the same thing by three different admins. —CodeCat 22:30, 7 August 2012 (UTC)Reply

Why can't you use the existing "disruptive edits"? There is nothing intrinsically wrong with repeated reversions (after all, the other person might be wrong!) except that they are disruptive, and debate would be better. Equinox ◑ 22:33, 7 August 2012 (UTC)Reply

{{DEFAULTSORT:αγαν}} sorts άγαν in Category:Greek adverbs under Ά instead of Α where it is wanted. Can {{el-adv}} be tweaked to achieve this, or must a sort argument be resorted to? thankyou, — Saltmarsh^{απάντηση} 05:16, 8 August 2012 (UTC)Reply

 Done. —Ruakh_TALK 05:29, 8 August 2012 (UTC)Reply

thank you -just like that! — Saltmarsh^{απάντηση} 15:23, 8 August 2012 (UTC)Reply

Having problems with Firefox so am now using Chrome. But of the three, only Firefox displays Gothic correctly. Why would that be? I have a Gothic font in my fonts folder so presumably just installing another one won't help. Mglovesfun (talk) 10:17, 10 August 2012 (UTC)Reply

Is the font you installed one of the fonts listed in MediaWiki:Common.css under .Goth ? —CodeCat 10:19, 10 August 2012 (UTC)Reply

Presumably, as that's the only source I use for looking up fonts. Maybe it's worth installing a second font as a 'backup'. Mglovesfun (talk) 10:21, 10 August 2012 (UTC)Reply

And now I have. In entries I can see Gothic, but as page titles such as in the recent changes, I can't! Mglovesfun (talk) 11:43, 11 August 2012 (UTC)Reply

Then it is probably working. Script templates don't work in page titles or recent changes. —CodeCat 11:48, 11 August 2012 (UTC)Reply

Then it seems that Firefox can handle Gothic when not wrapped up in {{Goth}} but IE and Chrome can't. Mglovesfun (talk) 14:20, 11 August 2012 (UTC)Reply

The {{Phnx}} template does not work for me (all I see is boxes) while Wikipedia's {{script|Phnx}} does work (it displays in the Aegean font). Can someone fix this? --WikiTiki89 (talk) 19:38, 12 August 2012 (UTC)Reply

Also now that I checked, Phoenician is missing from my Code2001 font. Any ideas why this might be? --WikiTiki89 (talk) 19:43, 12 August 2012 (UTC)Reply

I reinstalled Code2001 and it works now. But I still recommend adding more than just one font to the CSS (like Aegean). --WikiTiki89 (talk) 19:48, 12 August 2012 (UTC)Reply

I've now incorporated the font-list from w:Template:Script/Phoenician into that for {{Phnx}}: MediaWiki:Common.css?diff=17422947. —Ruakh_TALK 19:54, 12 August 2012 (UTC)Reply

1. Is it possible to assign parameter values within a template?

eg if x=100 then y=100 (where x and y are possible template parameters)

2. Or can a parameter value be assigned to a variable?

eg if x=100 then y=100 (where x is a possible template parameter and y is a variable created within the template)

— Saltmarsh^{απάντηση} 05:53, 14 August 2012 (UTC)Reply

Maybe I'm just being stupid, but I don't know what you mean, so my instinct is to say "yes". Can you give a concrete example (a template and the feature you wish it had)? Then I can see if it's doable. --Μετάknowledge^{discuss/deeds} 06:09, 14 August 2012 (UTC)Reply

Neither of those is possible, no; but you can achieve the effect of them by using a helper template, in the style of functional programming. Basically you have an "outer" template {{foobarbaz}} that's used directly in entries, and that does nothing but call an "inner" template {{foobarbaz/helper}} that's not used anywhere else. {{foobarbaz}} is responsible for organizing the parameters of {{foobarbaz/helper}} — in your example it would look something like {{foobarbaz/helper|...|y={{#ifeq:{{{x|}}}|100|100|{{{y|}}}}}|...}} — and {{foobarbaz/helper}} is responsible for generating the actual wikitext. —Ruakh_TALK 11:57, 14 August 2012 (UTC)Reply

Could anyone explain how this could be used? Mglovesfun (talk) 11:58, 14 August 2012 (UTC)Reply

Imagine you have two templates, called {{A}} and {{B}}. B is the actual template you want to create, but imagine you want to set a variable y inside that template. What you can do is pass every call to B to A instead, and then let A call B with the parameter y= set to whatever you want. —CodeCat 12:03, 14 August 2012 (UTC)Reply

• Thank you all.

• It was partially a theoretical question - the template user might use one of two possible parameter names x or y - because of (for example) second thoughts about the best name to be used for an argument. And was this possible without global changes to the "old" name. I can now visualise the use of a secondary template to achieve this.
• However - I think I shall introduce new templates ({{el-adj-comp}} and {{el-adj-absup}}) specifically for comparative etc degrees of comparison. Thank you again — Saltmarsh^{απάντηση} 04:54, 16 August 2012 (UTC)Reply

The "Nearby" list isn't working correctly any more. It only shows a few selected entries (possibly very old ones?): e.g. Sunday « swap « swop « synonym « thesaurus  » Thursday » trade » trade wind » Tuesday, no words in between these. Equinox ◑ 15:11, 14 August 2012 (UTC)Reply

The "random entry" feature had the same problem. Now seems to be fixed, though. Equinox ◑ 22:43, 6 December 2012 (UTC)Reply

Hello, would someone please edit Template:obsolete spelling of so it takes a "sort" parameter? ] needs to sort as "eadtrom" in Category:Irish obsolete forms, but it isn't. Thanks! —Angr 08:51, 15 August 2012 (UTC)Reply

Added. I still think we should find a better solution for sorting though... —CodeCat 13:44, 15 August 2012 (UTC)Reply

Can't argue with that! Mglovesfun (talk) 16:04, 15 August 2012 (UTC)Reply

What should I add to my userpage's *.css to display gender-period? Maro 22:25, 17 August 2012 (UTC)Reply

What is gender period? Mglovesfun (talk) 22:28, 17 August 2012 (UTC)Reply

A period (.) after the gender symbol (m, f, n). The period is currently not displayed by default. Maro 22:37, 17 August 2012 (UTC)Reply

Add the following:

.gender-period { display: inline }

--Μετάknowledge^{discuss/deeds} 00:27, 18 August 2012 (UTC)Reply

Thanks! Maro 21:56, 18 August 2012 (UTC)Reply

Similar question. Is there any way to turn off MediaWiki:Wikimedia-copyrightwarning notice?

.editpage-copywarn { display: none }

doesn't work. Maro

It's <div id="editpage-copywarn">, not <div class="editpage-copywarn">, so you need to use #editpage-copywarn { display: none }, not .editpage-copywarn { display: none }. —Ruakh_TALK 02:06, 19 August 2012 (UTC)Reply

Thank you! Maro 19:21, 19 August 2012 (UTC)Reply

I noticed that this user has added {{t}} (and t+, t- etc) to a lot of entries where it should really be {{term}} or {{l}}. These probably need fixing but there are a lot of them. Is there a way to find all these? Maybe someone with an XML bot can generate all instances of a translation template appearing outside a translation section? —CodeCat 10:27, 18 August 2012 (UTC)Reply

First, a terminological note: a "bot" is a program that interacts with the web-site (usually via the API) and makes changes — usually edits or page-creations, but sometimes page-moves, page-deletions, or the like. You mean something like "Maybe someone can write a program to analyze the XML dump and generate a list of pages where a translation template appears outside a translation section?".

But anyway, I've generated such a list, at Wiktionary:Todo/Translations templates outside translations sections (listed at Wiktionary:Todo). I've looked at several of the entries, and the problems are varied — in a few of them the problem is misuse of a translation-template, like in the cases you saw, but in one of them the problem was the lack of a ===Translations=== header, and in one case the translation-template was inside a <!-- ... --> comment so is arguably not really a problem — but regardless, the list is short enough that we might as well go through all of them. No need to separate out the one set of problems from the rest.

—Ruakh_TALK 03:16, 19 August 2012 (UTC)Reply

You call that short?? o.o —CodeCat 09:10, 19 August 2012 (UTC)Reply

I said short enough. There are less than four hundred items on the list, most of them can be handled quite quickly, and there's no time limit. —Ruakh_TALK 12:41, 19 August 2012 (UTC)Reply

The template {{he-noun}} currently does not support the g2 variable. The g variable compensates for this by accepting g=mf for nouns that can be either masculine or feminine. The problem is there is no way to indicate that something is masculine plural (m pl) or feminine plural (f pl). This is necessary for pluralia tantum and currently the workaround is to use the template {{head|he|noun}} instead but then there is no way to provide a construct state. Can someone who speaks fluent template please fix {{he-noun}}? --WikiTiki89 (talk) 12:14, 19 August 2012 (UTC)Reply

I oppose editing {{he-noun}} to add support for a g2= parameter; I don't think that's the right way to achieve what you actually want. —Ruakh_TALK 12:40, 19 August 2012 (UTC)Reply

I did not mean to add a g2 parameter. Only to provide some way to indicate a gender and plural at the same time. The best way I think is something like g=mp / g=fp by analogy to the existing g=mf. --WikiTiki89 (talk) 12:44, 19 August 2012 (UTC)Reply

I don't think that's the right what to achieve what you actually want, either. —Ruakh_TALK 12:46, 19 August 2012 (UTC)Reply

Well do you have any other suggestions? --WikiTiki89 (talk) 12:48, 19 August 2012 (UTC)Reply

Well, we have a template {{he-plural-noun}}. I'm a bit loath to recommend it, since its documentation seems contradictory — it says it's used "in entries for Hebrew plural-only nouns (pluralia tantum)", but then it has parameters sg and sgwv to support "the singular indefinite form" — but it still seems like a better bet than poking around in {{he-noun}}. —Ruakh_TALK 12:57, 19 August 2012 (UTC)Reply

Ok thanks, I wasn't aware of that one. --WikiTiki89 (talk) 13:00, 19 August 2012 (UTC)Reply

Problem: {{he-plural-noun}} does not support the dwv parameter. --WikiTiki89 (talk) 13:05, 19 August 2012 (UTC)Reply

Is there any bot-competent person around who would be interested in setting up a bot for inflections of Volapük nouns (and later verbs, if I can ever create a vo-conj template that doesn't scroll a mile to the right)? The three templates I'm looking at right now are {{vo-decl-adj}}, {{vo-decl-noun}}, and {{vo-decl-noun-np}}. The language is completely regular, just like Esperanto (whose verbs are currently auto-conjugated by user:MewBot), so there should never be errors in the inflected forms, as long as the root is spelled correctly.

In a similar vein I think we could also do with an Ido conj-bot (was discussed previously). Unfortunately my bot-writing skills are still about on the level of Luddite right now.

Any takers? Tempodivalse 21:51, 19 August 2012 (UTC)Reply

I sometimes slip up and write {{context|now|foobar}} in entries, and I've noticed other editors do it, too. When I pick up on it, I add _| after now|, as here, but I think it'd be helpful if someone could:

1. Create a WT:TODO cleanup list of entries which contain the context declaration |now| (or now|?) not immediately followed by a forced space (i.e. _|). (These entries display dated, now, offensive rather than the desired dated, now offensive.) And/or:
2. Cause context to automatically insert a space rather than a comma after 'now'. Is there really any circumstance under which it shouldn't? I suppose we might have some entries with a format like offensive now, previously acceptable, but those should be found and changed to the format previously acceptable, now offensive.

- -sche (discuss) 23:34, 19 August 2012 (UTC)Reply

If {{now}} was a context template, we could have it automatically add a space, like {{sometimes}} does, but Template:now is needed as the language code template for Nyambo, so it's not an option. --Yair rand (talk) 23:51, 19 August 2012 (UTC)Reply

Wiktionary:Todo/Now without space. It's a fairly short list, and mostly false positives, but I guess that's a good thing! —Ruakh_TALK 00:29, 20 August 2012 (UTC)Reply

@Yair: Ah, I wasn't sure if space-forcing could be done by {{context}} without recourse to {{now}}. Say, why doesn't {{context|now|dated}} display (Nyambo, dated), given that the content of {{now}} is Nyambo?

@Ruakh: Thanks! - -sche (discuss) 00:47, 20 August 2012 (UTC)Reply

Re: @me: You're welcome! Re: @Yair: {{context}} doesn't just check for the existence of Template:now, but also for the non-equivalence of {{now|sub=}} and {{now|sub=1}} (since a true context-template would give different results in those two cases). —Ruakh_TALK 01:15, 20 August 2012 (UTC)Reply

Ruakh is working on a complete redesign of the context templates, which would allow us to name the labels anything, including "now". —CodeCat 08:16, 20 August 2012 (UTC)Reply

Maybe all context templates should be subpages of {{context}}. That way they will be much easier to check for and won't have any naming conflicts with other templates. --WikiTiki89 (talk) 08:21, 20 August 2012 (UTC)Reply

That is one of the things he is doing, yes. The biggest issue with that right now is that a lot of context templates are called directly, rather than through {{context}}. If we move the templates, they will break unless we leave redirects. Actually, maybe we should do that now? *waits for Ruakh to join in* —CodeCat 08:32, 20 August 2012 (UTC)Reply

Yeah redirects are a good idea I'd say. Also, how does {{context|archaic|or|formal}} work if {{or}} is an unrelated template? --WikiTiki89 (talk) 14:01, 20 August 2012 (UTC)Reply

or is hardcoded (as are and, _, and ,). —Ruakh_TALK 14:26, 20 August 2012 (UTC)Reply

A rewrite? It might make sense to hold off on that until Lua becomes available, since it will probably need rewriting after that. (I'm not sure what the schedule is, but it's already been deployed to mw:, so I assume it's not that far away.) --Yair rand (talk) 10:51, 26 August 2012 (UTC)Reply

Do you think Lua will help with this? —Ruakh_TALK 20:35, 28 August 2012 (UTC)Reply

I'll right away snatch your rss as I can not in finding your email subscription hyperlink or newsletter service. Do you have any? Please permit me realize in order that I could subscribe. Thanks. — This unsigned comment was added by 176.222.198.94 (talk) at 03:45, 20 August 2012 (UTC).Reply

Just a question: for new family codes I've always tried to avoid codes which match language codes. However, this is causing a problem for one specific family, where every possible combination of letters is already used by language codes. Therefore I wanted to ask whether my behavior is supported by the community, or whether I should stop worrying and create family codes which conflict with language codes. -- Liliana • 17:54, 20 August 2012 (UTC)Reply

When we create new family codes, we normally prefix the first superfamily that has an ISO code, or we prefix qfa-. We can't create family codes that conflict with language codes, because many templates depend on them being unambiguous. But if you use the prefixing notation that we already use, it shouldn't be a problem. As a rule, all 2- and 3-letter codes must be valid ISO 639. —CodeCat 18:06, 20 August 2012 (UTC)Reply

Of course the prefix is added. I meant more like how {{etyl:poz-bnn}} could be confused with the unrelated language {{bnn}}. -- Liliana • 18:13, 20 August 2012 (UTC)Reply

{{es-verb form of}} allows its first unnamed parameter (or 1 or inf or verb or infinitive parameter — those are all synonyms in this template) to be passed to the template as ] or as apercibir. The difference in effect is that the latter causes the template to link to ] whereas the former causes it to link to ]. The template is frequently called with an argument like ]. These calls should be fixed so they call things like apercibir instead, so they link to the right section.

The same is true of {{fi-form of}}, except that the parameter in question is the first unnamed parameter (or 1, but no other synonyms). Striking this paragraph per discussion below.​—msh210℠ (talk) 15:19, 21 August 2012 (UTC) Reply

Could someone write a bot that will fix these, please? (Regex for the purpose is at User:Msh210/format.js, if that helps: search in the page for "correct language section".)​—msh210℠ (talk) 07:49, 21 August 2012 (UTC)Reply

I can definitely do unnamed parameters, picking up named parameters is trickier as they don't always appear in the same place. I bet I can do it though, if I take a bit of time. Mglovesfun (talk) 08:17, 21 August 2012 (UTC)Reply

Actually, AWB shuts off at 25,000 transclusions, forgot about that. {{es-verb form of}} has a lot more than that. Mglovesfun (talk) 08:26, 21 August 2012 (UTC)Reply

{{fi-form of}} is very different, it uses ifexist rather than {{isValidPageName}}, and it doesn't link to a language section. I assume it should do both of these. Mglovesfun (talk) 08:29, 21 August 2012 (UTC)Reply

If you are able to edit the template, you can cause it to add the entry to a category whenever it doesn't add the language section to the link. You can then use the category as a guide to what needs doing. —CodeCat 10:02, 21 August 2012 (UTC)Reply

Done — whenever the pages catch up with the edited template, and the category with the pages.​—msh210℠ (talk) 15:19, 21 August 2012 (UTC)Reply

"The following 200 pages are in this category, out of 198,804 total."​—msh210℠ (talk) 16:04, 21 August 2012 (UTC)Reply

I don't think that was really helpful. In order to actually fix those transclusions, a bot needs not only to find the entries, but also to find where in the entries the problem was. And once you write code to do that, then you can use the same code to find the entries from an XML dump. (A category would be helpful as a last step, after the vast majority of examples have been cleaned up, but until then I think it just gets in the way.) —Ruakh_TALK 17:22, 21 August 2012 (UTC)Reply

I wouldn't have thought it was helpful, either: I did it because someone half-asked for it.​—msh210℠ (talk) 20:57, 21 August 2012 (UTC)Reply

Ooh, you're right: {{fi-form of}} actually depends on existence of {{{1}}}, and adds suffix information to what's displayed if {{{1}}} doesn't exist: that shouldn't be bot-modified (except very carefully), as it'll change display. I'm striking that part of my request, above.​—msh210℠ (talk) 15:19, 21 August 2012 (UTC)Reply

Actually no... I cleaned up the template's code some, and the suffix part is entirely separate from {{{1}}}. —CodeCat 15:37, 21 August 2012 (UTC)Reply

...which changed the template's function. I trust you've checked every page it's transcluded on to be sure you didn't change anything on those pages?​—msh210℠ (talk) 15:58, 21 August 2012 (UTC)Reply

What did I change? —CodeCat 16:12, 21 August 2012 (UTC)Reply

If {{{1}}} did not exist — e.g., if it was ] with suffix foo attached and {{{suffix}}} was nonempty also — you've made the entry display — in the example — stem with suffix foo attached + the suffix foo.​—msh210℠ (talk) 16:18, 21 August 2012 (UTC)Reply

Why do you think I did that? —CodeCat 16:20, 21 August 2012 (UTC)Reply

Because I misread what you'd done! Sorry.​—msh210℠ (talk) 16:27, 21 August 2012 (UTC)Reply

Well, in theory you're right. Except that it was like that before I changed anything. —CodeCat 16:32, 21 August 2012 (UTC)Reply

If anyone can point me to an existing bot (perl, bash, JavaScript, or, I suppose, Python) that scans the dump for pages containing a given regex, or gets all pages in a given category, and edits them, please, then I'll be glad to modify it and do this myself.​—msh210℠ (talk) 20:45, 28 August 2012 (UTC)Reply

I've e-mailed you some Perl you can modify and use. —Ruakh_TALK 22:44, 28 August 2012 (UTC)Reply

Many thanks!​—msh210℠ (talk) 15:21, 29 August 2012 (UTC)Reply

Done fixing the entires. I've also re-edited the template so it doesn't populate category:es-verb form of with wikified parameter, and will delete the latter.​—msh210℠ (talk) 16:40, 4 September 2012 (UTC)Reply

Not terribly important (IMO), but: see Template talk:quote-news. - -sche (discuss) 07:50, 22 August 2012 (UTC)Reply

I have another bit of template breakage to report: see Template_talk:langcat. - -sche (discuss) 01:07, 23 August 2012 (UTC)Reply

We've been using this feature for three weeks now and most of the kinks have been worked out. I think the new system is very workable and hasn't really given any problems at all. Just one time when an admin edited the main GP page by accident, but there is an edit notice there now to warn unwary admins of that. So, do you think we could roll this out to Information Desk and Beer Parlour at the start of next month? —CodeCat 22:34, 23 August 2012 (UTC)Reply

Given that most of the kinks would only come up at the start of a month, and we haven't really had a start of a month yet, I think we should wait on this. —Ruakh_TALK 22:38, 23 August 2012 (UTC)Reply

I agree. Actually, not just at the start of the month, but also when people continue a previous month's discussion (whihc hasn't yet happened but will doubtless).​—msh210℠ (talk) 22:56, 23 August 2012 (UTC)Reply

I'm not sure about the ID. I think it might be better to keep the format there more newbie-friendly (and just archive more frequently than we do). --Μετάknowledge^{discuss/deeds} 00:05, 24 August 2012 (UTC)Reply

Is there anything to indicate that it may not be newbie friendly? As far as a user is concerned, they click to add a new discussion, post it, and it gets added to the correct page. To contribute to an existing discussion, they click edit, add their message, and save. They don't really have to do anything different. —CodeCat 00:55, 24 August 2012 (UTC)Reply

It's not what we've done, and I think that it may frustrate some of 'em. Again, I'm not sure, and with any luck we'll get feedback on it and find out. --Μετάknowledge^{discuss/deeds} 01:01, 24 August 2012 (UTC)Reply

@CodeCat: You seem to be assuming that everyone, including newbies, always adds new discussions by clicking the add-new-section link, and always contributes to existing discussions by clicking the edit-section link. I'm certain that that's not the case; I've seen many discussions started without an edit-summary of the form /* title */ new section, which is the only possible form of an edit-summary generated by the add-new-section link. (The edit-section link is harder to be so certain of, since it's theoretically possible that a user cleared out the "edit summary" field, but I'm reasonably confident that some users don't always use that, either.) —Ruakh_TALK 01:16, 24 August 2012 (UTC)Reply

Ok yes, that's true. To non-admins, that link will now be a 'view source' button. —CodeCat 01:21, 24 August 2012 (UTC)Reply

• The "comment" link at Wiktionary:Discussion rooms still goes to the main Grease pit page rather than to the current month's subpage. —Angr 01:27, 24 August 2012 (UTC)Reply

• Fixed, thanks! —Ruakh_TALK 02:00, 24 August 2012 (UTC)Reply

Well, I've made a complete ass of myself trying to add functionality for Luganda plurals (via {{lg-noun}} and {{lg-proper noun}}). I thought it would be easy, because plurals just look like abawala (almost the same format as English plurals). In any case, I would like an explanation of what I did wrong (or how to do it correctly, to look at it as glass half-full). The second best solution is that somebody does it for me, but I'd rather make this a learning opportunity. TIA --Μετάknowledge^{discuss/deeds} 06:27, 24 August 2012 (UTC)Reply

I would love to have some kind of documentation about how it works myself. I've wanted to change things before but was afraid to break things because I didn't know how it worked. —CodeCat 10:19, 24 August 2012 (UTC)Reply

Well, if nobody explains this to me, I will do my best, and hell may ensue. But at least we will know it was a preventable hell :) --Μετάknowledge^{discuss/deeds} 03:44, 25 August 2012 (UTC)Reply

Basically what you want to do is wrap the link in a span tag that has some basic data inside the class attribute for the script to deal with, such as language, type of form-of template to use, and extra info such as gender where applicable. For Luganda, if you just want a simple {{plural of}} line with nothing extra, you would use form-of plural-form-of lang-lg in the wrapping span's class. form-of is always required, afaik, as is specifying the language with lang-. plural can be replaced with numerous other options to specify the required template: diminutive, genitive, diminutive-plural, genitive-and-plural,plural-definite, plural-indefinite, singular-definite, vocative, singular-vocative, plural-vocative, third-person-singular, present-participle, simple-past, past-participle, simple-past-and-participle, present, past, infinitive, imperative, positive, comparative, superlative, exaggerated. Certain language-specific options also exist. Gender can be specified like so: gender-mf to set the gender to "mf". transliteration- and origin- (used to specify the displayed text in the link) work by the same syntax. --Yair rand (talk) 09:04, 26 August 2012 (UTC)Reply

If I search for 주세요 I get some hits but the infinitive 주다, where it shows up in the conjugation table is not among the hits. Does anyone know what is the problem, and how to overcome it? Matthias Buchmeier (talk) 13:02, 24 August 2012 (UTC)Reply

The search index is based on the wikitext, not on the final generated page-text, so it won't detect text that is generated by templates. I believe the only ways to overcome it are either to create an entry for the form, or else to make sure that the lemma entry's wikitext includes the form. —Ruakh_TALK 13:56, 24 August 2012 (UTC)Reply

While trying to figure out why many of the members of Category:Categories needing attention are so tagged, I noticed that a significant minority have an apostrophe in their category name. A quick check of what links to {{topic cat}} seems to verify that all categories that use topic cat and have an apostrophe are members of Categories needing attention. Is there a technical reason for this, and is there anything that can/should be done about it? Chuck Entz (talk) 00:38, 25 August 2012 (UTC)Reply

The technical reason is that {{PAGENAME}} generates &#39; (the HTML numeric-character-reference for the ASCII apostrophe) in all circumstances where you might have expected it to generate an apostrophe. (Similarly for double-quotes and ampersands.) The technical solution, ugly as it is, is to write e.g. {{topic cat|de|Tolkien's legendarium derivations}} rather than {{topic cat|de|Tolkien's legendarium derivations}}. —Ruakh_TALK 01:16, 25 August 2012 (UTC)Reply

Would it also be possible to change something in the template instead? —CodeCat 01:25, 25 August 2012 (UTC)Reply

Well, I didn't think so — hence my not suggesting one — but your question prompted me to dig a bit to make sure, and y'know what? It looks like the {{localurl:...}} parser-function (one of the standard magic words), unlike the {{urlencode:...}} parser-function (another one of the standard magic words), processes HTML character references before performing the URL encoding. (No one has ever accused MediaWiki of logical consistency!) So — yes. Currently, {{topic cat}} compares {{FULLPAGENAME}} to {{topic cat name|...}}; I think that if we change it to compare {{localurl:{{FULLPAGENAME}}}} to {{localurl:{{topic cat name|...}}}} instead, it will resolve this issue. —Ruakh_TALK 01:54, 25 August 2012 (UTC)Reply

I've been having some strange behaviour with templates and fonts. If I type {{recons|word|lang=en}} then the result is *word, and {{recons|word|lang=gem-pro}} gives *word. But if I type {{recons|word|lang=ine-bsl-pro}} I get *word. The two may look the same to you but they display differently to me; the first two display in the regular Wiktionary font, while the third uses a narrower font (probably Helvetica). If you use Special:ExpandTemplates you see there is no difference between them at all beside the language codes. So why is this happening? —CodeCat 12:49, 25 August 2012 (UTC)Reply

It sounds like the problem I was having at Wiktionary:Grease pit/2012/July#Odd displaying behavior of Latin-alphabet languages, except that I would be surprised if your browser recognizes Proto-Germanic as Western but not Proto-Balto-Slavic. I didn't think the people who wrote browser i18n software would consider protolanguages. —Angr 14:24, 25 August 2012 (UTC)Reply

Exactly, and the codes for proto-languages aren't even official, we just made them up. So why does gem-pro work, but not ine-bsl-pro? —CodeCat 14:26, 25 August 2012 (UTC)Reply

Maybe because gem is an official ISO 639-5 code and bsl isn't? Or because gem is recognized as Western but ine (which is also an official ISO 639-5 code) isn't? —Angr 14:40, 25 August 2012 (UTC)Reply

I have no idea. At first I suspected that it might be caused by having three parts to the language code instead of two, but *word using ine-pro also has the changed font. So maybe it is the ine- part. —CodeCat 18:21, 25 August 2012 (UTC)Reply

On a related note, when I view Swedish words here at English Wiktionary, they appear in my preferred font, but when I go over to Swedish Wiktionary, the whole damn site is in Arial instead of my preferred font. I really don't know how that happened. —Angr 00:51, 1 September 2012 (UTC)Reply

Word history: Abate, abluent, a-, abaction, ablepsy, a-, abnormous, aboriginality, Abderian, abandum, abiological, abnegator. My Spidey senses tell me this is far too long of a streak to be a coincidence. What's going on? Lesath (talk) 18:15, 25 August 2012 (UTC)Reply

It's random in alphabetical order. Good isn't it? :P —CodeCat 18:22, 25 August 2012 (UTC)Reply

I just tried it a few times, and though I did get a heck of a lot of ab- words, I also got "nonsense", "crow", "thesaurus", and "October". The common factor is that these are all pages that were created very early on, that is, they all have very low ID numbers. (Nonsense is page #59, crow is page #71, thesaurus is page #20, and October is page #119.) Similarly, a lot of ab- words have very low ID numbers, because of a massive alphabetical-order bot-import in December 2002 of entries from Webster's Revised Unabridged Dictionary (1913). —Ruakh_TALK 18:28, 25 August 2012 (UTC)Reply

I bet this relates to the thing I mentioned on Grease Pit the other day, where the "nearby" list only shows very old words (from early days of Wiktionary). Nobody has replied about that yet. Equinox ◑ 18:29, 25 August 2012 (UTC)Reply

I'm sure you're right. —Ruakh_TALK 18:42, 25 August 2012 (UTC)Reply

And people are noticing. (OTRS ticket 2012102610000356.) Can anything be done?​—msh210℠ (talk) 17:27, 30 October 2012 (UTC)Reply

It seems to be working again now (as of several days ago). The "nearby words" list is also working. Hurrah! Equinox ◑ 22:42, 6 December 2012 (UTC)Reply

I've started working on a bot to update {{t}}/{{t+}}/{{t-}}/{{tø}}, and in examining its first edits (to ]), I found that although the Kurdish Wiktionary doesn't have an entry titled فەرهەنگ, ku:فەرهەنگ is a redirect — a real HTTP redirect, 301 Moved Permanently, not just a MediaWiki redirect or JavaScript redirect — to ku:ferheng, which does exist. I don't know what's going on, and I don't know how the bot should handle it. I would just tell the bot to ignore ku.wikt for now, but the thing is, I don't know if there any other Wiktionaries that have similar behaviors, so ignoring ku.wikt might not fully bypass the issue.

Does anyone have any information and/or advice?

—Ruakh_TALK 20:38, 25 August 2012 (UTC)Reply

First of all, I want to thank you. We've needed this service for a while, and I'm really glad that you've volunteered. So, here's the story behind Kurdish: it's the Serbo-Croatian mess all over again. The Kurmanji dialect uses the Latin script and has a Wiktionary at ku.wikt; the Sorani dialect uses the Arab script and has a Wiktionary at ckb.wikt. We treat them as one language, although we have 'Kurmanji' and 'Sorani' nest under 'Kurdish' in translation sections. So you can use whatever solution you use for S-C. --Μετάknowledge^{discuss/deeds} 01:17, 26 August 2012 (UTC)Reply

Thanks for that information . . . unfortunately, it doesn't really explain what's going on at ku.wikt. From a technical standpoint, I mean. How does it happen that ku:فەرهەنگ is an HTTP 301 redirect to ku:ferheng? Should ku:فەرهەنگ be viewed as a redlink, or not? (Obviously the easiest thing for the bot is simply to say, "hey, ku.wikt doesn't have a page named فەرهەنگ, ergo, use {{t-}}". If people are O.K. with that, then I'm golden.) —Ruakh_TALK 02:18, 26 August 2012 (UTC)Reply

I can't answer that definitively. My educated guess is that way back in the birth of ku.wikt, they wanted it to be pan-dialectal, and that failed. When they settled on ku.wikt being Latn-only for UI & discussion, I think they somehow got the devs to mass-move stuff to Latin spellings, and that probably led to a redirect policy that differs greatly from ours. That's all conjecture, though, and I can't verify it because I hardly know any Kurdish (and I can't explain it technically, either). Personally, I'd rather the bot treat this as a {{t+}}, if that's possible. --Μετάknowledge^{discuss/deeds} 02:29, 26 August 2012 (UTC)Reply

Sorry, but you're not understanding what I'm saying. ku.wikt has some sort of technical feature that en.wikt does not; this is not just a policy difference, and they are not using "redirects" in the MediaWiki sense of that term. They are using HTTP 301 redirects, which is something that we do not have. —Ruakh_TALK 02:34, 26 August 2012 (UTC)Reply

I might be misunderstanding, but I don't think so. That feature is what prompted me to say that "I think they somehow got the devs to mass-move stuff". That is, I'm guessing that they didn't manage that themselves. As I said above, I can't explain any further than my guesses above. --Μετάknowledge^{discuss/deeds} 02:45, 26 August 2012 (UTC)Reply

I don't think there was any kind of mass-move. Or at least, if there was, it's not related to what I'm talking about. ku:فەرهەنگ never existed; it's possible that other pages used to exist in the Arabic script, and then were mass-moved to the Latin script (though I rather doubt it), but that doesn't explain ku:فەرهەنگ's magical HTTP 301 redirection to ku:ferheng. —Ruakh_TALK 02:50, 26 August 2012 (UTC)Reply

• Update: I've found a sliver of documentation on the relevant feature: mw:Writing systems, m:Automatic conversion between simplified and traditional Chinese, m:Wikipedias in multiple writing systems. So, for now I'll just ignore the Wiktionaries that have such automated conversion, until we figure out how they should really be handled. —Ruakh_TALK 02:47, 26 August 2012 (UTC)Reply

Maybe you could only just tell your bot to filter out entries in a given script when visiting a given site, i.e. don't check words in the Arabic script when visiting the ku site. I would guess their system would have to be sensitive to language codes, or they would be unable to properly cover Arabic, Urdu, Persian, etc, so you could probably narrow it down further to filtering specific language-code/script/site combinations. Chuck Entz (talk) 09:12, 26 August 2012 (UTC)Reply

Maybe I could, but I'd rather find out what actually needs to be done. :-/   —Ruakh_TALK 15:12, 26 August 2012 (UTC)Reply

I suggested something like this a while ago, but I'm back with a somewhat different and more technically specific proposal: can a bot be written that will create {{also}} links between any pagetitles which are identical except that one contains character(s) with diacritic(s) and the other contains the same character(s) but with different or no diacritic(s)? So, all pages which are identical except that one of them contains one of the characters oòóôõöøōŏőơǒǫǭǿȍȏȫȭȯȱṍṏṑṓọỏốồổỗộớờởỡợ and the other contains a different one of those characters should link to each other. This could be accomplished either by a bot using handmade strings of correspondences like the one I just wrote out (I'm happy to make such strings), or by the bot 'knowing' Unicode's names for the characters a-z, and equating with those characters any characters with a Unicode name of the form Latin Small Letter (with trailing space to prevent ᵺ "Latin Small Letter Th With Strikethrough" from being picked up as "Latin Small Letter T..."). That way, ] will be linked to and from ], etc. Bonus points if the bot also does this for Cyrillic Small Letters and Greek Small Letters. Even more points if the bot links o to ο to о. - -sche (discuss) 06:23, 26 August 2012 (UTC)Reply

It would very quickly run into cases where there are too many variants for the template (I suspect there would be more than a few). We would have to decide what we want it to do then. Chuck Entz (talk) 08:44, 26 August 2012 (UTC)Reply

It would have to learn to edit, and possibly to create Appendix:Variations of "foo" pages (not impossible, mind you, given our rigid structure). --Μετάknowledge^{discuss/deeds} 14:21, 26 August 2012 (UTC)Reply

Wasn't there a reason Robert Ullmann declined to add this functionality to autoformat or another bot? Can we define the character sets involved enough to do this reliably? 70.162.10.166 23:31, 27 August 2012 (UTC)Reply

Why don't we handle anagrams with templates?

I think the best way to handle anagrams is with a template. For example, on the page ], you could put {{anagrams|en|eimt}}. Which would put it in a hidden category such as ] and then display everything in the category. Then when you put the same template on ], ], and ], it would display all the anagrams automatically without the need for a bot to add them.

Is there any reason we don't do something like this? If not, shouldn't we? I would be willing to help write the template.

--WikiTiki89 (talk) 07:14, 26 August 2012 (UTC)Reply

The main problem I see is that the template doesn't work properly until you've put it in the other entries that are anagrams of the current one. That means you can't avoid the need for a bot. Also, in case you aren't already aware of this, templates can't produce those alphabetically-ordered strings from the page name- templates have no string functions. That means they have to be entered by hand or by bot. Add to that the fact that you'd be putting templates in a lot of entries that don't have anagrams, so they're nothing but overhead (though it would be a one-time thing if you substed them). It just seems to me like six of one thing, half a dozen of the other, but with extra template overhead. Chuck Entz (talk) 08:17, 26 August 2012 (UTC)Reply

Ok, I will concede that a bot will still be necessary. But this requires less boilerplate than the current system since there will only be one line to include all the anagrams. Of course this will only include anagrams that also have the template but this is only a problem at the start. If we have a bot convert all the current anagrams to the new system there won't be a problem. The advantages are that it is much easier to add a new word to an existing set of anagrams without updating every page. It just seems like a better way of organizing things since each page is responsible for adding just a template and not for adding every anagram. Also anagrams will be better formatted since the template will be able to use the language tag to determine the script, rather than bots just adding plain links like they seem to do now (although that can be fixed in other ways). Anagram bots wouldn't have to run as frequently to update anagrams since it will be much easier for a human editor to add the anagram template to a page that seems to need one. --WikiTiki89 (talk) 08:44, 26 August 2012 (UTC)Reply

Then we run into the age-old problem: and who will run the bot? --Μετάknowledge^{discuss/deeds} 14:33, 26 August 2012 (UTC)Reply

I can try. I've never run a bot before but I am a programmer and can probably figure it out if I knew where to start. --WikiTiki89 (talk) 19:21, 26 August 2012 (UTC)Reply

There seems to be a problem with tabbed languages when <references> doesn't have a trailing slash (as in <references/>). favela has a Romansch section that is invisible in the tabbed language layout (old). After adding the slash to the "references" tag the Romansch section is visible (new). Similarly in stabs (Swedish section). --MaEr (talk) 08:11, 26 August 2012 (UTC)Reply

It's not just tabbed languages- those of us without TL can't see that section either. I suspect, also, that any missing closing tag or system delimiter could do that. I remember a vandal screwing up the feedback page by typing <nowiki> in the feedback box, and another time when {{ without a }} in a comment near the top of the page caused no problems for months- until someone posted a comment containing }} without a {{, at which time three-quarters of the page disappeared. Chuck Entz (talk) 08:34, 26 August 2012 (UTC)Reply

Do we have anything that checks for this? It's the kind of "unexploded ordinance" that would be really wise to take care of ASAP. Chuck Entz (talk) 14:43, 26 August 2012 (UTC)Reply

Yeah, a TODO list of pages that either have <ref> without <references/> or that have <references> could be useful. Perhaps we could also set up an abuse-filter, similar to our semi-functional ref-no-references one, to catch and flag <references>? - -sche (discuss) 19:29, 26 August 2012 (UTC)Reply

Category:Pages with incorrect ref formatting? Mglovesfun (talk) 19:45, 26 August 2012 (UTC)Reply

As of the last database-dump, there were twenty-five pages containing <references>. I started "fixing" them (I'm putting "fixing" in quotes, because the pages I looked at didn't seem to be suffering any ill effects), but I ran into the complication that some people seem to be intentionally using this format:

<ref name="foo"/>
...
===References===
<references>
<ref name="foo">...</ref>
</references>

. I'm not sure how I feel about that format — I kind-of like it, and kind-of don't — but regardless, after I realized there was more than one such page, I didn't feel that I should unilaterally change them all.
—Ruakh_TALK 19:55, 26 August 2012 (UTC)Reply

By the way, if anyone's wondering — the twenty-five pages are ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ] · ]. I "fixed" the first four. —Ruakh_TALK 20:00, 26 August 2012 (UTC)Reply

favela's formatting did make the Romansch section invisible to me, as it did to Maer and Chuck, so that kind of formatting should definitely be changed. ]'s formatting doesn't seem to break the page (see my test addition of another language section), so I suppose we're left to weigh whether the risk of that format breaking things in the future is more or less bad than stifling people's freedom to choose to use that format would be. - -sche (discuss) 20:09, 26 August 2012 (UTC)Reply

I think ] should be changed: there's no risk to the current format there (the tag is properly closed, so it can't do any harm), but there's also no benefit to it. —Ruakh_TALK 20:47, 26 August 2012 (UTC)Reply

Um, same problem in 氷, right? The Japanese section is swallowing up everything after it for me in TL, but I can't seem to find the problem. --Μετάknowledge^{discuss/deeds} 04:18, 15 September 2012 (UTC)Reply

Not the same- I can see the rest of the page, unlike in the other case. Could it have something to do with the extreme length of the Japanese section? What is the last line you see? Chuck Entz (talk) 04:35, 15 September 2012 (UTC)Reply

Er, I was rather unclear. I can see everything, but every language after Japanese is on the Japanese tab instead of its own tab. --Μετάknowledge^{discuss/deeds} 04:46, 15 September 2012 (UTC)Reply

Oh yeah, and I tried null edit + purge to no avail. --Μετάknowledge^{discuss/deeds} 04:47, 15 September 2012 (UTC)Reply

I switched briefly to TL, and checked the behavior of the templates in the last section of the Japanese entry. I think you'll find that the entries in this list have the same problem. I'm guessing it has something to do with the div tag in {{ja-kref}}. Chuck Entz (talk) 05:52, 15 September 2012 (UTC)Reply

Thank you for identifying the template! The issue became obvious upon viewing the source — there was no </div>! I fixed it, and now all the entries look aright again. --Μετάknowledge^{discuss/deeds} 06:00, 15 September 2012 (UTC)Reply

I noticed a strange behavior when the result of an edit depends on itself. For example, after creating a page that links to another section of itself, since the page does not yet exist, the link still shows up as a redlink until the next edit of the page (even an edit with no changes). For example, see ] (unless someone already fixed it on that page). Another example is when an edit adds a page to a category and also displays everything in the category on the same page. The page will not list itself until the next saved edit (again, even one with no changes). Does anyone know why this happens and if there is a way to prevent it without the workaround of saving another edit with no changes? --WikiTiki89 (talk) 13:03, 26 August 2012 (UTC)Reply

Have you tried a browser reload/refresh? Chuck Entz (talk) 14:46, 26 August 2012 (UTC)Reply

It is not the cache because I can open the page on any computer and still see the redlink. --WikiTiki89 (talk) 19:20, 26 August 2012 (UTC)Reply

This also happens when you edit a template, and the documentation-page includes the template: the documentation will still exemplify the old version of the template. So far as I know, the only workaround is a null edit, as you say. —Ruakh_TALK 15:02, 26 August 2012 (UTC)Reply

Co-incidentally, I noticed this myself yesterday when I created Gutachten, the plural of which showed up as the redlink Gutachten. If you click the redlink, does it force recognition of the existence of the page to occur? - -sche (discuss) 19:25, 26 August 2012 (UTC)Reply

No it does not. It opens the redlink as if it were a read link, which redirects to the page itself, effectively refreshing the page and ignoring the # part of the link. As of now, ] still contains a redlink to istelf if you want to check it out. Just don't edit the page because I want to leave it like that for now so others can see what I'm talking about. --WikiTiki89 (talk) 20:07, 26 August 2012 (UTC)Reply

Yes, I see this sort of this all the time when I'm editing a new template and its documentation. My workaround solution is to build in an extra space in a non-display part of the template, create the documentation, create the template, then remove the extra space from the template to get everything to display the current version. It's not part of the cache, but is a "feature" of wiki. --EncycloPetey (talk) 02:20, 28 August 2012 (UTC)Reply

In neither Firefox nor Opera can I see anything on that page after the header "2008". The page ends there... even though in the page source, I see that it has archives going up to 2012. What's going on? I looked through the last several edits to the page, all of those old versions end with a big "2008", too, at least for me. - -sche (discuss) 01:54, 27 August 2012 (UTC)Reply

The main page-text really does end at the header for 2008; see The template Template:argwiktlink does not use the parameter(s):

text=Wiktionary:Beer parlour/timeline?action=edit

Please see Module:checkparams for help with this warning.Wiktionary:Beer_parlour_archives/headings?action=edit. (] transcludes ].) What you're seeing that goes up to 2012 is the right-hand sidebar. —Ruakh_TALK 02:00, 27 August 2012 (UTC)Reply

Aha! Well I feel silly now, lol. - -sche (discuss) 12:51, 29 August 2012 (UTC)Reply

Now that there is a list of entries that use {{t}} outside translation sections, would it be possible to have a list of entries that use {{proto}} and {{etyl}} outside an etymology section? —CodeCat 10:05, 27 August 2012 (UTC)Reply

You know how to program; why not try doing this yourself? You can use Wiktionary talk:Todo/Translations templates outside translations sections as a starting-point, and I'm happy to help. (The more people who know how to do this stuff, the better.) —Ruakh_TALK 12:35, 27 August 2012 (UTC)Reply

By the way, I see from w:User:CodeCat that you know Java, and don't know Perl. I think everyone should learn Perl, ;-)   but if you prefer, I can send you a Java version. (It's a lot slower, obviously, but it works.) Just e-mail me. —Ruakh_TALK 21:59, 27 August 2012 (UTC)Reply

Perl makes no sense to me... it's so terse with so many implied meanings that I can never understand just what is going on in the code and why. Writing it may be easy but reading it... no thank you! And presumably other people think that too otherwise everyone would use it. :) I prefer Python because it seems cleaner and stricter to me (and I actually learned Python by making my bot). —CodeCat 22:12, 27 August 2012 (UTC)Reply

Perl code is sometimes described as "write-only" (a joke originally, I believe, applied to APL), but I really don't have a problem reading it. But regardless, I'm not going to write a Python version, so I think your options are (1) my Perl version, (2) my Java version, (3) your own version in whatever language you want. —Ruakh_TALK 23:25, 27 August 2012 (UTC)Reply

At least I can understand Java, so I might be able to change it into Python. But the interface to Wiktionary is probably very different. —CodeCat 00:23, 28 August 2012 (UTC)Reply

There's not really an "interface" for XML dumps; you just download them, from http://dumps.wikimedia.org/backup-index.html. (Suddenly I understand why you asked about an "XML bot" that one time; I didn't realize that you didn't know how to get the dumps.) —Ruakh_TALK 01:03, 28 August 2012 (UTC)Reply

Generated this list. Most of the uses of etyl seem to be in entries for given names- I can probably filter these out tomorrow if you'd like them in a separate list. NadandoBot (talk) 02:43, 28 August 2012 (UTC)Reply

In User:Mglovesfun/sandbox (current version as of this date), I've done something a lot like that; click edit or diff and you'll see how. Mglovesfun (talk) 11:41, 29 August 2012 (UTC)Reply

I believe we discussed adding this code to {{t}}, {{t+}} and {{t-}} some time ago, and I seem to think I proposed two changes at the same time, it all got confusing. So I'm proposing just this change this time. Actually, I would propose that without the namespace check; no harm in checking other namespaces, and it avoids and #ifeq: call. Thoughts? Mglovesfun (talk) 16:06, 27 August 2012 (UTC)Reply

I have no strong opinion about this change, but FYI, you can — if you want — avoid the #ifeq: call while retaining the namespace check, by writing {{#if:{{NAMESPACE}}{{{1|}}}||]}}{{#if:{{NAMESPACE}}{{{2|}}}||]}}. —Ruakh_TALK 17:00, 27 August 2012 (UTC)Reply

There are other templates which need parameters where similar checks could apply; {{gloss}}, {{qualifier}} and {{sense}} are three prime examples where a first unnamed parameter is always needed, but not checked for. Mglovesfun (talk) 19:51, 27 August 2012 (UTC)Reply

I suppose an argument against this is that {{t}} is so widely used any change to it would create a long job queue, but... that's what the queue is for, isn't it? And this will be helpful going forward, if it catches mistakenly empty uses. Support. - -sche (discuss) 20:15, 28 August 2012 (UTC)Reply

I, too, have no strong opinions either way about this, but if we're to implement it, we should make it visible in the page using CSS, as we do for {{attention}}, q.v., since there can be very many translations in a page.​—msh210℠ (talk) 20:26, 28 August 2012 (UTC)Reply

Good point, one of the problem pages was language, as you can imagine, I didn't find the problem straight away! Mglovesfun (talk) 20:39, 28 August 2012 (UTC)Reply

If this is added to {{t}}, could it also be added to {{l}} and {{onym}}? They all work more or less the same way after all. —CodeCat 20:43, 28 August 2012 (UTC)Reply

I've written some code to automatically update the above categories (reads the category structure then scans the dump for valid pages to update, making sure to get the live version of the page first). You can see my test edits in the most recent contributions of NadandoBot. Any objections to moving forward with the rest of the edits? DTLHS (talk) 01:57, 29 August 2012 (UTC)Reply

No objections from me. --Μετάknowledge^{discuss/deeds} 02:32, 29 August 2012 (UTC)Reply

 Raifʻhār Doremítzwr made prolific (mis)use of Unicode modifier letters as ordinals. In the old discussion about Using modifier letters for superscripts, consensus came out solidly against using modifier letters for such things; a number of editors were also of the opinion that ordinals should not be marked with any extraneous letters at all (so, 1 August rather than 1st August). A large number of pages still contain 1ˢᵗ, 2ⁿᵈ, 3ʳᵈ, 4ᵗʰ, etc, however. So... would someone with AWB care to start changing those modifiers to regular letters, <sup>-superscript letters, or nothing, as appropriate? - -sche (discuss) 12:49, 29 August 2012 (UTC)Reply

Can someone who speaks template add the ability to add multiple genders to {{yi-noun}}, I'm tired of putting alternate genders in usage notes. --WikiTiki89 (talk) 15:18, 30 August 2012 (UTC)Reply

Done. Also, the template allows the specification of script (sc=), but that doesn't seem necessary, inasmuch as Yiddish is always written in Hebr. I'd have removed it while I was editing the template anyway, but I was afraid that maybe somewhere the template's used with sc specified (and not Hebr), and such an edit would ruin that entry. So... if someone can confirm that this template is never used with sc= (and not sc=Hebr), I think we can edit out that bit.​—msh210℠ (talk) 15:54, 30 August 2012 (UTC)Reply

Actually, I've just checked the list of pages that transclude yi-noun, and every non-userspace page that does so is an Hebr-titled one. That's enough circumstantial evidence IMO to get rid of the sc. Anyone disagree?​—msh210℠ (talk) 16:12, 30 August 2012 (UTC)Reply

Totally agree! Mglovesfun (talk) 17:13, 30 August 2012 (UTC)Reply

I honestly don't see the point in removing it. It doesn't hurt to leave the option in there in the case of some unforeseen circumstance (but then again, you can always just use {{head|yi|noun}} in that case). --WikiTiki89 (talk) 17:18, 30 August 2012 (UTC)Reply

Would you want sc= in {{en-noun}}? Mglovesfun (talk) 17:19, 30 August 2012 (UTC)Reply

The difference is that considerably more people write Yiddish in Latin script than those who write English in anything other than Latin script, although Latin script for Yiddish has never been standard and probably does not need to be included as entries in a dictionary. But there could conceivably be an unforeseen reason to do so in the future. --WikiTiki89 (talk) 18:36, 30 August 2012 (UTC)Reply

(Re "considerably more people write Yiddish in Latin script than those who write English in anything other than Latin script", that's probably not true. But it probably is true as a percentage of all those who write Yiddish/English respectively. In any event...) We've not allowed Latn Yiddish entries in the past: they've been deleted or converted to Hebr. If we consider it at all likely that that policy will change, then I agree we shouldn't edit the template. Otherwise, I see no harm in doing so (and see benefit in simplifying the template (and maybe in speed? I don't know)).​—msh210℠ (talk) 19:57, 30 August 2012 (UTC)Reply

Ok, here's what I think. Personally, I wouldn't do it. But if you want to, go ahead. --WikiTiki89 (talk) 20:00, 30 August 2012 (UTC)Reply

It would be nice to create Wiktionary:About Yiddish to document this sort of issue. For example, when/where does Yiddish use the Latin script? Mglovesfun (talk) 20:33, 30 August 2012 (UTC)Reply

Well, I have in front of me at the moment a Yiddish translation of Der Struwwelpeter →ISBN that uses Latin script (YIVO standard transliteration) in the main body of the book and includes the Hebrew script only in an appendix at the back. —Angr 10:35, 15 September 2012 (UTC)Reply

Yeah but I would think that a book like that is not intended for native Yiddish speakers. --WikiTiki89 (talk) 10:43, 15 September 2012 (UTC)Reply

No, but so what? —Angr 10:49, 15 September 2012 (UTC)Reply

The template {{suffixsee}} is not very kind to other scripts. It does not use the language code to determine which script to display the words in. And if you specify the script, it also shows the link to the category (which is mostly in Latn) in the script you specified. Can/should this be fixed? ({{prefixsee}} and {{circumfixsee}} may also have the same problems.) --WikiTiki89 (talk) 11:15, 31 August 2012 (UTC)Reply

{{deriv}} controls all three of these templates. I believe {{langscript}} can be used to automatically provide the script. If the second problem can be fixed it would be through MediaWiki:Common.css under the "/* formats derived terms */" section. DTLHS (talk) 00:32, 1 September 2012 (UTC)Reply