This template was deleted and the code was deprecated in favour of {{cel-gau}}. But we still have {{etyl:xtg}}, which categorises in Category:English terms derived from Transalpine Gaulish. And that category goes in Category:Terms derived from Transalpine Gaulish. Normally, that category would go in Category:Transalpine Gaulish language, but it doesn't work right because there is no template for that code. —CodeCat 13:16, 2 July 2011 (UTC)

Can't it accept etyl:xtg as the code? Mglovesfun (talk) 14:19, 2 July 2011 (UTC)

I don't think it was meant to be that way. I'm sure Ruakh would complain. :P But I've tried it and it doesn't work in any case. —CodeCat 10:40, 3 July 2011 (UTC)

I'm confused then, what is the problem? Surely the same is true for {{etyl:hbo}} and the like. Mglovesfun (talk) 10:49, 3 July 2011 (UTC)

And the same problem exists for that, too. Currently, Category:Terms derived from Transalpine Gaulish, Category:Terms derived from Classical Hebrew, Category:Terms derived from Late Latin and several others are not in a category themselves, because there is no 'language' category that they could be put in. —CodeCat 10:58, 3 July 2011 (UTC)

Could someone who knows how to fix it, please do so? —Ruakh_TALK 13:52, 2 July 2011 (UTC)

{{derivcatboiler}} tries to add this to ], which works about as well as you might expect. I've created {{etyl:hbo/family}}, in the hopes that it might be trying that first before defaulting to {{hbo/family}}, but no dice. Can someone fix this who knows how? —Ruakh_TALK 14:13, 2 July 2011 (UTC)

Etymology templates don't have family subtemplates yet, because they weren't part of the vote. For them, we still use {{langfamily}}, and {{family}} for families themselves. —CodeCat 14:27, 2 July 2011 (UTC)

So, can you fix {{derivcatboiler}}? —Ruakh_TALK 16:20, 2 July 2011 (UTC)

It doesn't need to be fixed, unless the consensus is that etymology templates should have a family subtemplate as well. I think that would be a good idea myself. Until then, I've added Classical Hebrew to {{langfamily}}. —CodeCat 16:27, 2 July 2011 (UTC)

Thanks! —Ruakh_TALK 14:19, 4 July 2011 (UTC)

Hello! Would anyone be interested in setting up a bot to run Ido verb inflections? Relevant table is at Template:io-conj. Ido is quite a regular language, so there should be no problems with exceptions etc. Thanks! Tempodivalse 00:57, 3 July 2011 (UTC)

SemperBlottoBot could do this and also for Esperanto. Semper's shied away from it as he doesn't know either language, but you are of course correct; it doesn't matter when the language in question has NO irregular forms. Mglovesfun (talk) 10:38, 3 July 2011 (UTC)

As far as I know, Ido is very similar to Esperanto. Are there any significant differences, other than the different endings, three infinitives and the perfect? I could probably just copy most of the Esperanto bot but I would need to be sure. —CodeCat 10:39, 3 July 2011 (UTC)

Good things rarely come from someone unfamiliar with a language being the primary generator of entries in that language. Even with few or no irregular forms there are other issues to consider, like the propagation of typos or other errors. I would hope that unless there is someone who is versed in Ido willing to work closely with the bot operator, they would not run a bot blind. - DaveRoss 14:29, 3 July 2011 (UTC)

Ido is indeed close to Esperanto, especially in terms of conjugation. It is mutually intelligible for a proficient Esperantist, and Ido's "improvements" (*chuckle*) take only a few minutes to learn. There are a few small differences in the endings, which are already correctly reflected in the template. I'm not aware of anything else that's different. As long as the template's correct, all verb forms created from it should be correct too. I've written many Ido entries (and even one 3-sentence article for the Ido Wikipedia), so I consider myself mostly competent enough to guide the bot through conjugation. I don't think we have any other Ido speakers around (not counting Razorflame). Tempodivalse 15:34, 3 July 2011 (UTC)

Could you give me an example of a verb that's already fully conjugated and has all the entries already created? Then I can use them as an example for the bot. —CodeCat 22:10, 3 July 2011 (UTC)

I don't think there is one, yet - not since I added some conjugations to the table. I will create one soon. (BTW, how does the new template look? Template:io-conj. I'm not very experienced with wiki-tables so some things were a little simplified.) Tempodivalse 22:13, 3 July 2011 (UTC)

User:Razorflame used to run a bot for autocreating Ido verb inflections. See Special:PrefixIndex/User:Darkicebot/io. --Yair rand 00:02, 4 July 2011 (UTC)

Creating a new bot shouldn't be very hard. MewBot (my bot) can already do Esperanto verbs, and it should be easy to adapt it a little so that it can do Ido verbs as well. —CodeCat 00:12, 4 July 2011 (UTC)

Fully conjugated example: devastar. Is that satisfactory? Tempodivalse 01:12, 4 July 2011 (UTC)

It looks like all the inflection entries are exactly the same? How does it know which form it is? —CodeCat 01:18, 4 July 2011 (UTC)

See Template:io-form of. The template looks at the part of the word that's not in the root and ascribes a grammatical description based on what it sees. Tempodivalse 01:30, 4 July 2011 (UTC)

This is the message I get when AutoWikiBrowser (AWB) skips some pages. Beats me what it means and why it has to skip such pages; it's skipping them when the replacement is possible. Mglovesfun (talk) 10:30, 3 July 2011 (UTC)

Such pages should not exist, methinks. List the skipped pages somewhere so I can check them out. -- Prince Kassad 12:24, 3 July 2011 (UTC)

From memory, head, like and slay. --Mglovesfun (talk) 11:04, 5 July 2011 (UTC)

All of those had old Egyptian translation entries which hadn't been fixed yet. I've done so to remove the illegal characters. -- Liliana • 19:05, 6 July 2011 (UTC)

Most recent one was roast. Mglovesfun (talk) 22:19, 13 July 2011 (UTC)

Fixed that one as well -- Liliana • 04:42, 14 July 2011 (UTC)

Wiktionary:TODO/pages with PUA characters has all pages with PUA characters from the Basic Multilingual Plane. I wasn't able to search for the two PUA blocks outside the BMP, as I couldn't get it to work with my regex engine. --Bequw → τ 04:05, 15 July 2011 (UTC)

