Please, please, please add "color" only as a named, final parameter (that only the bot will add!)

My expectation is that no human would chase the link down in advance to determine red/blue/green/yellow/orange/fuschia/whatever. That's bot work. So it should be an optional parameter.

Having the "t-xx" language codes is fantastic. Once {{trad}} stops using the legacy templates, we can go back to routinely clearing them out (subst:ing them) automatically.

--Connel MacKenzie 04:47, 30 March 2007 (UTC)Reply

Apart from naming the color parameter, show the link in blue by default. I.e. people that use the template always enter the third option: {{t|es|hola}}, resulting in ] ^(es), or maybe with a black link. Later a bot adds the color= parameter. There is no use in expecting people to put ‘black’ in there, just use it as a fallback default. (i.e.: ...(CSS/HTML stuff here) color:{{{color|black}}} (more CSS/HTML)...

The only problem left is if the FL wikt does not exist: the superscript link will be a link to the langcode:word page in this wiktionary, e.g. alq:woord (alq is Algonquian). That is not nice. But I suppose that people that know Algonquian will know that there does not exist a Wiktionary in their language, and thus we can expect from them that they use a different syntax. Other alternative: indeed code this in the Template:t-alq template.

To summarise: change the semantics of option 3, and remove option 4; a language code should always be given. Options 5 and 6 are for people that do not like templates, and can be replaced eventually. H. (talk) 16:57, 30 March 2007 (UTC)Reply

In other words, this is my suggestion, node that the code is very straightforward now:

] <sup>]</sup>

I did not change it, since I think you (Dodde) should experiment with this yourself. H. (talk) 17:01, 30 March 2007 (UTC)Reply

I like more straightforward code. My first suggested code, now when ArielGlenn added another row and 2 if-statements to cover the broken RC-problems that existed, this code is not really usable. A few of you stress that "keep it simple" for the end user. By that I don't understand why you would suggest that language code always had to be added. This should not be necessary. Also using color as a named parameter makes it less user friendly and will also decrease the readability in the edit text. If someone happens to put the wrong color, that's not a problem, because it will be corrected lateron anyways. It should not be possible to do wrong when adding a translation (unless performance will suffer too much). This is also important because the bot has to rely on what is edited to some extent too. With many ways for users to do right there will be less problems. But ofcourse, there may be performance issues here too to weigh against user friendlyness. And last we are talking about the end look. Here we have to get a good readability and simplicity to the syntax. Of this reason I want to avoid a named color parameter, especially if we can find solutions which don't need a lot of code. However. one way or another the current code needs to be truncated. ~ Dodde 18:13, 30 March 2007 (UTC)Reply

• Making color a named parameter makes it more user friendly, since it means they do not have to enter it. Most won’t. For a bot, it is no problem to use the param.
• Making the language code necessary is in its way also simple: there is no plethora of multiple possible uses, but just one (plus the optional color).
• I suggest you first focus on what the template is to do, and think about the bot later. First things first.
• I am not sure about your statement that more right ways lead to less problems. If a user is using templates, one can assume he is a bit more experienced ans thus he will recognise the error that points out to him that the first parameter is mandatory. Users that do not use templates do not suffer from the problem.
• Named parameters are not that bad for readibility. I agree that it is something you have to get used to. H. (talk) 13:04, 31 March 2007 (UTC)Reply

I miss the possibility to just give only one argument when adding the translation - the translation, for {t}. And I miss the possibility to leave the language code blank (or a code for "don't know") if it can't be found for {t!}. There are several thousand language names, it's not good to rely on always having the answer on which language code to convert to. Also misspellings of language names can't be given language codes unless they are recognized and changed.

These misspellings could be flagged by the bot with a category for unknown language. It's more likely that the user knows the code and uses that. The other option is provided for convenience. DAVilla 09:30, 2 April 2007 (UTC)Reply

