Wealth Maker: Wiktionary - Recent changes [en]: Wiktionary:Grease pit

Wiktionary - Recent changes [en]

Track the most recent changes to the wiki in this feed.

Aug 4th 2011, 02:38

Definition from Wiktionary, the free dictionary

(Difference between revisions)

Revision as of 17:49, 3 August 2011 (edit)		Latest revision as of 02:38, 4 August 2011 (edit) (undo)
Line 662:		Line 662:
	::::::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 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 {{temp\|attention}}. [[User: DCDuring \|DCDuring]] <small >[[User talk: DCDuring\|TALK]]</small > 13:15, 1 August 2011 (UTC)		::::::The issues raised would seem to require a BP/RFDO/GP discussion on {{temp\|attention}}. [[User: DCDuring \|DCDuring]] <small >[[User talk: DCDuring\|TALK]]</small > 13:15, 1 August 2011 (UTC)
		+	:::::::@[[User:Mglovesfun\|Mglovesfun]] (comment of 10:16, 1 August 2011) and @[[User: DCDuring \|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. [[User:-sche\|- -sche]] [[User talk:-sche\|(discuss)]] 02:38, 4 August 2011 (UTC)

	== Nias language ==		== Nias language ==

Latest revision as of 02:38, 4 August 2011

Wiktionary > Discussion rooms > Grease pit

Wiktionary discussion rooms (edit) see also: requests
Information desk comment \| history Newcomers' questions, minor problems, specific requests for information or assistance.	Tea room comment \| history \| archives Questions and discussions about specific words.	Etymology scriptorium history Questions and discussions about etymology- the historical development of words.	Beer parlour comment \| history \| archives General policy discussions and proposals, requests for permissions and major announcements.	Grease pit comment \| history \| archives Technical questions, requests and discussions.

All Wiktionary: namespace discussions 1 2 3 4 5 - All discussion pages 1 2 3 4 5

A grease pit

Welcome to the Grease pit!

This is an area to go with the Beer parlour and the Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary both as a dictionary and as a website.

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

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

Permanent notice

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

Grease pit archives

2006

2007

2008

2009

2010

2011

All subject headings

[edit] Audio bot

Could somebody please check if my bot does not spoil anything while adding audio files? I am not active on en.wiktionary and don't check latest policy changes. Bot contributions: Special:Contributions/DerbethBot. --Derbeth ^talk 17:31, 1 May 2011 (UTC)

[edit] Orange links

User:Yair rand/orangelinks.js is a script that turns all links to language sections that don't exist orange where the broken links would otherwise be blue. It works by requesting the full wikitext of each of the relevant pages from the API, and checking whether the target language section exists on the page. Does anyone know whether, if the script was turned on by default, it would cause problems to have such large requests being made on every page load? --Yair rand 21:45, 1 May 2011 (UTC)

[edit] How to most effectively add script templates

As a bit of an 'experiment' I converted {{l|xcl}} to {{l|xcl|sc=Armn}} in all Old Armenian entries; as I said above, I think the worst that can happen in this case is sc=Armn will appear twice, and really, there's no problem there. It's a bit ugly though, as named parameters should come after unnamed parameters, namely {{{1}}} and {{{2}}} for {{l}}, but I'm unsure of how to do that. Also, how easy would it be to check (using regexes in my case) for sc=Armn appearing twice in a template, and being able to remove it. Mglovesfun (talk) 12:14, 2 May 2011 (UTC)

Strictly speaking, it is theoretically impossible for a single regular expression to determine what parameters are used in a template and where a template-call ends: the ability of template calls to be nested arbitrarily is beyond a regular expression's ability to understand. That said, if we restrict consideration to template-calls whose interiors do not contain { or } — by far the most common case — then we can replace (\{\{l\|xcl\|[^\{\}]+)\}\} with $1|sc=Armn}} (adding |sc=Armn to the end of any template-call that starts with {{l|xcl| and doesn't otherwise contain { or }) and (\{\{l\|xcl\|[^\{\}]+)\|sc=Armn\|([^\{\}]+\|sc=Armn\}\}) with $1|$2 (removing |sc=Armn from the interior of any template-call that starts with {{l|xcl|, ends with |sc=Armn}}, and doesn't otherwise contain { or }). For a bit more coverage, you can sprinkle in \s* wherever whitespace is allowed. —Ruakh_TALK 13:01, 2 May 2011 (UTC)

That explains why I was finding it so hard. Hmm. Mglovesfun (talk) 13:08, 2 May 2011 (UTC)

I'm happy to do replacements like the one above for languages only written in one script, such as Old Armenian, is this sort of replacement. The only 'problems' are really cosmetic rather than functional (unless someone can show otherwise) that script templates can appear twice, and can appear before the word itself. FWIW I was talking to msh210 about character ranges; this tbot userpage seems to be a bit of a gem, the idea is to detect script from the character range and add a script template accordingly. I'm not gonna do anything at the moment, though, apart from discuss it. Mglovesfun (talk) 11:13, 3 May 2011 (UTC)

Re: "The only 'problems' are really cosmetic rather than functional (unless someone can show otherwise) that script templates can appear twice, and can appear before the word itself": I don't get it. Were you not satisfied with my suggestion above? —Ruakh_TALK 11:18, 3 May 2011 (UTC)

Right, I was fooled by "Strictly speaking, it is theoretically impossible for a single regular expression to determine what parameters are used in a template and where a template-call ends". I thought you were saying your script wouldn't actually work. I see what you mean now. Mglovesfun (talk) 12:00, 3 May 2011 (UTC)

I shall give it a go before running it 'en masse' to see if there are any problems. Mglovesfun (talk) 12:02, 3 May 2011 (UTC)

I ran it using hy instead of xcl ({{hy}} = Armenian) using the regex function of AWB and it skipped all 8000+ Armenian entries. Mglovesfun (talk) 23:05, 3 May 2011 (UTC)

I don't know much about AWB; what does that mean? I just tested my first regex above, after changing xcl to hy, and — for example — it matches two occurrences in [[ալոէ]]. (That's using JavaScript regexes, but judging from w:Wikipedia:AutoWikiBrowser/Regular expression, AWB regexes seem to be the same in all relevant respects.) Actually, the above wouldn't work perfectly at that page — in my second substitution, I didn't consider the case that \|sc=Armn had originally appeared at the end of the template-call — but I don't see why AWB would have skipped that page, since the first substitution does match. (BTW, to address the issue I just mentioned, the second substitution should replace (\{\{l\|xcl\|[^\{\}]+)\|sc=Armn(?=\|)([^\{\}]*\|sc=Armn\}\}) with $1$2.) —Ruakh_TALK 23:27, 3 May 2011 (UTC)

Perhaps it's human error on my part. --Mglovesfun (talk) 11:50, 4 May 2011 (UTC)

[edit] Translation cleanup script

I'm playing with User:Mglovesfun/add t.js in an attempt to write a script to add {{t}} and also move transliterations and genders inside the {{t}} templates. It seems to be beyond my capability and don't, worry, I'm not planning on running it any time soon. Current problems is that it matches the format * <languagename>: [[foo]] anywhere, so it'll add it for descendants too. Also, it will only format the first link, so * <languagename>: [[foo]], [[bar]] will only add t to foo, not bar. There loads of stuff I can mention, those are too obvious ones. Mglovesfun (talk) 11:48, 3 May 2011 (UTC)

You could limit it to inside ttables by adding (?=([\s\S](?!\{\{trans\-top))+\{\{trans\-bottom\}\})to the end of the regexp. --Yair rand 22:57, 3 May 2011 (UTC)

Could you add it to that page? Mglovesfun (talk) 23:07, 3 May 2011 (UTC)

[edit] smart quotes

Template_talk:term#Smart_quotes, any input? Mglovesfun (talk) 15:36, 3 May 2011 (UTC)

This seems like more of a beer-parlour issue, no? —Ruakh_TALK 17:04, 3 May 2011 (UTC)

I don't disagree. Mglovesfun (talk) 23:06, 3 May 2011 (UTC)

[edit] DEFAULTSORT in Greek entries and interwiki order

I tried a python script we use in el.wikt to add DEFAULTSORT keys to Greek words (User:Flubot/Adding_DEFAULTSORT_key_to_Greek_words). It's not very elegant because I've made some changes to run it here, but it works. There are two points: (a) If someone had previously inserted a valid DEFAULTSORT key somewhere in the middle of the text, the script moves it right before interwiki links. This change is not necessary but harmless, I think. (b) It changes the order of some interwiki links, for example it moves hu after lt, i.e. Magyar after Lietuvių (see this) and Suomi after Romanian, ie fi after ro (here). That seems alright to me but I would like to have other opinions before I go on with this script. --flyax 02:23, 5 May 2011 (UTC)

I see that Interwicket used to sort interwikis by language name and not by language code order (see Absinth). Luckas-bot does the same (see φόρος). So, if their is no objection I'll resume my edits with this script in a couple of days. --flyax 11:57, 6 May 2011 (UTC)

[edit] Subpages for entries?

moved to the Beer parlour.

[edit] pywikipediabot - Importing existing free-licensed database into Khmer Wikt

Greetings from Khmer Wikt!

I have came across a blog post somewhere about pywikipediabot in importing existing database from a free-licensed dictionary into Wikt. I heard that the Burmese or Lao project has been doing it. So, how can I and my team make sure of this bot for Khmer Wikt project? Currently, there's 1-2 active users who devote their time to manually make each entry one by one into our Khmer Wikt. So, I need your help in exploring if this pywikipediabot can help make life easier with a great deal of time saved! Thank you! --វ័ណថារិទ្ធ (Vantharith) 16:36, 7 May 2011 (UTC)

[edit] Autoformat

For some time I haven't been finding any results from either Autoformat or a replacement on various clean-up lists. Is that because there is nothing to clean up? If not, this would to make it highly likely that entropic processes will eventually overwhelm us. DCDuring TALK 11:41, 8 May 2011 (UTC)

There are over 500 articles that have an {{rfc-auto}} template. Are you still doing those? SemperBlotto 16:53, 8 May 2011 (UTC)
- AutoFormat died ages ago, in my opinion never to return, and KassadBot has no edits since the 1st of May. --Mglovesfun (talk) 12:01, 9 May 2011 (UTC)

Do we actually need a bot running 24/7 to format pages? Are cleanup lists generated from the dumps enough? Nadando 20:13, 9 May 2011 (UTC)

Not 24/7 but if it's once a day, it certainly helps! --Mglovesfun (talk) 11:12, 16 June 2011 (UTC)

[edit] Make conjugation box open immediately

Hi, Can I make the conjugation box open immediately when I enter an entry? For example: If I go to parlare the Conjugation is hidden and i need to manually press "show" in order to show it. Jobnikon 16:13, 8 May 2011 (UTC)

See Wiktionary:Per-browser preferences. Specifically , tick the box that says "Show the translation sections expanded, instead of having them collapsed." = this applies to all such sections, not just translations. SemperBlotto 16:49, 8 May 2011 (UTC)

Thanks!Jobnikon 17:09, 8 May 2011 (UTC)

Or you could just click "Show conjugation" in the "Visibility" section of the sidebar. --Yair rand 20:49, 8 May 2011 (UTC)

This page contains a deprecated message; Special:CategoryTree was implemented long ago. It should either be deleted, in which case it would revert to the default message "The following {{PLURAL:$1|category contains|categories contain}} pages or media. [[Special:UnusedCategories|Unused categories]] are not shown here. Also see [[Special:WantedCategories|wanted categories]]." Or the portion labeled "the [http://tools.wikimedia.de/~daniel/WikiSense/CategoryTree.php?wikilang=en&wikifam=.wiktionary.org&cat=*Topics&m=c&go=Load&userlang=en&terse= Category Tree browser] from the Toolserver" should be changed to "[[Special:CategoryTree|the CategoryTree]]" instead, or something similar. TeleComNasSprVen 23:42, 11 May 2011 (UTC)

"Category:Latin words needing attention" needs to be changed to "Category:Latin terms needing attention", but unfortunately this template is protected. TeleComNasSprVen 05:28, 12 May 2011 (UTC)

Done. --Yair rand 05:30, 12 May 2011 (UTC)

I find it a bit irritating that such templates don't categorize when the form with macrons isn't given. That is, even when there are no macrons, you have to write out the page name to tell the template that, or else it won't categorize. --Mglovesfun (talk) 11:20, 12 May 2011 (UTC)

[edit] Anonymous feedback

I noticed while I was logged out that there is a section located in the sidebar titled "feedback" with the header "Send you anonymous feedback to Wiktionary" and includes several javascript commands to mark an entry a particular way according to a standard scale of some sort, as well as a link directly to Wiktionary:Feedback, which is of course where we get all of our feedback in writing. However the section disappears while I am logged in, and I'm no longer able to comment on a particular entry. Why has this feature been removed for autoconfirmed users who just wish to scroll through entries? TeleComNasSprVen 00:52, 13 May 2011 (UTC)

I think it's assumed that logged-in users would fix something themselves, or have a better idea of how to get someone to fix it. —Internoob (Disc•Cont) 03:25, 21 May 2011 (UTC)

Apparently is has to be anonymous, you can't do it while logged in. Mglovesfun (talk) 13:10, 22 May 2011 (UTC)

This has always been for unregistered users only. It wouldn't be hard to enable it for all users but, as Internoob pointed out, it didn't seem like something most users would want. - TheDaveRoss 20:40, 20 June 2011 (UTC)

[edit] Making topic cat use numbered parameters

Currently, (almost) all category boiler templates have the language code as the first numbered parameter, and the name of the category as the second. {{topic cat}} is rather conspicuous because it requires parameters called lang= and current= instead. Would anyone object if I modified the template so that it allows you to call it with numbered parameters as well, like other boiler templates? —CodeCa t 16:20, 16 May 2011 (UTC)

I've spotted this before; I'd say go for it. Obviously lang and current should still work, as they're so widely use. Looks like a good case where regular expressions could be used to simplify these templates using MglovesfunBot. Mglovesfun (talk) 21:12, 17 May 2011 (UTC)

I have made the change now, and a few categories now use this newer system. Would anyone object to running a bot that converts the old style to the new, or is that going overboard? —CodeCa t 12:37, 22 May 2011 (UTC)

I support using a bot to do that. --Daniel. 12:44, 22 May 2011 (UTC)

Since it's thousands and thousands of edits, I think it's "going overboard" to do it without a vote. —Ruakh_TALK 13:05, 22 May 2011 (UTC)

I don't see how the number of edits matter when they're all minor. It wouldn't change the readers interface at all - it would appear the same to readers (i.e. non-editors) a bit like changing {{infl|fr|adverb}} to {{fr-adv}}. Plus, the old system would still work - editors can still use it, just a bot may modify it later to do the same thing, just slightly simpler. Mglovesfun (talk) 13:08, 22 May 2011 (UTC)

WT:BOT says "I will make sure that the task is so innocuous that no one could possibly object". That's not good wording, as it doesn't care why someone objects. In theory, even if nobody does object, someone could hypothetically object or hypothetically have objected, so no task would ever pass under this rule. Furthermore I could object just because I'm in a bad mood or I have a grudge against someone. Anyway, in upholding what I'd like to think is the spirit of this rule, there's no reasonable reason to object to this. So under the spirit of the law, this doesn't even require consultation, never mind a vote. Mglovesfun (talk) 13:14, 22 May 2011 (UTC)

The only reason I can think of for not doing this is if we prefer {{topic cat|lang=fr|current=Something}} over {{topic cat|fr|Something}} for 'canonical' reasons... But topic cat has always been a bit of an odd one out when it comes to the category structure. —CodeCa t 13:28, 22 May 2011 (UTC)

[edit] Orphaned appendix pages

Is there a way to find out which appendix pages do not have links to them? It would be useful to be able to see which of our reconstructed entries are not linked to from etymologies yet. —CodeCa t 12:36, 22 May 2011 (UTC)

So currently, Template:syc-root-entry is set up to include three (and only three) letters as the basis of the Syriac root. That covers the vast majority of Syriac roots, however, there are quite a few that don't follow this pattern. Some will have only two letters, others four or sometimes five. Is it possible to set the template up in a way so that it includes all of those possibilities? I'm guessing it's an easy fix, maybe make two letters required and the rest optional with "#if:" or something. --334a 20:41, 22 May 2011 (UTC)

How's this? --Yair rand 20:54, 22 May 2011 (UTC)

I've cleaned it up a bit by adding line breaks, and I changed the nested ifs to ifs appearing side by side, because there doesn't seem to be any difference. —CodeCa t 21:10, 22 May 2011 (UTC)

With the ifs nested it wouldn't have to actually run the parserfunctions after the first blank parameter, I think. --Yair rand 21:15, 22 May 2011 (UTC)

That works beautifully! Many thanks to both of you. :) --334a 21:43, 22 May 2011 (UTC)

Or should that be... {{syr-root-entry}}? See the discussion below (June 2011). --Mglovesfun (talk) 11:11, 16 June 2011 (UTC)

[edit] "Sister projects

Thought you might find this interesting:[[1]]Geof Bard 04:11, 24 May 2011 (UTC)

These seem to be Dawnraybot edits, many of them. How do we fix them? --Mglovesfun (talk) 11:10, 24 May 2011 (UTC)

Remove variables from templates. For example:

# {{pt-verb form of|[[abandonar]]|ar|indicative|tense=preterite|number=plural|person=first-person|dialect=brazil}}

change into

# {{pt-verb form of|[[abandonar]]|ar|indicative|preterite|plural|first|dialect=brazil}}

Ungoliant MMDCCLXIV 00:24, 8 June 2011 (UTC)

[edit] Sloooooooooow

This wiki is incredibly slow today (other sites seem normal, so I don't think it's me). I'm going to do something more productive instead. SemperBlotto 10:27, 3 June 2011 (UTC)

It's my ISP's fault - "You will currently be experiencing intermittent connection issues on your broadband internet service. Our engineers are aware of this issue and are currently working to fix it fast. We apologise for any inconvenience this may be causing." SemperBlotto 14:48, 3 June 2011 (UTC)

[edit] Dutch nouns

Would anyone object if I converted {{infl|nl|noun}} to {{infl|nl|noun|g=g}} a bit like I did for French nouns a few weeks ago? It would fill up Category:Dutch nouns with incomplete gender. Mglovesfun (talk) 16:24, 4 June 2011 (UTC)

I wouldn't mind, but replacing it with {{nl-noun}} would be preferable. —CodeCa t 18:17, 4 June 2011 (UTC)

{{nl-noun}} produces automatic plurals and diminutives, some (perhaps more than 50%) of which will be wrong. It's the same reason I don't convert {{infl|fr|noun|g=m}} to {{fr-noun|m}} - something like mois could have the automatic plural moiss. Mglovesfun (talk) 11:09, 5 June 2011 (UTC)

Nobody's objected. --Mglovesfun (talk) 10:36, 9 June 2011 (UTC)

[edit] Help with template for Japanese Pitch Accent

I've written a template for Japanese Pitch Accent. (I'm about to use it for a batch import.) It displays like this:

(Standard Japanese) Pitch Accent: びしょうじょ [2]

And the code looks like this: {{ja-accent-standard|accent=2|び|しょ|う|じょ}}. First you have the accent as a named parameter (a number saying which mora is accented). Note: a mora is similar to a syllable, and can be one or more characters (kana). After the named parameter follows each mora in the word as an unnamed parameter.

This works pretty well, and I'm quite happy with it. It works for 99% of the entries.

However, there are some entries with 2 kernels (i.e. downsteps in pitch). Also, though I've yet to see one, there's no reason why there couldn't be more than 2.

E.g. 四方八方, which is しほう-はっぽう [2]-[3] has 2 kernels. I want it to show this:

(Standard Japanese) Pitch Accent: しほう-はっぽう [2]-[3]

What I want to write is: {{ja-accent-standard|accent=2-3|し|ほ|う|-|は|っ|ぽ|う}} and have it automagically work, but I don't see how to do that.

Any ideas for how to write such a template? Vaste 06:34, 11 June 2011 (UTC)

Would the following work perhaps?

I add another parameter accent2, and if it's present, I'll look for the "-" separator (with a switch). I then now where each part of the word starts/ends and I can call the original template on each part. Same could be done with a parameter accent3.

E.g. so I would write (for 粗衣粗食):

Is this too ugly? Vaste 06:32, 12 June 2011 (UTC)

[edit] Trying to make a template subst-able

The template {{langrev}} works fine when it's transcluded, and it works fine when subst-ed as long as the subtemplate for the language name in question exists. It's only when it doesn't exist ({{langrev|foobar}} for example) that the template doesn't work. It works when transcluded and gives an empty string, but when subst-ed it gives something else instead. Does anyone know how this could be fixed, so that it is subst-ed with an empty string if the parameter is an unknown language name? —CodeCa t 11:50, 13 June 2011 (UTC)

Essentially, {{subst:langrev|French}} works because Template:langrev/French exists, {{subst:langrev|ABCDEF}} creates {{subst:langrev/ABCDEF}}, which can't subst: because it doesn't exist. You'll need some sort of {{safesubst:#ifexist:Template:langrev/1 in there (would finish, but am going out and haven't worked it out in my head yet). --Mglovesfun (talk) 11:58, 13 June 2011 (UTC)