Romanian entries have been left with cedilla characters for a couple of months. I have written a python script that replaces all cedillas with commas in Romanian entries. The script does not touch etymologies though, for there is always a possibility that a Turkish word with ş is modified. Please see the script in User:Flubot/cedillaBot and Special:Contributions/Flubot and tell me if there is any other thought or objection. See also User_talk:Mglovesfun#Romanian_crap. --flyax 21:19, 3 July 2011 (UTC)

You could allow it to change etymologies if the word appears inside {{term|...|lang=ro}}, or following {{etyl|ro|...}}. —CodeCat 21:33, 3 July 2011 (UTC)

OK, I'll see if I can do it. In the meantime I am editing Romanian verb forms (no etymology section). --flyax 21:59, 3 July 2011 (UTC)

There is a new version of the script that skips a line with "Turkish" or "etyl|tr" or "term|...|lang=tr" but changes instances of "term|....|lang=ro". See ascuți. --flyax 10:51, 4 July 2011 (UTC)

I've written a second script (User:Flubot/cedilla2Bot) that changes cedillas to commas in Romanian words found

1. in lines beginning with * Romanian: or {{ttbc|ro}}
2. inside {{term|...|lang=ro}}, {{l|ro|...}} and {{t|ro|...}} templates. --flyax 10:33, 5 July 2011 (UTC)

I noticed there are quite a few topical categories that don't use the {{topic cat}} template. Is there any way to find all of them easily? —CodeCat 13:32, 5 July 2011 (UTC)

Wiktionary:Todo/missing topic cat Nadando 19:05, 5 July 2011 (UTC)

Thank you! —CodeCat 19:21, 5 July 2011 (UTC)

Was there ever a vote that made {{topic cat}} mandatory? If not, I assume that good judgment will ensure that no content will be removed in the course of such cleanup operation. DCDuring TALK 19:35, 5 July 2011 (UTC)

Topic cat's purpose is to categorise and to provide descriptions that are consistent across the different languages. It also helps with keeping track of which topical categories there are, since all topics are now added to Category:List of topics. The descriptions can easily be copied into the description that the template uses, so nothing needs to be lost. —CodeCat 19:44, 5 July 2011 (UTC)

Is the operation by which arbitrary text can be added, edited, or deleted to an individual page fully documented and obvious to any potential contributor? Do such changes appear immediately? Does the procedure conform to the general procedures common to this wiki? To other wikis in the MediaWiki family? DCDuring TALK 20:51, 5 July 2011 (UTC)

I don't know, I didn't design it. o.o —CodeCat 20:52, 5 July 2011 (UTC)

• In my opinion, the answer to all these questions is mostly "no". The sole exception is that, if someone is brave enough to make a change, the change will be apparent. Use of this approach facilitates standardization and may have value in creating and maintaining categories from some list (approved by whom?) for all possible languages, but otherwise violates wiki spirit. DCDuring TALK 21:02, 5 July 2011 (UTC)
  • Yes, the mechanics of {{topic cat}} are rather obscure. However, I have the impression that people are used to creating and editing subtemplates such as Template:topic cat parents/Greek mythology. --Daniel 21:09, 5 July 2011 (UTC)

• I think you have the wrong impression. Personally, I almost never bother with the topic-cat stuff, because it's too opaque for me. I find it very unfortunate that the derivation categories now use it, too, because now they're something else for me not to bother with. The good news is that when stuff breaks, I know whom to bug, because only one editor is likely to have changed it. —Ruakh_TALK 21:28, 5 July 2011 (UTC)

No, you have it backwards... the recent derivation category change means they no longer use the topic cat structure. Nadando 21:31, 5 July 2011 (UTC)

Hmm, you're right, I was thinking of {{catboiler}}. (I had a problem with one of them, and the auto-generated documentation at {{derivcatboiler}} is wrong; and apparently no one knows how to fix it.) I don't understand the topic cat stuff, either, but at least for derivations categories it was workable. Thanks for the correction. —Ruakh_TALK 22:54, 5 July 2011 (UTC)

I asked Daniel about changing the documentation, I think the automatic documentation doesn't really work so well. —CodeCat 22:57, 5 July 2011 (UTC)

Do you think it doesn't work well just for {{derivcatboiler}} and {{famcatboiler}}, or other templates as well? I already said that these two templates have many flaws that could be fixed relatively easily by recreating them from scratch. (rather than trying to adapt complex code of metatemplates to work for them when certain "#if" and "#switch" conditions are met) --Daniel 23:14, 5 July 2011 (UTC)

The changes I made to {{catboiler}} for those templates are actually fairly small. Most of the important work is done by {{derivcatboiler/ALL}}, and catboiler only needed to be adjusted to use it. —CodeCat 23:33, 5 July 2011 (UTC)

I didn't say you made big changes to {{catboiler}}; I said other things. In fact, if most of the important work is done by {{derivcatboiler/ALL}}, then you already got a separate template. The problem is that your separate template is difficult to edit, because it apparently goes out of its way to transclude {{catboiler}}. --Daniel 08:24, 6 July 2011 (UTC)

There is a new template, {{famcatboiler}}, which can be used to create categories for language families. It has only one parameter, which is the code of the language family. —CodeCat 19:23, 5 July 2011 (UTC)

Prince Kassad is going to be happy about that. --Daniel 19:25, 5 July 2011 (UTC)

