Wiktionary:Grease pit/2007/March

There's something wrong with the tea room all I see their is what looks something like Java. Just go there and you'll see. Randy6767 01:08, 10 February 2007 (UTC)

Oh dear -- Java tea is a herbal medicine, not a real tea at all! Seriously, if belatedly, the page is OK for me now. --Enginear 11:57, 10 February 2007 (UTC)

This was moved here from Wiktionary:Beer_parlour

1. missen - each of the inflected forms is linked. I think that this is good - the forms need creating because those unfamiliar with the language may have difficulty finding the 'basic' form.
2. hablar - the person and number are detailed. I think that this is also good - those unfamiliar with conjugation tables may not understand. —Saltmarsh 10:43, 24 January 2007 (UTC)

• καλή an inflected form of καλός. As Connel says - I think that the each form should be identified. But there is a lot of labour here! —Saltmarsh 10:43, 24 January 2007 (UTC)

I still see no solution here for the problem I posed in WT:BP#.7B.7Binflected_form_of.7D.7D_of_more_specific. Suggestions? henne 21:30, 12 February 2007 (UTC)

Some of these templates are called xx-verb others xx-conj. Is there a convention? Does it matter? —Saltmarsh 10:54, 24 January 2007 (UTC)

We've tended to use xx-verb for the POS inflection line (just under the POS header, e.g. {{en-verb}}), so that shouldn't be used for inflection/conjugation tables. I'd recommend xx-conj for verb conjugation tables, as long as there is no need in the given language to have a template for conjunctions. In the majority of languages, this shouldn't be a problem. --EncycloPetey 16:46, 24 January 2007 (UTC)

Agree. henne 21:30, 12 February 2007 (UTC)

Hi :) Can someone here who is super good at code set it up so the "ergative" template automatically tags the article as "Category:(Language) ergative verbs", where "(Language)" is the language of the effected word?? :-) Or is this impossible?? Thank you :-)

Done. henne 21:24, 12 February 2007 (UTC)

Please can someone help me with the "if" syntax in a template {{el-word}}. To be called with one unnamed argument or none:

{{el-word|evró}} or
{{el-word}}

to print

ευρώ (evró) or
ευρώ

Where ευρώ is the PAGENAME. The templates I have looked at for help have all been too nested to understand the syntax. thanks —Saltmarsh 08:40, 10 February 2007 (UTC)

for example '''{{PAGENAME}}''' {{#if:{{{1|}}}|({{{1}}})}} look at the help pages on meta. Robert Ullmann 08:48, 10 February 2007 (UTC)

Side question from the peanut gallery: are Romanizations of Greek wikified? E.g. {{#if:{{{1|}}}|(])}}? Also, FYI: m:Magic words & m:Parser function. --Connel MacKenzie 15:43, 11 February 2007 (UTC)

Greek Romanizations are not wikified. Atelaes 19:32, 11 February 2007 (UTC)

I have moved the last bit of this to Wiktionary:Beer parlour#Romanisation - wikified? —Saltmarsh 15:21, 13 February 2007 (UTC)

Can we use Javascript here? At Wikipedia I can "point" to a history link and get a nice popup listing everyone's contributions to an article without having to "click". It also can pop up a "diff". --Ed Poor 20:51, 12 February 2007 (UTC)

I recommend using WT:PREFS for the popups Javascript. --Connel MacKenzie 21:32, 12 February 2007 (UTC)

After patrolling an edit, a screen comes up with the option of patrolling anon's, logged-in users, or both. However, the "both" option only brings up unpatrolled logged-in changes. I don't know which page is being brought up (or if it's even a page), and so don't know how to fix this. Is anyone else having a similar problem, or a solution to it? Or am I simply doing something wrong? Atelaes 06:16, 13 February 2007 (UTC)

That's what you're supposed to see. That doesn't mean it's supposed to make sense. But, there it is. --EncycloPetey 06:23, 13 February 2007 (UTC)

Also, is this the proper page for this sort of question? Or is there an "I'm a retarded admin" page somewhere? Atelaes 06:20, 13 February 2007 (UTC)

This is the proper place for technical questions, though the IRC can be a good place too. --EncycloPetey 06:23, 13 February 2007 (UTC)

Don't think you're retarded. I hadn't even noticed the lack of anons. --Enginear 19:46, 13 February 2007 (UTC)

1. This is probably the best place to ask this sort of question.
2. IRC is good also; was your question answered adequately, there? (The answer given there, was, go to WT:PREFS, turn on "Popups", "Patrol", "Enhanced patrol", "Refresh patrolling", then in Special:Preferences turn of the mediawiki default "Enhanced" Recentchanges display.) So yes, you were doing something wrong, sortof...that page is obsolete. If you see it at all, you are probably doing it the hard way. If instead you use "popups" to hover over a (diff), you can then click on the (mark) link, and go the the next one (saving quite a few page loads in the process.)

--Connel MacKenzie 06:41, 16 February 2007 (UTC)

It's still not working for me quite as you described. (I'm still on IE7 if that's relevant.) I've turned on "Lupin/popups", "Patrolling enhancements", "Patrol in "expert mode" with no alerts", and "Refresh Special:Recentchanges every 5 minutes". I've deselected "Hide minor edits in recent changes" and "Enhanced recent changes". It all works as you say, except that when I hover over a "diff" I can't find anything amongst the large number of pop-up options which looks like it could mean "mark as patrolled", so I have to click the diff and then click the "mark as patrolled" button. --Enginear 20:29, 17 February 2007 (UTC)

The mark as patrolled option isn't in the popups, it's on the original screen. What happens for me (and what I'm assuming is supposed to happen) is that you pull up the RC page, wait a few seconds, and then a new button called "mark?" magically appears between "diff" and "hist". You hover your cursor over diff for a few seconds, popups shows you the changes, then you press "mark?". Nothing visible happens, but if you refresh the page, all the entries that you hit the mark? button will disappear (if you're hiding patrolled edits). With new pages it's a bit more complicated. Usually on a new page, the mark? still appears, but off to the side somewhere, and sometimes it just doesn't show up at all. That make sense? Atelaes 20:45, 17 February 2007 (UTC)

That doesn't happen for me. Nothing clickable appears. --Enginear 21:04, 17 February 2007 (UTC)

Huh. Then I have no idea. Perhaps someone else does. You could consider switching from a corporate monstrosity (IE) to an open source beacon of light (Firefox). You'd be amazed at what that can do. In addition, you'll feel better about yourself as a human being. :-) Atelaes 01:33, 18 February 2007 (UTC)

That's my POV too...I'm just not that good at getting around to it. ;-) --Enginear 09:43, 18 February 2007 (UTC)

• D'oh! Thanks for the reminder. No, advanced patrolling still hasn't been rewritten to work with Microsoft abominations Internet Explorer. (Disclaimer: not entirely IE's fault: I used a dirty-coding shortcut of "innerHTML" to do it, which IE rightly scoffs at...but then again, *all* of Javascript is a dirty little hack, so meh.) --Connel MacKenzie 06:47, 23 February 2007 (UTC)
  • In the meantime, nudge, nudge! --Connel MacKenzie 06:49, 23 February 2007 (UTC)

I created and account and logged in using Firefox 1.5.0.9 but whenever I move to a different page, Wiki tells me I'm not logged in and that I must create an account.

What do I have to do to get Wiktionary to accept my login and keep me logged in? Cookies are activated. This is a major waste of time.

Thanks, ricked/ricked2

(collapsed two sections together)

I've logged in repeatedly but whenever I move to a different page the login prompt in the upper right corner of the page recurs and wiki tells me I'm not logged in and that I must create an account. I'm using Firefox 1.5.0.9 and cookies are enabled.

What do I have to do here? This is ridiculous.

Ricked2

I'm using 2.0.0.1 so I can't directly to reproduce it. Are you checking the box (remember my login ...)? (Not sure what that box is supposed to do exactly, keep you logged in until you log out?, but it always works better to check it.) Robert Ullmann 08:59, 16 February 2007 (UTC)

I use that version of FF without problems. Perhaps there is a firewall between you and Wikimedia that blocks cookies? --Connel MacKenzie 06:38, 23 February 2007 (UTC)

The likely suspect is webproxy48 (not the exact proxy name; but you should be able to ascertain the proxy settings you are using from there, and contact the proxy administrator, requesting a cookie exemption for *.wikipedia.org, *.wiktionary.org, *.wikinews.org...) --Connel MacKenzie 06:43, 23 February 2007 (UTC)

What Is Mount Point In Linux ? — This comment was unsigned.

It is the place where a device is logically mapped. In *nix, since all filesystem things descend from "/", there has to be a logical place to mount a device, for example a disc on the device /dev/cdrom. Since the OS gets persnickety if you try to access /dev/cdrom directly, the normal practice is to "mount /dev/cdrom /mnt/cdrom" so that the particular type of CDROM is recognized properly. --Connel MacKenzie 06:38, 23 February 2007 (UTC)

I've created templates for four-column derived and related terms and used them to format the derived terms section of time, which is very long. The only thing is, the columns don't seem to be coming out the same width - the first column is much wider than the other three. I've set the widths to 24% each, like top4 and mid4 already have. Can someone see what's wrong and fix it, please?

Could someone also remind me where info on new templates is supposed to be posted, please? Thanks. — Paul G 20:06, 23 February 2007 (UTC)

I fixed the typo on time. Templates are listed at WT:I2T (index to templates) or a subpage of it. --Connel MacKenzie 07:34, 25 February 2007 (UTC)

Thanks. What was wrong with it after all? — Paul G 08:19, 25 February 2007 (UTC)

I've updated WT:I2T#Columns with the new templates and an explanation of when to use which, and how to use them. — Paul G 08:47, 25 February 2007 (UTC)

You're welcome. The two typos were: you used {{rel-top}} instead of {{rel-top4}} (after creating it) and you forgot to update {{bottom}} to {{rel-bottom}} to close the multi-column DIV properly. --Connel MacKenzie 02:46, 26 February 2007 (UTC)

So, I know the wiki philosophy is "be bold," but I fear this time I may have been a bit too bold. I sent an email to www.perseus.tufts.edu, which is a classics website, which happens to have a copy of the Lewis & Short Latin dictionary (which is the most prestigious Latin dictionary, as I understand it, and is conveniently also out of copyright). I asked them if we could get a copy of it from them, and rather surprisingly, they said yes! However, here's where the trouble begins. I'm completely techno-illiterate. Here's a copy of the email. Could someone more intelligent than I interpret for me and tell me what to do next?

Hi Jesse,

We can give you the Lewis and Short as TEI XML, if you're interested (although it's pretty hefty--around 70MB). I don't know if you store the definitions as anything more elaborate than Wiki markup, but you could probably extract them from the XML using a stylesheet. Would this work?

-- Adrian

Any help anyone could give would be GREATLY appreciated. Atelaes 20:31, 27 February 2007 (UTC)

Fantastic. I'll get the first pass parsing done (as we are discussing on IRC) and we'll see where it goes from there. You'll start the WT:BP thing about the template, and the WT:VOTE for User:LewisAndShortBot right? --Connel MacKenzie 03:08, 28 February 2007 (UTC)

I stumbled upon this template recently. I think it could be useful, if some CSS is used to enable people to not see it, or see it in some other romanisation system or... Should similar templates be made for other scripts, or languages? H. (talk) 15:27, 1 March 2007 (UTC)

SemperBlotto recently asked, in WT:RFV what was causing the {{{1|definition}}} type entries that anyone doing patrolling has seen in abundance. It's caused by the "basic entry" button pre-fill:

==English==

===Noun===
{{en-noun}}

# {{{1|{{substub}}}}}

...is what you get. Personally, I'm not sure this is more helpful than the output for Noun, which is:

I still see nothing of the formatting that was decided there, e.g. reduced. I suppose this has to be done somewhere in Monobook.css, but I am not familiar with the inner workings of that. Can somebody take on this project? Shouldn’t be too difficult, is it? I would appreciate if somebody explained me how this is done, then maybe I can do it myself in future. H. (talk) 15:31, 1 March 2007 (UTC)

First we'd need a way to determine what script a word were written in. It would be possible to physically split all of the templates, but it would probably better to rely on a lang tag or even a mediawiki extension to accomplish this through software. DAVilla 18:15, 24 March 2007 (UTC)

Why is it that some languages (Old Prussian is the one I first noticed) appear in the list sometimes, and then disappear when it is updated, only to reappear when it's updated again, re-disappear, re-reappear, and so forth...? To give an example: the Old Prussian language appears in the 27 Sept dump of last year, is nowhere to be found in the 17 Oct dump , reappears on 24 Dec , and disappears again on 25 Feb . What's happening? -- Beobach972 23:04, 6 March 2007 (UTC)

Oh, thank you. I have been trying to refine the statistics regularly; I'll keep a close eye on that case this next time around. One task I intend to do, is to overhaul how I generate those statistics - anyone that wants to, is welcome to try themselves. Currently, there is no separate column for "form-of" items (e.g. past participles, plurals, etc.) nor is there any distinction for the number of definitions for any given entry. Since I now have to choose between this, importing Lews&Short, or real work, I may actually get to this now. --Connel MacKenzie 02:21, 11 March 2007 (UTC)

Well, it has been a couple hours, so I'm getting close to having something usable. My question now, is, should the new analysis replace that, or suplement it? --Connel MacKenzie 04:16, 11 March 2007 (UTC)

Perhaps the first time around it should simply supplement it, as I for one don't have a solid grasp on what the new and improved Wiktionary Statistics shall look like. Perhaps once people see it in action, they'll have a better idea of how to answer that question. Atelaes 04:44, 11 March 2007 (UTC)

• Yipes. That was harder than I thought it would be. And messier, too. Wiktionary:Statistics#Detail. --Connel MacKenzie 06:10, 11 March 2007 (UTC)

I prefer the new analysis to the old one, it is more detailed (and as it contains all of the information present in the old analysis — and more! — I see no problem at all with it replacing the old one). -- Beobach972 04:03, 12 March 2007 (UTC)

Strange. Are Middle English entries supposed to be marked "archaic"? It seems a fifth of them are. DAVilla 17:54, 24 March 2007 (UTC)

That is strange. I analyze section by section, so those must have those tags within the Middle English sections...which seems just wrong. Did you spot-check any of these yet? --Connel MacKenzie 17:59, 24 March 2007 (UTC)

chould. Not categorized, hard to find. DAVilla 18:38, 24 March 2007 (UTC)

Hm, why does this template not have a plural section? Many proper nouns do have plurals... or are we talking about a very strict sense of "proper noun" that can refer to only one thing (such as "The White House") rather than the wider sense that refers to more than one thing (such as "David" and "Englishman")?

One reason this should have a plural section is that it is very useful to point out that proper nouns ending in consonant + y do not change the y to ie in the plural, unlike common nouns: for example, "Patty", the female given name, becomes "Pattys", while "patty", the food, becomes "patties". Example: "There are three Pattys in my class"; "I had two patties for lunch". — Paul G 14:59, 7 March 2007 (UTC)

Sure it does. It just defaults to not showing a plural, which is the usual case. See {{en-proper noun}} Robert Ullmann 15:14, 7 March 2007 (UTC)

Ah, thanks for that. Sorry, I hadn't read the documentation. — Paul G 13:35, 11 March 2007 (UTC)

Even proper nouns in the very strictest sense still have plural forms:

• 1908, Gilson Willets, Inside History of the White House, page 41

  These periods may, for the sake of convenience, be said to embrace what may be called the first, second and third White Houses

Or a better example for The Great Wall of China comes from a ESL textbook, approximately: Six Great Walls placed end to end would stretch around the circumference of the Earth. DAVilla 18:06, 24 March 2007 (UTC)

But that's not really the same thing as a plural. That is an example of hypothetical duplication for metonymy. The essence is the replicated measurement of the Great Wall, not the existence of more than one Great Wall. This is an exceptional use of proper nouns limited to the subjunctive, not a standard one. --EncycloPetey 18:45, 24 March 2007 (UTC)

Hey, we have all these indexes (or indices for you purists) such as Index:Polish, Index: Romanian, Index:Swedish which are relatively barren. We have tons of entries for words in these languages that are not reported in said indexes. These seems like a problem capable of solving itself with a minor amount of lubrication, eh? bd2412 T 15:04, 19 March 2007 (UTC)

I've been working on some Wiktionary-specific extensions to MediaWiki, the software behind Wiktionary and Wikipeida. One of them allows you to access a live index of each language: index of Ancient Greek

Note that this development wiki does not contain a full copy of Wiktionary since Brion didn't have so much space on the server he let us use. Feel free to import or create some articles to see them added to the index. — Hippietrail 18:13, 19 March 2007 (UTC)

Investigating this I noticed that 120 pixel thumbnails don't display for me:

should look almost identical to

but the 120px one doesn't display. Is this a wiki bug? Does anybody know what's going on? Cynewulf 22:22, 21 March 2007 (UTC)

I see the same thing; the generated HTML looks right, but the WM s/w returns nothing for the image (not even broken link). I can work around it in the template (of course ;-) but something is broken. Robert Ullmann 15:32, 22 March 2007 (UTC)

They both look fine to me. The problem may be browser or platform specific. --EncycloPetey 18:28, 24 March 2007 (UTC)

Wow! It displays in IE, but not in FF! --Connel MacKenzie 03:49, 25 March 2007 (UTC)

Now both display for me... Cynewulf 13:33, 25 March 2007 (UTC)

I asked a few times in #wm-tech, and some anonymous developer tweaked whatever it was that needed to be tweaked, I guess. Looks fine to me now, but I have no idea why. (Other than developer magic, of course.) --Connel MacKenzie 17:00, 25 March 2007 (UTC)

(now if we could get some magic on Special:Wantedpages... Cynewulf 17:04, 25 March 2007 (UTC)

Hi, is there some reason that we are supposed to use brackets around lemmata in a plural templates (i.e. {{plural of|]}} rather than {{plural of|mongoose}}). I seem to recall being told to so this before (and have been doing so) but I don't recall why, or why this is necessary in "plural of" templates but not in any others (unless it is necessary in others, in which case... oops!). Cheers! bd2412 T 04:56, 22 March 2007 (UTC)

As it was explained to me by EncycloPetey, it is because the linking which the template adds does not count as a "linked" article. If an article does not contain any links, it does not count as an article. I don't know why this is, but that's what's been told to me. A plural article probably does not have any other links, and so if the parameter is not linked in the template, the article will not count as a "good article". Atelaes 05:22, 22 March 2007 (UTC)

Can we not make the template do this automatically? Perhaps by subst'ing in the brackets on either side of the word when it is laid down? If not, we should have a bot run through all the "plural of" entries and add the brackets where they are lacking. And is this necessary for other part of speech templates as well? bd2412 T 13:08, 22 March 2007 (UTC)

No, you can't fix it in the template; it has to be in the page wikitext. This is why the wikilinking was made conditional in the template, so bot or bot-like action could link it in the call. Some of them have been done that way. Robert Ullmann 15:34, 22 March 2007 (UTC)

The bot did run initially, as a one-time run. I've completely forgotten that I intended to re0run it once a year, or so. I'm not sure that having that bot run continuously, is such a good idea, anyway. Moods change, policies (when they exist) change, general sentiment changes. Hopefully, with the new statistics page I generated, this has even less importance than it used to. Perhaps, with a reminder, after the next XML dump, I could run through this again, just for old-time's sake. --Connel MacKenzie 17:55, 23 March 2007 (UTC)

It still affects the page count displayed on the main page. --EncycloPetey 18:27, 24 March 2007 (UTC)

Aye, another run of that bot would be a good idea - why wait for the dump tho, couldn't it just read everything in Template:plural of now? bd2412 T 18:42, 24 March 2007 (UTC)

I just edited β, and could not get it like I want it. The problem arises when entering right-to-left symbols, particularly in {{see}}. I added the Hebrew, Arabic and Phoenician cognates there, however, the diff link for Hebrew is on the wrong place. Moreover, I cannot get them in the order I want them. Who has experience with this, and can share some tips on how to get this to work in Firefox or an external editor? H. (talk) 12:30, 22 March 2007 (UTC)

Cutting and pasting each RTL item onto a separate line, then pasting them into the {{see||||||||||}} line has worked for me, in FF, on occasion. It seems more effacious to push for en.wiktionary.org to adopt Hippietrail's <DidYouMean> extension. (Oh no, wasn't I supposed to start a WT:VOTE for that? Well, anyone can start it...) --18:01, 23 March 2007 (UTC)

Well, you learn to work with it. If you see some strange stuff like ]]] or similar, it helps putting some Roman letters (ltr) on that line, that will split it up. H. (talk) 17:06, 30 March 2007 (UTC)