I wanted to avoid using ifexist. The template works when not subst-ed because if the subtemplate doesn't exist, it expands literally to [[:Template:foobar]], which can then be checked for. —CodeCa t 12:06, 13 June 2011 (UTC)

After a lot of experimentation, I've found and implemented a solution. I don't have time right now, though, to explain the ins and outs of why this approach was necessary; sorry. I'll comment back later. —Ruakh_TALK 15:02, 13 June 2011 (UTC)

I have no idea what you just did but thank you! —CodeCa t 15:07, 13 June 2011 (UTC)

You're welcome! —Ruakh_TALK 15:30, 13 June 2011 (UTC)

O.K., turns out I do have time. (A co-worker in QA messaged me, asking if I was available . . . and I haven't heard from her since.)

So, the main problem is that {{subst:#ifeq:a|b|c|d}} (or {{safesubst:#ifeq:a|b|c|d}}) apparently doesn't evaluate any non-substituted template-calls or non-substituted parser-function-calls in a or b. Therefore, while {{#ifeq:{{fr}}|French|equal|unequal}} and {{subst:#ifeq:{{subst:fr}}|French|equal|unequal}} both produce equal, {{subst:#ifeq:{{fr}}|French|equal|unequal}} produces unequal. (This is not just #ifeq:, by the way. {{urlencode:{{fr}}}} and {{subst:urlencode:{{subst:fr}}}} both produce French, but {{subst:urlencode:{{fr}}}} produces %7B%7Bfr%7D%7D.)

Unfortunately, the obvious solution — just change {{langrev/{{{1|}}}}} to {{safesubst:langrev/{{{1|}}}}} — doesn't actually work. This is because non-existent templates can't actually be substituted, apparently; {{safesubst:langrev/foobar}} just gets saved verbatim to the database, and the translation to [[:Template:langrev/foobar]] happens during rendering. (Incidentally, {{subst:langrev/foobar}} also gets saved verbatim to the database, and doesn't even get translated during rendering — since subst:, as you know, doesn't trigger transclusion during rendering, which is the whole reason that Conrad created safesubst: to begin with — so it actually gets output verbatim as well: {{subst:langrev/foobar}}.)

So, my solution was to use {{safesubst:padleft:|1|...}} to grab just the first character of {{safesubst:langrev/{{{1|}}}}}, and see whether it's [ (meaning that we're not substituting, and the template doesn't exist, so {{safesubst:langrev/foobar}} is becoming [[:Template:langrev/foobar]]), or { (meaning that we are substituting, and the template doesn't exist, so {{safesubst:langrev/foobar}} is remaining itself), or anything else (meaning that the template does exist). This isn't a perfect test, since in theory {{langrev/foobar}} could be a real template whose value starts with [ or {, but I knew that wouldn't be the case here. Ideally I would have preferred to test more than just one character, but it would be messy to have [[ or {{ in the string being compared to, because that could confuse the MediaWiki parser. (But if we ever need that in the future, we can probably accomplish it by using {{safesubst:urlencode:...}} to translate [[ to %5B%5B and {{ to %7B%7B.)

Does that make sense?

—Ruakh_TALK 15:30, 13 June 2011 (UTC)

Yeah... kind of. Substitution still confuses me a lot. I'm just glad it works! —CodeCa t 16:17, 13 June 2011 (UTC)

[edit] Using plural forms in category boilerplate parameters where appropriate

Right now, most of the category boilerplate templates such as {{poscatboiler}} take a parameter that indicates the name of the category, but that parameter is singular even though the name of the category itself is plural. For example, {{poscatboiler|en|noun}} creates Category:English nouns. Daniel said it was originally inspired by {{infl}}, since part-of-speech categories were the first to use such a system. But now that we have many more categories, it's becoming cumbersome because they all have to be added to {{theplural}} each time. So I would like to ask if anyone would object to simply using the plural form as the parameter? —CodeCa t 20:57, 13 June 2011 (UTC)

[edit] topiccatboiler

I've been working on improving the {{catboiler}} template so that it can be used for a wider range of purposes. One of those purposes is to replace {{topic cat}}, but that's so widely used that it would be a bad idea to start messing with it on a significant scale. That's why I'd like to ask first if anyone would object to me testing the new template, {{topiccatboiler}}, on a small part of the topical tree and a few languages, to see if there are any bugs that need to be worked out? So far it already works well, but there may be some small bugs or improvements that need to be taken care of, and it would be better to make sure they're found before the template is used on a full scale. —CodeCa t 16:24, 15 June 2011 (UTC)

It used to display Classical Syriac, now it displays Syriac. {{syr}} already displays Syriac. Is this as straightforward as it appears. --Mglovesfun (talk) 17:17, 15 June 2011 (UTC)

According to ISO 639, syc is 'Classical Syriac', a single historical language, and syr is 'Syriac (Northeastern Neo-Aramaic)', a living macrolanguage. So it seems to me that the original naming was correct. —CodeCa t 10:47, 16 June 2011 (UTC)

It could (or frankly, it will) create a bit of a mess if we modify one now. In this version of ܗܘ the contributed used both syc and syr. --Mglovesfun (talk) 10:56, 16 June 2011 (UTC)

There is no Category:Classical Syriac language yet, so we can assume that all uses of {{syc}} should really be {{syr}}. Maybe a bot could fix this? —CodeCa t 10:58, 16 June 2011 (UTC)

Using regular expressions it's quite easy. I agree that this is the easiest way, then make {{syc}} displays Classical Syriac and let editors changes entries from one to the other whenever they see fit to. --Mglovesfun (talk) 11:10, 16 June 2011 (UTC)

No, I meant precisely {{syc}}, Classical Syriac of Edessa, everywhere in Category:xcl:Syriac derivations. --Vahag 11:27, 16 June 2011 (UTC)

It's enough to make you syc (wahey!) --Mglovesfun (talk) 11:30, 16 June 2011 (UTC)

The Syriac templates would need to be renamed, too. Maybe that would be a good place to start. —CodeCa t 11:48, 16 June 2011 (UTC)

Yes but not so fast, let's let the discussion go on a little. --Mglovesfun (talk) 11:49, 16 June 2011 (UTC)

I've looked around a bit and I noticed that the code 'syr' is used in some places already. So it looks like for a long time we've used both codes for the same thing. —CodeCa t 12:11, 16 June 2011 (UTC)

Yes, "syc" should probably be changed back to "Classical Syriac," which is what I've been using it for. The code "syc" is indeed used for "Neo-Syriac" (divided into the dialects "Assyrian Neo-Aramaic" and "Chaldean Neo-Aramaic", apparently). Maybe it's a good idea to have "syc" be "Classical Syriac" while "syr" is "Neo-Syriac"? It gets rid of all the ambiguity "Syriac" causes. I know that doesn't jive too well with Wiktionary's policy of not using "modern" or "neo" or "new" when naming languages, but "Syriac" almost always refers to the classical language. Modern speakers usually don't even call their language "Syriac" (in English, at least). --334a 17:36, 16 June 2011 (UTC)

A lot of people use 'Greek' to refer to 'Ancient Greek' as well. —CodeCa t 17:42, 16 June 2011 (UTC)

Is it gonna be the case that these all need to be sorted by hand? And in some cases split between Classical Syriac and Syriac? --Mglovesfun (talk) 17:43, 16 June 2011 (UTC)

Are there any Classical Syriac entries? If not, then all the 'proper' uses of syc are probably only in etymology sections. I've already converted most of the categories. —CodeCa t 17:52, 16 June 2011 (UTC)

I think from 334a is saying, it might be the opposite, and the question I was about to ask was 'shall we convert all of these to Classical Syriac?' If 334a has created these as Classical Syriac entries (that is, syc), how many Syriac entries do we have created by other users? So, if 334a has created in these as 'syc' entries, I think we should respect that. --Mglovesfun (talk) 18:02, 16 June 2011 (UTC)

But I don't know how to tell the two apart, so I can't really help with that. —CodeCa t 18:06, 16 June 2011 (UTC)

Mglovesfun understood me correctly: every single entry I've made in "syc" is Classical Syriac. Should "syr" even be used? I thought Wiktionary's policy was not to have macrolanguages, but I could be wrong. To be honest, the labelling of only Assyrian and Chaldean Neo-Aramaic as "Neo-Syriac" is pretty dumb since the Neo-Aramaic dialect "Turoyo" is a lot closer to Classical Syriac than Assyrian/Chaldean Neo-Aramaic but isn't included in the "syr" macrolanguage group. The folks over at ISO/Ethnologue/wherever might realize that one day and change it... --334a 18:27, 16 June 2011 (UTC)

If that's the case, then we would need to start by changing the template. Without it, we can't create entries using the code. —CodeCa t 18:40, 16 June 2011 (UTC)

Is there any modern language that is generally referred to as "Syriac"? --Yair rand 18:54, 16 June 2011 (UTC)

Syriac (neo-Syriac that is) is an official language in some areas in Iraq according to its constitution It is also being taught in some public schools in Iraq and Sweden.--Rafy 21:28, 16 June 2011 (UTC)

I would argue that it isn't, at least not really. Usual names include "Assyrian", "Chaldean", "Neo-Aramaic" or even just "Sureth/Suret/Surit". Having the names "Syriac" (for Neo-Syriac) and "Classical Syriac" is a little like calling Italian "Latin" and Latin "Classical Latin". In the same way that Romance languages don't descend from Classical Latin (but Vulgar Latin), most Neo-Aramaic languages, or at least Assyrian and Chaldean, don't directly descend from Classical Syriac. The name "Syriac", which describes the classical eastern Aramaic dialect of Edessa, is a misnomer when it comes to the Northwestern Neo-Aramaic languages. A lot of the confusion and multiple names has to do with relatively recent sociolinguistic and nationalist reasons. --334a 21:36, 16 June 2011 (UTC)

(NB, this is why I said to CodeCat "Yes but not so fast, let's let the discussion go on a little.") Mglovesfun (talk) 22:01, 16 June 2011 (UTC)

Does anyone object to {{syc}} displaying Classical Syriac instead of just Syriac? I've just done it now as CodeCat suggested. This has turned into a bit of a mess. Good news is we 'only' have 355 Syriac entries. {{syc}} has 718 transclusions, {{syr}} has 46, just 9 of those in the main namespace. Mglovesfun (talk) 22:21, 16 June 2011 (UTC)

I take it that the templates actually have the correct code, they just need to go into different categories? —CodeCa t 22:49, 16 June 2011 (UTC)

I might be mostly level 2 headers than need changing, and then there's translations. In reply to 334a, we don't allow 'Chinese' but we do allow Arabic and Nahuatl. Mglovesfun (talk) 23:16, 16 June 2011 (UTC)

Is there actually anything that does use {{syr}} correctly, or is everything we have that's now called Syriac actually Classical Syriac? —CodeCa t 23:23, 16 June 2011 (UTC)

Debatable; w:Northeastern Neo-Aramaic has some good coverage. If it's anything like Greek and Ancient Greek, there's probably a massive overlap. Mglovesfun (talk) 23:35, 16 June 2011 (UTC)

Ok, but what I mean is, is there anything that should definitely not be moved to Classical Syriac? Or can I just move everything indiscriminately? —CodeCa t 23:51, 16 June 2011 (UTC)

Again, I think waiting another 24 hours will do no harm. I can't answer that, we need 334a. It literally will take less than 5 minutes to change these by bot. AWB, Category (recursive) with Category:Classical Syriac language, change ==Syriac== and to ==Classical Syriac== and you're done! --Mglovesfun (talk) 11:14, 17 June 2011 (UTC)

I had a once-over of all the {{syr}} transclusions and fixed what was supposed to be Classical Syriac. The few {{syc}} entries that weren't created by me are also Classical Syriac (the ones that I know of and/or edited, anyway), so I think it's pretty safe to go ahead with a bot and make the L2 header switch. Also, is it possible to change all the entries under (the subcategories of) Category:Syriac irregular nouns to Category:Classical Syriac irregular nouns? --334a 03:30, 18 June 2011 (UTC)

Shouldn't be too hard. Mglovesfun (talk) 09:55, 18 June 2011 (UTC)

[edit] Template:emoticon

Template:emoticon failed RFDO last year. However, I recreated it to help me with populating Category:Japanese emoticons. Feel free to revise my decisions. --Daniel 05:29, 18 June 2011 (UTC)

I think the point was the emoticon is not a context. If something's an emoticon, you should write 'emoticon' in the definition, and tag using a manual category. Writing out a manual category really isn't as difficult as people think; I don't understand why people are so scared of it. Mglovesfun (talk) 09:54, 18 June 2011 (UTC)

NB I've deleted it as 'previously failed RFD', but we can still reopen the discussion. Do you (others) prefer to have (emoticon) on the definition line, or simply to write in the definition 'An emoticon that […] '. Mglovesfun (talk) 10:07, 18 June 2011 (UTC)

I like your solution. As far as I'm concerned, from this short discussion onwards, {{emoticon}} can stay deleted. --Daniel 01:57, 25 June 2011 (UTC)

[edit] Sorting in Welsh

Welsh has the peculiar property that ‹ng› is considered a single letter, which is alphabetized between ‹g› and ‹h›, when it's pronounced [ŋ], but it's considered two letters ‹n›+‹g› (and thus alphabetized between ‹nff› and ‹nh›) when it's pronounced [ŋɡ]. The word cyngyd is actually ambiguous between the two: when it means 'adjoining' or 'frontier', it's pronounced [ˈkəŋɪd] and should be alphabetized between words starting cyg- and words starting cyh-. But when it means 'intention', it's pronounced [ˈkəŋɡɪd] and should be alphabetized between words starting cynff- and words starting cynh-. This is what Welsh print dictionaries do: the word is listed twice, 'adjoining'/'frontier' under C+Y+Ng+Y+D and 'intention' under C+Y+N+G+Y+D. In the entry itself, I've tried to force the correct sorting of the adjective meaning 'adjoining' and the noun meaning 'frontier' using sort=cygzyd, while the noun meaning 'intention' I didn't give a sort= parameter since it can sort automatically. This kludge worked for the adjective: at Category:Welsh adjectives, it's correctly sorted between cyfyng and Cymraeg. But at Category:Welsh nouns, there's only one entry, and it's alphabetized between cynaniad and cynrychiolydd. Ideally, it should be listed twice in the category: once where it already is, and once again between cyfystyr and cyhoedd. Is there any technical way to make that happen? —An gr 08:51, 18 June 2011 (UTC)

Is there a unicode character for <ng> when it is used as a single character? If not there is no way to distinguish two identical strings as you describe. - TheDaveRoss 20:43, 20 June 2011 (UTC)

No, there isn't, and if there were it would probably be deprecated, just like the single-character codes for Dutch IJ (Ĳ ĳ) and Serbo-Croatian Dž (Ǆ ǅ ǆ), Lj (Ǉ ǈ ǉ), and Nj (Ǌ ǋ ǌ). —An gr 21:51, 20 June 2011 (UTC)

What about a zero-width space ⁠? Would that work? —CodeCa t 21:56, 20 June 2011 (UTC)

I dunno. I suppose cyn‌gyd is a possible article title, but I don't know if it would be considered legitimate. I'd have to put "See also" templates at the top of each article linking to the other, but since the two would look alike to the human eye, it would definite confuse people. (But that would be true with a separate "Ng" character, if one existed, too.) —An gr 05:20, 21 June 2011 (UTC)

This is kind of . . . awkward . . . but redirects can belong to categories. You can create a [[cyn⁠gyd]] that redirects to [[cyngyd]] and belongs to Category:Welsh nouns with one sort order, while [[cyngyd]] itself belongs to Category:Welsh nouns with a different sort order. —Ruakh_TALK 11:17, 21 June 2011 (UTC)

Also, if you do plan to do this, I'd use the zero-width non-joiner (‌). This is what Persian uses as well, which has a similar problem. -- Prince Kassad 12:26, 21 June 2011 (UTC)

Yes, that worked. I used the zero-width non-joiner rather than the zero-width space in the redirect, and now Category:Welsh nouns has two entries, one in each location. (One of them is italicized because it's a redirect, but I can live with that.) Thanks for your help! —An gr 06:51, 22 June 2011 (UTC)

[edit] Distinguishing categorised and not-categorised scripts

Many templates have a sc= parameter which allows you to set the script. The category boilerplate templates use this parameter to add an extra bit to the name of the category to specify what script its contents is in. However, we have no proper method of categorising entries into those categories. {{infl|sh|noun|sc=Cyrl}} will categorise in Category:Serbo-Croatian nouns. I wonder how we could adjust templates like this so that they know their script parameter should also be used in the name of the category, so that it becomes Category:Serbo-Croatian nouns in Cyrillic script. —CodeCa t 10:31, 19 June 2011 (UTC)

Why would that be necessary? The category already divides up Latin and Cyrillic scripts by sorting. As you browse the category, first you get all the Latin-alphabet words, and then all the Cyrillic-alphabet words. To find a word, just click on the initial letter in the script you want in the little navbox thingy on the category page. —An gr 13:53, 19 June 2011 (UTC)

That will work for Serbo-Croatian, but not for Chinese, where the two scripts are mixed together. —CodeCa t 13:55, 19 June 2011 (UTC)

Simplified and Traditional Chinese characters aren't really two different scripts. —An gr 16:49, 19 June 2011 (UTC)

Making {{infl}} categorize all words by their scripts is a bad idea, at least because people don't want to separate Serbo-Croatian into categories by script. --Daniel 02:15, 24 June 2011 (UTC)

[edit] Linking here from Venetian Wikipedia

I tried to link to one of our pages from vec.Wikipedia using [[wikt:en:insegnar‎]]. It gave a blue link, but clicking on it went to Wikimedia instead of here. It seems to me that this is because there is no vec.Wiktionary. Is this a bug? or is there a better way of linking here in this situation? SemperBlotto 15:43, 20 June 2011 (UTC)

Maybe [[en:wikt:insegnar‎]]? I think [[wikt:en:insegnar‎]] resolves as "go from vec.Wikipedia to vec.Wiktionary, and from there to en.Wiktionary" (and fails if there is no vec.Wiktionary), whereas [[en:wikt:insegnar‎]] should resolve as "go from vec.Wikipedia to en.Wikipedia, then to en.Wiktionary". - -sche (discuss) 16:31, 20 June 2011 (UTC)

Cross-wiki linking can be ugly. There's a trick: use m:wikt:insegnar, it works everywhere. -- Prince Kassad 16:40, 20 June 2011 (UTC)

How does m:wikt know which Wiktionary (English vs Venetian vs German etc) to go to? Or does it always only go to en.Wikt? - -sche (discuss) 17:24, 20 June 2011 (UTC)

It goes to en.wikt, no matter what. -- Prince Kassad 18:42, 20 June 2011 (UTC)

(Re -sche.) Wouldn't that need to be [[:en:wikt:insegnar]], with a colon?—msh210℠ (talk) 17:08, 20 June 2011 (UTC)

Yes, the extra colon makes it work! SemperBlotto 18:46, 20 June 2011 (UTC)

Ah, you're right. - -sche (discuss) 17:24, 20 June 2011 (UTC)

Or create a template like {{wikipedia}}, though I suppose it won't be able to handle every single language, you could certainly allow lang=en and lang=it. --Mglovesfun (talk) 17:11, 20 June 2011 (UTC)

[edit] Static Dump / Openzim Extention

I'd like to request a static dump of Wiktionary dump (html, not xml). If possible adding .zim export capability would be even better to enable offline work. OrenBochman 13:20, 22 June 2011 (UTC)

[2]- these haven't been available for a long time. Nadando 18:01, 22 June 2011 (UTC)

Those are Wikipedia only I think. Also they are 3 years old. - TheDaveRoss 19:37, 22 June 2011 (UTC)

[edit] Xyzy and infl

I believe {{infl}} should not support {{Xyzy}} anymore. --Daniel 02:12, 24 June 2011 (UTC)

See diff, diff, and Thread:User_talk:Yair_rand/The_first_parameter_of_infl. --Yair rand 02:16, 24 June 2011 (UTC)

Maybe we should keep {{Xyzy}}, though, rather than having duplicate code in large numbers of different templates ({{infl}}, {{term}}, {{l}}/{{onym}}, {{t}}, {{form of}}, etc.). If sc= and lang= are both arguments to {{Xyzy}}, then other templates can just do something like {{Xyzy|...|lang={{{lang|}}}|sc={{{sc|}}}|face=...}} and let {{Xyzy}} figure out whether sc= is non-blank, whether lang= is supported, etc. —Ruakh_TALK 02:34, 24 June 2011 (UTC)

How come {{term}} is no long italicising words? Ƿidsiþ 06:28, 25 June 2011 (UTC)

[edit] Adding en: to topical categories

Is there any way to do this, recategorize the entries adding en:? I'm not quite sure how to do it. Obviously something like [[Category:English nouns]] to [[Category:en:English nouns]] is unacceptable. Thoughts? And what about {{context}}, is that up-to-date yet? Mglovesfun (talk) 22:44, 29 June 2011 (UTC)

Yes, I updated {{context}}. Either {{context|grammar}} or {{context|grammar|lang=en}} should categorize an entry into Category:en:Grammar. --Daniel 11:10, 30 June 2011 (UTC)

I trust you first went through all our entries adding lang= to context tags in non-English sections.—msh210℠ (talk) 16:11, 30 June 2011 (UTC)

No, msh210, I didn't do that. If a Mandarin section has {{context|grammar}} today, it is incorrectly categorized. If the same Mandarin section had the same code before the creation of categories with "en:", it was incorrectly categorized as well. I did not solve that problem, and I did not introduce that problem, because that's not my problem. --Daniel 10:01, 1 July 2011 (UTC)

That's been a problem for years and years; if anyone knows how to solve it, be our guest! Mglovesfun (talk) 10:15, 1 July 2011 (UTC)

AF ~~KassadBot~~ A bot can do it easily: check the language header and add lang=foo to any context tag that lacks it. it doesn't even have to be sure it's a context tag: there's nothing wrong with adding that parameter to a non-context tag on the definition line. I have longed for such a bot for a long time.—msh210℠ (talk) 18:58, 1 July 2011 (UTC)

I would prefer it if the language were always required, so that we could find these errors without bots. The template could add the entry to a cleanup category if the language is missing. —CodeCa t 19:05, 1 July 2011 (UTC)

That's not inconsistent with having a bot add the parameter.—msh210℠ (talk) 19:31, 1 July 2011 (UTC)

But it would allow us to rely on bots less. Bots come and go as their owners join and become inactive, but a cleanup category will always work. —CodeCa t 19:46, 1 July 2011 (UTC)

Maybe you could check whether the first part of the category is the name of the language? Something like... 'if there is a category in the English section and its name begins with English, it shouldn't be prefixed'. —CodeCa t 23:17, 29 June 2011 (UTC)

Good idea. --Daniel 11:10, 30 June 2011 (UTC)

I'll work on it. Mglovesfun (talk) 10:15, 1 July 2011 (UTC)

I've come up with a heavy, ugly yet perfectly good way of doing it using User:MglovesfunBot/switch. The switch is perhaps so big, it's impractical to use it in the number of entries we're talking about. Like all of them! Mglovesfun (talk) 11:02, 1 July 2011 (UTC)

But your switch would only work if there were a way to separate the language name from the rest of the category name. And in any case, we have {{langrev}} now which is faster than your switch but it does the same. —CodeCa t 11:19, 1 July 2011 (UTC)

That is how it works (in reply to sentence 1) and I've changed the switch (in reply to sentence 2) but... I have found an unexpected bug. Shouldn't be too hard to fix; but will have to think about how to modify the code so it can't go wrong again. Mglovesfun (talk) 16:39, 1 July 2011 (UTC)

[edit] New-look layout?

In the midst of a session (10:50ish BST) the screen layout changed in Firefox (but not Chrome) - looking at mo I have an clickable list of languages in boxes down the LHS and only the clicked language is displayed - I'm not aware of doing anything to make this happen - and it's there before I log on. Looked at Announcements - Community portal etc

I think I like it - but can someone explain ? —Saltmarsh^{talk-συζήτηση} 10:09, 30 June 2011 (UTC)

Sounds like you enabled tabbed languages, either through WT:PREFS or the gadget or the button in the beer parlour or here or through my userpage. (I didn't accidentally enable it for everyone or something, did I?) --Yair rand 10:14, 30 June 2011 (UTC)

I now feel rather stupid - I'd copied textbox/button wayback in April as a "sample" - and promptly forgotten that it actually did something! Sorry to have bothered you! —Saltmarsh^{talk-συζήτηση} 10:21, 30 June 2011 (UTC)

[edit] Bad category name generated by template obsolete

Applying {{obsolete}} to clepest generates membership in Category:English terms with obsolete senses. It is the form not any particular sense that is obsolete, though clepe may be entirely obsolete, suggesting the need for yet another category name. These needs to be corrected promptly or the category hidden until it is. DCDuring TALK 19:08, 30 June 2011 (UTC)

I disagree. In my point of view, "Category:English terms with obsolete senses" does not suggest the existence of nonobsolete senses. Therefore, I think that that category should contain terms that are entirely obsolete, among other levels of obsoleteness. --Daniel 10:10, 1 July 2011 (UTC)

It's not a bug, it was an intentional edit by Daniel, I suspect it's in response to the RFM debate that you (DCDuring) started on Category:English rare terms. Mglovesfun (talk) 11:10, 1 July 2011 (UTC)

I am aware of why the context tag generates the name. It has to do with an attempt to overgeneralize some scheme of template operation. (See tail wagging the dog.) I didn't ask that such specific context template design choice be made. It seems to me that the current name generated fits the most common use case of the context tag. As Ruakh had pointed out in the earlier discussion, the "rare" category name does not well fit an ordinary human's understanding of the words in the cases where the term has no non-rare senses. This is an example of another class of cases where an ordinary human's understanding of the category name does not fit. I understand that those who think in mathematical/logical/database/programming terms are not bothered by this. Those manners of thinking characterize a generous portion of contributors here, not of internet and Wiktionary users at large. That is why we cannot rely on ourselves, even in the aggregate, as model users. If we are the only users to be considered, then the category name should be hidden.

Alternatively, we might need some kind of switch in the context tag to alter the name or to eliminate the context tag for inflected forms in favor of something like {{obsolete form of}}. I haven't thought through the consequences - not that such lack of thought necessarily prevents notions from being proposed, voted on, passed, and implemented. DCDuring TALK 12:13, 1 July 2011 (UTC)

Maybe the obsolete tag could be moved to the headword line if it applies to the term itself, and kept in contexts if only one sense is obsolete? —CodeCa t 12:31, 1 July 2011 (UTC)

But that couldn't change its categorization behavior, could it? DCDuring TALK 12:37, 1 July 2011 (UTC)

It could if we introduce a new kind of template to be used for headword lines, similar to {{context}} but appearing differently and also putting words in different categories. —CodeCa t 12:41, 1 July 2011 (UTC)

Here are a few possibilities to be considered:

Having two categories: "Category:English obsolete terms" and "Category:English terms with obsolete senses".
Having only one, comprehensive, category with a longer title for all levels of obsoleteness: "Category:English obsolete terms or with obsolete senses"
Having only one, comprehensive, category with a shorter title, for all levels of obsoleteness: "Category:English terms with obsolete senses"

I assure all of them are possible to be implemented relatively easily. Currently, the third possibility is in practice. --Daniel 14:46, 1 July 2011 (UTC)

Of those options I favor the first. The "terms with X senses" category would clearly be populated based on the presence of a single "X" tag in the relevant L2 section. Ruakh had suggested that a bot could populate the "X terms" category, which I assume would mean using Autoformat-like logic to insert a hard category.

I don't believe the category names are appropriate for inflected forms. Inflected forms don't have senses of their own; they inherit the senses from the lemma. Whatever sense they have, they are almost always "rare", "obsolete", "archaic", or whatever on their own. Thus it is the form of the term that is obsolete not the term itself.

Furthermore, we have many cases where there are multiple PoS sections (and even multiple Etymology sections, which probably can be ignored) with a few possible combinations of PoS-level and sense-level "rarity", "obsolescence", etc. This is an intrinsic feature of our page structure. We have overcome the difficulty with respect to L2 sections, but analogous solutions for PoS (Ety-PoS, actually) would require a lot of effort. DCDuring TALK 16:14, 1 July 2011 (UTC)

The second of those three possibilities seems more accurate than the third (and not less than the first) and easier to maintain than the first (and not harder than the third), so the best. However, it should be not "English obsolete terms or with obsolete senses" but something more grammatically correct: either "English terms obsolete or with obsolete senses" (my choice) or "English obsolete terms and terms with obsolete senses" or "English terms that are obsolete or have obsolete senses" or cetera.—msh210℠ (talk) 16:32, 1 July 2011 (UTC)

With regards to using {{obsolete}} for obsolete forms of words that do not necessarily have any obsolete senses, we now have {{obsolete spelling of}}, which populates Category:English obsolete spellings. That seems the exact analogy to the treatment I seek for obsolete forms of lemmas. I suppose that means that I would like {{obsolete}} to be a clean up target to be replaced by {{obsolete spelling of}} or {{obsolete form of}}. DCDuring TALK 21:16, 1 July 2011 (UTC)

Note: {{obsolete spelling of}} populates Category:English obsolete forms, per a decision to delete certain categories of spellings. Category:English obsolete spellings is not populated by any template, and should be deleted eventually. --Daniel 23:16, 1 July 2011 (UTC)

The option 2 surely is easier to maintain, and leaves all terms with a level of obsolescence together, so I'm with msh210: I choose the option 2. More specifically, I vote for "English terms obsolete or with obsolete senses", too.

DCDuring, I fail to see the benefit of separating categories as described in the option 1. It adds a layer of complexity and a second place to look for obsolete things to say. --Daniel 00:46, 2 July 2011 (UTC)

[edit] Autoformat: return to entropy

I again (See #Autoformat above.) haven't seen any evidence of the Autoformat function being performed for the ten days at least. Do we no longer need such automated problem identification? Do we no longer have duplicates and other problems in translation tables? Headers are always in appropriate structural arrangement? etc? As crowds diminish, do we want to rely more on crowdsourcing for this function? DCDuring TALK 21:05, 30 June 2011 (UTC)

I'm sure not, but PrinceKassad runs the bot now and they've been having some problems lately I think. —CodeCa t 21:14, 30 June 2011 (UTC)

We just need someone to run the script. And let's be patient with those who run it. Mglovesfun (talk) 11:10, 1 July 2011 (UTC)

Oh yeah, it kinda died because of unified login issues (since I no longer have a global account)... should be fixed for now. -- Prince Kassad 13:45, 2 July 2011 (UTC)

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. —CodeCa t 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. —CodeCa t 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. —CodeCa t 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 [[Category:English terms derived from {{Template:hbo/family|l=}}]], 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. —CodeCa t 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}}. —CodeCa t 16:27, 2 July 2011 (UTC)

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

[edit] Ido inflection bot

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 [talk] 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. —CodeCa t 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. - TheDaveRoss 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 [talk] 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. —CodeCa t 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 [talk] 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. —CodeCa t 00:12, 4 July 2011 (UTC)

Fully conjugated example: devastar. Is that satisfactory? Tempodivalse [talk] 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? —CodeCa t 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 [talk] 01:30, 4 July 2011 (UTC)

[edit] Page has character in Unicode Private Use Area

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)

[edit] Romanian cedillas again

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|...}}. —CodeCa t 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)

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

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

[edit] Topical categories that don't use topic cat

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? —CodeCa t 13:32, 5 July 2011 (UTC)

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

Thank you! —CodeCa t 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. —CodeCa t 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 —CodeCa t 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. —CodeCa t 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. —CodeCa t 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)

[edit] A template for language families

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. —CodeCa t 19:23, 5 July 2011 (UTC)

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

[edit] An IPA generating template for initialism pronunciation

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 {{IPA|/dʒiːiː/}}? DCDuring TALK 17:47, 6 July 2011 (UTC)

How is this?

IPA: /eɪ biː siː diː iː ɛf dʒiː eɪtʃ aɪ/

IPA: /dʒeɪ keɪ ɛl ɛm ɛn əʊ piː kjuː ɑː/

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

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

And in Dutch:

IPA: /aː beː seː deː eː ɛf ɣeː ɦaː i/

IPA: /jeː kaː ɛl ɛm ɛn oː peː ky ɛr/

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

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

—CodeCa t 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. —CodeCa t 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 IPA: /ˌ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. :) —CodeCa t 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. —CodeCa t 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)

[edit] IE9 search suggestions

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? ~ hey zeuss 08:17, 11 July 2011 (UTC)

Opensearch behavior in Firefox. The tooltip shows the URL of the description file. ~ hey zeuss 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: [[File:Wiktionary-logo.svg|link=Wiktionary:Main Page]] 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: [[File:Wiktionary-logo.svg|link=http://some.evil.address]]. 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 [[File:Wiktionary-logo.svg|link=http://[a blacklisted domain]]], 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.org/wiki/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)

[edit] Luxembourg flag

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)

[edit] Advanced InterWiki template

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 [[language]] 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)

[edit] Template:infl

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 ..., 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 ..., 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 ... (meaning "inherit the language from the surrounding context", and therefore, in our case, meaning "English"), or else treat it the same as ... (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 [[homes]] 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 homes, 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 homes 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 homes . —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. —CodeCa t 10:41, 23 July 2011 (UTC)

[edit] Script support

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. —CodeCa t 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)

[edit] String functions (again :)

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:

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?
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 [StringFunctions] 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.org/wiki/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}}}}