To allow those not good at IPA (eg, me) to help in possibly inserting true pronunciation sections in our entries for initialisms, would it be possible to have a template that converted the initials in the Latin/Roman alphabet to IPA (eg, {{initpron|G|E}} would yield {{IPAchar|/dʒiːiː/}}? DCDuring TALK 17:47, 6 July 2011 (UTC)

How is this?

IPA^(key): /eɪ biː siː diː iː ɛf d͡ʒiː eɪt͡ʃ aɪ/

IPA^(key): /d͡ʒeɪ keɪ ɛl ɛm ɛn əʊ piː kjuː ɑː(ɹ)/

IPA^(key): /ɛs tiː juː viː dʌb.əl.juː ɛks waɪ zɛd/

IPA^(key): /əʊ wʌn tuː θɹiː fɔː(ɹ) faɪv sɪks sɛv.ən eɪt naɪn/

And in Dutch:

IPA^(key): /aː beː seː deː eː ɛf ɣeː ɦaː i/

IPA^(key): /jeː kaː ɛl ɛm ɛn oː peː ky ɛr/

IPA^(key): /ɛs teː y veː ʋeː iks ɛi̯ zɛt/

IPA^(key): /nʏl eːn tʋeː dri viːr vɛi̯f zɛs zeː.və(n) ɑxt neː.ɣə(n)/

—CodeCat 18:11, 6 July 2011 (UTC)

I like it. --Daniel 18:31, 6 July 2011 (UTC)

How does this deal with US/UK differences? I'm thinking of the letter Z here. -- Liliana • 18:32, 6 July 2011 (UTC)

Each language has its own subtemplate, the one for English is {{IPA letters/en}}. You could create {{IPA letters/en-US}} and so on if you want to. —CodeCat 18:43, 6 July 2011 (UTC)

For initialisms, you should definitely separate the syllables in English. Leaving out stress is probably OK, although there are initialisms where the stress makes a difference like in /ˌjuˈɛn/. Also, American English does not recognize vowel-length, and some vowel sounds are different in different regional dialects (e.g. UK & US). You can't call the English template "English", because there's too much regional variation for that. Also, your renderings for w is incorrect for all varieties of English. --EncycloPetey 18:56, 6 July 2011 (UTC)

The template as it is now is really just a proof of concept. Feel free to adjust it as necessary. :) —CodeCat 19:01, 6 July 2011 (UTC)

Now that's what I call responsiveness. DCDuring TALK 19:10, 6 July 2011 (UTC)

I've separated the letters now but I'm not sure if the way Msh210 has chosen to indicate stress is really the most practical. —CodeCat 19:24, 6 July 2011 (UTC)

For the English letter names with one than one syllable, I've added syllable separators. --EncycloPetey 19:28, 6 July 2011 (UTC)

• See ADR for an example of deployment of the template and the enabled alternative entry scheme for members of Category:English initialisms. DCDuring TALK 23:24, 7 July 2011 (UTC)

Microsoft removed support in IE9 for auto-detection or discovery of opensearch providers. It must have been a security problem for Microsoft. This feature removal is another example of why I think that web developers have been depreciating Internet Explorer. Of course, I can install a Wiktionary search provider the old fashioned way, but then I don't get any search suggestions.

In the Internet Explorer add-on gallery, there's an accelerator for Wiktionary, but no search provider. There's also an article that explains the way search providers are listed in the registry, but that just seems messy to me, and I'd rather install from an xml file. We should be able to get search suggestions for Wiktionary in any browser, right from the search bar. Does anybody have a workaround for this, other than editing the registry? ~ heyzeuss 08:17, 11 July 2011 (UTC)

Opensearch behavior in Firefox. The tooltip shows the URL of the description file. ~ heyzeuss 20:51, 19 July 2011 (UTC)

Hello, I noted that Wiktionary still uses the template "Click", especially on its main page. The MediaWiki syntax now supports this behaviour natively: ] becomes an image link to the main page. I was wondering if someone could replace the only remaining usage within template:sisterprojects, because it's under cascading protection. Thanks, --The Evil IP address 16:36, 11 July 2011 (UTC)

Awesome, thanks for pointing this out! I've changed {{click}} to use that native behavior — which makes it trivially subst:-friendly — and subst:ed it at {{sisterprojects}}. —Ruakh_TALK 16:57, 11 July 2011 (UTC)

It seems that link can be anything, even an external URL like this: ]. So one could hide the URL of some malware-site behind a wiktionary image.

Is this really necessary? Does anyone check if these links point to a server one can trust? --MaEr 18:04, 11 July 2011 (UTC)

It doesn't look like this is going through the spam blacklist, so probably not. Nadando 18:35, 11 July 2011 (UTC)

I don't know what you mean. I just logged out and tried to add ]], and it got rejected. —Ruakh_TALK 18:47, 11 July 2011 (UTC)

This shouldn't be an issue as the sister projects template is protected and can only be edited by admins. --The Evil IP address 19:23, 11 July 2011 (UTC)

The {{pt-noun}} template isn't working as intended here, because it uses plural= instead of just a second unnamed parameter. I'm not sure why my most recent edit hasn't solved the problem; thoughts? Mglovesfun (talk) 21:06, 13 July 2011 (UTC)

I think the job queue is broken, so your template change didn't propagate to the entry. I went to http://en.wiktionary.orghttps://dictious.com/en/confusão?action=edit and clicked "Save page" (without making any changes), and now it shows up right. —Ruakh_TALK 21:08, 13 July 2011 (UTC)

Actually, none of the accellerated templates were working for me the last time I was editing, even with templates that haven't been recently edited. There may be something bigger causing this issue. --EncycloPetey 21:13, 13 July 2011 (UTC)

There have been some changes in the past few months, I had to update User:Mglovesfun/vector.js to get WT:ACCEL to work. Mglovesfun (talk) 21:15, 13 July 2011 (UTC)

No good. I've followed the instructions at WT:ACCEL and accelerated termplates still aren't working for me. --EncycloPetey 16:19, 14 July 2011 (UTC)

Oddly, English plurals (from en-noun) seem to work, but Spanish and Galician do not. -EncycloPetey 17:09, 14 July 2011 (UTC)

I just enabled the gadget to display flags next to the language names in the headers and noticed that it doesn't display a flag for Luxembourgish entries. Is there any reason for this? Cheers, BigDom 09:57, 14 July 2011 (UTC)

File:Flag of Luxembourg.svg is now displayed for Luxembourgish entries. --Yair rand 10:04, 14 July 2011 (UTC)

Thanks, it works now. BigDom 10:05, 14 July 2011 (UTC)

Hi. The Wikibooks has the best InterWiki horizontal template - b:Template:Associated Wikimedia. Is there useful group template (horizontal or vertical) in Wiktionary? Could you please create a new template similar as the b:Template:Associated Wikimedia template? --Averaver 15:55, 19 July 2011 (UTC)

For use where and under what circumstances?​—msh210℠ (talk) 18:11, 19 July 2011 (UTC)

Also: I don't like that template, as it (seems to AFAICT) use CSS to hide unwanted stuff instead of omitting it.​—msh210℠ (talk) 18:20, 19 July 2011 (UTC)

I've fixed that issue there. I don't know what Averaver (talk • contribs) has in mind for it, but I think it might be useful at language- and/or topic-category pages. (We already have something similar at language categories.) —Ruakh_TALK 19:15, 19 July 2011 (UTC)

Possible places for that template - language and Category:Languages and similar. --Averaver 03:20, 20 July 2011 (UTC)