Don't require language name/code for {t}, add a solution for "don't know" for {t!}~ Dodde 08:31, 2 April 2007 (UTC)Reply

I can't leave out the first parameter because everything (including gender and number) would be shifted and it's impossible to distinguish them all. For instance, what's the difference between es sg as {{t|es|s}} and son as {{t|es|son}}? Not much. It is however possible to leave the second parameter blank, as demonstrated above, but even this case I don't think is important because common sense would lead one to simply write ].

As to your other point, I've created {{t8!}} with the modification that it takes the language name, not the code. DAVilla 08:46, 2 April 2007 (UTC)Reply

But in a majority of times, probably 90%, the language name in t8! does no good but make the readability worse. and for t8, that was the whole point to keep it simple for the user. Demanding such things that can be added by the bot is not keeping it simple. t7 suggested {t|translation} would be enough. This should really be possible if going with t8 aswell. If not, the syntax gotta change. ~ Dodde 08:54, 2 April 2007 (UTC)Reply

Regarding t8!, as I have discussed before, I don't like the idea of having the language names just for anchors spelled out in the template as a long time solution. While waiting for an extension to MediaWiki I can accept it, but this will never happen for wikts that don't exist. To demand the language parameter is even worse.

Okay, how about making t! accept either the language or the code? The only problem is that this is an expensive function. Honestly I would have the bot replace the codes with the full language name anyways for this very reason. The bot could indicate somehow that the language name were already checked. If the code were given, the language name would have to be looked up, so it's probably more expensive to use the language code. This is likely to remain this way since decoding is going to remain expensive even with an extension to MediaWiki, which won't be able to capture every case, and precisely those cases that use {t!} are the ones to worry about.

No, t+, t- and t! should be named by the bot, no need for alternative syntaxes which will complicate... As I argued before this is a case counting to less than 1 for every 10,000 translations. If the language is not recognizable to the bot it's a very little problem. The only result is that the anchor is excluded from that particular link. I would suggest using the same syntax for the anchor on t! as on t+ and t-. While the #lang extension then will be a solution for t+ and t-, t! will keep its syntax sinte the extension will not be to much help for t! I would like for the bot not having to keep track and be updated with hundreds and yet hundred of different language names. Because of this, the anchor-parameter should be spelled out with the complete language name rather than using the code at all (and when added with t, neither the language code nor the language name should be needed in the syntax) ~ Dodde 11:40, 2 April 2007 (UTC)Reply

The reason that the language code or name, even when added with {t}, is needed or at least recommended from our persepective, is that it's actually wanted. {t} needs to be able to more or less give an example of what kind of output that the bot is going to produce. If people didn't want to see the interwiki links then they wouldn't want to use {t} at all. The contributor wants to see the interwiki link, and that's what {t} provides. Otherwise why have an intelligent {t} at all? Just have people enter simple links and run a bot around to convert them all. DAVilla

Okay, I got you now. The user adds {t|unrecognizable lang code or name} and the bot converts it to {t!}. Well there's already an easy answer: use a hyphen for the language. In every rendition of {t!} that I could imagine, the hyphen would either be passed through as the anchor, ] that is, or it would be caught and excepted.

The reason I prefer to leave the full language name with {t!} is that—besides being slightly more versitile, which you discount as minor, and more efficient anyway, for the moment at least—it confuses the syntax in a good way, that is, in at least a few cases making it clear that the language name is possible if the language code is not known. DAVilla 18:39, 2 April 2007 (UTC)Reply

As for t8, accepting just one argument, why is not this possible? "if not argument 2 or 3, then ]" or something? Does this create some kind of problem? Dodde 09:05, 2 April 2007 (UTC)Reply

Just one argument? Yes, that could be added. But then if someone tried to modify that with gender or something the results would be very strange. I would sooner put up an error message. In fact I think I'll do a combination. DAVilla 09:30, 2 April 2007 (UTC)Reply