• Tim just committed some MW software changes. http://lists.wikimedia.org/pipermail/wikitech-l/2007-April/031064.html and further down in that thread, http://lists.wikimedia.org/pipermail/wikitech-l/2007-April/031083.html from just a couple hours ago. Do these changes help force the editbox to go RTL for you? Does it work, at all? Since I can't read that language, I can't tell if it works or not, here. --Connel MacKenzie 05:35, 1 May 2007 (UTC)

Could somebody please add more parameters to this template? I need at least 40 on α. Discussions about whether those should be there can be put on that talk page or mine, but please add the params anyway. H. (talk) 14:11, 22 March 2007 (UTC)

It involves adding a lot of conditional text to every call; it probably shouldn't have been expanded even to 20. We either want a see-extended template with a lot, or a better method once it is more than ~ 10. (note that it is hard to reduce the count later, one has to check the entire wikt for calls, so please don't just add more right away ;-) Robert Ullmann 15:19, 22 March 2007 (UTC)

Okay, I'm going to make a shocking proposal here: for entries for which there are more than, say, a dozen variations to which a "see also" should point, we should just make a separate page - perhaps an Appendix - of variations of that entry, and replace the "See also" atop the page with a link to that page. Keeps us from having to replace it on dozens of pages if there's some change in the order or format of that particular "See also" section. Cheers! bd2412 T 15:43, 27 March 2007 (UTC)

Just make it a template; there won't be a shocking number (;-) and then include it on those pages. It can use the appropriate CSS span-class stuff without all of the conditionals. And it will save updating all of the pages in the set. So, like Template:see-also-B would cover all the B, beta, etc. Ask Hippietrail, so it will play nicely with his extension? Robert Ullmann 15:51, 27 March 2007 (UTC)

I've put all the variations of "a" (that I could find) in Appendix:Variations of 'a'. Actually, there are probably very, very few terms that would need more than a dozen "See also" parameters in the first place (in fact, I can't think of another). Obviously this appendix will need lots of fixing up to be useful for anything, but I think it's the best solution to this particular quandary. bd2412 T 16:01, 27 March 2007 (UTC)

I like that, thanks. I will be doing the same for other letters. The problem is: what is the reference letter? α brought up the problem, but you made it Appendix:Variations of 'a'. But what to do with, e.g. θ or even 𐤑? Just take the best-known reference letter, I guess. H. (talk) 09:44, 28 March 2007 (UTC)

This being the English language Wiktionary, I think anchoring the appendix to the letter 'a' is appropriate. As for θ and 𐤑, I don't see that there are enough variations to require an appendix rather than a template. bd2412 T 18:59, 28 March 2007 (UTC)

For sake of uniformity, I’d like an appendix. And wait until I get to theta, you’d be surprised how much is derived from it :-) H. (talk) 17:05, 30 March 2007 (UTC)

Pardon me, but ===Derived terms=== is far, far outside the scope of {{see}}. --Connel MacKenzie 03:50, 2 April 2007 (UTC)

How about a super-long see template specific to > 10? DAVilla 17:56, 30 March 2007 (UTC)

Please, no. --Connel MacKenzie 03:50, 2 April 2007 (UTC)

Why not? It would only be used on a handful of pages, those with more than ten links. DAVilla 07:13, 3 April 2007 (UTC)

Why not just see also an Appendix of like terms then? That way, if something new is added, you don't have to go back and make that addition to every page to which the see also would apply. Cheers! bd2412 T 13:10, 5 April 2007 (UTC)

