Can you show us what you would like your signature to look like? - DaveRoss 05:41, 24 December 2010 (UTC)

Like the one i have now but aligned to the right & a Tilde ~ between the name and date ; And to that I don't have to keep typing <br>'''~~~~'''
==== Red 11:38, 27 December 2010 (UTC)

Maybe <p style="text-align"right"><b>==== <i>]</i></b> ~ {{CURRENTTIME}}, {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} (UTC)</p> and then use only ~~~ instead of ~~~~? I haven't tested it.​—msh210℠ (talk) 17:13, 27 December 2010 (UTC)

Too Long for me to type I was wondering if i could use a User:Red/Sig to code my signature and I would just type the tilde for faster typing as a macro.

==== Red ~ 01:12, 8 July 2025 (UTC)

P.S. It's not working ^_^

I've recently been seeing strangely coloured links - a sort of dark brownish red? They are for terms that exist - i.e. the link should be blue. As I have poor eyesight, it is very confusing. SemperBlotto 11:04, 27 December 2010 (UTC)

Do you have examples of the circumstances for us to try to replicate. What browser do you use? DCDuring TALK 12:33, 27 December 2010 (UTC)

Take a screen shot (Prt Scr near F12, and paste into Microsoft Paint or something equivalent). Mglovesfun (talk) 12:36, 27 December 2010 (UTC)

They wouldn't happen to be this color, would they? --Yair rand (talk) 13:35, 27 December 2010 (UTC)

It has something to do with Special:Preferences --> Appearance --> Advanced options, which colors links to pages that are smaller than a given byte threshold. However it's coloring random links that way for me in Firefox now as well. — lexicógrafa | háblame — 17:06, 27 December 2010 (UTC)

I'm using Google Chrome at the moment. A screenshot is at . The strange link colours include that for "Main Page" over on the left. In the main body of Latin words, the ones at the top (funny colour) are newish; the ones at the bottom don't exist yet. The effect comes and goes, by the way. SemperBlotto 16:49, 27 December 2010 (UTC) (Oh, and the colours don't look quite right after all the processing)

When I visit a redlink and do not save anything and then use "back" to return to the page that had the redlink, the redlink changes to a maroon/brown color. I thought that was a desirable feature, serving on occasion to remind me of unsaved work. If I then visit another redlink, the same thing would happen. If I refresh the page, the saved edits turn blue, the unvisited ones remain red and the visited/unsaved ones remain maroon. Could that be what you are noticing? DCDuring TALK 20:48, 27 December 2010 (UTC)

Now I see. Using FF3.6.13 I just got the maroon color when moving synonyms from a show-hide to dispaly after {{sense}}. I did not use any of the links. This is new behavior, not particularly functional AFAICT. DCDuring TALK 00:33, 28 December 2010 (UTC)

This notice is being cross-posted to the major administrators noticeboard (incidents or alerts) style pages on all the major projects.

Earlier today, a w:User:Meepsheep2 was blocked on the English Wikipedia. Apparently in reprisal, he vandalized a major template on English Wiktionary with a fake fundraising banner that he photoshopped. Someone reported it on IRC, and we blocked him quite quickly for this time of night, but we want you to be on the lookout for future similar incidents. Please help keep an eye on major templates for vandalism specifically related to the fundraiser banners, and if they occur, globally lock their accounts (if you do not have that access, please block them locally on the wiki they vandalized, and then find someone on IRC who can globally lock the account). Stewards can assist with this. I know you guys all watch the high value templates anyway, and I'm not asking you to do anything different with those. I'm specifically referring to incidents that spoof the fundraising banners. Please keep an extra careful eye out for those, and take the extra step of asking a steward to globally lock the account to prevent future recurrences of this specific kind of vandalism. Please send any questions to drosenthal (at) wikimedia.org, or use my English Wikipedia User Talk page as I cannot respond locally on all projects. ⇒DanRosenthal ^{Wikipedia Contribution Team} 07:04, 29 December 2010 (UTC)

Okay, no one's commented as of yet, so I'm going to be more explicit about a proposed change, and am hereby explicitly labeling it aas a proposed change rather than a mere idea. I want to change {{#if:{{{lang|}}}|]}} to

{{#if:{{isValidPageName|{{accent:{{{1}}}|l=}}}}<!--
then-->|]<!--
  and-->]<!--
else-->|{{#if:{{{lang|}}}|]}}<!--
-->}}

and add an {{{l}}} parameter to each accent: template so that, for example, {{accent:US}} will read {{{l|]}}} instead of ]. Thoughts, support, objections?​—msh210℠ (talk) 16:46, 1 December 2010 (UTC), modified slightly 18:03, 1 December 2010 (UTC)

How did I miss this excellent suggestion? This may provide all of you with the opportunity to hear my version of US pronunciation. DCDuring TALK 17:41, 1 December 2010 (UTC)

Okay. I've taken the first step: I've added {{{l}}}, as described above, to every accent template (more precisely, to every template that's not a redirect and that's on the list at ]).— This unsigned comment was added by msh210 (talk • contribs).

And now I've added to {{rfp}} code similar to the above, but categorizing only if lang= is set.​—msh210℠ (talk) 10:01, 7 February 2011 (UTC)

Discussion moved from WT:RFDO#Template:Xyzy

This sounds like a "Be bold" kind of situation. How about someone who knows how to make a bot just takes {{langscript}}'s pile of language-script listings, autocreates things like {{sc:en}}, {{sc:fr}}, {{sc:he}}, etc. (with the four letter script code as its content), and fill those not covered by langscript with "None". Then we can deprecate Xyzy and other templates. --Yair rand (talk) 17:15, 29 December 2010 (UTC)

Let's not be too bold given the number of pages involved. In fact I'd strongly advise caution, testing, etc. Mglovesfun (talk) 17:19, 29 December 2010 (UTC)

Right!​—msh210℠ (talk) 17:25, 29 December 2010 (UTC)

There are already a ton of language templates. I don't think creating a ton more for each possible piece of information we would like to store about a language is a very good idea. I think it would be better to give each language template a t= parameter, which decides what information to return. This is probably faster too, because it saves on a separate template retrieval since it's re-using the same template instead. —CodeCat 17:21, 29 December 2010 (UTC)

That sounds good, and is what some other templates do.​—msh210℠ (talk) 17:25, 29 December 2010 (UTC)

Otoh, I don't think everything should go in there. For example, the script code should, but not the script name (so that in case we decide to change what we call it, it's centrally located at template:script or wherever).​—msh210℠ (talk) 17:32, 29 December 2010 (UTC)

So what could go in there? The only other language information that I can think of is language family, and that's only necessary in main language categories, and is handled pretty well by {{langfamily}}. --Yair rand (talk) 17:36, 29 December 2010 (UTC)

Family, yes. Link to a Wikipedia article on the language, perhaps. Status as living, if we have use for that now or in the future, yes. Maybe other things?​—msh210℠ (talk) 17:39, 29 December 2010 (UTC)

Type of language (mainspace, proto, conlang) would be useful too, because it's used by {{langprefix}} and that's used by a lot of other templates. —CodeCat 17:45, 29 December 2010 (UTC)

Including language family in these templates would be completely useless, since the families have no effect on any mainspace entries. Bits of information on the language would also be useless if they aren't useful for the entries themselves. Keep in mind that these templates are loaded, usually dozens or even hundreds of times, on every single page in Wiktionary. --Yair rand (talk) 12:25, 30 December 2010 (UTC)

I really doubt that the templates are actually loaded more than once. Most likely they are loaded once and re-parsed with different parameters each time. —CodeCat 12:27, 30 December 2010 (UTC)

A translation table with a dozen translations is a dozen language templates loaded. --Yair rand (talk) 12:36, 30 December 2010 (UTC)

True, but those are already loaded as it is. That wouldn't change at all in the new situation. —CodeCat 12:49, 30 December 2010 (UTC)

I don't think one extra small template load per language would make all that much difference. Trying to load this onto parser functions for every usage, plus using safesubst for everything so that it's still substable, would probably be less efficient. --Yair rand (talk) 17:29, 29 December 2010 (UTC)

But if we use {{sc:he}} (or {{he/sc}}) we'd need to use a parserfunction for it anyway (#ifexist the script template) which is not necessary if we load it into {{he}} (just use {{he|sub=sc}} and the parserfunction (#switch) use is in the template itself). Seems to me we come out even.​—msh210℠ (talk) 17:39, 29 December 2010 (UTC)

If we fill all the unknown script codes with "None" as I suggested, then we can avoid parserfunctions entirely. --Yair rand (talk) 17:43, 29 December 2010 (UTC)

We can't rely on its being filled in for all languages, as new language templates can be created at any time. (Unless we create an sc: (or /sc) template for every two- or three-letter string?)​—msh210℠ (talk) 17:58, 29 December 2010 (UTC)

I thought new language templates were only ever added by a bot? --Yair rand (talk) 18:04, 29 December 2010 (UTC)

On the other hand, if we make it mandatory that every language template have a corresponding script template, we can catch such cases easily where a human creates a language template without an associated script template. -- Prince Kassad 01:04, 30 December 2010 (UTC)

Here is a first draft: User:CodeCat/en, User:CodeCat/ru, User:CodeCat/gem. It's short and simple but it works the way it should. Thoughts? —CodeCat 17:54, 29 December 2010 (UTC)

Language templates need to be substable. --Yair rand (talk) 18:04, 29 December 2010 (UTC)

Oh... and this isn't? I don't really know how else to do it then. Do you know? —CodeCat 18:10, 29 December 2010 (UTC)

Ok I think I found a way. How is this now? —CodeCat 18:12, 29 December 2010 (UTC)

No, that way won't work non-substed, simply transcluded. The only way I know to have parser functions workable substed and non-substed is to use safesubst: surrounded by includeonly, or to use {{{|safesubst:}}}. --Yair rand (talk) 18:15, 29 December 2010 (UTC)

Allright, I fixed that, and it seems to work now. —CodeCat 18:18, 29 December 2010 (UTC)

Shouldn't this discussion be on WT:GP where people will expect to find it? Mglovesfun (talk) 01:35, 30 December 2010 (UTC)

Moved, then. :) —CodeCat 12:15, 30 December 2010 (UTC)

I quite like the idea of {{he/sc}} (et al.). The information already exists on this wiki in langscript, so a bot could create them. I bet Conrad.Irwin could do it, just he's not active right now. So basically templates would do {{{{he/sc}}|{{{1}}}}}, since the entire content of he/sc would be Hebr, this would be {{Hebr|{{{1}}}}}. Mglovesfun (talk) 12:48, 30 December 2010 (UTC)

With my proposal that would just become: {{{{he|t=sc}}|{{{1}}}}} which isn't really all that different. —CodeCat 12:53, 30 December 2010 (UTC)

Well, 'my' way (actually msh210 above) you wouldn't need to modify any of the templates themselves, it would be entirely done by subtemplates not transcluded by the language templates themselves. Mglovesfun (talk) 12:55, 30 December 2010 (UTC)

I remember my old proposal of editing Template:en to display various names: see the old revision and its code. It would be easy to add support for scripts, families and a good safesubst: to make it work, and deprecate {{langscript}}, {{langfamily}} and {{Xyzy}} in the process.

However, I may be wrong, but I believe that one template with a list of 825 scripts is parsed much more quickly than a group of 825 templates with one script in each template. --Daniel. 13:18, 30 December 2010 (UTC)

While that may be the case, you have to look at it from a practical point. How many language templates are used on average on a single page? I doubt the average is higher than about 10-20. Most pages only have one language on them. —CodeCat 13:28, 30 December 2010 (UTC)

So we've got a number of possible solutions:

1. The current way of using Xyzy, which holds a decent-sized switch function to choose scripts for some of the more popular languages, going through a few dozen options for every case.
2. The way used by Daniel.'s templates, using {{langscript}} itself, using a very large switch function to go through hundreds of languages to get the right script.
3. Codecat's suggestion of changing over the existing language templates to use switch functions.
4. The langcode/sc method, creating one /sc template per language, which would include the ISO 15924 script code for the language's script. (Another possibility would be to just redirect the templates to the script template, though I don't know whether that would be better or worse.)

Option number 3 would be used (assuming we're talking about a link, which is usually the case) pretty much as {{{{{{{lang}}}|t=sc}}|lang={{{lang}}}|]}} which would be loaded as this: {{(transclusion #1, of the language template){{#switch:sc|=Hebrew|sc=Hebr|possibly other options...}}|lang=he|]}}. Option #4 would be used as {{{{sc/{{{lang}}}}}|lang={{{lang}}}|]}} which would be loaded as {{(transclusion #1)Hebr|lang=he|]}}. For the same function, #3 uses two transclusions of the same template and two switch functions, and #4 uses two transclusions of different templates and no parser functions. Multiple transclusions of the same template probably don't have to be loaded separately, so the extra transclusion in #4 would only have any effect in the first load of that template in each page. Language templates and script templates are used in pretty much all links, and there is tons of template duplication on some pages, and virtually none on other pages. Translation tables will often have links to dozens of different languages, and language sections will often have dozens of links to entries in the same language. I would give a rough guess that we're weighing on average, one extra transclusion (option #4) against about three to five small parser functions (option #3) and a bunch of extra data, or against a bunch of massive parser function with hundreds of options (#2), or against a bunch of decent-sized parserfunctions and some inaccuracies (#1). However, the real problem is that none of us, as far as I'm aware of, have the slightest clue about how Mediawiki works these things. :) --Yair rand (talk) 13:33, 30 December 2010 (UTC)

We should really make a benchmark for this kind of thing. But I don't really know how to do that... —CodeCat 13:39, 30 December 2010 (UTC)

Certainly not me, BTW we need to consider multi-script languages. Mglovesfun (talk) 13:40, 30 December 2010 (UTC)

As Yair and more people correctly said, {{langscript}} uses a very large switch function to go through hundreds of languages to get the right script. However, I believe a group of {{sc:en}}, {{sc:fr}} and {{sc:he}} and other 822 templates would be even worse, because it would go through millions of names of pages to go to the right MySQL row. --Daniel. 13:53, 30 December 2010 (UTC)

MySQL uses indexing, which makes these requests really quick. Switch functions generate much more overhead, because these need to be processed by the CPU. -- Prince Kassad 13:57, 30 December 2010 (UTC)

If we mandate that each language template must have a fixed set of subtemplates, then it would be a good idea to have a maintenance script/bot to check each template and make sure that all subtemplates exist. Otherwise we would have to use #ifexist everywhere... —CodeCat 14:50, 30 December 2010 (UTC)

I don't think making sure that each language code has a script subtemplate would be too difficult. ISO doesn't add new codes all that often, do they? --Yair rand (talk) 14:54, 30 December 2010 (UTC)

Annually. -- Prince Kassad 14:59, 30 December 2010 (UTC)

I really dislike option #2, both because Robert Ullmann (talk • contribs) apparently felt that it would be too expensive, and also because I think it's ugly. I think of default display behavior as a "property" or "attribute" of languages, rather than something that languages get mapped to, if that makes sense. (Or maybe I've just been an OO programmer for too long.) Options #3 and #4 are both good IMHO. I tend to prefer the parenthesized variant of option #4 (whereby {{he/script}} redirects to {{Hebr}}, as in fact {{HEchar}} already does) as the cleanest approach, but option #3 does have the benefit of matching {{etyl:xx}}. —Ruakh_TALK 22:48, 30 December 2010 (UTC)

Just a note that if we do end up using option 4, the templates should be added to a category (like Category:Language-to-script associations). -- Prince Kassad 17:34, 31 December 2010 (UTC)

I second the cries to just "test" this (just create a page that contains the templates you want, and open the page with ?action=purge&forceprofile=true, then look for the massive comment in the page source to find out how long parsing took — retry a few times to sort out all the randomness). From very basic testing, it seems that the switch statement doesn't scale very well User:Conrad.Irwin/script1 (it requires O(n) time, so the language codes starting with a z are very slow), though loading 800 simple templates is ok User:Conrad.Irwin/script2; Xyzy 800 times is halfway between the two User:Conrad.Irwin/script3. .

I suspect that options 3 and 4 will be similarly performant — though the more information gets put into the templates in 3, the slower it will get. Option 2 seems an odd choice, it may provide a big O(1) speedup, but at the cost of a small O(n) slow down — so longer pages are made slower even though shorter pages are faster; still, I trust there's a reason it's like that (Ullmann is better at this game than I am). If we were to use Option 4, it would be better to manually copy the contents of the script template to each language instead of using a redirect (that way you're loading only two templates per language instead of three). Actually I suppose all the options would be greatly improved if we didn't need to load the script template at all — are there any differences that can't be implemented in CSS once you know the {{{lang}}} {{{sc}}} and {{{face}}}?. Conrad.Irwin 17:22, 1 January 2011 (UTC)

I already suspected that large switches would be slower. However, I imagine that the underlying code just looks at each case until it finds a match. So I suspect that if the first case is always taken, it is faster than if it has to fall back to the default case. And if this is so, then the switch-per-template approach will probably be very fast if we order the cases in order of usage frequency. This is what I already did in my little test above. —CodeCat 18:24, 1 January 2011 (UTC)

If the problems are only arising on pages like water, that won't help, as you need all branches of the #switch: (and some more...). Where are the current problems with these templates best exhibited? Conrad.Irwin 18:34, 1 January 2011 (UTC)

No, all the script stuff is in the CSS. But we would need to use a bot to add the script information to every single foreign script entry, therefore it's easier to create a bunch of templates. -- Prince Kassad 19:09, 3 January 2011 (UTC)

Technically I think CSS3 supports bidi stuff, and obviously JS does, but personally I'd greatly prefer that that remain in the HTML proper. But aside from that, everything can be done in CSS. Anyone have any thoughts how to handle bidi stuff without loading script templates? (One option, that I don't really like, is just to say that sc= is mandatory when explicit bidi marking is required. This should be relatively rare; basically it would only come up when either (1) a term in a right-to-left script either starts or ends with a directionally neutral character or (2) two terms in right-to-left scripts are listed next to each other with only directionally neutral characters in between. In the former case, a browser would mistakenly treat the neutral character as left-to-right, and in the latter case, it would mistakenly treat the characters as right-to-left.) —Ruakh_TALK 19:21, 3 January 2011 (UTC)

It just came to my mind you could use variable selectors in the CSS, like , etc., which would forever obsolete script templates. It only breaks IE6. Is this worth looking into? -- Prince Kassad 19:25, 3 January 2011 (UTC)

Well, on second thought, you could just change the templates like {{infl}} to add a class with the language code (like class="lang-ru") which could then be formatted in CSS. That would be an IE6 safe method. -- Prince Kassad 19:19, 4 January 2011 (UTC)

Indeed; or class="lang-ru-term". —Ruakh_TALK 15:19, 5 January 2011 (UTC)

I implemented the CSS method for now, at least until we can decide on another method. Notice its effects on water. Before:

• Preprocessor node count: 125094/1000000
• Post-expand include size: 359213/2048000 bytes
• Template argument size: 68657/2048000 bytes
• Expensive parser function count: 54/500

After:

• Preprocessor node count: 110350/1000000
• Post-expand include size: 342076/2048000 bytes
• Template argument size: 68516/2048000 bytes
• Expensive parser function count: 54/500

Note how especially the first two went down a lot. And Xyzy is not even used very much on water, because most translations are implemented using {{t-simple}} which circumvents it. -- Prince Kassad 21:39, 8 January 2011 (UTC)

• ...Hm, so what happened with this? The change to Xyzy was reverted by Ruakh with the edit summary "that solution is not ready yet. for one thing, CSS changes take >30 days to reach all users" over a month ago. Is there any way to make it ready? --Yair rand (talk) 15:04, 21 February 2011 (UTC)

• I believe it's ready now: it's been 34 days since PK and I finished the remaining necessary CSS changes that I know of. —Ruakh_TALK 15:26, 21 February 2011 (UTC)

Okay, looks like the CSS solution seems to cause unexplained problems. Therefore, I retract my previous decision and now vote to delete the template outright, replacing it with {{Latn}}. Yes, defaulting to Latin script is evil™, but as it seems, there's no other solution ready yet, so we're stuck with this. -- Prince Kassad 22:20, 8 March 2011 (UTC)

Hi, all.

I'm requesting authorization to run my interwiki bot in the article namespace. It runs in -auto mode which means no existing redirects will be removed.

Please, read and cast your vote at Wiktionary:Votes/bt-2010-12/User:MalafayaBot for operation in Article namespace. Thanks, Malafaya 14:44, 30 December 2010 (UTC)

You should announce the vote in the BP: AFAICT that's SOP. Can you explain the edit to ]?​—msh210℠ (talk) 20:23, 30 December 2010 (UTC)

I also announced at BP. It's been over 3 years since that edit but I can think of 2 possible explanations:

• I was supposed to run the bot for Wikipedia and inadvertedly started it for Wiktionary, and a wrong interwiki in some other Wiktionary was found;
• I was supposed to run for Categories and ran it against articles, and a wrong interwiki in some other Wiktionary was found;

As it was the first edit, I suppose I was still doing some tests to apply for bot flag, which was then declined (I had asked for article interlinking, exclusively done by Interwicket at the time). Anyway, I immediately noticed the mistake and corrected it. Malafaya 18:15, 31 December 2010 (UTC)

I should add that if new edits are required, I can easily provide them. Malafaya 18:25, 31 December 2010 (UTC)

You say "and a wrong interwiki in some other Wiktionary was found". Do you mean — or, anyway, is it true — that if another Wikt has ain interwiki link to us (]) from a different pagename (]), then your bot will link our page (]) to theirs (]) also?​—msh210℠ (talk) 16:01, 3 January 2011 (UTC)

This used (unless I'm mistaken) to link to {{{1}}} and display {{{2}}}. Now it links to and displays {{{2}}}, breaking, e.g., ] (and doubtless many other pages).​—msh210℠ (talk) 18:08, 30 December 2010 (UTC)

That was a consequence of this edit by Daniel. to {{makelink}} on 23 October 2010. The edit had no edit-summary, but the goal was apparently to replace a call to {{wlink2}} with equivalent code, for reason or reasons unknown. (I have some guesses, but I don't care enough to speculate.) It looks like copy-and-paste went awry, with {{#if:{{{3|}}}|{{{3}}}|{{{2}}}}} appearing in two places where {{{2}}} must have been meant. I've fixed it now.

I seem to recall Daniel. (talk • contribs) agreeing at some point to stop engaging in this sort of behavior. Does anyone remember the details of that? Specifically, was it before the above-linked edit, or after?

—Ruakh_TALK 20:52, 30 December 2010 (UTC)

The German word Aar has three different genitive forms: Aares, Aars, Aaren. Template:de-noun only allows two. Can the template be expanded, or should I use a different template? - -sche 23:48, 30 December 2010 (UTC)

I don't think we want to add a gen3 parameter just for one word. You could use {{infl}}. Mglovesfun (talk) 17:32, 1 January 2011 (UTC)

Why not? We've created a pl3 parameter for the sole reason that Junge uses it. -- Prince Kassad 19:25, 1 January 2011 (UTC)

Abakus also uses three plural forms. How would I use template:infl? - -sche 21:39, 1 January 2011 (UTC)

Park and its compounds (Tierpark) also have three plural forms, as does Sozius (see de:Sozius). - -sche 19:42, 10 January 2011 (UTC)

Atlas also uses three genitive forms. I have tried to add a third parameter to de-noun, but it does not work. - -sche 19:45, 10 January 2011 (UTC)

Why? Where's the problem? -- Prince Kassad 21:52, 10 January 2011 (UTC)

It works now. Possibly I just had to update my cache, or there was a delay in the software calling up the new version of the template. I can however not tell if my last edit, which added the two }}, was necessary. - -sche 22:31, 10 January 2011 (UTC)

Right now we have three different kinds of language templates: Those with no prefix like {{en}}, those for reconstructed languages like {{proto:ine}} and those for conlangs like {{conl:tlh}}. The problems this creates are kind of obvious when you look at all the extra templates we've now needed to create: {{langprefix}}, {{languagex}}, {{langnamex}}, {{lx}}, {{termx}} and so on. And still, a lot of important templates still don't work for languages with codes that have prefixes. So I'm hereby proposing to do away with this and just use the code directly. {{proto:ine}} becomes {{ine}}, {{conl:tlh}} becomes {{tlh}} and so on. Note that this does not mean that we should now allow these language in the main namespace. This is only about the names of the language templates, not more. —CodeCat 17:38, 31 December 2010 (UTC)

But the problem is that AutoFormat will consider them eligible for the mainspace if they exist without a prefix. This is why we had to choose this option to begin with. -- Prince Kassad 17:42, 31 December 2010 (UTC)

Then can't AutoFormat be fixed so that it doesn't? It seems to me that by trying to solve a small problem we've created a much bigger one. —CodeCat 17:42, 31 December 2010 (UTC)

A bit of technical background: AutoFormat checks the page User:AutoFormat/Languages to know which languages it accepts. This page is regularly refreshed by UllmannBot (well at the moment, this procedure is frozen...) which checks all templates with two or three lowercase letters. It then sorts out those that are not language templates (like rfv, rfd, ...), and adds all the others to this list.

Any changes to this would require either maintaining the list manually (which is very tiresome), or changing the UllmannBot code, which I have no access to since it's not public. -- Prince Kassad 17:48, 31 December 2010 (UTC)

Given the proposal above with respect to language templates, I think it would be easy to add language type as one of the pieces of information associated with languages. So, for example, {{ine|t=type}} or {{ine/type}} could return proto. UllmanBot could then use that information when it makes its list. —CodeCat 17:53, 31 December 2010 (UTC)

Or instead to just add a comment to the template <!-- (constructed) -->. Bots are much better at reading comments than expanding out templates. Conrad.Irwin 17:31, 1 January 2011 (UTC)

We may have to assume that UllmannBot won't be updating that page, and its code won't be released, ever. If that's true, then another solution is needed, anyway. Conrad's and CodeCat's, just above, sound good.​—msh210℠ (talk) 15:56, 3 January 2011 (UTC)

Is it possible for some help creating a Proto-Eskimo template so that I can add Proto-Eskimo derived words from Eskimo-Aleut languages? Many thanks- Jakeybean 19:25, 31 December 2010 (UTC)

What's wrong with {{proto|Eskimo|foo|lang=kl}}? Mglovesfun (talk) 17:31, 1 January 2011 (UTC)

Sorry, what I mean is it's red-linked therefore it doesn't exist under the list of languages here, or do we only list those relevant to English, i.e. Proto-Indo-European and Proto-Germanic? Slight confusion, sorry. Jakeybean 17:58, 1 January 2011 (UTC)

Do you mean Proto-Eskimo, the way we have Proto-Germanic? —Stephen ^(Talk) 18:06, 1 January 2011 (UTC)

Yeah, and the category also. Thanks Stephen! I just wasn't sure what the consensus was with Proto languages in general so was reluctant to create anything. Jakeybean 18:17, 1 January 2011 (UTC)

Proto-Eskimo entries would be stored in the Appendix namespace, like *inuk. Compare *ahwō. —Stephen ^(Talk) 18:46, 1 January 2011 (UTC)

Cool, thanks. Just FYI there are two precedents to Proto-Eskimo; Proto-Inupik and Proto-Yupik. Proto-Inupik can also be called Proto-Inuit but I've used the term Proto-Inupik as it gives higher Google hits. Jakeybean 18:56, 1 January 2011 (UTC)