I don't think ] is a good place for it, since that page is about words spelled <language>, not about any specific topic called "language". We generally include Wikipedia-links, for people who want to cross the boundary from "word" to "topic", and of course we have our topic-category hierarchy that people can navigate into; but individual entries don't usually have huge numbers of links to the topic-oriented projects, and by and large I think that's a good thing. —Ruakh_TALK 17:03, 20 July 2011 (UTC)

+1 (what Ruakh said).​—msh210℠ (talk) 17:25, 20 July 2011 (UTC)

Then I'll agree as well. --Mglovesfun (talk) 20:50, 20 July 2011 (UTC)

Can I request an update. Have pretty much got as far with this as I can, I'd just like the list regenerated to check for any I've messed up and any new ones since the last regeneration. --Mglovesfun (talk) 21:16, 20 July 2011 (UTC)

The latest XML dump is from June 19th. (See http://dumps.wikimedia.org/backup-index.html.) I don't know what the story is; but it's pointless to regenerate the list based on data that are more than a month old. Sorry. —Ruakh_TALK 23:02, 21 July 2011 (UTC)

Too true. Mglovesfun (talk) 23:12, 21 July 2011 (UTC)

This gives me time to mention the current parameters exclude a lot of cases I think we'd like to fix. For example a lot of the entries in Category:Italian apocopic forms or some given names categories in xxx male given names, but not xxx proper nouns. Also alternative forms, and so on and so on. --Mglovesfun (talk) 10:35, 23 July 2011 (UTC)

I can handle that sort of request — I already disregard "... derivations" as a special case of category-that-doesn't-count (though actually that one's obsolete now, isn't it?), so I can certainly add "... alternative forms" and so on, but I need a precise list of categories that don't count. Alternatively, I need a list of categories (or of category regexes) that do count, if that's easier. —Ruakh_TALK 01:39, 25 July 2011 (UTC)

Re: original request:  Done —Ruakh_TALK 01:39, 25 July 2011 (UTC)

Can someone generate a cleanup list for all instances where this template is called without including any arguments/parameters? I've noticed that there are a host of pages now that have the bare template as the only component of the headword line. --EncycloPetey 22:38, 21 July 2011 (UTC)

It should be possible to edit the template such that it categorizes the entry into a cleanup category when no parameters are present. Nadando 23:01, 21 July 2011 (UTC)

Anyway, here's the list (more than a month old, as Ruakh pointed out above). Nadando 23:20, 21 July 2011 (UTC)

I've updated that list, I hope you don't mind. As you can see, it now occurs on many more entries, especially ones that look like Pilcrow's sort of entry (e.g., containing ligatures or diacritics). —Ruakh_TALK 01:54, 25 July 2011 (UTC)

Pilcrow uses it that way. When I first saw him do it, I was going to object on his talk page until I realized I didn't know what I was object to. Using infl on it's own just displays a bold headword. Using {{infl|en}} (or whatever language) has become quite fashionable, as the infl template automatically checks for script when a language is present. Mglovesfun (talk) 23:14, 21 July 2011 (UTC)

I think a language-code should always be specified, because our generated HTML should indicate the language: {{infl|fr}}, for example, produces <b xml:lang="fr" lang="fr">...</b>, which indicates to browsers and other "user agents" that ... is in French. (Not a big deal for most users, but — for example — users with screen-readers probably want to hear /pɛ̃/ rather than /peɪnz/.) —Ruakh_TALK 23:42, 21 July 2011 (UTC)

How do the browser and user agents handle entries with only the straight-text inflection line, like most inflected forms of English nouns, verbs, etc? Should all of those inflection lines be replaced with {{infl|en}}? DCDuring TALK 00:41, 22 July 2011 (UTC)

Currently that generates <b xml:lang="{{{1}}}" lang="{{{1}}}">...</b>, which is not exactly standards-compliant. How a user agent might handle it is anyone's guess; I assume that most user agents would either treat it the same as <b>...</b> (meaning "inherit the language from the surrounding context", and therefore, in our case, meaning "English"), or else treat it the same as <b xml:lang="" lang="">...</b> (meaning "we are explicitly not indicating any language — not English, not anything else"). But of course, there's nothing stopping us from changing bare {{infl}} to generate something more sensible — either to assume English by default, or else to explicitly not indicate a language. In the latter case we'd want users to use {{infl|en}} in English sections, reserving {{infl}} for things such as Translingual musical symbols that really aren't in a language. (Personally I'd prefer the latter approach, but the assume-English-by-default approach is definitely an option.) —Ruakh_TALK 01:06, 22 July 2011 (UTC)

An inflection line in an English section at ] that was, say, '''homes''' would generate all that? DCDuring TALK 01:32, 22 July 2011 (UTC)

Oh! Oops, sorry, no. I misunderstood your question. (I didn't read it carefully enough, apparently.) No, '''homes''' generates just <b>homes</b>, which inherits its language (English) from the surrounding context. Sorry about that! —Ruakh_TALK 10:57, 22 July 2011 (UTC)

OK. How does the common situation of a template-free inflection line differ from that of {{infl}} with no arguments in how it is treated by browsers and other user agents? Is there some benefit to changing to "{{infl|en}}". Or enough benefit to make a change worthwhile? DCDuring TALK 11:46, 22 July 2011 (UTC)

I think the common situation of a template-free inflection line is just fine. We might prefer {{infl|en}} for consistency's sake (or, we might not), but the generated HTML is just peachy. The current generated HTML for {{infl}} is problematic, though. (It's the thing that generates <b xml:lang="{{{1}}}" lang="{{{1}}}">homes</b> that I somehow decided you were asking about above.) —Ruakh_TALK 12:43, 22 July 2011 (UTC) Update: Yair rand has changed {{infl}} to generate <b class="None" xml:lang="" lang="">homes</b> . —Ruakh_TALK 21:35, 28 July 2011 (UTC)

I would prefer {{infl|en}} because it's easier to do search and replace on it. There is no easy way to search for the page title in AWB. —CodeCat 10:41, 23 July 2011 (UTC)

Looking at this edition of my sandbox, {{l}} automatically provides script support for Khmer, but {{term}} and {{infl}} do not. If I try the same thing for Ancient Greek, it works perfectly. Huh? Mglovesfun (talk) 13:00, 24 July 2011 (UTC)

{{l}} requires that a language be specified, so it simply uses the language's script template if no sc= is specified. {{term}} and even {{infl}} do not, so they still use {{Xyzy}}; see #Xyzy and infl above (or here once it's been archived). I think we should fix {{Xyzy}} to support all languages, but as you can see, no one replied. I didn't want to make the change without at least one person agreeing with me . . . —Ruakh_TALK 19:16, 24 July 2011 (UTC)

I would agree with such a change. {{l}} also uses {{Xyzy}}, though. —CodeCat 19:25, 24 July 2011 (UTC)

Re: the change: Cool. I've written a new version, with a page of test-cases (not yet unit-test-ified): User:Ruakh/Template?action=edit and User talk:Ruakh/Template. Please take a look. (That goes for anyone else reading this, too, by the way.)
Re: {{l}}: I don't know what you mean. You edited it a month ago to no longer use {{Xyzy}}. Is there something subtle going on, or are you just misremembering?
—Ruakh_TALK 20:34, 24 July 2011 (UTC)

Whatever works, to be honest! --Mglovesfun (talk) 20:35, 24 July 2011 (UTC)

Yeah, changing Xyzy to just call the script subpage is an excellent idea, since we now have them. -- Liliana • 20:42, 24 July 2011 (UTC)

Does it really need to support being given template-parameter cruft as lang? --Yair rand 20:42, 24 July 2011 (UTC)

I don't know. There are currently entries that call {{infl}} with no parameters, and currently {{infl}} produces {{Xyzy|{{PAGENAME}}|face=head|lang={{{1}}}}} when that happens. Obviously, we could easily fix {{infl}} to use lang={{{1|}}} before changing {{Xyzy}}; but I don't know what other templates are likely to have similar problems. —Ruakh_TALK 20:59, 24 July 2011 (UTC)

 Done a few days ago, and nothing seems to have broken. (Note: Yair rand has changed the behavior of bare {{infl}}, but I ended up using a more general approach that didn't specifically check for template-parameter cruft, anyway.) —Ruakh_TALK 21:20, 28 July 2011 (UTC)

I'm working on some fun and complicated verb conjugation template ideas, and it's becoming increasingly clear that I'll need to do some simple string processing if I'm going to make this work. From all I've read so far, there's apparently some very strong resistance among the Witkionary powers-that-be to ever enabling the StringFunctions extension. Looking for alternatives, I ran across a number of useful workaround templates that reproduce a lot of the basics that I need, over at w:Category:String_manipulation_templates. This leads me to my questions:

1. I can't seem to figure out how to call a Wikipedia template from Wiktionary. I've read conflicting documentation stating that interwiki template calls are / are not possible. Could someone here elucidate?
2. If interwiki calls are a non-option, would anyone object to me copying the pages included in w:Category:String_manipulation_templates over to Wiktionary?

Looking forward to your collective wisdom, -- Eiríkr Útlendi | Tala við mig 19:30, 25 July 2011 (UTC)

Cross-wiki template transclusion is not possible. The ENWP string-manipulation templates were imported and later deleted. --Yair rand 19:39, 25 July 2011 (UTC)

Cross-wiki template transclusion is not possible -- thanks for confirming that. Now I just need to find where I read that it is supposed to be possible and fix that errant page.  :)

What's "ENWP"? If it's shorthand for "English Wikipedia" and you mean the same "String_manipulation_templates" category, do you happen to know why they were deleted? Would anyone object to re-adding them? If so, for what reasons? Even very rudimentary string processing would be enormously useful, so I'm quite puzzled as to why this functionality is missing... -- Eiríkr Útlendi | Tala við mig 19:51, 25 July 2011 (UTC)

Yes, he means that category. See (e.g.) Template talk:str find for an archived copy of the discussion that led to the deletions. —Ruakh_TALK 20:06, 25 July 2011 (UTC)

Thank you very much, Ruakh, that clarifies things substantially. I note you mentioned that it's considered likely that a significant subset of its functions will eventually be incorporated into the ParserFunctions extension -- is there any roadmap or timetable covering when this might happen, and/or what steps would be needed to make this a possibility? -- Eiríkr Útlendi | Tala við mig 20:19, 25 July 2011 (UTC)

That's happened already, but there's a dedicated config option called $wgPFEnableStringFunctions to control whether those functions are enabled, and that option is decisively set to false. (I now think that Yair's comment, the one that I was replying to and disagreeing with, was correct, though I haven't been able to find where the decisive statement was made.) —Ruakh_TALK 20:48, 25 July 2011 (UTC)

Hmm, see mw:Special:Code/MediaWiki/51497, where Tim Starling (now, and probably then, WMF's Lead Platform Architect) provided this documentation for the $wgPFEnableStringFunctions option:

Enable string functions.

Set this to true if you want your users to be able to implement their own parsers in the ugliest, most inefficient programming language known to man: MediaWiki wikitext with ParserFunctions.

WARNING: enabling this may have an adverse impact on the sanity of your users. An alternative, saner solution for embedding complex text processing in MediaWiki templates can be found at: http://www.mediawiki.orghttps://dictious.com/en/Extension:Lua

Which was actually quite a long time ago; my comment that you quoted was well out of date even when I posted it.
—Ruakh_TALK 21:01, 25 July 2011 (UTC)

Given the description of how processor-intensive the wikitext-based string functions are, I'm not surprised that the admins are loath to enable them here. But the indicated alternative of mw:Extension:Lua, although very attractive, seems to likewise be out of reach and unavailable here on Wiktionary. Testing with {{#luaexpr: something}} and <lua>...code...</lua> both fail to do anything Lua-ish. I'm hoping I'm wrong and Lua is in fact enabled? -- Eiríkr Útlendi | Tala við mig 21:46, 25 July 2011 (UTC)

From what I understand, the Lua extension will never be enabled on WMF projects, because WMF does not want our mirrors to have to install Lua. (Currently, you could theoretically mirror a wiki on shared hosting space, but the Lua extension generally requires more permissions than that.) Tim Starling's comment was directed at sysadmins of other MediaWiki wikis, not at editors within WMF.
Also, from what I understand, the wikitext-based string functions themselves really aren't all that processor-intensive, but just as Wikipedians have created hideously expensive rudimentary string-manipulation functions based on the padding functions, the devs are concerned that they would create hideously expensive rudimentary regular-expression functions based on any string-manipulation functions. (I haven't seen Tim Starling, specifically, make that claim anywhere, but other devs have made such comments in associated Bugzilla tickets.)
—Ruakh_TALK 22:02, 25 July 2011 (UTC)

By the way, this line of discussion is probably not going to be fruitful. A more productive prompt: what is it that you are trying to do? Are you certain that it depends on expensive string-manipulation functionality that we do not have, or is it something that we can (try to) help you implement a different way? —Ruakh_TALK 22:06, 25 July 2011 (UTC)

Thanks again, Ruakh, I'd just reached that conclusion myself (i.e. time to change tack). The main things I need to be able to do:

• Supply a top-level template with a series of arguments, such as a verb stem, which modes the verb uses, conjunct prefixes (multiple possible), disjunct prefixes (multiple possible), etc.
• For each verb mode, which I'm so far implementing as a second tier of sub-templates, build the relevant verb forms. This necessitates checking the first and last characters of certain arguments in order to apply the appropriate sound shifts.

For the multiple possible values for certain arguments, I'd considered using explode or something similar to break a string like "val1 val2 val3" into its constituents, but since this is unavailable and since there will be fewer than half a dozen values given at once, I can work around this by just using named arguments such as "conj-pref-1" "conj-pref-2" etc.

Thinking it through, I might be able to use heyzeuss's / Yair Rand's clever approach to {{Template:str len}} (described here) for the first and last character problem. I've never done anything with {{subst:}} before though, so that presents a new challenge. Are there any bad gotchas with using {{subst:}} in sub-templates? -- Eiríkr Útlendi | Tala við mig 22:24, 25 July 2011 (UTC)

You can use subst inside a template itself, once, but it will disappear after that. Then it will leave hard text in its place, and no longer transclude the other template. It is something you would do if you wanted to edit a large group of templates. Otherwise, you can nest templates in a regular entry all you want, even with subst. You'll have to give it a try to see what it really does. This is an expression that I used to remove the last two letters from a page name, courtesy of Yair rand:

{{subst:padright:|{{subst:#expr:{{subst:str len|{{subst:PAGENAME}}}}-2}}|{{subst:PAGENAME}}}}

~ heyzeuss 09:25, 26 July 2011 (UTC)

Thanks heyzeuss. I don't suppose you or anyone else knows a way to do something slightly different -- not to leave off the last character, but to get the last character? More something like {{Template:lastchar|a string}} returning just the g? It seems the only wiki way to do it is ugly brute-forcing like we see in w:Template:Str index. I may just have to come up with some alternate. -- Eiríkr Útlendi | Tala við mig 23:52, 26 July 2011 (UTC)

I italicized the last part of "Category:English words suffixed with -ness". See its last revision.

Rationale: That's how text is formatted by {{term}} and {{suffix}}. Italic.

What do you think? Should this be done for all categories of English morphemes? --Daniel 03:50, 26 July 2011 (UTC)

That sounds like a Beer-parlour question rather than a Grease-pit question, no? —Ruakh_TALK 13:38, 26 July 2011 (UTC)

Can the {{suffixcat}} template be changed so that it does that? —CodeCat 15:39, 26 July 2011 (UTC)

Yes. --Daniel 11:43, 29 July 2011 (UTC)

It seems perfect for BP: A good idea that should easily get community support, possibly without even needing a vote. The BP discussion will undoubtedly surface some complaints about certain character sets not taking italics well, possibly some of which haven't been heard before. It may surface other issues. The process seems essential to get the job done right, minimizing after-the-fact corrections such as trouble many changes that seem like good ideas to some. DCDuring TALK 16:29, 26 July 2011 (UTC)

OK. I opened a BP conversation. --Daniel 11:43, 29 July 2011 (UTC)

Suddenly all the links on the site are being capitalised and some of them redirect to Wikipedia instead of Wiktionary. Every page on the wiki seems broken now! What's going on? —CodeCat 12:28, 27 July 2011 (UTC)

• Also, new entries get added with a capital first letter. SemperBlotto 12:31, 27 July 2011 (UTC)

And templates don't seem to work sometimes. -Bequw

The same thing is happening on Italian (and all other?) Wiktionary. SemperBlotto 12:35, 27 July 2011 (UTC)

The Grease Pit is called Wikipedia:Grease pit now, as well... —CodeCat 12:36, 27 July 2011 (UTC)

Anyone on IRC report our problem? Get news about cause? DCDuring TALK 12:37, 27 July 2011 (UTC)

There seems to be a discussion on #wikimedia-tech. –Matěj Grabovský 12:41, 27 July 2011 (UTC)

And the Main Page has disappeared.... Ƿidsiþ 12:38, 27 July 2011 (UTC)

It's still there but it's called Wikipedia:Main page now. —CodeCat 12:40, 27 July 2011 (UTC)

In my computer, I see "Wikipedia:Grease pit", but "Wiktionary:Main Page".

When I edit this discussion, above the edit box, there is a red link "Template:Editnotice load".

The edit tools (the list of characters, such as "Acute: Á á Ć ć É é ǵ ...") are broken, too: There is "REDIRECT" unexpectedly written there. --Daniel 13:09, 27 July 2011 (UTC)

Seems to be back to normal now. Will we ever know what happened? SemperBlotto 13:24, 27 July 2011 (UTC)

Wikipedia was also experiencing problems. Must have been something to do with the Wikimedia servers. —Stephen ^(Talk) 13:34, 27 July 2011 (UTC)

I couldn't even get to this page to make a comment. Mglovesfun (talk) 17:49, 27 July 2011 (UTC)

Is there any code to "unlink" a linked text?

For example, typing {{unlink|]}} to return foo. --Daniel 18:58, 28 July 2011 (UTC)

Nope. --Yair rand 18:59, 28 July 2011 (UTC)

Would be a good idea, especially a substable one. For example, we avoid links in use examples (usexes) and translation glosses; a template that removes square brackets would be ideal. --Mglovesfun (talk) 10:55, 9 August 2011 (UTC)

How can someone change a noun that is said to be uncountable but one of the definitions is not uncountable, for example on the 64th note page?

— This unsigned comment was added by Celloplayer115 (talk • contribs) at 17:25, 30 July 2011 (UTC).

I have fixed the entry. Thanks! —Ruakh_TALK 18:38, 30 July 2011 (UTC)

I have been trying to reduce the number of entries in Category:English terms needing attention. Mostly entries are there that should be in other places and would be if they had more specific tags (rfp, etystub, rfe, rfc-sense, etc). In some cases Tea Room or the entry Talk page would be better.

In some cases, I am at a loss to determine why an item is in the category. See D. Even if I have made a dumb error in this case, failing to find something obvious, it would be handy to have documentation for each maintenance category that indicates what templates or conditions lead to membership. Any thoughts on how that could be achieved for existing templates etc? Is there a Special page that provides the information? Does one need to process the Template space XML dump? DCDuring TALK 17:44, 30 July 2011 (UTC)

I don't know about the general case, but in the specific case of ], I think that templates shouldn't add that category directly, but rather should use {{attention|xx|explanation}}. Formerly, adding the category directly was preferable, because of the way {{#if:...}} and so on used to work (they used to always evaluate/expand all of their arguments, and then choose which one to return, whereas now they only evaluate/expand whichever one should be returned, making them more like conditional expressions in regular programming languages), but nowadays there is no disadvantage to using {{attention}} conditionally, and there are three advantages:

• Logged-in readers with almost any modern browser can, by adding something like .attentionseeking:before { content: "\A0\FFFD"; color: red; } to Special:MyPage/common.css, cause {{attention}} to appear visibly on the page. (In that example \A0\FFFD + red shows up as " �" — a no-break space followed by a generic "replacement character" — other people might prefer something like .attentionseeking:before { content: "\A0 attention needed here"; font-size: .8em; color: orange; }, which should look like " attention needed here". Unfortunately, even then, "attention needed here" isn't considered part of the actual text of the page, so you can't search for it using your browser's Ctrl+F or whatnot.)
• Even logged-out readers, or readers with IE6 or IE7 (which don't support the above), can do a view-source to find instances of class attentionseeking in the page, whereas — as Yair rand can tell you — mere categories leave no trace at the place where they were added.
• This allows a message to be included, accessible either as hover-text for users who have made {{attention}} visible, or in the page-source for users searching it for attentionseeking. The message can explain exactly why the template thinks there's a problem.

—Ruakh_TALK 19:15, 30 July 2011 (UTC)

By the way, at ] it was being added by a {{gloss-stub|English}} in the ==Translingual== section. I've changed that to {{gloss-stub|Translingual}}, though I'm not sure if that was the right fix . . . —Ruakh_TALK 19:20, 30 July 2011 (UTC)

Thanks for finding the {{gloss-stub|English}}. I had searched for "en}}" and "en|" trying to find candidates.

Finding {{attention}} is the least of my worries as FF search handles that in the edit window. (I could even use CatScan to find items that were in the category and had the attention template.) My big problem is in not knowing what other templates might be causing the categorization, especially because "en" is not present. DCDuring TALK 19:40, 30 July 2011 (UTC)

Re: "My big problem is in not knowing what other templates might be causing the categorization, especially because 'en' is not present": Right, but if those templates use {{attention|en}} to cause the categorization, rather than just including a literal ], then you can easily find where that's happening (albeit not by using edit-window + FF-search). —Ruakh_TALK 20:00, 30 July 2011 (UTC)

And if they don't? Are you suggesting a need to check templates that do not use {{attention}} and substitute template code? DCDuring TALK 20:12, 30 July 2011 (UTC)

Re: "Are you suggesting ?": Yes, exactly. —Ruakh_TALK 20:53, 30 July 2011 (UTC)

OK. What is the most effective way to locate the offending templates? Should I just keep track of the offenders that I discover? Should I just try to redo the templates on my own?

How does this work for other maintenance categories? Are we comfortable that there are no other offended categories? DCDuring TALK 21:00, 30 July 2011 (UTC)

The day after tomorrow, I'll be at a computer where I have the latest XML dump, so will be able to generate a list of templates whose wikitext includes the string terms needing attention (assuming that no one else reading this page beats me to it). As for other categories . . . I have no idea. Like I said, I don't know how to handle the general case. :-P
I wonder if it would be worth seeking a change to MediaWiki that would cause a bit of HTML to be generated in situ wherever a category is added, as a hook for CSS and/or JavaScript. In addition to your use-case, and other similar editor-y use-cases (e.g., someone trying to empty a category, or someone who sees that an entry is in the wrong category but can't see how to fix that), this would also be useful for TabbedLanguages (where it would be helpful if the script knew with certainty which categories belonged to which language-sections), and probably other sorts of things as well.
—Ruakh_TALK 21:31, 30 July 2011 (UTC)

Wiktionary:Todo/templates bypassing attention —Ruakh_TALK 22:33, 31 July 2011 (UTC)

By the way, at ], the way I found the place was by going to Edit -> Preview in ==English==, and seeing that it didn't have that hidden-category, and then trying the same in ==Translingual==, and seeing that it did. I then did the same within Translingual, going to Edit -> Preview in ===Etymology 1=== and ===Etymology 2=== and ===Etymology 3===. Once I narrowed it down to the third translingual etymology, it was easy to find by inspection. If it hadn't been, I could have done binary search, by deleting half the content of the edit-window and clicking "preview", and seeing if the remaining half still had the category. It doesn't take that long, but it's annoying that we have to do it! (And of course, it requires having turned on the option to display hidden categories.) —Ruakh_TALK 21:40, 30 July 2011 (UTC)

I may have already gotten the offenders that actually put items in the category, though CatScan seems to behave oddly and can't be trusted. Once I have this category down to size, it is relatively easy to detect what causes additions to the category from the edit history of items newly added.

The more general problem bothers me and should bother anyone doing category based clean up. The more complex the template structure the more the need for some means of either controlling it or counteracting its less desirable side effects. DCDuring TALK 21:54, 30 July 2011 (UTC)

Also, temporarily unhiding a hidden category like this can enable one to use the position of the Category in the list of categories to localize the source. Though not desirable, it might be necessary for refractory cases. DCDuring TALK 22:06, 30 July 2011 (UTC)

I (but not just me) set up some templates to categorize in ]

when lang= is used. The idea being to call attention from editors of a specific language when there is an rfc/rfd/rfv (and so on) debate. 'Emptying' categories like Category:English terms needing attention is not as much a priority as one might think. The priority is to fix the entries, not to uncategorize them. Mglovesfun (talk) 10:16, 1 August 2011 (UTC)

For a Wiktionary's host language, English here and possibly for all languages with active participation from multiple contributors, the category is not very useful compared to the more specific categories.

{{attention}} itself has often been used when more specific tags like {{rfp}}, {{rfc}} and its more specific variants (including those yet to be created) are fine. The lang=en parameter is not especially valuable at this time, at least not for populating a category.

For all uses, {{attention}} specifically undermines the open and collaborative nature of Wiktionary. The comments embedded in {{attention}}, only visible in the edit window, simply have the effect of further diminishing the role of ordinary users to contribute via the Talk page. {{attention}} is also a one-way system of communication. The natural thing to do is to simply delete the tag once the matter is addressed to the satisfaction of the editor. A Talk page comment invites a response not a deletion. Talk pages have a useful role in demonstrating one way that entries get improved and in inviting participation.

The idea of topical attention has not worked so far. Often the tag seems to simply be used to keep a complainant from inserting a WP link in the entry (a per se good thing) or a OneLook or other Reference link, following them, and validating the definition. If we had some means to systematically invite folks with specialized interests and knowledge from en.WP and other wikis to work on definitions specific to their contexts or, possibly, topical categories, the idea might work.

The issues raised would seem to require a BP/RFDO/GP discussion on {{attention}}. DCDuring TALK 13:15, 1 August 2011 (UTC)

@Mglovesfun (comment of 10:16, 1 August 2011) and @DCDuring (comment of 13:15, 1 August 2011): I'm not sure I understand this discussion completely, so you may have already thought of this, but regarding those last two comments: could the entries be put into both the general and the specific categories? Is that feasible? That way, editors from each language are alerted as Mglovesfun likes and can tackle things by language if they prefer, and specific problems are also highlighted as DCDuring likes so editors can tackle "issue by issue" if they prefer. - -sche (discuss) 02:38, 4 August 2011 (UTC)

There is nothing wrong with that idea in principle. However, what has happened is that Category:English terms needing attention receives all items from many templates (if lang=en) and from {{attention}}. {{attention}} only puts its items in that category. As a result the items categorized by {{attention}} are swamped by those put in by other templates. Many of those items can be in RfP, RfC, RfV, RfD for a very long time. I would argue that once an item is on such maintenance lists it should be removed from the Category:English terms needing attention. English certainly differs from languages that have no everyday contributors, for which Category:XXX terms needing attention may be appropriate.

It may be that we need yet another category for English entries that seem to be problematic but for which the complainant does not know where to send it or knows it is not a good fit in the main maintenance pages.

Items truly needing topical attention may sit in a clean up category for a very long time, as long or longer than entries in some less common languages. They clearly need a separate category or even set of categories because of the long dwell time of entries there. DCDuring TALK 03:36, 4 August 2011 (UTC)

Which language family is the Nias language in? I would like to know that. (Besides, I just got started by adding a Nias word for stone, which is kara, from here . --Lo Ximiendo 13:47, 31 July 2011 (UTC)

Please don't steal words from other dictionaries! Also, this page is for technical questions, like "I can't get {{my new template}} to work; what am I doing wrong?" But, to answer your question: w:Nias language says it's an Austronesian language. —Ruakh_TALK 14:21, 31 July 2011 (UTC)

Will I have to contact the guys of the dictionary? I don't know how to avoid that. --Lo Ximiendo 14:27, 31 July 2011 (UTC)

You can't copyright a translation of a word; kara either means stone or it doesn't. If it does, nobody can claim the copyright to that. BigDom 13:22, 3 August 2011 (UTC)

Firstly — that's not completely true. Secondly — even to the extent that it's true, it doesn't address concerns about plagiarism and accuracy. —Ruakh_TALK 14:16, 3 August 2011 (UTC)

I'm not saying that one should take words straight from another dictionary because obviously you need to know enough of the language to be sure that what you're entering is an accurate translation. You wouldn't stop anyone using a dictionary to add French pierre or Spanish piedra or German Stein even though those translations can be found in dictionaries. I don't know whether kara is an accurate translation, but if it is then how is this any different? By the way, Wiktionary seems to encourage editors to use translators and dictionaries for short nouns. BigDom 14:39, 3 August 2011 (UTC)

I would indeed stop someone, if I could, from stealing pierre from another dictionary. If they know French, then why do they need to steal that? By the way, your link threw me for a loop for a moment, until I realized that you're just misunderstanding it. That page isn't encouraging editors to use (i.e. plagiarize) translators and dictionaries for short nouns; it's recommending those as tools for translators (people who translate text). It's not "use these to improve Wiktionary", it's "Wiktionary is useful to you; these might be, too." —Ruakh_TALK 15:59, 3 August 2011 (UTC)

Fair enough, I realise that I did misunderstand the use of that page. I think we'll have to agree to disagree on our interpretation of copyright law. WT:Copyrights states pretty much what I said earlier, "individual words are not copyrightable" (I know that page is a draft, but it's correct). This document agrees: "it is almost impossible to copyright individual words" as they are "universal, factual data which do not qualify for intellectual property cover". Translation dictionaries do not meet the w:Threshold of originality in the same way as phonebooks etc. are not copyrightable. BigDom 16:27, 3 August 2011 (UTC)

I don't follow any of your comment. I'm not sure how you think I'm interpreting copyright law, or why you think so. The only things I've said about copyright are (1) that your initial comment is not completely true and (2) that copyright is not the only reason not to steal translations from other dictionaries. Which of those do we have to agree to disagree on? And your quotations don't support you, anyway; they are saying "the word 'X' cannot be copyrighted" while you are saying "a translation of the word 'Y' as 'X' cannot be copyrighted". The latter may be true — and often is — but it does not follow from the former, and it's not supported by the pages you link to. "WT:Copyrights", indeed, implies quite the reverse: it says in part, "a definition is often a short description of a word's meaning which may inadvertently be identical to what is found in a published work. Any claim for copyright infringement would likely depend on proving a pattern of individual infringements" . The implication is that an intentionally identical definition would be infringement, unless covered by fair use, and that the only reason we could get away with stealing a few defs would be that it would be hard to prove (which is obviously not relevant in this case, since the editor is openly admitting it). "This document" does not discuss translating dictionaries, but it argues that a translation memory (TM) should be viewed as the copyrightable property of the translator who produced it, so that it, too, is not really supportive of the notion that individual translations can't be copyrighted. (TMs differ from translating dictionaries in important ways, so I wouldn't cite that document in support of any specific view of the latter; I mention its position only because of your misleading quotation from it.) —Ruakh_TALK 17:49, 3 August 2011 (UTC)