The appendix system seems to be doing the job. See Category:Variations of letters and Category:Variations of words for examples. Neither is particularly heavily populated (we don't even have them - or need them - for every letter of the alphabet). bd2412 T 04:12, 20 July 2007 (UTC)

Some issues have arisen whilst trying to implement the {{t}} solution that was voted on and approved, for translations in ===Translations=== sections.

Glossary: FL = foreign language. XML dump = http://download.wikimedia.org/ wikt = Wiktionary

1. The ambiguity of the vote, left Dodde unsure whether to link non-existant entries, or not. Several options exist. Does the FL entry exist on en.wikt? Does the FL entry exist on the FL wikt? Should they be linked, even if not? Should extra template code be added to change the color of the link, if the FL XML dump shows it does not exist?
2. What should be done for translations that don't have a FL Wiktionary, at all?
3. What should be done for translations that don't have a FL Wiktionary, and never will, at all? (Due to ISO 3166 vs. ISO 639 conflicts)
4. Should the local en.wikt link go to the proper language section using the "#" syntax?
   1. If so, where will it get the language name from? A second set of language templates that have no wikification?

Add more issues that have come up, for discussion, above. Discuss them, below.

--Connel MacKenzie 07:11, 27 March 2007 (UTC)

• I like the notion of having a separate set of language templates, that are de-wikified. I am not eager to maintain that set of templates though. (Not like I've spent much time maintaining the current set, either.)

• I thought the consensus was to always link translations using {{t}}. But a closer reading shows some ambiguity in the earlier votes. A new vote on the topic must be very specific to only that one issue, or it will degrade to chaos (again) quickly.

• I think having a "dead link" mechanism for non-existant FL-wikts can be accomplished in the same manner the red/blue proposed solution is - with an extra parameter to {{t}}. Just don't have them show up, but still use the {{t}} syntax for consistency/sanity.

--Connel MacKenzie 07:11, 27 March 2007 (UTC)

• Imho it is a very bad idea to use different templates. Just try to keep it simple. This is easier for the users of wiktionary (although the implementation of the template is a little bit more difficult). In addition, the transfer of information between different wiktionaries is a lot easier when you have only one template. It is the same for using the template or not: if you do not have one standard, you run into troubles. On wiktionary NL we use the template trad, which is to be used for all translations. This template is gradually implemented and used by a tool I've written. We currently accept that there are obsolete links to non existent FL wiktionaries. As a simple solution (not the best one though), I asked the devs to enable the m:StringFunctions extension. This extension is not yet enabled, but allows a check on the length of the language code. If it is two characters long, I consider is as correct, otherwise not (e.g. "test" is not a language code but "en" is correct). The only other option that works is to use the parser function #switch (see m:ParserFunctions#.23switch:) and to write one entry in the switch statement for each wiktionary that is supported by the foundation. However, I do not know what the impact will be on the servers for this solution (I guess it's very high impact). Annabelleke 14:59, 27 March 2007 (UTC)

Imho it's a bit too crude a test only to look for length of the language code - not all two-letter combinations correspond to a wiktionary, but otoh there are plenty of valid three-letter codes which does. \Mike 15:06, 27 March 2007 (UTC)

Yeah, that's correct. Forgive me. But when you test on the length (less than four characters), you can already eliminate a lot of wrong entries. Annabelleke 15:17, 27 March 2007 (UTC)

Actually there's a much simpler solution to the test you want to perform, which is implemented in a different way at {{language}}. You can check the #language: of the parameter against the parameter itself. If the parameter is not recognized as a language by MediaWiki, then the two will be equal. Only true language codes are recognized (and converted) by the #language: function.

However, this doesn't address the issue of whether the FL Wiktionary actually exists. You are correct that a long switch statement will finally be aborted down the length of the page. A work-around to switch statements is an array of templates such as Template:FLW-xx where xx is the language code. But I'm sure an at least slighly more elegant solution will be discovered here. DAVilla 08:55, 31 March 2007 (UTC)

I don't understand the ISO 3166 reference? (It is the codes for countries, used as TLDs.) We never use these anywhere, in internal coding or in the names of the projects. (Japan is jp in 3166, so Japanese websites end with jp, but we use ja, the ISO 639 language code, everywhere in Wikimedia: ja.wiktionary.org, ja.wikipedia.org, etc. Just because those are domain names doesn't mean they have any connection to 3166, it applies only to the TLD.) Forget 3166, there are no code problems there. Robert Ullmann 16:00, 27 March 2007 (UTC)

Regarding discussion about translation templates, its syntax and functionality, here's what I imagine:

Two different translation templates are needed, one for basic need which will probably be used 95%+ of the times, and one with more code covering all extra functionality that would be needed for special cases, such as linking to two different norwegian wikts, the chinese wikts and customizable internal link-text etc. I have made a template for the basic need {{t2}} to work with. This should later be renamed to {{t}} . With this template I work from the idea of 1) all translations using the template, even if no link is supplied for the foreign wiktionary, 2) no matter if the link to the foreign wiktionary, same template is used, both for red and blue links, 3) an extra set of language templates as {{es}} are to be made, because the existing language templates only works with {{t}} for the TOP40 languages since they are provided in the templates naked, with no brackets. ({{t-es}} is created as example) 4) links should not be provided to entries of wiktionaries that does not yet exist (this is also a must if we don't want to create many thousands of templates, and I also don't see any reason at all to link to a wiktionary that doesn't exist). If users want, they can still adding translations as normal with ] only, this will be automatically changed by the bot, at later update.

The syntax is {{t2|(colour)|language code|pagename}}.

• {{t2|blue|es|hola}} equals ]^(]) (with blue foreign language-link) and gives the result Template:t2.
• {{t2|red|es|hola}} equals ]^(]) (with red foreign language-link) and gives the result Template:t2.
• {{t2|es|hola}} equals ] (the foreign language-link is being surpressed) and gives the result Template:t2.

~ Dodde 21:47, 27 March 2007 (UTC)

Looks good. However, I would make the color option named, it will make the code much easier. Maybe there can be an extra possibility like ‘check’ which indicates that the color has to be checked. This can then be done by a bot. Likewise, a value ‘none’ is also possible. You can then switch on it, ...

Another idea is to have the Template:t-lang templates also for non-existant wiktionaries, and code in there that it is not existant. That would make it possible to check on that and leave the subscript out in that case. This is another argument for making an extra set of templates. No need to make them all at once, it can be explained in the talk page of {{t}} how one can add such a new template if one links some obscure language. H. (talk) 11:37, 28 March 2007 (UTC)

Not thinking at all about the server load, I would say that linking to entries where the FL wiki itself does not exist, should be avoided. We don't know if the wiki will ever exist, there might be a typo, etc. But it is to be hoped that if the FL wiki exists, eventually it will have the desired word entry (and if a link to create it is provided, someone may take the initiative). I'd prefer the links to nonexistent entries to be set red automagically by the {{t}} somehow. Now, having said that, I have no idea what this means for server load or what capabilities the template processing engine has for checking existence on the fly etc. Anyone willing to point me to some reading? ArielGlenn 05:37, 28 March 2007 (UTC)

We should have a solution for the link to the FL wikt (link in superscript). Can someone explain me the problem with {{language}}? As I understood, there should be problems regarding the performance of teh server.

I really do not like the syntax of a translation template, where one needs to fill in whether a link should be red or blue. This needs be checked automatically (so issue 4 should be handled automatically). I am working on Transtool, so that it can be used to transfer translations between different wiktionaries. With such a syntax (manually entering blue / red) you're asking for troubles. Please try to keep it simple as possible for the end user (max two templates ({{t}} and {{t2}} for linking to different wikts, and with as few parameters as poddible).

Annabelleke 08:16, 28 March 2007 (UTC)

Yes, when you add a translation (atleast from a technical point of view) there is no difference if you add it as Language: ] or as Language: {{t|language code|translation}} which will give the same output. The intention is not for the blue/red argument to be set manually. This will be set automatically by a bot upon a new xml-dump to check against. So nothing has to be more complicated than before for the end user. Regarding the server loag, I would guess that atleast 80% of the translation actually are to languages which in fact do have their own Wiktionary even if a lot less of these actually will provide an entry at this point. Letting translations use the template even for non-existent wiktionaries just is about those extra 20% or less percent and wouldn't have that huge impact on server load, am I wrong. By having all translations using the translation template though, some pointed out for me, the gain is uniformity in the translation section of the edit text without a messy mix of ] and {{}}'s. ~ Dodde 08:33, 28 March 2007 (UTC)

Oh, I see. Running a bot is a possibility, but then you might have thousands of bot edits, which do not contribute to the Wiktionary (I mean, no new entries, no new translations, etc.). The best way to solve this problem is to alter the software, one should update the Parserfunctions extension, to check for the presence of valid interwikilinks (valid links can be checked, see e.g. m:Template:If interwiki link). Annabelleke 08:50, 28 March 2007 (UTC)

I don’t see the problem with those bot edits. What must be, must be. For me, the layout of entries is as important as meaningful content.

Regarding transtool and different templates: it is already too late for that, fr.wikt uses fr:Modèle:trad-, fr:Modèle:trad and fr:Modèle:tradmême. But maybe if we find a good solution here, we can convince them to give that up.

I’d like to stress again that I think the FL link should always be there if that wikt exists, no matter whether they define it or not. I think the color of the link is less important. H. (talk) 11:37, 28 March 2007 (UTC)

Hamaryns, You are right regarding the message you put higher up in the discussion, {{t-lang}} would need to be created for non-existing wikts aswell, for {{t}} to work correctly because of the use of anchors. {{t2|es|hola}} is the suggested syntax for the surpressed FL-link, so no value 'none' is needed. The languages currently used in translations on enwikt can be created by bot, but ofcourse in the future probably new languages will be used in the translations list an,d these has to be created upon adding that particular language in the translations list. If the language code doesn't exist in the set of {{t-lang}} templates, the output will be visibly wrong. However, I think you are wrong talking about "too late" for anything.

Annabelleke, yes it is good if the mediawiki software can be changed so that bot changes aren't needed to update which entries that exists on the foreign Wiktionary. But the question is if this will be done, I surely don't know how, and I don't know who would implement this. For it to work, MediaWiki has to make one request to a foregin database for each translation. Does this mean less server load than to call Template:t-lang the same amount of times for the language name that corresponds to the language code given in syntax? Question is also a matter of time. Will this be done done pretty much right ahead or will it put on a todo list that can take one month if lucky or an eternity if unlucky? The system with bot modifications as suggested above for maintaining this templates and which to link to with red or blue links and which not to link to, is that the way to work on meanwhile finding a better, integrated method, do you think, Annabelleke? Regarding the use of {{language}} I am not sure exactly how it works, but containing 3 times as much code as {{t2}} itself, and 20 times more code than the suggested {{t-lang}}-templates, it doesn't seem to me to be an effektive method regarding either server load nor the bandwith usage. Is the reasoning wrong? Discussing technical solution regarding changing the mediawiki software won't make me any wiser, since I know nothing about that. What I would like to know though, is to have a clear answer if I should continue working on this bot-solution, or if I should not.

~ Dodde 20:15, 28 March 2007 (UTC)

Well I understand the problem of performance now, so please forget what I have said about the {t-xx} templates. In addition to my remark on the bot edits: I do not like bot edits for this type of edits. But if there is general agreement that the user should see the link in red if the page in the FL wiktionary does not exist, please continue with your work. Annabelleke 09:37, 30 March 2007 (UTC)

Miscellaneous comments in random order:

Dodde, please listen to what people are saying. The link to the FL wiktionary should exist, no matter what color it is. No one really cares if it is perfectly correct or not, rather, only that the link exists so a person can go to that FL Wikt: to see what's up.

The "color" template parameter must be optional. No human is likely to do that checking, only Dodde's bot. So it should be the only Username that makes those edits. I suspect it will be similar to RobotGMwikt's issue: human interwiki links are wrong a great majority of the time.

The separate set of language templates seems to solve a lot of long standing problems. Other things have had to work-around the lack of them previously. (Stats, Wiktionary: pages, etc.) If we finally did have a set of templates that define all the possible Wiktionaries we can reach by interwiki links, lots of things are inherently easier. Trying to overload the TOP40 templates is just a bad idea. Those templates have a well-defined use, and this is quite something different, with a much more limited scope (only languages that have Wiktionaries.)

Adding the non-existent language codes seems like the wrong way to go. Since they ultimately probably will exist, it doesn't seem very useful to define them as never being able to exist.

Brion had said it was ISO3166 - I did not check. But the two letter codes used by WMF are not ISO 639-3!

--Connel MacKenzie 20:24, 29 March 2007 (UTC)

Aren’t they ISO 639-2? H. (talk) 17:02, 30 March 2007 (UTC)

Also of note: Special:Whatlinkshere/Template:es is still broken, from {{trad}}. --Connel MacKenzie 20:54, 29 March 2007 (UTC)

Can you explain this? I don’t see what’s the problem. H. (talk) 17:02, 30 March 2007 (UTC)

Annabel, I don't understand where {{language}} is being used in this scheme. The translations are entered like this (from what I understand of the proposal):

<nowiki>* LanguageName: {{t|languageCode|translation}}</nowiki

resulting in

* LanguageName: ] <sup>]</sup>

with perhaps parenthesis or SPANs or whatnot.

I'd like to point out that the initial language name seems redundant. Yes, it makes it easier to sort, and that is the en.wiktionary.org way. But something like:

* {{t|languageName|languageCode|translation}}

would eliminate all of the secondary template lookups at once, and perhaps be more consistent. Did I miss out on an earlier conversation about that particular issue? --Connel MacKenzie 21:46, 29 March 2007 (UTC)

Connel, I have never said that it was used here in {{t}}. I did not know that {{language}} existed, so I when I encountered it, it seemed to be a solution to the problem of checking whether a FL wiktionary exists (which we also need at wiktionary NL). However, now I understand that there are performance issues and that template {language} is not a solution to our problems. Annabelleke 09:37, 30 March 2007 (UTC)

The server performance issues are mostly separate, from the "does it work/will it work" discussions above.

As I understand it, {{trad}} typically will be used by a hundred or so translations on about 150,000 pages (eventually.) Using very, very low estimates for a basis (as I just did) should facilitate reasonable discussion. (Currently, only 21,000+ entries have ===Translations=== sections on en.wiktionary.org. Few have over 50 translations entered, right now.)

So, each time the page is edited, the MW server software has to determine what the template wants done. A hundred separate times. Each time a robot edits the page, to correct a single red/blue link, the WM software has to redo those template evaluations. For each template evaluation, trad forces the MW software to first lookup some other language code template. Assuming miraculous page caching, that means about 200 template "reads" just to evaluate what a page should look like, before saving.

If someone were to then edit one of the templates, the job queue would then tag 150,000 pages for reparsing, resulting in 200 x 150,000 page reads and 150,000 page writes.

The proposed solution of using the existing language templates puts the WM servers at greater risk of a sysop mistakenly editing one of those templates, causing a nice backlog in the job queue. Also, it simply doesn't work, in most cases.