~ hey zeuss 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)

[edit] Partially italicized category name

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? —CodeCa t 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)

[edit] What's going on with the links?

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? —CodeCa t 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... —CodeCa t 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. —CodeCa t 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)

[edit] Unlinking...

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

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

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

[edit] Changing uncountable nouns to countable in definitions

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) 17:25, 30 July 2011 (UTC).

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

[edit] How can one determine what templates/conditions place an entry in a given category?

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 [[Category:Language terms needing attention]], 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 [[D]] 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 [[Category:Language terms needing attention]], 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 [[D]], 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 [[Category:<language> terms needing attention]] 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)

[edit] Nias language

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 [3]. --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" [original emphasis removed, current emphases mine]. 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)

I came up with the idea that templates that don't have two unnamed parameters should be in Category:Translation templates needing attention. It's turned up quite a few results already - ten so far. How would people feel about t, t+ and t- having the same function. Any downsides? Mglovesfun (talk) 22:35, 1 August 2011 (UTC)

No, none? --Mglovesfun (talk) 11:07, 3 August 2011 (UTC)

It's a good idea, but I think a missing second argument should probably just use the normal {{attention}}, rather than Category:Translation templates needing attention. Actually, thinking about it — maybe there should be a "default" category that {{attention}} uses when no language code is specified. If that were the case, then I think a missing first argument to {{tø}} should probably also just use the normal {{attention}}. —Ruakh_TALK 11:15, 3 August 2011 (UTC)

Partly related, the five remaining entries in Category:Translation templates needing attention use a language code and a transliteration with no original script, because the original script isn't known. These are for ancient languages like Sumerian and Hittite. --Mglovesfun (talk) 11:23, 3 August 2011 (UTC)

I quite like the idea of a cleanup category just for translations templates, but I wouldn't object if other users preferred using an established category (that is, one we already have and use). --Mglovesfun (talk) 16:03, 3 August 2011 (UTC)

[edit] Definitions

There are several (8K) sorted definitions from Wiktionary here. This file may be interesting for somebody, I hope. -- Andrew Krizhanovsky 08:42, 2 August 2011 (UTC)

Category: High volume discussion pages

Hidden category: Wiktionary pages with shortcuts

You are receiving this email because you subscribed to this feed at blogtrottr.com.
If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

Wednesday, August 3, 2011

Wiktionary - Recent changes [en]: Wiktionary:Grease pit