The notion of using a Javascript thingamajig to check, would possibly work, but at enormous expense to the servers. The client-side javascript would be checking existince of every page on FL Wiktionaries, on every en.wikt: page view. (That is, 100 extra full URL anonymous requests performed by the javascript itself.)

It would be really nice if the WM software allowed en.wikt templates to somehow detect the existence of a FL wiktionary entry, and change the color of the link based on that. But at this point, we don't have a reliable way of telling what FL wikts even exist, let alone if a particular page exists there.

Dodde's idea of checking the local en.wiktionary page's existence, (in combination with whether the FL wikt exists) could give a reasonable expectation of what to expect on the FL wikt.

The idea of having Dodde's bot check the FL wikt's is appealing. His bot could then add the optional "color" parameter for any given link (perhaps yellow-green, if the bot thinks the link exists, orange if it thinks it does not, black if the FL wikt does not exist?) His bot could also be responsible for unifying the syntax from any of the formats we currently use, to the proposed template "t" format.

The idea of having a Javascript client that transforms the three different syntaxes we currently use for translations, into one, on each page view, and assume the FL wikt entry exists, also seems viable.

Certainly, the best case, would be if someone who really knows PHP could work some magic on the WM side of things. But that would generate complaints from Tim, Brion and Jens.

I've pretty much run out of other ideas for making this work.

--Connel MacKenzie 21:33, 29 March 2007 (UTC)

Nice summary. A few comments regarding a few things in your post.

First off, I am not sure what you mean for me to listen to. It has come clear to me that people want a link, no matter if the entry on the FL wikt exists or not, but I have not heard anyone say they want a link to non-existing page on a non-existing wiktionary. H. is writing further up "I think the FL link should always be there if that wikt exists". To me it's pretty obvious there is no reason to link to a non-existing site, and I have heard no one explain why it would. Technically there is no difference though {{t2|es|hola}} without link, and {{t2|black|es|hola}} with a black link. The {{t2}} template parameter is optional, and there is no point in adding it upon adding a translation to a word. Plain and simple. Anchors are also added automatically if language code is given.

I don't understand why you suggest other colours than blue and red for exist and not exist. These two colors seems to me to simplest to understand what they mean. If a link should be provided for a nonexisting page, on a nonexisting wiktionary, it should be black, I agree, though I still would like to just skip the link. (The translation template is still being used though, and the language code is used for the language name in the anchor).

Note that a Wikipedia link has a slightly different color than an internal link. I think it would be nice to have the ‘red’ version be slightly different as well, e.g. orange, or light-red, or whatnot. H. (talk) 17:02, 30 March 2007 (UTC)

I disagree that there is no need for language templates for Wiktionaries that doesn't exist, since the language code will be used for the anchor, but neither language code, nor colour parameter, should be needed to add by the user, since the bot will go it through and change it eventually, so simple {{t|hola}}, {{t|es|hola}} and ] will practically all give the same results (the extra language code will make the anchor right until Doddebot checks it)

~ Dodde 22:38, 29 March 2007 (UTC)

OK, I have a better sense of the server load issues now, thanks for the explanation and the raw numbers. That makes it pretty clear that rendering changes to the pages on the fly is not the way to go (from the server side). And I would strongly argue against doing it via javascript if only for accessibility reasons, although the number of requests that the javascript cient would make per page seems prohibitive as well. Which leaves the bot to alter the pages periodically, or leave them all with links that may or may not point to anything. So, how feasible is the bot? If it runs say once a day on the entire 150,000 pages, checking for existence of entries, that's a huge load, I suppose. But if we let it loose every two weeks, say, then we have pages out of sync for a while. I'm starting to lean towards sttic links to pages *and sites* that just may not be there. If we can get pretty colors though, I agree that red and blue are the colors with standard meanings to the reader/editor. ArielGlenn 01:11, 30 March 2007 (UTC)

I don't consider it as a big issue compared to all other issues discussed here. As a start the bot can check the dumps for information input, whenever they arrive, that means seldom more often than once a month. It would be possible to run the bot daily (or so) checking for newly created and deleted pages on the foreign wiktionaries, and the changed and newly created pages on english Wiktionary, but for that I think I have to do some testing first before I promise anything. ~ Dodde 03:08, 30 March 2007 (UTC)

My apologies, I have been doing all sorts of stuff the last days; I should be contributing to this.

User:Doddebot just started creating lots of t-xx templates, and I don't think I've seen even any mention of doing this by bot? blocked Doddebot for a few hours. Sigh: it is 3AM here, could someone (Connel?) review this? I need to sleep! Robert Ullmann 00:25, 30 March 2007 (UTC)

I asked him to Be Bold on IRC, so everyone could get an idea of what the final result will look like. --Connel MacKenzie 02:08, 30 March 2007 (UTC)

"Wiktionary:Votes/2007-03/Translations - wiki links clarify 3" was withdrawn due to the complexity of the matter. To be able to vote, it's alot easier to see working examples of the various options voted for. The use of the existing set of templates is realised to not be feasible since all templates except the WT:TOP40 ones use brackets and can't be implemented in the code. A second set is discussed to be the only real choice beside altering the MediaWiki code. Connel is suggesting it in this discussion twice. In his first post "I like the notion of having a separate set of language templates, that are de-wikified", and in his summary further down "The separate set of language templates seems to solve a lot of long standing problems. Other things have had to work-around the lack of them previously. ..." also a few other places less clearly. Annabelleke opposed the idea as it seems (suggesting "keep it simple") while the use of the second is simple for the users and no other solution exists. I was sure we all were agreed now to check out this possibility in order to make a final decision at a later stage. However, I have created 110 or so of these templates that has a Wiktionary, ang 60 are to be made. I hope all these smaller things (edit) doesn't have to go through a vote each time, then we have to wait until next year before we all get set with this. When we decide wheather to go with this new syntax, I need to use the bot to make needed changes in the articles to update the syntax in the articles as needed. I hope this also (edit) doesn't need an extra vote. ~ Dodde 01:18, 30 March 2007 (UTC)

I suppose you meant to add ‘no’ to all those sentences concerning votes. Don’t worry, we’re not that bureacratic here. H. (talk) 17:02, 30 March 2007 (UTC)

Regarding the syntax of the current version of {{t2}}, an overview is presented at Template talk:t2 ~ Dodde 01:34, 30 March 2007 (UTC)

As I said before, I'm beginning to understand the performance issues. Imho, it is a good idea to have the {t-xx} templates to see a working example before it is generally used. Annabelleke 09:47, 30 March 2007 (UTC)

PS: (@Dodde): we have to keep it simple for the end user. But, if for performance issues a solution, where many templates are needed, is necessary, I do not see why one should hesitate to implement it

I put some comments on {{t2}}. H. (talk) 17:02, 30 March 2007 (UTC)

While we’re at it, we could think about what the template should an should not do. If we need to compute the full language name anyway (or have it as a parameter), then we can have the template add the initial *Language: as well. Although then the question is what to do with multiple translations. OTOH, I think it should not be concerned with gender information, so I propose to remove the gender and plural parameters out of it. H. (talk) 17:02, 30 March 2007 (UTC)

Wouldn't you need two templates then? One for the common case, and one for the case where one English word correspond to multiple words in the target language. \Mike 19:38, 30 March 2007 (UTC)

Well, if the word has more than one translation, the basic translation template is used more than one time on the same line. Think of the template's function as simply switching place with each linked word, ], in the translation section. ~ Dodde 20:44, 30 March 2007 (UTC)

{{t3}} DAVilla 19:23, 30 March 2007 (UTC)

Yes, I suggest we have one simple template for 98% of the translations, and one enhanced template for any other use that may be necessary. At this point we should focus on the simple one.

Option 1 See {{t2}} code and talk.

• {t|color|lang code|translation}, {t|lang code|translation}, {t|translation}

Option 2 See {{t5}} code and talk.

• {t|lang code|color|translation}, {t|lang code|translation}, {t|translation}

Option 3 See {{t6}} code and talk.

• {t|color=color|lang code|translation} / {t|lang code|translation} / {t|translation}

Option 4 See {{t4}} and discussion on Template talk:t2

• {t|color=color|lang code|translation} / {t|lang code|translation} / {t|translation} (will end with error)

Option 5 See {{t5}} code and talk.

Option 6: (approx. 2 lines of code) See {{t6}} code and talk.

• {t|y=lang code|translation} (for existing entries)
• {t|n=lang code|translation} (for non-existing entries)
• {t|translation} (bot will change to the upper two)

This means very easy syntax, and very good user friendlyness, aswell as good readability. No real downsides except that it links even to non-existing wikts if lang code is given. Choosing this template would probably suggest that no language code should be given for wiktionaries that doesn't exist. (the use of anchors for these languages won't be of much use anyway). The bot will maintain it if needed.

Option 7: (approx. 1 line of code) See {{t7}}, {{t7+}}, {{t7-}}, code for t7, t7+ and t7-, and talk.

• {t+|lang code|translation}: Template:t7+ (for existing entries)
• {t-|lang code|translation}: Template:t7- (for non-existing entries)
• {t|-|translation}: Template:t7 (for non-existing wiktionaries)

  This doesn't provide an anchor for the translation. See {{t7!}}.

  t7! is red linked, what is to see about it? Supposingly less than 1 of 10,000 translations will be a translation to a language not having a Wiktionary, and at the same time being in need of an anchor. Even if it is the 10,000th case, it will link to the right page. This is a microscopic problem.

• {t|lang code|translation}: Template:t7 (for unchecked entries, still providing FL-link) (bot will change to upper three)
• {t|translation} or ]: hola (for unchecked entries, not providing FL-link) (bot will change to upper three)

  I have modified {{t7}} to use {{language}} for which I assume the issues with Top40 will be worked out, by using Template:t-xx if nothing else. Although that call is expensive, any {t} should be modified by bot, so there won't be many {t} references lying around overall on the project. The benefit is that it also allows for {t|language name|translation} and even corrects the language name in annoying cases, like Farsi => Persian, or translates it like español => Spanish. DAVilla 09:28, 1 April 2007 (UTC)

This means the simplest possible code, no named parameters, best readability, no downsides.

Your modification of t7 made the syntax malfunction. As I explained above the problem the modification was suggested to solve is of microscopic proportion. Since the language code is not a required argument when adding a translation, I see no point adding the parameter for it. The bot will review it in 2½ weeks time anyway, and change to the right syntax, weather given the language code as an argument or not. If you don't mind, I will revert your changes on t7, to keep the set for option 7 to be all simple. If you like, add more options 8 and 9 for consideration, or something. ~ Dodde 10:08, 1 April 2007 (UTC)

I hadn't written {{langcode}} yet, but it's up now, and so my modifications work. They only concern deciphering the language for ease of use, not implementation in terms of the {{t7!}} business which I agree is a minor point. DAVilla 11:03, 1 April 2007 (UTC)

Now presented as option 8:

Option 8: (very complicated t, streamlined t+/t-/t!) With {{t8}} and {{t8!}} and still using {{t7+}} and {{t7-}}. See code for t8, t7+, t7- and t8!, and talk.

• {{t|language code or name|translation|m/f/n/c|s/p} Template:t8 (entered by user)
• {{t+|code|translation|...}}: Template:t7+ (for existing entries)
• {{t-|code|translation|...}}: Template:t7- (for non-existing entries)
• {{t!|language name|translation|m/f/n/c|s/p}}: Template:t8! (for non-existing wiktionaries)

I hope I didn't forget to present someone's viewpoint. Please add more options if you have more ideas.

To have other colors than the standard ones (lighter red, green-yellow, etc.) will complicate the code. That is unnecessary according to me. Should we have a vote for different options? Elsewise, please give a hint on weather we should go for option 2 or option 3 (please give some good arguments if choosing option 1 or option 4). There might be more options, feel free to add these in the line. Personally I think I vote for option 2 for the time being... (Edit: I kinda like Option 6 (Edit: best now) ~ Dodde 18:54, 30 March 2007 (UTC)

Option 5 gave the suggestion of having green links for existing entries, I kinda like that. Option 6 also have this color selection. ~ Dodde 23:00, 30 March 2007 (UTC)

I have created translation section examples of all above options 1-6 for evaluation. Check it out User:Dodde/t-examples We want blue or green links for existing entries? Are these options ready for a vote, or we want more options to choose from? ~ Dodde 02:42, 31 March 2007 (UTC)

Although I like the idea of inferring, before bot review and indication of color, the existence of the FL page from the one that exists locally, I'm going to abandon the y= n= idea I raised with Option 5 because I think the default assumption that should be made is that the FL page exists. The reason I feel this way is looking toward a more completed state of the project, when most translations, excepting the fringe words, would be defined. DAVilla 09:46, 31 March 2007 (UTC)

For every function we want to add, there will be more and more code. Option 6 keeps everything simple. Very simple syntax, very good readability, user don't have to add either language code, nor if the link should be red or blue/green. Option 6 keeps it simple also because templates will only be needed for the Wiktionaries that exist. Maintaining the t-lang templates adding one for all hundred of languages that may appear in one or more translation lists over the site is pretty time consuming. I don't feel like doing this, but if it's not done, it will create problem with the Most wanted-pages list. This goes for option 1-4, but not for option 6.

You say you want the default option to be that the FL page exist, but to provide the link, you need to add "y=" or "n=" together with the language code. A link to the FL page can never be created without this information in the syntax. And no one is hindering someone who create a translation to add a "y=es" or whatever, as a guess the page exists. Probably many will do this anyway. I have a hard time finding a better solution for what we essentially want with this template, than what is given by option 6. Any extra option will make the template code longer and longer, but will result in a minimal gain.

Then as of right now we are discussing the bot is checking the translations whenever there is a new dump, and that mean we will wait for an update on an average of 2½-3 weeks. This is really not a big deal. Weighing that 1 of 50 translations will not provide a FL link for 2½ week extra, against a less good syntax in one but probably more ways - then 2½ weeks wait has to be accepted. It might also be possible in the future to find a good way to update the pages more frequently, not using the dump, but be relatively thrifty using the servers resources when retrieving necessary information perhaps on a daily basis or so. Then the intermediate state of the translation will be of even less importance.

So I really hope option 6 is not abandon because of small reasons like this one. ~ Dodde 10:23, 31 March 2007 (UTC)

I don't think my objection was really understood, but anyways just ignore it, it was a minor point. DAVilla 16:34, 1 April 2007 (UTC)

Imho, option 6 seems to be the best solution at the moment. Thanks for your efforts and the examples for the different options. Annabelleke 10:54, 31 March 2007 (UTC)

I don’t like any of the options a lot. I think Robert Ullmann is going in the right direction: have a template {t}, which is meant for users, where they can enter what they know, i.e. at least the translation, preferably (or even necessarily) also the language code, and optionally language section links etc., in a overviewable syntax. Then have a bot convert the template to something less readable (that is no problem by then, since the information is there now, it only has to be editable for corrections), which includes existence of FL etc. (although I still think this is unnecessary: have the link anyway, no matter whether blue or red, it is blue-green already).

This all presupposes we have bots running over the xml all the time. Do we want this? Isn’t it possible to find a solution in which users can enter the final template at once? Leaving out the color and existence of the FL link would make this already more feasible. And probably the {t-lang} template array makes automatic inclusion of the section link possible. H. (talk) 16:01, 1 April 2007 (UTC)

It is the last point that is the most contentious right now. You looked through all of these options, but they were just brainstorming and hashing out how things should work. I look at the proposals that are actually being considered at the moment, and I don't see much difference between them. The questions that it comes down to are:

Do we need to have language section anchors fully spelled out?

Should we use {t} "meant for users, where they can enter what they know" as you put it, and then have a bot convert it to {t+} or {t-}, and possibly {t!}, or should we have only {t} and {t-}, where {t} also has to be implemented efficiently and doesn't allow much room for error. The latter is what's status quo, what Robert Ullmann is supporting.

On other things you talk about whether the color even needs to be controlled by bot, I think everyone is pretty much for doing that already. DAVilla 16:27, 1 April 2007 (UTC)

The best solution so far seems to be an array of templates {{t-xx}} for translations specific to each language. There are two reasons for doing this. The first is a bad reason, and that is that for some God forsaken reason (edit: that being for easy substitution DAVilla 19:19, 1 April 2007 (UTC)) the {{xx}} templates are linked except for a handful of them. Although it's difficult to fight, this really needs to change for I can't name how many reasons; see Connel above. Additionally it makes automatic categorizations by label templates difficult since it breaks {{language}}. Second is that, besides the hassel of writing the full language name, languages have unique concerns in terms of script, and that, neither, should need to be specified as a parameter. It is the last point that caught my interest. This is essential to the function of a number of tempates, for instance all the form-of tempates and POS templates and anywhere that a non-roman script word is displayed. I would like to take action and have a few useful arrays of FL code templates: one for the language name (never linked), one for the rank of a language (to determine if it's TopX), and one for the script used. In fact I would override the existing {{xx}} templates to take parameters (requests such as lang or script) aside from one concern: these shouldn't be templates! What we really need is a built in #language: function that gives the English name of the language as well as a #script: from which the correct style template can be inferred. Then I wouldn't care so much that {{xx}} implements indirectly the almost useless TopX function for X=40. DAVilla 09:46, 31 March 2007 (UTC)

I've been doing a couple of things. First of all I figured that {{langcode}} would be a useful thing to have around, and so I've added a few pages prefixed by Language: such as Language:Farsi (known here as Persian), Language:Min-nan (a redirect to regular spelling), and Language:ру́сский (at the correct case, with redirect from upper). The idea is to be able to derive the code of a language from any language name. Of course once the language code is discovered the template should be substituted. For instance I have employed {{langcode}} in a proposal for a user-friendly {{t}} which would be substituted with {{t+}} or {{t-}} by bot.

And what can you do with a code? After discovering how incomplete the built-in {{#language:}} is I've begun overloading the templates. When a language code template such as Template:es or Template:pap is called with no argument, it returns the name of the language, wikified except for the more recognizable, so that the template can be substituted as it has historically been used. But the template can also be called with certain requests:

• FL to retrieve the foreign-language name, similar to {{#language}} but using the correct case and potentially some day more complete.
• en to retrieve the English-language name, similar to calling the template with no argument but excluding the wikilink. This replaces the function of the recent {{t-xx}} templates. Translations could be incorporated with other language codes as well.
• wiki to retrieve the correct project prefix, which is usually the same as the name of the template but with some exceptions like Template:nan. If there is no Wiktionary with this prefix, then it is blank.
• script to retrieve the (primary or most general) script template name, or blank if none. There are also script1, script2 etc. and a scripts request for the number of scripts. If scripts=1 then script and script1 are identical, but see Template:cmn for an example of more than one script.

The idea is the same as above, to always substitute, so this shouldn't mess up Special:Whatlinkshere. However, if there are problems the code I've proposed can be moved to the Language: pseudospace. DAVilla 07:19, 2 April 2007 (UTC)

With all due respect, stop modifying the language templates and roll back the ones you've changed.

These must be subst'able; that is their primary use; you can't add parser functions or anything outside the noinclude span other than the canonical language name. Robert Ullmann 14:51, 2 April 2007 (UTC)

I've actually already stopped after doing just a handful to get feedback. The point was that they can still be substituted, e.g. {{subst:fa}} produced Persian when I typed it in here, despite the fact that the code of Template:fa at this point in time is:

{{#switch:{{{1|}}}|=]|en=Persian|FL|fa=فارسی|wiki=fa|scripts=1|script|script1=FAchar}}<noinclude>]</noinclude>

So it would seem that yes, you can add other things outside the noinclude span without breaking them. But if there is a real objection I can move the code somewhere else. I certainly won't be touching the others any time soon. DAVilla 16:51, 2 April 2007 (UTC)

Your "subst:" resulted in brutal-to-the-servers "switch:" statements! Roll it back! Sheesh, the biggest point of having a separate set (for a separate use) was not to break things that already exist! I, for one, am perfectly aware that impossible-to-comprehend templates can be contrived, with only non-rendering complexity added. So no, you don't need to complete the experiment just to prove that it is somewhat possible. Overloading existing templates that fill a fairly well defined role, with new functionality is just not a good idea. --Connel MacKenzie 05:12, 3 April 2007 (UTC)

Hey, I'm sorry. I only did a few and I announced it because I wanted to make sure that it was working right. I don't know how I missed that the subst: wasn't. DAVilla 05:51, 3 April 2007 (UTC)

Wait just a minute... okay, so the experiment was a distaster, accepted. On your point about switch statements though. Are they really brutal to the server? I would have thought they'd just be implemented as essentially a string of ifs. DAVilla 06:43, 3 April 2007 (UTC)

No, they cannot be substituted. Yes, it produces Persian. Have you looked at the page wikitext? (obviously not) Robert Ullmann 22:17, 2 April 2007 (UTC)

Yikes! How did I miss that? Okay... rolling back. DAVilla 05:14, 3 April 2007 (UTC)

I will move these to the Language: pseudospace. DAVilla 05:48, 3 April 2007 (UTC)

(See also the discussion in the Beer parlour on anchors in this template.)

Another problem with this template as it stands is that translations that are spelled identically to the headword give links back to the same page, which the wiki software makes bold rather than links. See the translations section of didgeridoo for examples of this.

Sorry to bring problems rather than solutions, but I'm not familiar enough with the syntax of templates to fix this myself. — Paul G 11:54, 31 March 2007 (UTC)

Replying to Paul G, I've just fixed that as part of the following;

I don't see the fix. Did you change {{t}}? DAVilla 16:13, 1 April 2007 (UTC)

See Australia. Robert Ullmann 17:29, 1 April 2007 (UTC)

It works for Finnish because the translation has ls=Finnish, but it doesn't work for Indonesian which was more recently entered. I'm going to see if I can find a more general solution. DAVilla 17:56, 1 April 2007 (UTC)

No, it didn't work for Indonesian because some idiot created a code template named in. Deleted it; fixed the table. Robert Ullmann 14:14, 2 April 2007 (UTC)

Not that it maybe matters, but isn't the code for Indonesian "id" rather than "in"? ~ Dodde 14:28, 2 April 2007 (UTC)

Hey, the bot didn't flag that? Okay, anyway the original page still has the links bolded because by "fix it" I think you meant via bot, not altering the template itself. This is correctible using #{{language|{{{1}}}|default=something or other}} but there's no way I'm going to make such a controversial edit. I will add an anchor to something though, maybe an underscore since it's practically impossible for a single space to appear as a header. Feel free to alter the text of the anchor though. DAVilla 17:14, 2 April 2007 (UTC)

I've added the anchor in every case, not just when the page name is the same, because it actually makes the code simpler even than it was before, whereas checking the pagename would make it more complicated. Because a lone hyphen is very unlikely to appear as a header (and would be incorrect if it did), the link is simply to the top of the page. DAVilla 17:37, 2 April 2007 (UTC)

Sorry, Paul, I corrected the problem you brought up with didgeridoo but in a batch of edits that I am unable to defend having actually introduced a bug, and so they were all rolled back. But the problem is very simple to solve and doesn't require having a bot running around to spot-check these or any complicated code at all if you can accept having an anchor in ] as the link. DAVilla 06:39, 3 April 2007 (UTC)

this is also in reply to all of the above. Guys, this just isn't that complicated or hard!

Objectives:

• provide links to FL wikt entries in the default presentation voted on
• provide CSS customization of those links
• make the links blue if FL wikt entry exists, red otherwise
• don't generate links to non-existent wikts
• don't use lots of template calls, optimize performance
• link sections when needed on the en.wikt

We don't need to reinvent things already solved: this whole thing comes from fr:Modèle:trad. (The name is short for traduction.)

So:

• Use {{t}} if the FL entry exists
• Use {{t-}} if the FL entry does not exist
• If the FL wikt does not exist, leave out the code Fixed. In this case the code is optional.
• use the ls= parameter to specify a language section if needed, usually leave this to the bot

All done, except adding the CSS spans. Then you can have pretty colors if you like.

The bot will:

• Change t to t- or the reverse when it knows if the FL entry exists
• Remove the code when the FL wikt does not exist, and add it if it does
• Add ls= if needed, remove it if not
• Add sc= (script) parameter when missing for the languages that use it (e.g. Arabic, Japanese, etc)
• Replace {{trad}} and {{trad-}} with t and t-. (They are useful redirects, since that name is used on other wikts, and will work here exactly the same way, so users will have no difficulty.)

Bot will take me a day or two. (A few hours, but I have other work too!)

Okay? Robert Ullmann 12:30, 31 March 2007 (UTC)

Issues raised above that this does not solve:

1. All links should be directed to the correct language section. (Well, technically, it's only necessary to do so when target language isn't at the top of the page, but there isn't any way to check that dynamically and anyways no reason not to link in every case.)

   What do you mean it doesn't solve it? It links to the correct language section in the en.wikt, and the language is usually at the top in the FL wikt?

   I specifically said ALL links. It doesn't link to the correct language section by default, which would be a cleaner design than what we have if it could be implemented efficiently. Unfortunately the latter doesn't seem feasible at the moment, but that doesn't mean this isn't a goal.

2. Not only does the template not provide section links in every case, it never even addresses the issue of doing so concisely. If the bot were run to completion, ls=Full language name would be a parameter to every call.

   No, only when it is needed. E.g. the target entry has more than one language. The bot knows if it does. Humans don't have to worry about it. (If a new language is added above the target, the bot will add the ls link on the next run.)

   Right. Exactly what I said. But it doesn't do it concisely, which was my point. It requires an ls=Full language name parameter.

3. Likewise it requires the scripts to be fully spelled out, when this information could also be derived from the language code. None of the other proposals tackle this, but it will need to be addressed.

   We don't have script templates in a consistent pattern, and no, it can't be derived from the language code in the general case; entries that use {{ZHtra}} and {{ZHsim}} are used for various language codes, yes, it could default it; we'll leave that to the bot which can do it without performance overhead on rendering.

   Shit, the pattern of script templates can be adjusted as needed. Their precise names are a secondary issue, if only there were a way to determine this in general. Your point about Chinese is a good exception to what I said, but it's just that: an exception, and one that can easily be handled with special code, as we are already forced to do with the FLW linking for the Chinese languages. DAVilla 19:30, 31 March 2007 (UTC)

   So you are back to testing for and looking up xx-char (or whatever) for every call. Same problem as the t-xx templates. Most language won't use them. And Chinese isn't an exception; it is the rule; for each language you have to look at the actual script being used. (So the bot will add sc=ARchar if the script is Arabic, not if the language is "ar". Try doing that in a template!) Robert Ullmann 17:04, 1 April 2007 (UTC)

   Good point. But this is really a discussion that extends far beyond translations. Would it be possible for the MediaWiki-or-whatever-it's-called software to simply examine the output of a page post-processing and insert the correct styling whereever the character script changes? Then we wouldn't have to have these scripting templates at all. This would be most flexible if based on a bunch of information in the MediaWiki: namespace. DAVilla 17:46, 1 April 2007 (UTC)

One other point that might be more positive than negative is that it incorporates genders and plurals, which aren't strictly necessary. Coming from a language that has the like, it's probably a good inclusion.

It is a bit simpler to write {{t|lc|word|f|p}} that {{t|lc|word}} {{f}} {{p}} but it isn't a requirement that people use one or the other.

Actually, since the language code is already provided to {t}, wouldn't it be possible to link the gender and number to a language-specific grammar page describing what those abbreviations mean for that language? Do we already have anything like that in the appendix? DAVilla 08:11, 2 April 2007 (UTC)

I also like t/t- better than my own yes/no idea I lambasted above. I would propose {t+} when the page on the FLW exists, {t-} when the page does not, and {t!} when even the FLW does not exist. Use the simple {t} as a default, heavy code that relies on the existence of the local page to guess color and does all the clean parameter checking, maybe even reverse-locating the language code from the language name when necessary. Hey, that sounds like fun! I think I'll go write that... DAVilla 17:26, 31 March 2007 (UTC)

I wanted to do this the same way as the dozen or so other wikts where it is absolutely standard. They invented it, and they are doing it right. Robert Ullmann 17:51, 31 March 2007 (UTC)

Nonsense. That's an argument solely against change in any form. We can make {t} work similarly if that makes entering the information easier, but there's no reason not to make the bot-edited code for {t+}, {t-}, and {t!} as well tuned and refined as possible. I understnad your objections to using templates to derive the language name, and I would so much like to see #language: give the English language name as the most direct work-around, but this last argument is stuck in a rut. DAVilla 19:30, 31 March 2007 (UTC)

Bot works now: see die, abortion, Thursday. Tested a very little bit, still needs some details. Robert Ullmann 17:51, 31 March 2007 (UTC)

The wheel may be invented thousands of years ago. That doesn't mean the invention can't be improved after that. Why stick to a solution that is more server intense, offer less readability, has a trickier syntax, and so on, when there are more efficient solutions to be found. Different names of templates with red or blue FL-link will make the code a little shorter, but not much. As I understood, however, this was something one wanted to get rid of. Option 6 offers everything one has asked for. Good readability, short and server friendly code, simple and intuitive syntax, blue/green (if this has decided to be blue already no need for further discussion, just that I didn't see that decision) for existing entries, red for non-existing entries, surpressed FL-link for non-existing Wiktionaries. I think it's a waste going back and decide to use french version with all its downsides, with server intense code, worse readability, more complex syntax, and so on. I seem to just don't get it. ~ Dodde 18:03, 31 March 2007 (UTC)

Excuse me?! You really don't have any idea what "option 6" (the code in {{t4}}) does to the servers compared to the present code in t and t-, which is similar to the fr.wikt code? The French version is far less server load. (and we are talking serious effects here; t and t- cause the server to load TWO templates for the page; t4 causes up to several HUNDRED) You're right, you don't get it. "option 6" is horribly LESS efficient. Robert Ullmann 18:15, 31 March 2007 (UTC)

Excuse me too?! You seem to like comparing apples with pears as you oversee the fact that {{t}} doesn't even have the functionality that {{t4}} does. As I understand people want the anchors to be included in the internal link, current version of {{t}} is not even considerable without removing this request, or accepting terrible readability in the edit of the article. {{t4}} contains this functionality and preserve the good readability. {{t}} doesn't. If {{t}} would, it would contain 6½ lines of code while current version is 5½ lines of code. {{t}} does this with in the current version of {{t}}. {{t4}} does this with 2 lines of code. Since the template calls you are referring to only contains as little as 3-9 bytes each I've been told this is not a big deal. I might have been told wrong, but then it's just to remove this snippet of code from {{t4}} and end up with 1½ lines of code, half the template calls, half the if statements, and so on, comparing to {{t}} which will still have 5½ lines of code, double the template calls, double the if statements etc. This is rather a discussion about using the second set of {{t-lang}} templates rather than choosing between any of the options 1-6 and existing {{t}}. What's also important about this, is that not only the number of different templates that is called counts, also how many times each template is called, and the amount of code there is in each of these templates. Altogether {{t}} does horrible compared to variants discussed above, like option 2 and option 6. If you want even more effective code, you could use {{t6+}} for existing entries, {{t6-}} for nonexisting entries, and {{t6}} without an FL-link. This would probably end with just 1 line of code per template since each template will be much more specific on what to do. I was told a number of different template names was not wanted so I didn't go by with this option, but I could give an option 7 for this version for review. Each of the options above can also take a parameter for the anchor instead of having it mandatory in each template, but to the cost of much worse readability when editing the article, and also to the cost of more oftenly having to make changes to each article. Question is if the pos with this weighs up the cons. But please don't compare apples with pears, it's just not leading forward in this discussion. ~ Dodde 21:57, 31 March 2007 (UTC)

Please explain to us the difference in server load between a few lines of parser functions and a sub-template call? Do you know this difference? (yes this is a test question, I don't think you know the answer) Robert Ullmann 12:17, 1 April 2007 (UTC)

How does this turn into a contest of who is better knowing about Mediawiki software and different template functions effect on the servers? You are proving no point in this. The use of anchors will be a load to the servers, no matter if we use {{t}}, {{t4}} or {{t7}} or any of the other options for this. Removing this from the equation, the {{t}} with 5½ lines of code is more tempting on the servers than for example {{t7}}(+/-) with only 1 line of code. I hope we will see a long-term solution of the anchor issue by adding an extention to the MediaWiki code as suggested by Rob Church at Bugzilla . While waiting for this we can use the {{t-lang}} set of templates. It will mean some load to the servers, but it's not of the worst case scenario we have been discussing as a long-term solution. If deciding to remove the anchors completely until the extention is added to MediaWiki, well, so be it, no need to mess around with hardcoding the anchors in the template syntax for some links and some links not, since it makes the readability suffer. If allowing the template to add the anchors by using the second set of language templates, then when the extention is implemented just that spot of code in the templates {{t-{{{1}}}}} is just switched out for {{#lang:{{{1}}}|en}} (or similar). ~ Dodde 13:17, 1 April 2007 (UTC)

In fairness I think Robert Ullmann considered the {{t-xx}} templates to have been presented as the long-term solution, as indeed I think they were. But it seems we all agree now that they cannot be. DAVilla 16:07, 1 April 2007 (UTC)

The use of anchors doesn't add any server load at all above what the links do. Using the template calls to generate them adds very serious load. (The answer to the question you evaded is that a few lines of parser code translates to something less than a millionth of a second of CPU; a template call generates a page access, an SQL query, a network op to the backend database server, and disk ops; caching does help a lot.) Also if we are going to use the "t-xx" templates, we need a few thousand of them. (remember, you need the section ref whether the FL wikt exists or not.) Robert Ullmann 16:35, 1 April 2007 (UTC) Oh, and then you need a separate set to tell you whether to generate the FL link. So now you have 2x database refs per translation. Robert Ullmann 16:38, 1 April 2007 (UTC) Strike that, not so hard; testing for the existence is possible. Robert Ullmann 16:58, 1 April 2007 (UTC)

Using the ls= parameter means we don't have to give up anchors for now; users can add them wherever/whenever they care; the bot can add them if it is doing any t/t- flip in the entry, adding them only when needed; we suffer no performance hit now or later, and when/if we get a parser function, t/t- can ignore the ls parameter and the bot can routinely remove it if it is editing the entry. Robert Ullmann 16:58, 1 April 2007 (UTC)

Ullman, that suggestion seems fair and feasable to me.

~ Dodde 18:33, 1 April 2007 (UTC)

As long as the bot puts the anchors in, I agree for reasons of efficiency that {{t-whichever}} should not try to figure that out on the fly. I'd rather see gender and number kept outside of the template, because those features don't necessarily attach to all parts of speech. I'm less interested in having the user coose one of language name or language code, but I'm not heavily invested either way, it will get changed by the bot in any case. ArielGlenn 05:03, 2 April 2007 (UTC)

A friend of mine used to point this out when we were working together: a user interface should not surprise the user. Software should do what the user expects.

We can't do anything new and fancy in the basic template call (with or without layers of slow and unreliable cruft ...). Templates trad/trad-/t/t- must work the way they do on the other wikts.

Why? Because the majority of edits into the Translations tables are IP-anon or users that do just a few of those. They are often coming here from the FL wikts, to add links to entries they've created there (and that is why they want the FL links). They are going to use what they are familiar with. (And it doesn't matter if you think they are wrong to make that assumption; they do.) If what we do works differently, someone will have to spend all day and all night talking at and biting newbies and editing IP-anon edits. They aren't adding a lot of t/trad calls now, but as soon as they start seeing them everywhere, they will. Robert Ullmann 16:35, 1 April 2007 (UTC)

Note similarly that is impossible to train users not to use t for languages without an FL wikt. They'll assume that is the standard new format for all the language entries; it must work for any language and code. Robert Ullmann 16:52, 1 April 2007 (UTC)

Okay, that kills nearly all of the initial proposals. If Dodde agrees, can we strike them out? DAVilla 17:29, 1 April 2007 (UTC)

I am not sure exactly what you mean, but according to my personal viewpoint, strike out whatever you like as long as you keep option 6, 7 and 8 (I understand better now, I like the idea of having the {{t}} being the extended one, for the simplicty of the users and having the bot change to t+ t- and t! as needed... I haven't checked the code closer yet though) Option 1-5 is less thought-through. ~ Dodde 18:39, 1 April 2007 (UTC)

I agree that we should not surprise the users/editors. But on the one hand, it is argued that we shold not reinvent the wheel and that we should use a system that resembles the system in use at other wikis; then it is argued that if we use that system (trad/trad- etc), it must work exactly as on other wikis. We should certainly learn from what other wikis are doing, but we need not be locked into their methods. One of the great things about having evry wiki be independent is that each one is an independent realm for experimentation. Any new idea we put to use will undoubtedly be examined by other folks to see if they can steal fromimprove it. And if we come up with improvements, we can find a way to implement them without confusing the user/editor, if it means using slightly different template names, for instance. ArielGlenn 01:48, 2 April 2007 (UTC)

Thank you; I was going to add another note to point out that I'm not trying to discourage innovation; just that in this case t/t-, trad, trad- have to take code, translated word as the first two parameters and work as expected. It already does more than that; it allows alt-links which the fr: version does not; you can user gender/number if you want, we can do the section links, etc. The other wikts for the most part don't do that. Maybe they'll borrow some? Robert Ullmann 14:35, 2 April 2007 (UTC)

Templates t/t- generates the FL wikt link if and only if the FL wikt exists. No additional template calls were used (;-). So users can always provide the language code; if WMF initializes the language, the links will appear. Robert Ullmann 17:27, 1 April 2007 (UTC)

How do you test for existence of the FL Wiktionary? DAVilla 17:51, 1 April 2007 (UTC)

DAVilla, by bot all language codes for existing wiktionaries will exist in the bot-script, if you mean in template I don't know.

~ Dodde 18:33, 1 April 2007 (UTC)

Oh I get it. No, not quite. {{#language:pap}} is Papiamentu, but pap.wiktionary.org does not exist. So {{t|pap|translation}} erroneously gives a link: translation DAVilla 18:52, 1 April 2007 (UTC)

You are right, it isn't exactly testing for the existence of the FL wikt, but rather whether the WM software will generate a correct link; e.g. in this case it will generate http://pap.wiktionary.orghttps://dictious.com/en/translation rather than the erroneous http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=pap:translation&action=edit

For most codes/languages it will get the right answer; even when it doesn't it generates what would be a valid link. The bot can make sure it is always flipped to t-.

And note that it is really giving the right answer for a red link in a wiki: it takes you to the meta page about starting the new project. ;-) Robert Ullmann 13:59, 2 April 2007 (UTC)

Okay, at least you got it not to generate the invalid link. That new "feature" you've seem to found I'd just as well bot-replace with {t!} though. DAVilla 17:52, 2 April 2007 (UTC)

I really don't have time to read the 40 kilobytes of discourse above. Can someone please summarize the outstanding issues at this point in time? --Connel MacKenzie 03:34, 2 April 2007 (UTC)

My view: The primary impetus seems to have been the problem of not knowing whether a FL Wiktionary existed. We have tried to solve this and other problems with a number of language code templates, but these are viewed as inefficient. I have argued that {t} can be inefficient as long as a bot later substitutes it. Robert Ullmann now claims to have solved this problem more elegantly but see my response immediately above.

The other issues include not changing the basic syntax of {t}, which might include gender and number, so that it can be understood across projects, and whether to include long tags for language sections and scripts. It is generally agreed that there needs to be an extension to immediately decipher a language code into the English name, but the question is what to do until that time. DAVilla 08:00, 2 April 2007 (UTC)

Thank you.

The original (third) vote was supposed to be to determine that links to existing FL Wiktionaries should always occur, whether or not the FL page existed. That issue has been resolved, now, right? Or are we still debating using red/blue indicators for that, instead of simply always linking? --Connel MacKenzie 05:27, 3 April 2007 (UTC)

It's mostly resolved, down to a few languages where the Wiktionary doesn't exist but could be brought into existence with very little red tape. DAVilla 11:51, 3 April 2007 (UTC)

Everyone has had time to say what they feel and these are my interpretations of the discussions wherever they have been held, here on GP, template talk pages, irc, user talk pages, in earlier votes:

1. Colors should distinguish existing FL entries from non-existing. Blue for existing. Red for non-existing.
2. FL links to non-existing wiktionaries are not necessary, but is also not a problem. The number of these translations are too few to make this a major issue. Technically the bot can't add the FL links unless the language code is provided by the user, so there should be a possibility to leave the language code blank for these entries. I suggest the color of this link (since it is dead) to be black ^(ex) if the language code is entered, and if not entered it would leave ^(-) instead. (changing If language code is given simple black text will be displayed instead of the link, containing the language code ^(ex). If the language code is not given, only the internal link will be displayed.
3. {t} is used as the main translation template, including all advanced parameters, {t+}, {t-} and {t!} is used as slimlined templates for existing entries, non-existing entries and non existing wikts respectively, saving the servers as much as possible.
4. {t} should be possible to be used when {t+}, {t-} and {t!} are not enough, performing any of the three templates' results.
5. translation templates should not call language templates to produce the anchor (known as "another set of {t-lang} templates") since this will put too much load on the servers
6. translation templates will all contain a lang= parameter to make the anchor for all entries, if feasable only those entries that needs it (not being the top or only language section in the linked entry).
7. users should be able to enter any of these basic syntaxes when adding a translation, without any error occuring ], ], {{t||translation}}, {{t|lang code|translation}} or any other syntax that is accepted by any of the templates.
8. the syntax should not be different between the 4 different templates. Just that {t} is the one with more options.
9. like current version of {t} there should be 4 unnamed parameters: argument {1} being the language code, argument {2} being the translation, argument {3} being the gender (m/f/mf/c/n) and argument 4 being s/p (singular/plural). The rest of the parameters, if any, should be named parameters.
10. named parameters in all templates should be lang=
11. other named parameters, like sc= for script for arabic etc. will be put only in {t} and in such way that is believed saving the servers most.
12. when and if an extension is added to MediaWiki to allow for the {#lang} function for use instead of spelled out language names in the syntax with parameter lang=, this will be changed in the syntax as well as in the templates needed.
13. the color of an unchecked translation hasn't been discussed. Davilla suggests green, is this ok?

We may all have slightly different opinions about minder aspects, but I hope we can end this discussion here and accept the results above somewhat unchanged to get anywhere with this thing. What do you all say? ~ Dodde 06:48, 5 April 2007 (UTC)

Thank you for splitting the separate issues apart. They are quite distinct; colluding them has caused no end of grief.

1. I think one thing that I expressed poorly is your first point: I'm not convinced they need to be different colors, but if they can be, that is a Good Thing.
2. On the second point, I cannot disagree strongly enough completely agree. If the FL wikt exists, but the FL entry does not, there MUST be a link. Right now, we have barely scratched the surface of the translations we expect to have, on each entry. For a very long time, those red links will be absolutely essential. Eventually, WMF should have Wiktionaries for all those languages. But we'll have to wait and see how that pans out. --Connel MacKenzie 06:19, 6 April 2007 (UTC) (edited)
3. {{t}} should be compatible with other wikt's accepted formats (de:, fr:, in particular.) So yes, I agree.
4. Complex cases can use other templates to supplement {{t}}: yes!
5. Agreed: template chaining is bad.
6. lang= is for language codes, not language names, right? I'm on the fence regarding this.
7. Agree.
8. I don't know enough about the other options.
9. Agree, unless it makes the templates too complex.
10. I agree that the templates must be consistent, between themselves.
11. Agree
12. Agree
13. Orange?  :-) Any color is fine.

--Connel MacKenzie 21:06, 5 April 2007 (UTC)

Comments to Connels post:

2. I think you misunderstood this point. Point 2 is regarding non-existing wikts, not about non-existing entries on existing wikts. We are all agreed by now to provide links to all wiktionaries that exist wether the entry exists or not. :) The problems mainly are of technically character. The bot has to know a complete list of all thousands of languages, this is time consuming to create and to no use. A black ^(--) will give the info there is no wiktionary to link to, And when the Wiktionary is created, the bot will update the link to look like any other FL-link to Wiktionaries that exist.

6. No, language code is given by an unnamed parameter, {{{1}}}, lang= is for fully spelled out language names, used for the internal links' anchors.

8. Well, the meaning of the point is kinda "don't complicate things by using completely different syntaxes for the different t-templates". Practically this means all syntaxes should be based on {{{1}}} to be the lang code, {{{2}}} to be the translation, and the rest should be named parameters. This will keep it simple and effective.

9. Given there are only two unnamed parameters explained above, it's not complex at all.

13. :) Well 1 vote for green, 1 for orange...

~ Dodde 22:15, 5 April 2007 (UTC)

I was not able to follow the discussions the past few days. But when I have read the last comments, it seems that one wants to use both red and green for links to the FL wikt. Please do not do this as 8% of people can not differentiate between these two colours (blue and yellow may also be a problem, although to a lesser extent). For more information see w:Daltonism. Any other colours would be fine. Annabelleke 08:28, 6 April 2007 (UTC)

Blue and red are the suggested colours for links to existing wikts, to existing entries and non-existing entries respectively, black to non-existing wiktionaries. If you mean point 13 green was suggested to be the colour until the translation was checked by the bot which if checking every new dump this will last for about two weeks only. That means new translations will be linked green for two weeks if language code is provided at all. This isn't a big issue since it is only very temporary coloring for newly added translations ~ Dodde 08:39, 6 April 2007 (UTC)

Well... 2 votes for orange. Thanks for the answer. Annabelleke 11:08, 6 April 2007 (UTC)

1. Everyone agrees. A Good Thing™.
2. What a question! Whether to link FL Wiktionaries that have a subdomain but have not been set up yet. Too much too argue, I think. But:
   • I don't like black links. Too much of a surprise. If we link these semi/quasi-non-existent Wiktionaries, then the links should be semi/quasi-reddish, or at least something that looks semi/quasi-reddish. Black text is okay though, e.g. ^(xyz).
   • I don't like ^(-). Too confusing. If the language code is unknown, just make it look like any regular link. After all, those are lacking language codes too.
3. Connel and Dodde argue different points.
   • As to the exact syntax of {{t}}, we should really have the freedom to lead the way and decide what we think is best, as per the next section below. However the language code as the first parameter is fairly standard, so that really only applies to the other parameters.
   • Dodde seems to imply that {{t+}}, {{t-}}, and {{t!}} would not take all the advanced parameters like alt= and script|sc=. I don't see why they wouldn't, unless you'd want every translation of e.g. Arabic to have to rely on {{t}}.
4. I'm not sure if we all three understand. But at least there aren't any strong statements to disagree with. Cheers! This round's on the house!
5. Uh-oh. Here I disagree with both of you. {{t}} should be user-friendly, even if it's complex, because the other templates can be streamlined. Just run the bot to keep the number of unreplaced t's (undiscerned +/-/! calls) low.
6. I have been using lang= as Connel describes, but the name of the parameter is a minor point. At the moment, including the full-language name is an ugly necessity.
7. Agree up to the "or any other syntax" clause. Certainly {{t}} should accept the same parameters as any of the other templates, but if {{t}} is user-friendly then the streamlined templates couldn't work flawlessly with all the cases that {{t}} could handle.

   Edit: The following is in response to "other named parameters, like sc= for script for arabic etc. will be put only in {t} and in such way that is believed saving the servers most" (Dodde, above) DAVilla

8. Having sc= and alt= as other "options" (edit: for {t} only) is not viable, per above. The other options that {{t}} might have include alternate names for the parameters and the ability to accept either the language name or the language code. I could agree only if Dodde meant the latter.
9. Arguments 3 and 4 are not certain. They don't make the template complex, but I would want to make sure that they're not too restrictive.
10. This seems to go with the next point.
11. Dodde seems to repeat himself, and I don't care to repeat myself.
12. Yes, please, please, please! We none of us can wait. However, the completeness of any such extension is a question of... well, unless you want to wait a long time, it's not much of a question. Which is why I suggested that {{t!}} take the language name rather than the language code as the second parameter. If not as the second parameter, it might have to as a named parameter anyway.
13. Any color is fine with me, and green seems objectionable. How about red + blue = magenta? I had actually made the color of an unchecked translation correspond with the color of the local link, but anymore I don't think that's a very good heuristic for exitence, and it also causes strange behavior when the local page is written, making it appear that the FL one was too.

Comments to DAVilla's post:

2. I have changed point 2 in the original post according to one of your proposals.

Okay, great!

3. Yes, the whole point having {t+} {t-} and {t!} is to use as server friendly code as possible for the majority of cases. Arabic is not used often enough to include it in the slimmed templates. Translations of Arabic will always use {t} rather than {t+} or {t-}.

I don't see sc= as being server unfriendly at all. As Robert says in the post above that begins "Excuse me?!" and compares language templates to "the present code in t and t-" using sc= optionally:

• "a few lines of parser code translates to something less than a millionth of a second of CPU; a template call generates a page access, an SQL query, a network op to the backend database server, and disk ops"

If the code in {t} and {t-} that Robert himself wrote uses sc= then I don't think it's a problem.

4. Clarification: {t} should be possible to show a blue link, a red link, an orange(?) link, black text, or no link at all.

Yes, and you mean that this should happen automatically, correct? There's no point in specifying the color of a link within {t} since that's what {t-} etc. are for.

5. Clarification: Using the second set of {t-lang} templates won't make it any more user friendly. The use of these templates was to automatically provide the anchor when language code was given. Even if this is still the goal with addition of {#lang} MediaWiki extension, bot will produce lang= arguments automatically until then. The idea of this second set of language templates is abandoned already.

I can understand not doing this in the general case, e.g. not calling {{language}} within the {{wikipedia}} template in order to say "Such-and-such Wikipedia", but I haven't abandoned it completely. In particular I think it is feasible to do with {t} provided that {t} is always bot-replaced. This seems to be the major point of contention.

6. Clarification: (Response? DAVilla) In that case you are using the lang= parameter wrongly. Language code is the first unnamed parameter, spelled out language name for use with anchor is given by the named lang= parameter. I agree it would be nicer to not have to use this, that's why we hope for the {#lang} extension. But until then, lang= is the parameter to use.

Wait, I wasn't talking about {t} at all. I was talking about other templates I've written, in similar style to yet other templates used here, that take a lang= parameter. See form of templates below.

7. Clarification: What I meant was that the user ofcourse can enter the more complex syntax aswell if they wish, but should have the possibility to choose any of the simpler syntaxes as described and let the bot do the check and change.

Okay, that's what I thought you meant. All I was saying is that {t} would be the most general case, so I think we agree. It's a very good principle.

8. Why would sc= and alt= not be viable as options for {t}? They are already included in existing version of {{t}}. (I don't understand at all what you mean by this) Why alternate names on parameters? That is total waste and only complicate things. Allowing {t} to accept language name instead of language code is just a waste. The user shouldn't even have to enter language code at all. Why bother with this.

No, that's not what I meant. Options as far as code goes. I have rephrased above. The ability to accept other parameters is not a heavy requirement on all {t*} templates. They do not complicate the templates to the degree you claim. And if {t} is more user-friendly and places fewer restrictions on the server friendliness, then a very knowledgeable contributor should be able to write any translation in a form that avoids the clunkier {t}, opting to use one of the specialized {t*} templates. It's not a requirement for every user, but it should at least be possible so as to keep the number of {t} templates low as they are continuously converted to the correct form. The reason again is that {t} in this proposal is meant to be more user- rather than server-friendly. As a consequence of this, all templates must be useable with Arabic, for instance, accepting alt= and sc= as basic parameters.

As far as allowing {t} to accept the language name, it is not a waste if the user knows the language name, perhaps only the foreign language name, but not the language code, or if for instance an anon does not enter the information under a recognized name, which happens from time to time, there being so many languages and all. Accepting the language name as an option for {t} would be more difficult for the servers, but only until a bot came along to convert {t} into one of the others.

9. What do you mean by too restrictive? All parameters are optional except argument 2 which is the translation.

I mean restrictive in the sense that only f, m, fm, n, c, p, and s can be used. Some languages have more than just a singular and a plural. Old English for instance has a dual number. I wouldn't be surprised if certain words in other languages were combinations of genders other than fm as well. We could sit down and try to figure all of these out, or we could try to make the code as general as possible, but it would be much easier to just leave it out, as you had suggested when you started.

10. Clarification: lang= and only lang= will be the named parameter in {t+}, {t-} and {t!} while in {t} lang= will be one of several named parameters.

11. Clarification: Because you misinterpret what I write doesn't mean I repeat myself.

(Sorry. You actually stated something I had inferred in one of the other points more clearly in this point, so it wasn't repetition so much as clarification to begin with.)

12. I object to using different syntaxes on the translation templates, see point 6-8 again. The parameter lang= will be used for the spelled out language name, and the language code will be the first argument. In {t!} aswell as like in the other templates. Doing elsewise is not intuitive and will complicate things.

Yes, it has to not complicate things, as specifically per number 7. To come to a point where we would decide on whether to use the full-language name in {t!} rather than the language code, we would first have to agree that either the full-language name or the code should be acceptable in {t}, which is the more general case. Since you do not agree with the latter point, then it is useless arguing this more minor point. DAVilla 14:22, 7 April 2007 (UTC)

Ok, alot of clarifications and repeating since very little of what I wrote in the point list seemed to be clear to DAVilla. ~ Dodde 11:48, 7 April 2007 (UTC)

You wrote this as a list of 13 points, but couldn't we narrow those down to just 2 major points now, excluding everything that's agreed to? DAVilla 14:22, 7 April 2007 (UTC)

After your extensive comments I am not sure we have agreed on antyhing but very few points... As it seems the basic assumptions for the reason why to have a set of different translation templates is not even clear, judging from your comments. As long as we can't agree on anything without compromising we will not get anywhere. Here goes another set of comments.

3. And if you read my response to this, I thought it was not very fancy comparing apple with pears. If the functions used in {t} is not serverunfriendly at all, why the heck do people want 4 different templates then, at all??? Is the reason only because we want different names of the template depending on which colour that should be used in FL-link? Well... If this is the case, probably 5 or so points should be reformulated. Then I would like another statement from Mr Ullman, where he is not comparing apples and pears.

Robert Ullmann had only suggested using {t} (which we call {t+}) and {t-}. If I were to take your approach then I too would wonder why a distinction between {t} and {t+} would even be necessary. DAVilla 22:15, 7 April 2007 (UTC)

4. No, not automatically, since {t} will include all extra options, while the other templates won't, {t} needs to have a parameter for colour. {t} will be used when options needed exist only in {t} but not in the other templates. Unless you want {t} to be close to identical with {t+} {t-} and {t!} with the only difference the colour of the link. No one but you has suggested this yet, so I dunno what do propose.

I see what you're thinking now. In my view, the color parameter isn't necessary. That's what a distinction between {t+} and {t-} is for (between {t} and {t-} in Robert's solution). If the translator wants to pick a color, they can just use the correct template. But in your system you can't use {t+} and {t-} with every translation, e.g. Arabic, and so a color parameter is necessary for {t}. In other words, there are two ways to say "red link", use {t|c=red} or {t-}, and the bot is going to pick different answers in different cases. Likewise for blue. If you're lucky enough to work in a language that uses two scripts, one which requires sc= and one that doesn't (Serbian comes to mind), then you wouldn't have to remember c=red/blue, as long as you write sc=RUchar so that the bot knows it can't use {t+/-}. However, you wouldn't be able to use {t} when no script template is required because the bot wouldn't be able to distinguish, without a bit more effort, those cases from cases where the user forgot to specify the script. That is, you'd have to remember to use {t+/-} for Latin script, or you'd have to write a clever bot, or you'd have to live with {t} for Serbian entries that didn't require it. Suffice to say, this isn't the most elegant solution. DAVilla 22:44, 7 April 2007 (UTC)

5. Since {t} is always changed by the bot, there is no need to use options that won't last for any reason anyway. The anchor will be excluded from the internal link for 2 weeks. Why bother with this at all? It just complicates it. Besides, we hope for the extension and then this will not be needed anyway.

6. Alright... however, in {t} lang= means "language name", language code is the unnamed 1= parameter.

8. What I oppose against is that a handful more options doesn't necissarily make it more user friendly. A short, but clear and distinct documentation on the use of {t} will have a better affect. 1=lang code, 2=translation 3=gender 4=number. And a few examples to this. No need to be able to give 1= with language NAME instead, or other things...

It is a waste because if the user is adding a translation on enwikt, he has to specify the language in the list anyway, and the bot will use this name anyway. Any spelled out name within the syntax will be disregarded and fill no purpose at all. Why add something in the syntax that has no purpose at all, and that only means unnecessary complex code and documentation and explaining. I'd suggest just skip it.

Hi Dodde, did you have a look at my examples for {{t8}}? I took

{{t|español|niña}}

as input and produce this:

Template:t8

That is to say, the template accepted not only the name of the language, but the name of the language in Spanish, and from that language information alone linked to the correct section (#Spanish) and the correct Wiktionary (es:). That's what I mean by user-friendly. DAVilla 22:15, 7 April 2007 (UTC)

However... if no one objects, sure, add alt= and sc= and Arabic to all templates. Regarding the server load, I am not the expert. {t} still needs to accept a parameter for FL link colour/black text/no link though.

9. All I am trying to do is to come to an end with this, summarizing peoples viewpoints. No one is really giving feedback for good ideas, only presenting new proposals that makes us need to start all over again. I really don't know if we will come to an end ever with this. Can anyone else try to summarize the viewpoints of all participants, not only one's own viewpoint? So we can concentrate on what still needs to be discussed. IF it is found that the gender and number options are not good enough, you can still add the text after the t-template, and you can always add more options to the template later if it would be necessary.

Summary: Well, to be honest I think it is better with small points since even these seem to be impossible to agree on. Bigger points would be even more impossible. If you can leave the thoughts of allowing spelled out language names in {t} and {t!}, and you can agree on adding alt=, sc= and arabic but no more in all templates I think we are agreed on most. If you answer yes on this, I will change the original list again to go with these changes. (Please just a simple yes or no for clarification on this one) ~ Dodde 16:21, 7 April 2007 (UTC)

Directly: No, I don't agree with the first point. BUT, you have laid out the alternatives very clearly now. DAVilla 22:55, 7 April 2007 (UTC)

I think if I made some of your assumptions on the bigger points, then these smaller points would follow quite naturally. The primary issue as I see it is: should we be calling {{language}} and {{langcode}} from {{t}}, with the understanding that all instances of {{t|...}} are to be replaced? If that's acceptable, then it really pins down the definitions of {{t+}}, {{t-}}, and {{t!}}. If not then there's a lot more flexibility—e.g. not all {{t}}'s need be replaced, {{t!}} and even {{t+}} are unnecessary—and both your solution and Robert's simpler solution make sense. DAVilla 22:15, 7 April 2007 (UTC)

Ok, I am glad we finally start to talk the same language here. :) I agree with you that if (and only if) we agree on the bigger points, smaller points will fall naturally. Now it's not decided nor approved, but if Doddebot is going to run the service, ofcourse I will make it clever enough to make the needed distinguishes that are needed to give the correct end result for each translation. This means, the user shouldn't need to think about anything but supplying the correct translation. The bot would change to the correct color, the correct script, and the correct language code, no matter if the user entered any of these or not. You are right in all your comments this time. I did take for granted four t-templates was wanted, and the reason for it was to keep the code as simple as possible, especially t+ t- and t!. But I also took for granted t would still be used for those remaining 5% of the translations that needed extra parameters, such as alt= or sc= as I first thought of. These assumptions would also lead to that adding the server intense option to enter the language name instead of simply the language code is not at all a good idea. However, if the assumptions are altered and we look upon {t} as only an intermediate level and absolutely all {t} will be changed by the bot to either t+ t- or t!, yes then the server intenseness for {t} isn't a matter at all. As I imagine this on sight though, is that the bot check won't need to wait until the next dump arrives before it can do checks, but maybe it will be possible to check like twice a week, then what is possible to do with this intermediate level {t} really doesn't matter much, hence I suggested just skipping it. But it's no big deal, if all {t}'s are meant to be changed. Then on the other hand, t+ t- and t! must all include every single option (except that language thingy of {t}) that I assumed was only going to be added in {t}. If your interpretation of Ullman's posts is that as long as no extra set of {t-lang} templates are used, the server load is not an issue. Yeah, then, why not. My assumptions wasn't like that, but I don't know much about this technical side, so if you are confident this is the way to go, I'll take your word for it.

I have asked Robert to confirm. DAVilla 13:32, 8 April 2007 (UTC)

Let me summarize again: ~ Dodde 06:40, 8 April 2007 (UTC)

1. Colors: red (non-existing)/blue (existing), black text for non-existing wikts, nothing at all if language/language code is not given, orange or magenta for links that are not checked (votes 2 - 2)
2. {t} is used only as an intermediate level translation template, thus server load issues hardly matters. This allows for very good user friendliness. Color parameter is not needed in because all {t}'s will be changed to {t+} {t-} and {t!} by the bot. Each template will have it's own color (orange/magenta,blue,red,black). Second set {t-lang} templates may also be used in {t} if there isn't a programmically simpler/better solution. Each translation should be possible to put in either {t+}, {t-} or {t!} when checked by the bot.
3. all translation templates will contain a lang= parameter to make the anchor for all entries ({t} will have the first parameter too for this), if feasable only those entries that needs it (not being the top or only language section in the linked entry).
4. focus should entirely be user friendliness for the {t} syntax, while the other templates need to have a fixed position on unnamed parameters and apart from that as server friendly syntaxes as possible.
5. the general case for unnamed parameters positions' are {1}:language code, {2}:translation, {3}:gender, {4}:sing./pl.
6. when and if an extension is added to MediaWiki to allow for the {#lang} function for use instead of spelled out language names in the syntax with parameter lang=, this will be changed in the syntax as well as in the templates needed.
7. (syntaxes from translation templates of other languages' wiktionaries should be considered upon agreement on syntax used for {t} on English wiktionary.)

I feel we are already fairly agreed on main part of point 1, point 3, point 5 and point 6. Point 2 and point 4 are changes according to my interpretation of DAVillas comments. Point 7 is a liable suggestion, but this could be discussed in the section below (stop the presses) ~ Dodde 06:40, 8 April 2007 (UTC)

This is in line with what I had in mind, yes. I would suspect that Robert still prefers the present "only {t} and {t-}" solution. I will let him speak for himself, but if so we would have two very clear (thank you) solutions to one problem. Since his voice is more authoritative on these technical matters, I expect Connel to side with him. Connel is most concerned about point number 7, but if the first two parameters are the language code and translation in that order then we should have already satisfied his demands on the sytax of {t}.

We should remove from this discussion the question of gender and number in point 5, as that is a perpendicular issue to the choice between these alternatives, now raised in parameters in translation lists below. DAVilla 13:16, 8 April 2007 (UTC)

The section you are pointing at is about having gender information in translations lists at all. This discussion has nothing to do with {t} until it's decided to remove all gender information from the translations list, which I hardly think will happen neither now nor later.

Two templates would be enough if we wouldn't need a userfriendly {t}, and let {t!} be a special case of {t-} somehow. ~ Dodde 13:47, 8 April 2007 (UTC)

I think this is a good way to go: have one template, {t}, for user input. It does not really matter whether it is server intense, since a bot will convert it to another template which saves the server. At the same time, it should do everything one expects from it, such that the user that inputs it has a good feeling. I.e., compute the section link (with {language} if must be), display the FL link (in some color, I’d propose not to alter it, in which case it will be like this. If people are willing to write that bot, cool. I think it is nice to have a template which seems to do everything you want, be it server-intense, if the more tech-savvy people know it will be converted to a more server-friendly version in time. At the same time, it is important that users shold not be bothered to think about whether they need to use {t-}, {t+} or whatever name the more server-friendly templates will have. (For that matter, if it is not to be entered by users, we could as well have only one, with a color named parameter.)

Regarding 4.: see bugzilla:9465. H. (talk) 14:58, 11 April 2007 (UTC)

You aren't hearing much from me because I am doing about ten different things, and the net here sometimes goes away for many hours ;-) I am paying attention... I do think a {{t+}} would be good as well when we look closely at the server effects, and considering that this really should be the most common case (right?!). Keep in mind that users will persist in putting in t+ and t-, even if they are supposed to always start with t. (remember, 98% of users never read the documentation)

I do have the bot code to do this using the XML, I believe Dodde has plans to do something with more dynamic lookups; these aren't incompatible. The no-FL-wikt ("t!") case is left as {t} for now. (one option is just to strip out the template! it isn't really going to be doing anything, it can be systematically added later.) Robert Ullmann 14:28, 12 April 2007 (UTC)

See pie, star, die, Thursday, abortion. Robert Ullmann 15:36, 12 April 2007 (UTC)

Note in particular that it changed nl:stempel in die from t- to t+, it was created April 2nd. Robert Ullmann 15:56, 12 April 2007 (UTC)

If I ran the 'bot all the way through the XML it would update 229 entries, mostly t to t+ for entries in the nl.wikt. Tell me if you think that is a good idea ;-) Robert Ullmann 16:30, 12 April 2007 (UTC)