Template talk:t

I created this template while cleaning up the dysfunctional frtrad template. It allows to encapsulate translations and puts a star referring users to the other Wiktionary projects. I don't know if it will be accepted by the community or if it should be. Let's say it's an experiment for the time being.

It can be used as follows:

====Translations==== *Alanguagename: {{t|fr|pomme|f}} To produce: *Alanguagename: ] ''f''

I'm curious how it will be received. Polyglot 00:18, 22 August 2005 (UTC)Reply

Good work. It would be the standard in all translations and definitions in Wiktionary. --77.210.55.105 06:52, 6 October 2007 (UTC)Reply

Many translations still use plain links instead of this template, especially those added before the template was created. I have started to convert plain links to template:t for Scandinavian languages, using a pywikipedia regex described on my user page. Some statistics below. --LA2 21:48, 16 September 2010 (UTC)Reply

Date of database dump	Number of translations using
	{{t|...}}	{{t+|...}}	{{t-|...}}	Total	Change	...|sv|...	Change
2010-08-12	164,532	260,929	193,825	619,286		16,743
2010-08-24	169,279	261,479	194,337	625,095	+0.94 %	16,892	+0.89 %
2010-09-01	170,155	263,288	195,192	628,635	+0.57 %	16,994	+0.60 %
2010-09-12	169,009	267,026	196,983	633,018	+0.70 %	17,403	+2.41 %

Well, its good, apart from if u see necessary, then (as necessaire is not a noun, therfore neither m or f), u get left with some {{}} signs. I wouldnt know how to fix this --Expurgator t(c) 01:30, 22 August 2005 (UTC)Reply

This doesn’t seem to be a problem. Both {{t|nl|baard|m}} and {{t|nl|baard}} {{m}} work, but they produce different results: baard m and baard m. I prefer the second. By the way, this template already existed: Template:trad, but I changed it a bit to make the star be more informative. henne 09:43, 8 November 2006 (UTC)Reply

What do others think of this? I suggest to abolish the m/f/mf/n/c/p/s as fourth/fifth parameters, since it just makes the image more complex. I mean, you don’t have to use them, but I suppose we want some uniformity, so a consensus would be good.

So I suggest to use {{t|nl|ding}} {{n}} (rendered as ding n) over {{t|nl|ding|n}} (rendered as ding n). I think the second form sort of suggests the gender tag is part of the word, which we don’t want. henne 12:50, 8 December 2006 (UTC)Reply

That's why a template, so we can fix it; I'll change the order for now. Robert Ullmann 21:19, 25 December 2006 (UTC)Reply

How can one indicate the sense number? There may be a particular of the translated word that is the one one would want to indicate as the sense for the translation. I tried {{t|pt|morro (1)|m}}, but that creates a link to a nonextant word rather than a link to a particular sense (1) of an extant word. Perhaps that should be a named parameter since it doesn't always occur. Vivafelis 03:02, 13 April 2009 (UTC)Reply

Unlike other wiktionaries, English Wiktionary does not utilise numbers as indications of particular senses. The reason in simple: if someone where to add or rearrange the senses at a target link (i.e. morro in your case), all the glosses in all the entries that link to it would need to be fixed. Therefore, just provide the link without any gloss (numerical or parenthesised prosaic) when adding translations, and on the target entry itself use {{qualifier}} to indicate which particular sense of the wikified English word the translation refers to. --Ivan Štambuk 07:03, 13 April 2009 (UTC)Reply

There should be some trick to allow piped links for the translation, or an extra argument for it. For example, on the page for uniform, I want to translate it with ]. I cannot enter this as the second parameter. OTOH, just entering {{t|nl|uniform}} gives an incorrect wikilink. There must be some trick using {{isValidPageName}}. henne 15:56, 17 November 2006 (UTC)Reply

The problem is in passing the parameter to this template. The work-around I think would look something like this:

] ...

Which would default in '2' for 'sc' if 'sc' is not given, and add the hash only if the variable 'hash' is passed in, then add a pipe and display only the 'sc'/'2' combination after that pipe. Note that if both '2' and 'sc' are not given, this will do funky things. But it would have the advantage of getting rid of the #if 'sc' thing at the start, which problably doesn't belong here anyway. To then call it from uniform, you'd have {{t|nl|uniform|hash=Dutch|sc=|dn=uniform}}. Please note that I haven't tested this exact combination anywhere yet. --Connel MacKenzie 19:11, 17 November 2006 (UTC)Reply

sc is the script parameter, the name of the script template, not something defaulted to or from param 2. And you are making it way too complicated ;-) Robert Ullmann 15:23, 7 December 2006 (UTC)Reply

Looks promising. Though maybe it should be even more general: remember my question in the Information Desk? Allowing alternative links or something. So instead of a ‘hash’ parameter, allow ‘al’ (for alternative link), which is the link or something.

It is totally unclear to me what the ‘sc’ param is doing there anyway. Funky things isn’t that bad, one should hope everybody makes a preview first when he uses a template, and would see that he did something wrong... henne 12:21, 20 November 2006 (UTC)Reply

So that you can use (e.g.) {{ARchar}}, you can't use it in the 2nd parameter, and you can't wrap it around the whole thing. Robert Ullmann 15:23, 7 December 2006 (UTC)Reply

I thought of a much easier solution: just always add the language hash to the link. This should always work, since that heading is supposed to be present. The problem then only is to derive the language name from the language code. I don’t know how to do this with the templating mechanism, but there must be some way to do this, right? Something like:

] ...

henne 15:04, 7 December 2006 (UTC)Reply

Don't worry about sc=, it has little to do with this (just as to wrap the script template in on the right level and has no default). It is easy to convert language codes to names, except that a number of the less common languages have code templates with wikilinks and other cruft inside them. We really ought to say that all the 2- and 3-letter language code templates translate to just the en.wikt standard name, and nothing else. Robert Ullmann 15:23, 7 December 2006 (UTC)Reply

Easy to do, and it won't change the call at all. But, if I do it now, it will break for (say) Kurdish, because {{ku}} translates to Template:ku rather than Kurdish. Robert Ullmann 15:23, 7 December 2006 (UTC)Reply

You did something strange now: {{t|nl|ding}} now appears as ding^(Nederlands). I think it was better before, where the abbreviation appeared in the subscript: ding^(nl). What I am suggesting is that you make the piped link automatically include the hash to the language section. I think it would work like this:

{{#if:{{{sc|}}}|{{{{{sc}}}|]}}|]}}
 {{#switch:{{{3|}}}|f|m|mf|n|c={{{{{3}}}}} <nowiki/>|}}{{#switch:{{{4|}}}|s|p={{{{{4}}}}} 
<nowiki/>|}}]

(without the linebreaks) Do you understand what I mean now? henne 12:45, 8 December 2006 (UTC)Reply

Yes, but this won't work. #language is the name of the language in the language. We need the name of the language in English ;-) As I said, this would/will be easy if we can remove the wikilinks in some of the language name templates. (A language well-known enough to have a wikt ought not to be linked on every appearance anyway!) Robert Ullmann 21:19, 25 December 2006 (UTC)Reply

See e.g. false#Translations for Dutch. I think it is really better to use the abbreviated version. henne 10:54, 9 December 2006 (UTC)Reply

Due to the discussion about how the superscript should look, this issue hasn’t been solved: it still is not possible to use alternative links, which is necessary way more often than you would think. Can somebody at least temporarilly introduce this, perhaps like Connel suggested? henne 10:20, 10 January 2007 (UTC)Reply

Since nothing is happening with this, I took a look at the Dutch wiktionary, where it is used for every translation. The code over there is this:

<span lang="{{{1}}}" xml:lang="{{{1}}}">{{#ifeq: "{{{3|{{{2}}}}}}"|"{{PAGENAME}}"| 
{{{3|{{{2}}}}}}|]}}</span> <span 
class="trad-sup-code"><sup>{{#ifeq:{{{2}}}|nl|(nl)|]}}</sup></span>

(without the linebreaks) It allows for piped links by making this the second parameter! This is only possible because they haven’t cluttered this template with information for gender and number, which I have always found a bad idea. The trick is that if the third param is present, it is used.

We can do away with the part {{#ifeq:{{{2}}}|nl|(nl), since we do not include the English translation (they have this strange policy of including the Dutch translation for Dutch words). I am also unsure what the test for PAGENAME is for.

Furthermore, it does nice CSS stuff to be able to hide the superscript, which will please SemperBlotto ;-).

Does anybody see a trick to integrate this, or will it break too much pages? The current layout also puts the gender info after the superscript link, so moving this out of the template wouldn’t change that. It would only get me a lot of work to correct all entries I edited that use it. :-(

Can’t we have the language codes instead of the language names spelt out, like van^Nederlands. It is simply too much (and not even English). If we can’t use a common button such as ^ or *, then let at least keep it to two or three letters. —Stephen 04:21, 10 December 2006 (UTC)Reply

That was an experiment by someone, I put it back to the code. Tried leaving off the parenthesis. Also changed the order of the link and the gender/plural markers. Robert Ullmann 21:19, 25 December 2006 (UTC)Reply

Some talk about this has taken place in the Beer parlour and a vote on whether text or symbols should be used is taking place here. The first vote ends 15 January 2007, the second on 31 January 2007. Saltmarsh 11:44, 26 December 2006 (UTC)Reply

• See also Template talk:t/Archive

Since we've decided to use this, I'm doing some serious s/w engineering. Sections follow, separated if you have comments. Robert Ullmann 15:29, 24 January 2007 (UTC)Reply

Use alt= parameter: {{t|(lang)|(pagename)|alt=(display name)|...}}

Plays well with the sc= parameter if needed. Robert Ullmann 15:29, 24 January 2007 (UTC)Reply

Note that this is not needed for the case above: Dutch/uniform. The template does the right thing already. (see uniform) Robert Ullmann 15:35, 24 January 2007 (UTC)Reply

The template links to the correct section in the entry in the English wikt IF the code template for the language does not have any wikilinking inside it (it shouldn't, as the existence of a wikt for a language indicates that it is a major language.) E.g. {{ku}} MUST be "Kurdish", not "]"

If you get bad formatting or links, check the language code template. Robert Ullmann 15:29, 24 January 2007 (UTC)Reply

Someone else has been tiring himself here: {{Rhymes2}}, maybe you can use that, or get in contact with Jimp, so that he can use the trick you used here in {{Rhymes}}. henne 11:33, 25 January 2007 (UTC)Reply

Um I see. And that method won't work anyway: if you invoke it more than one or twice (e.g. if t tried to do that), you will exceed the amount of wikitext that can be transcluded in a page. Robert Ullmann 14:47, 25 January 2007 (UTC)Reply

The syntax has changed a bit now. A named parameter is needed for the section reference (ls for ‘language section’). Thus the syntax now is {{t|nl|data|ls=Dutch}}, if a link to the language is needed (which it is in this case, since data exists in a lot of languages. H. (talk) 14:03, 1 April 2007 (UTC)Reply

And note that the user doesn't have to worry about it; the tbot will add the ls= parameter when needed, and remove it when not. But it is harmless to add it, as long as the language name is correct. Robert Ullmann 15:42, 1 April 2007 (UTC)Reply

I (or someone) will add a CSS class to allow logged in used to display a symbol instead of the language code as the link to FL wikt. This has not been done yet. Robert Ullmann 15:29, 24 January 2007 (UTC)Reply

I'm beginning to really hate this template. Manually entering them one by one defeats the purpose of automatically adding a link to the FL wikt:. Manually cascading the DB searches for the stupid @#%%ing language name (from the language code) is a Bad Idea. Especially a couple HUNDRED TIMES on any given page...where the caching is flushed because it is a page, including a template, trancluding a different template, trancluding yet another template. For each appearance of {{t}}!

It seems pretty clear to me, that this should be done either in PHP on the server, or in Javascript on the client. My WT:VOTE in support was based on that premise. Why is the template still here? For a reference model?

This template also screws up WhatLinksHere, BTW. --Connel MacKenzie 19:28, 25 January 2007 (UTC)Reply

Can you explain this a bit more for the not-that-knowledgeable in JS and inner workings of Wiki? I think (thought) the template is very nice, since it does a lot of things that save me typing. For example that FL wiki link. You wouldn’t expect me to enter ^(]) after every word, do you? That’s what templates are for, to standardise and save typing. Ok, maybe the language trick should be changed. We can still use {{Rhymes2}} (after renaming). henne 19:55, 28 January 2007 (UTC)Reply

Connel worries a lot about performance issues I don't understand enough about (he refers to 3 levels of transclusion, there are at most two, but so on) ... What he is talking about with JS is doing something that doesn't require the t template, but does magic for each line in the Translations section when the page is rendered. We can't use the Rhymes2 thing anyway; never mind performance, once it gets transcluded a few times you'll hit the page limit. And I don't understand why or where it screws up Whatlinkshere. I wonder if there is something somewhere that explains more. Robert Ullmann 20:42, 28 January 2007 (UTC)Reply

I just stumbled upon {{language}}, which is used in {{context}}. Since context is used a lot too, maybe we can just use language here (and in {{rhymes}}) too? henne 19:13, 29 January 2007 (UTC)Reply

{{language}} is at least one level worse that what I was doing (what t does now), and only would increase Connel's complaint. He probably isn't complaining about {{context}} too much because it is only used a few times per entry, but it is a lot more complex (both in implementation and use) than it should be. At least t right now is just doing one straight template call. Robert Ullmann 21:32, 29 January 2007 (UTC)Reply

All of the performance issues corrected in the current version; the only templates calls are for script, gender, and number, which occur in any case. Robert Ullmann 16:16, 1 April 2007 (UTC)Reply

Implementation of this template's language link was discussed at length at Wiktionary:Grease pit archive/2007/March#Issues implementing Template:t in translation sections. —Mzajac 20:54, 10 March 2008 (UTC)Reply

Link to the foreign language wikt is only generated if FL wikt exists. Robert Ullmann 17:23, 1 April 2007 (UTC)Reply

As requested by Connel; it also makes it easier for users who don't know the language code to use. Robert Ullmann 22:36, 2 April 2007 (UTC)Reply

I would like to add hover text to the interwiki link that makes it more clear that the link is to a foreign-language Wiktionary. The format of code:word may be immediately obvious to all of us and very clear to anyone who has contributed to the wiki projects, but it is not clear to a user who is unfamiliar with the format. This may not be so much a problem for blue links, more important for red links if you've ever wondered why people come here and write definitions in other languages. The two-letter language code, also in parentheses, doesn't completely identify this.

I don't think my addition of hover text, before it and several not so good contributions were reverted, made this distinction completely clear, but is there a better way to do it, maybe adding to the default code:word instead of replacing it? DAVilla 06:30, 3 April 2007 (UTC)Reply

I think that was good, how about you re-add it. But I’d leave the order of FL link and gender info as it is. Notice that it doesn’t fit with our current policy about romanisations either (i.e. they should come between gender and word). H. (talk) 13:39, 5 April 2007 (UTC)Reply

Thanks for the feedback. Putting the FL link at the end was an experiment that didn't last very long. I would like to see an example of what you think is best when everything is included. We might have to consider accepting the romanization as a parameter. DAVilla 15:30, 8 April 2007 (UTC)Reply

For translations into languages with non-Roman scripts, it would be nice for this template to support a parameter that gives the translation's transliteration. Using the "alt" parameter for this doesn't seem quite adequate. Thoughts? Rod (A. Smith) 16:50, 26 July 2007 (UTC)Reply

How about "R" for "Roman alphabet"? How did this created with such an important piece missing? --Connel MacKenzie 01:08, 8 August 2007 (UTC)Reply

Because the exact syntax of Translations lines hasn't been nailed down yet. The only issue here is that the template provides for gender and number, which usually come after the transliteration if present. It is possible to just ignore those parameters and use the m, f, etc templates after a transliteration as usual. Robert Ullmann 01:21, 8 August 2007 (UTC)Reply

I added tr= as shown above. Robert Ullmann 13:08, 10 August 2007 (UTC)Reply

Thanks, Robert. I'll start using this template for Korean translations now. Rod (A. Smith) 15:46, 10 August 2007 (UTC)Reply

I'm eagerly awaiting the non-Roman script handling for Korean translations. Rod (A. Smith) 16:07, 10 August 2007 (UTC)Reply

Oops. Somehow I hadn't noticed “sc”. Rod (A. Smith) 16:11, 10 August 2007 (UTC)Reply

tr= doesn't work with Armenian. Check at pilaster entry. GareginRA (talk) 21:22, 31 October 2021 (UTC)Reply

Someone keeps reverting my code with the transliteration provided (which doesn't work anyway), but you can find it in history. GareginRA (talk) 19:50, 1 November 2021 (UTC)Reply

This template code is very hard to read so I can't see where the red colour comes from. It is different from the standard colour of redlinks though which is ugly. It should be made the standard colour. Also, if these colours are done with inline styles they should be moved to Common.css. I would've done this myself but I can't read the code. I'm available to help if there are any questions though. (Except that I'll be travelling again for the next 6 weeks) — Hippietrail 07:53, 6 August 2007 (UTC)Reply

t itself does not use any explicit colors. t- uses color:red, and it should be very easy to read where (even if the rest is a bit dense!) Robert Ullmann 13:07, 6 August 2007 (UTC)Reply

OK I've replaced the hard-coded "red" with hard-coded "#002bb8" which is the monobook colour for redlinks. But of course now I realize it should be a new shade that matches the external link blue (#3366BB in monobook). I'll see if I can find a good colour mixing site and make one. I've only just noticed that external links do go darker when they have been visited. I'll keep this behaviour for the red links. — Hippietrail 01:07, 7 August 2007 (UTC)Reply

The second term must be the headword both here and on the FL Wikt. But with Old English, we on en.wikt use headwords without diacritics (like the Anglo-Saxons did), whereas ang.wikt marks long vowels with macrons in the pagenames. A word like belean (“dissuade”), for example, I want to write as {{t|ang|belean|alt=belēan}}, but obviously this will not work because if the OE wiktionary does have an entry for it it will be at belēan instead. Any thoughts? Widsith 20:22, 30 January 2008 (UTC)Reply

Is this template for nouns only or adjectives as well? --S.Örvarr.S 15:23, 9 February 2008 (UTC)Reply

It's for every part of speech, including nouns and adjectives. In using it with adjectives, there seem to be differences in opinion regarding whether to include the gender marker. (FWIW, I personally prefer to exclude the gender marker for adjectives.) Rod (A. Smith) 19:25, 9 February 2008 (UTC)Reply

1. If the foreign language is unknown or has no wiktionary, the template should leave out not only the link, but also its trailing non-breaking space. Currently, it inserts two non-breaking spaces in a row. Example, from Rusyn:

• русин m (rúsyn)

2. Formatting the foreign-language links by making them all three of superscripted, smaller, and surrounded by brackets is overkill. Functionally, it is more formatting than is needed to draw attention to their special status: the use of superscript already takes these links out of the text flow and indicates them as something special. The brackets add clutter and may be mistaken for other characters at their small font size. They do enlarge the link target, but this is just compensating for the needless small-font formatting, and shouldn't be necessary anyway because language codes are two or three letters long. The superscript also increases line spacing, making the display uglier in some web browsers.

I would suggest formatting these on the baseline as monospaced font (implying code), or at least remove one of superscripting or brackets. Examples for comparison:

1. Current format: альбатрос m (al’batrós)
2. Superscript only: альбатрос ^uk (al’batrós) m
3. Browser's default monospaced font: альбатрос uk (al’batrós) m
4. Square brackets only: альбатрос (al’batrós) m

—Mzajac 03:50, 10 March 2008 (UTC)Reply

(1) {t} is only for use in translation tables, etymology inline uses {term}. If the FL wikt doesn't exist, use {{tø}} or just leave it and Tbot will fix it.

(2) the link format was very extensively discussed and voted on. Robert Ullmann 12:53, 10 March 2008 (UTC)Reply

#1 is a flaw in the way this template displays. Wouldn't fixing it merely require a few characters to be moved inside of a switch statement?

2: In Safari, the superscripted link format destroys line spacing in the translation tables—it looks terrible, especially if a list item has several translations and wraps to two or more lines. Did the very extensive discussions consider this acceptable, or overlook it?

Can someone link to the very extensive discussions from this page? That might reduce misunderstandings, and save unnecessary work for both me and you. (I've spent a lot of time editing in Wikipedia, but I'm fairly new to Wiktionary. I don't make idle requests without looking for relevant discussion first. I'm becoming frustrated because people keep replying to my suggestions with "that was discussed, now run along", instead of responding to the actual question.)

Thanks. —Mzajac 15:20, 10 March 2008 (UTC)Reply

(note that snide remarks in edit summaries and attitude are not helpful) (1) it will probably get fixed presently. Until then, use {tø} as pointed out or just don't bother with {t} at all since it isn't really accomplishing anything with nothing to link to.

(2) yes, it is annoying to be told that "all this was already discussed". Please note the converse effect: it is annoying to have people endlessly insist that something is wrong, when it has been thoroughly hashed out. In this case, Wiktionary:Grease_pit_archive/2007/March#Issues implementing Template:t in translation sections is the bulk of it. (And, note, this particular issue hasn't come up often, but the others you obliquely refer to may have. In general, you might have a better time if you asked why something is some particular way, instead of saying it is somehow wrong, and you know how it ought to be fixed.)

We might very well more the style of the link to CSS, to provide user WT:PREFS customization, but the default style was decided. You might ask on WT:GP if someone can do a bit of CSS. (noting as I said, if the attitude is "this is broken, fix it NOW" you won't get far ;-) We do like improving things. Robert Ullmann 16:32, 10 March 2008 (UTC)Reply

I'm sorry for the snarky comment, Robert. My original remark here was simply to point out a couple of ways in which this may be improved, not as a complaint. I had tried to find relevant discussion first, and it appeared that no one had considered these points. Both problems are only rarely evident (the first with obscure language codes, the second only in Safari), and I thought it possible that no one was aware of them. I would have merely fixed the first myself, if the template weren't protected. I interpreted your reply as "we won't consider any changes, and aren't even interested in discussing why not." I'll try to be less sensitive give my responses more thought.

I have scanned through the extensive Grease Pit discussion you linked about the foreign language link, but there's really nothing about the format there. From combing through the discussion here again, it appears that the superscript format may have been inherited from link text which originally an asterisk, and that it was changed to text with brackets later. But there's no discussion at all about its format, although that may be elsewhere. I'd like to find it, so I can understand the issue. —Mzajac 20:51, 10 March 2008 (UTC)Reply

yes, it seems there isn't a specific link there; please look at Wiktionary:Votes/2007-01/Translations - wiki links (run off) and then it links to a previous poll and to a BP discussion. Robert Ullmann 12:38, 11 March 2008 (UTC)Reply

Thank you. Your link led me to the Beer Parlour archives, where I think I found most of the relevant discussion and the two run-off polls. Since I have them open in browser tabs, I'll link to them here for future reference.

I guess the superscript format was adopted from other-language wikis without discussion. It seems that the parenthesis were added unilaterally for the run-off vote (with a comment that parenthesis were preferred by most commentors, but my count doesn't support that). One commentor mentioned that he thought he might hate less if it looked smooth and modern and professional." There was some opposition to the parenthesis, but not enough to stretch out the already lengthy discussion and voting. I only mention this to establish that the current solution was not chosen by acclamation.

Anyway, if there was any interest, I would still offer some formatting options which haven't been considered, and I believe could be more in line with professional typography and less jarring to the eye. I'd be interested in an incremental improvement, not reopening a can of worms. But it looks like there is consensus support for the current version, and it does fulfil its function. Thanks for your patience. —Mzajac 18:38, 11 March 2008 (UTC)Reply

1. 2004-06-18 Interwikis in =Translations=
2. 2004-09-20 Template for translations ?
3. 2005-05-31 Interwiki translations in Allow
4. 2006-10-16 Translation links to sister language dictionaries
5. 2006-12-07 Translations - wiki links
6. 2006-12-26 Vote: "Translations - wiki links"
7. 2007-01-08 Translations could be linked to other-lang Wiktionaries.
8. 2007-01-18 Vote: Translations - wiki links (run off)
9. 2007-02-12 Interwiki links in translations: when?
10. 2007-02-19 Translations - wiki links (run off)

I have built a test case demonstrating the problem no. 1, above, at User:Mzajac/test. The improved template code at User:Mzajac/t can be pasted right into this template {{t}}. —Mzajac 19:16, 11 March 2008 (UTC)Reply

Thanks, Robert. —Mzajac 16:50, 18 March 2008 (UTC)Reply

For the past few months I assumed a blue t link meant the word exists in its native Wiktionary just as the red t link means it does not exist. Only now did I realize the semantics of the blue t link are not the opposite of the red link.

• t- The red t link means "The native Wiktionary has no article on this word".
• t The blue t link means "The native Wiktionary either does have an article on this word or it has not been checked"!

To me this is very counterintuitive, especially since the bot in charge of these links does know whether the native articles exist or not. I feel strongly that the semantics should be change and a new variant of the template introduced:

• t- The red t link means "The native Wiktionary has no article on this word".
• t+ The blue t link means "The native Wiktionary does have an article on this word".
• t The external link coloured t link means "The native Wiktionary has not yet been checked for the existence of this word".

Since the t variant is the current default, the quickest to type, and the one people are used to using if they haven't checked the native Wiktionary, changing its meaning makes good sense. Since + is the opposite of - it also makes sense for the blue link.

The only other question is regarding the colours of the links. Originally all links were "external link pale blue". Later was introduced "standard HTML red" for t-, a shade which was not the same is standard redlink red and niether a match for standard "external link pale blue". Later I modified the template and computed a shade of red to best match the other link colours already used. At that point I overlooked the different meaning for blue in these links as compared to other links.

I propose therefore to set the red and blue versions of the t links to the standard red and blue link colours. As for the "untested" links, they could revert to "external link pale blue", or they could share one of the "unkown" colours I've used for links in JavaScript extensions such as the citation tab or "ajaxtranslinks.js" which sets an orange colour for links in translation tables where a page exists for the term but has no entry for the correct language.

Opinions? — hippietrail 10:31, 18 March 2008 (UTC)Reply

Note that we do have {{temp|t+}] with the desired semantics. The colours could use a bit of tweaking.

There is also a null form {{tø}} used by the bot when someone has added {{t}} for a language with no wikt. (Which really isn't necessary, a plain link would be fine.) If the wikt is created later, the bot will change it to one of the other forms. Robert Ullmann 12:21, 18 March 2008 (UTC)Reply

I can't seem to be able to pass in {{fpl}} for the {3} parameter as in {{t|es|PUF|fpl}} on FAQ. Any way to add this (and as well {{mpl}}). Or should I leave it as just f? Thanks --Bequw → ¢ • τ 15:47, 19 March 2008 (UTC)Reply

Try {{t|es|PUF|f-p}}: PUF f pl. —Michael Z. 17:15, 19 March 2008 (UTC)Reply

Note that {mpl} and {fpl} are both deprecated, should be {{m|p}} and {{f|p}}. (If you use mpl or fpl, they get immediately replaced by AF) Robert Ullmann 07:40, 20 March 2008 (UTC)Reply

Does anyone mind if I edit this template (and its littermates) to support a gender of g, which would then transclude {{g|langname}}? (If I'm understanding the code right — obviously I'd want to test first to be sure — all it would take is modifying the |}} at the end to be |g={{g|{{{{#if:{{{xs|}}}|t2|t-sect}}|{{{1|}}}|{{{xs|}}}}}}}}}, i.e. mostly just copying over the section-link code.) —Ruakh_TALK 23:51, 8 September 2008 (UTC)Reply

It wouldn't be easier just to follow the template with {g|language} when needed? Robert Ullmann 05:38, 9 September 2008 (UTC)Reply

By that token, wouldn't it be easier just to follow the template with {{m}} (or the like) when needed? (I actually don't understand why the gender stuff is incorporated into the template that way, but if we're going to do it, {{g}} actually seems like the one it's most useful for, because that way the template can handle the standard language name and everything.) —Ruakh_TALK 11:44, 9 September 2008 (UTC)Reply

Yes, there isn't much reason other than just having it as one template, this being a bit less noisy.

However, note that the existing {t} does not reference {{m}} unless m is in the "call". Since the template language evaluates all branches of an if or switch, your code will cause {{g}} to be referenced and expanded for every use of {t}. (!)

we could do this a bit better: |g={{{{{3}}}|lang={{{1}}}}} and "teach" g to take lang=code. Using {3} instead of g prevents calling g all the time; if {3} is (for example) "m", it will do a redundant call to {m}, but that is no overhead, as it will be retrieving template:m anyway. At the same time, better to have {g} re-expand t-sect only when it is used, rather than on all calls to {t}. What do you think of all that? Robert Ullmann 12:49, 9 September 2008 (UTC)Reply

Yeah, sure, fine, whatever. :-)   —Ruakh_TALK 14:59, 9 September 2008 (UTC)Reply

There is a some bug on that page: value (translations -> the degree of importance you give to something -> Russian). Can anybody fix it? -- 4th-otaku 09:14, 1 November 2008 (UTC)Reply

There was a Roman letter mixed in with the Cyrillic. Fixed. —Stephen 17:07, 1 November 2008 (UTC)Reply

Hi,

When I try to convert from the previous standard towards the t template way of doing things, I'm finding I can't encode Japanese translations that have also hiragana listed. Romaji probably belongs with tr, but could there maybe be another parameter for hiragana? Hippietrail probably knows best what a good name for it would be. The previous unsigned comment was made at 2008-11-15T07:44:36+00:00 by user:Polyglot.

I wholeheartedly agree with Polyglot. For mostly ideographic Taiwanese Chinese with w:Bopomofo to mostly phonetic Korean with w:Hangul, including mixed system Japanese with w:Kana, Roman characters may be used as a standard representation for pronunciation but the original phonetic script is important in referring to alphabetized directories like dictionaries, encyclopædiae, telephone books, and such.

Beyond this, the best transliteration system for English-based novices rarely picks up the nuances and regular patterns that are vital to understanding the language and are rarely one-to-one making back-translation ambiguous at best. Cf. w:ISO/TR 11941 v. w:McCune-Reischauer romanization, w:ISO 3602 v. w:Hepburn romanization, w:ISO 9 v. w:BGN/PCGN romanization of Russian. Fortunately, w:BGN/PCGN has used w:ISO 7098 pinyin for awhile, abandoning systems that half included many w:Wade-Giles place names like Pei-ching and reliquary ones like Peking, in favour of w:Běijīng.

Furthermore, adding one extra parameterallows for, say, w:UNGEGN v. w:ISO 233 w:Romanization of Arabic, or vocalized v. non-vocalized. I have had many friends find difficulty with pronunciation because of the gap between Germanized Hebrew and native English pronunciation or even with government identification when moving between formerly French Arab countries to the Anglosphere. Back to Japanese, the w:okurigana system can vary markedly from user to user so a kana transliteration can provide a vital fall-back for real-life situations. In the end, just a native script and English transliteration are insufficient for a top-end global dictionary. :)--Thecurran 15:04, 16 January 2009 (UTC)Reply

You are overthinking this (as regards the template parameter itself ;-). tr= just means "whatever we put in the parenthesis". For Hiragana and Rōmaji, you just use tr=], rōmaji. (Noting that neither is a "transliteration", they are both script forms of Japanese ;-) If you want to show others, then do that; the template isn't sentient, it doesn't "know" what "tr" might mean; it just "knows" to put that in the parenthesis, eh?

However, translations tables should not be in the business of providing multiple transliterations; that belongs in the entry for the word. Robert Ullmann 15:19, 16 January 2009 (UTC)Reply

I really like the t template, because it groups everything of a translation together, the language, the script, etc. What's missing is the comment that's sometimes found between parentheses after a translation like archaic, only in a certain region, only for specific senses, etc. Could that also be put in a parameter?

Just use {{qualifier}} after the template and whatever, as anywhere else this is done. Robert Ullmann 15:10, 16 January 2009 (UTC)Reply

Please add this one to Category:Translation templates. Thanks in advance
--Jerome Potts 19:37, 7 June 2009 (UTC)Reply

Anyone have a quick guide when to use the different templates over others?

You can always use {{t}}, since we have a bot that makes adjustments. The template {{t+}} is used when the taget page exists on the other-langauge Wiktionary, and {{t-}} if it does not. However, as I said, you can always just use {{t}} and let the bot take care of any adjustments. --EncycloPetey 21:51, 13 March 2010 (UTC)Reply

What purpose does xs= have? It doesn't seem to be mentioned in the documentation. Mglovesfun (talk) 13:31, 15 May 2010 (UTC)Reply

No purpose, leave it alone, ignore it, pretend it doesn't exist. (O.K., so if you really care: one feature of this template is that it links to the appropriate language section; for example, {{t|arc|foo}} will link to ]. It can do this by mapping from the ISO code to the language-name, but apparently it's inefficient to do that in general; so, it does it for a small number of commonly-used languages, but for other languages, Tbot adds xs=Aramaic to short-circuit that logic. To be honest, if anyone besides Robert Ullmann had set that up, I would suspect that they were raging morons with no clue what they were doing, but Robert is extremely knowledgeable about this stuff. He says to leave it alone, ignore it, pretend it doesn't exist, and let Tbot handle it; so leave it alone, ignore it, pretend it doesn't exist we do.) —Ruakh_TALK 22:17, 15 May 2010 (UTC)Reply

I'm a little surprised that when either {{{1}}} or {{{2}}} is not specified (or not a valid page name, for 2) that it doesn't categorize in a cleanup category, such as Category:Entries with translation table format problems. It would allow entries with problems to be found more easily. Mglovesfun (talk) 15:06, 21 September 2010 (UTC)Reply

I often see translations formated like this:

• Finnish: first1 first2, second

is this just a old format for translations or an alternative format? is it ok to convert it to:

• Finnish: first1 first2, second

Tdomhan 10:53, 19 December 2010 (UTC)Reply

If first1 first2 is includable per WT:CFI, then yes, you can convert. The first format is intended for SoP translations. For one word translations you should always use the second format. --Vahag 11:06, 19 December 2010 (UTC)Reply

nb should refer users to no.wikt rather than nb.wikt, as the latter does not exist. The no.wikt is the only wiktionary on which Norwegian Bokmål is a wiki language. Njardarlogar 16:15, 16 March 2011 (UTC)Reply

This template includes an extra span before the ^(langcode) interwiki link, with a CSS class tlc, so that users can customize the display of translations by adding code to their personal CSS that overrides the site CSS that renders it invisible, making the translations display as translation^{language code}, rather then translation^{(language code)}. Unfortunately, the mobile site does not include the normal site CSS, so all translations are showing up like Wort de(de). There is no way to edit the mobile site's CSS, so the only way to fix this that I can see is to remove the extra span. The display of the mobile site should take priority over the option to customize the display, I think. --Yair rand 21:43, 11 September 2011 (UTC)Reply

I agree wholeheartedly. We should never have duplicate content with one hidden by CSS at all times (and this is one of the reasons). I suggest we get rid of either and drop the class from the other (so people hiding it will be able to see it, since the other will be gone). Which to get rid of? I guess the obvious choice is the one that's been invisible by default hitherto, which IINM is the 'tlc' one.​—msh210℠ (talk) 21:49, 11 September 2011 (UTC)Reply

Agreed. Someone can easily write JS to add the parens. --Bequw → τ 01:29, 12 September 2011 (UTC)Reply

Fine. Done, and to template:t+ and t-. The parens are default, and (I strongly suspect) removable by JS, which I haven't written. (If they weren't there, they'd be addable using just CSS. But the default view hitherto was with parens, so I kept 'em.)​—msh210℠ (talk) 06:27, 12 September 2011 (UTC)Reply

If we used <span class="tlcp">(</span>{{{1}}}<span class="tlcp">)</span>, then anyone's current parenthesis-hiding CSS would continue to work. Or we could use a new class, so it's still CSS-customizable, but without causing weirdness for anyone who currently has span.tlcp { text-decoration: underline; } or whatnot. (Before making any such change, though, we might as well wait to see if anyone complains. I suspect that we support a lot of customization that's not actually used by anyone.) —Ruakh_TALK 23:24, 12 September 2011 (UTC)Reply

Shouldn't {{t+}} call {{documentation}}? --129.125.102.126 18:40, 16 August 2012 (UTC)Reply

No, because it doesn't have documentation. We could, of course, fake it. --Μετάknowledge^{discuss/deeds} 18:44, 16 August 2012 (UTC)Reply

Well, it does, in that Template:t+/doc redirects to Template:t/doc. (And even if it didn't, we could write {{documentation|t/doc}}.) —Ruakh_TALK 18:50, 16 August 2012 (UTC)Reply

Could one of you add "{{documentation}}" to {{t+}}? Or, alternatively, remove it from {{t-}}? --129.125.102.126 15:52, 18 August 2012 (UTC)Reply

Done. Mglovesfun (talk) 16:03, 27 August 2012 (UTC)Reply

Thank you. --129.125.102.126 01:46, 13 September 2012 (UTC)Reply

Do we still want to keep the xs function? My understanding is it replaces the automatic wikilink to a language section with an identical wikilink, for whatever reason. Robert Ullmann's taken that with him to his grave. So, can we remove it? Mglovesfun (talk) 16:03, 27 August 2012 (UTC)Reply

Firstly — there is no xs functionality. Liliana-60 unilaterally removed it back in January.

Secondly — Robert didn't take the reason to his grave; I'm not sure what gave you that idea. He always explained that it was more efficient to use xs, when present, than to retrieve the language-code template.

—Ruakh_TALK 17:22, 27 August 2012 (UTC)Reply

• I'm thinking we might want to bring this back. Some pages are calling hundreds of language templates, which could be avoided. Anyone know if pages like water would be helped significantly if they used something like xs= instead of calling language templates? --Yair rand (talk) 11:56, 18 November 2012 (UTC)Reply

Instead of adding this to the main template, I'd prefer it if it were added to the purposely-simplified alternative {{t-simple}}. Actually... that template already has it, so never mind. —CodeCat 12:53, 18 November 2012 (UTC)Reply

Hm? No, it doesn't. {{t-simple}}'s entire code is ]. No xs=. --Yair rand (talk) 13:02, 18 November 2012 (UTC)Reply

Oh, I missed that. Well, you could change it to ] right? Or maybe even ]? —CodeCat 13:09, 18 November 2012 (UTC)Reply

The first one, I think. No reason not to leave a backup option, is there? --Yair rand (talk) 13:23, 18 November 2012 (UTC)Reply

No, but if speed is an issue, the second one is faster than both the first and the current setup. —CodeCat 13:26, 18 November 2012 (UTC)Reply

Is it? I didn't know that adding "alternate wikitext" for parameters made any difference at all. --Yair rand (talk) 13:28, 18 November 2012 (UTC)Reply

Well, I don't think it would surprise you that {{{xs}}} is faster than {{{{{1}}}}} because the latter transcludes a template...? —CodeCat 13:30, 18 November 2012 (UTC)Reply

Yes, but if the xs parameter is supplied, then it wouldn't make a difference whether there's a fallback or not, would it? It would be only be slower when the fallback is actually necessary to function. --Yair rand (talk) 13:33, 18 November 2012 (UTC)Reply

I'm not sure. I imagine that the parser has to evaluate the text before it can process it, so code that is syntactically more complex will be slower no matter what. —CodeCat 13:35, 18 November 2012 (UTC)Reply

Re: "if the xs parameter is supplied, then it wouldn't make a difference whether there's a fallback or not, would it?": I'm not so sure. I had always assumed as you did, but mw:Extension:Scribunto/Parser interface design#Parent frame access states that, "In wikitext, every triple brace and every pipe has a substantial cost." And I seem to recall reading elsewhere (also in the context of motivations for Scribunto) that templates like {{Cite book}} are actually among the more expensive templates on the English Wikipedia, just because of the huge numbers of parameters and fallbacks, even though they don't actually have much in the way of parser-functions. —Ruakh_TALK 17:01, 18 November 2012 (UTC)Reply

We used this before. It caused us huge headaches when we renamed Swazi to Swati and Low Saxon to Low German, because thousands of translations now linked to a wrong (non-existing) language. -- Liliana • 18:50, 3 December 2012 (UTC)Reply

A bot can update all instances of xs=Oldname to xs=Newname whenever we rename a language, can't it? That actually seems simpler than catching all the right, and only the right, other instances of Oldname. - -sche (discuss) 19:07, 3 December 2012 (UTC)Reply

But how are you going to find out where the old name is used? Given that xs= eliminates all uses of the language code, you can't use Whatlinkshere or anything. -- Liliana • 19:19, 3 December 2012 (UTC)Reply

Use AWB or a dedicated script to search the latest database dump for all instances of xs=Oldname. Make a second search when a new database dump comes out to catch the (presumably few) entries that may have been added in the time between the previous database dump's release and the decision to rename the language. - -sche (discuss) 19:25, 3 December 2012 (UTC)Reply

Just as "nb" refers users to no.wiktionary, nds-de and nds-nl should link to nds.wiktionary, because it is the only wiktionary that exists, and it uses the unified code to cover two lects which are treated as separate here. - -sche (discuss) 22:41, 18 December 2012 (UTC)Reply

The links to foreign-language Wiktionaries don't make clear what the link is for. Most readers will not know about ISO codes, or what the code followed by a colon means on Wiktionary. Perhaps we should add a title to the links? Something like "see this word's entry on the (language) Wiktionary"? --Yair rand (talk) 17:40, 18 February 2013 (UTC)Reply

That would be helpful, if users think to hover the mouse over the link... —CodeCat 17:44, 18 February 2013 (UTC)Reply

People don't usually think to use titletext... hence the problem with {{zh-n.}}. But still support, every little bit helps. —Μετάknowledge^{discuss/deeds} 17:51, 18 February 2013 (UTC)Reply

Can a call to translit modules be added, so that when tr is missing or blank the automatic transliteration would work? It would work for selected languages only but the list could grow and modules improved. List of Category:Transliteration modules - a few would not be useful, like Arabic or Persian. All Slavic languages, Armenian, Georgian, Greek would definitely work.

This is what I mean: for example in surveillance#Translations, see Georgian translations without transliteration (no tr)

Instead of ზედამხედველობა (zedamxedveloba), მეთვალყურეობა (metvalq̇ureoba), დაკვირვება (daḳvirveba)

We could get: ზედამხედველობა (zedamxedveloba), მეთვალყურეობა (metvalq̇ureoba), დაკვირვება (daḳvirveba)

Is that feasible? --Anatoli ^{(обсудить}/^вклад) 05:22, 16 April 2013 (UTC)Reply

Why would automatic Arabic and Persian transliteration not be useful? --Yair rand (talk) 10:47, 16 April 2013 (UTC)Reply

Missed the question, sorry. The automatic Arabic and Persian transliteration will not be perfect and as you just said on Ruakh's talk page, this applies to Hebrew.

Arabic, Persian, Urdu and Hebrew usually don't write short vowels. It's even more applicable to Persian - vowel points are extremely rare.

I'm not familiar with Hebrew but there are ambiguities, as I can see, even with fully vocalised words. Arabic can be difficult as well, since the module is not smart enough to understand when ة (tāʾ marbūṭa) is part of a genitive construct (ʾiḍāfa) and "t" should be pronounced, not silent, like before a pause. The initial alif is seldom vocalised, especially if it's elidable, a part of the definite article, "al-" ال is assumed but it changes dependent on the preceding word's grammar case to "ul-" or "il-", can be silent ('l) or the alif may not be part of an article but still no vowel points. Alif with a hamza on top (أ) can be either "a" or "u". Vowels are seldom used.

That said, if difficult (only partially phonetic languages) are automatically transliterated, users should be told about the limitations. --Anatoli ^{(обсудить}/^вклад) 00:22, 18 April 2013 (UTC)Reply

By the way, are you not confusing transliteration and transcription here? Dakdada (talk) 08:12, 18 April 2013 (UTC)Reply

That's immaterial. We commonly use "transliteration" etc to mean "standardised romanisation". —Μετάknowledge^{discuss/deeds} 21:07, 18 April 2013 (UTC)Reply

I saw the sarcastic question but thought I won't answer this first. Some people seem to be obsessed with the notion that transliteration is always just letter-to-letter conversion from one script to other. It may work for some scripts and languages but won't work for other or may not be useful. In my opinion, there should be a combination of both to make the transliteration consistent but also practical and useful.

Transliterating letter-to-letter languages like Arabic, Persian, Hebrew and Urdu will be hardly useful. Google Translate abandoned the practice because it only confuses users. With Persian, vowel marks are not even used, if they are it's extremely rare.

We use word stresses, which have nothing to do with the transliteration. If a letter has more than one reading, we put what is right in this case.

Languages have unpredictable exceptions when both the knowledge of the script and phonetic rules may not help or even mislead, e.g. Bulgarians know the Russian alphabet, they don't need to be told what each letter means (except for letters ъ and е, which have different pronunciation and rules and the missing letter ё) but they won't know how to read конечно where letter "ч" is not pronounced as expected or even Ukrainians often pronounce "г" incorrectly (the Ukrainian way /ɦ/) in words where "г" is not /g/ but /v/, e.g. "сегодня".

When English is transliterated into other scripts, it's usually done phonetically (approximately, adjusting to the native language), not letter-by-letter.

Modules can't handle all exceptions, that's why we need humans to override the automatic transliteration where necessary. --Anatoli ^{(обсудить}/^вклад) 00:05, 19 April 2013 (UTC)Reply

Very true that many non-alphabetic languages are usually romanized via a transcription. But Anatoli won’t usually acknowledge the difference between transliteration of Russian text, and transcription of spoken Russian. —Michael Z. 2013-04-19 02:08 z

Which language is non-alphabetic - Arabic, Hebrew, Japanese hiragana? Letter-to-letter transliteration without stress marks and ignoring exceptions (per some strict standards) may be useful for some purposes (e.g. to write names in a passport) but dictionaries and textbooks provide the transliteration, which is useful and practical. I'm not going to start another debate with you, Michael, perhaps you should start picking on other language conventions and editors of that language where deviations from what is written and what is pronounced is more different than in Russian. Perhaps you would still have the same opinion as you do now if you actually had to work with foreign languages on a daily basis for a long time but you would have, at least understanding why it is done the way it's done and would offer alternatives, rather than just criticising and pointing some standards nobody uses in the real life. What is the point in transliterating the word "English" into Ukrainian as "Енґлісх" or "Енґліш", what's the use of this? "Інґліш" would, at least be some indication on pronunciation. You're taking the concept "transliteration" too literally. --Anatoli ^{(обсудить}/^вклад) 02:26, 19 April 2013 (UTC)Reply

Transliteration has a clear and unambiguous meaning, does it not? You seem to be talking about transcription, not transliteration, hence my question above. Dakdada (talk) 12:02, 19 April 2013 (UTC)Reply

Just to be clear: I don't want to stir troubles, I just want to make sure that we are talking about the same things. If Wiktionary uses the word "transliteration" to mean "transcription", it should be made clear. Dakdada (talk) 12:04, 19 April 2013 (UTC)Reply

The transcription as in modules: Category:Transliteration modules, those, which are tested and approved for use, that is. --Anatoli ^{(обсудить}/^вклад) 12:07, 19 April 2013 (UTC)Reply

That is not supposed to be transcription. Since it was started a decade ago, Wiktionary:Transliteration and romanization has said “transliteration and romanization are not pronunciation. They relate to the written languages, not to the spoken languages.” —Michael Z. 2013-04-21 23:48 z

That page is maintained by you, no surprise it doesn't contains practical and useful transliteration examples but arguments you used in criticising WT:RU TR, like Russian case ending "-ого". I have already given you examples of transliterating "English" into Ukrainian as "Енґлісх" vs "І́нґліш" and into Russian as "Энглисх" vs "И́нглиш", since you just haven't been paying attention to the fact that Russian is just not "the worst case of violating this letter-for-letter" transliteration. The former examples ("Енґлісх" and "Энглисх") are correct if "lettering across" method is used but absolutely useless. The latter examples ("І́нґліш" and "И́нглиш") are practical, may be used in dictionaries. This discussion is irrelevant to transliteration modules, anyway, which provide the default values for each letter, displays accents and with Russian it's close enough in majority of cases, especially when handling of "ё" after letters ж, ш, щ, ч was added. --Anatoli ^{(обсудить}/^вклад) 00:19, 22 April 2013 (UTC)Reply

None of that is relevant to the definition of transliteration Wiktionary has held from before I even saw this website. Also, your “Енґлісх” etc. has no bearing on romanization at all. —Michael Z. 2013-04-22 00:48 z

Of course it has no bearing on romanization. It's the transliteration, since pronunciation doesn't matter when transliterating for you, it's the result of what you're advocating. Or is English also non-alphabetic, like Arabic or Hindi and can't be transliterated? --Anatoli ^{(обсудить}/^вклад) 01:19, 22 April 2013 (UTC)Reply

I am advocating using standard transliteration or romanization systems, or at least something using the same principles, for our transliteration and romanization of non-Latin scripts, for the benefit of readers of the English-language Wiktionary. That is a clear and sensible goal, and your examples have nothing to do with it. —Michael Z. 2013-04-23 18:46 z

You haven't answered why it's wrong or ugly to use "Енґлісх" for "English" but OK to write "segodnja" and "čto" for "сегодня" (sevódnja) and "что" (što)? Is it because Russian has less exceptions and they can be ignored? I have to use exaggerated examples by means of Ukrainian, since you ignore or don't understand examples from other languages.

transliteration and romanization is maintained by you, the transliteration section specifically targets Russian and supports your individual point of view, ignoring other languages: konnichi wa is a transliteration of こんにちは (letter-to-letter: "konnichiha"). There is no benefit to readers in letter-to-letter transliteration. The ISO standards are designed for correctly transliterating place names or surnames. --Anatoli ^{(обсудить}/^вклад) 22:35, 23 April 2013 (UTC)Reply

Transliteration, is, by definition, letter-to-letter: it's only supposed to represent characters in another script. For users, however, such direct transliteration is not very useful since it can't be read, so we should only use transcriptions from one language to another. However these are language-specific: transcriptions from Russian to English is different from transcriptions from Russian to French. Dakdada (talk) 13:59, 24 April 2013 (UTC)Reply

Anatoli, go ahead and add a better example to the page.

Your arguments are getting abstract. I have never suggested that Japanese should be romanized in the same way as Russian. As I’ve mentioned before, languages should be romanized according to standard methods, and for logographic languages that is usually by a transcription method.

The “individual point of view” at WT:TRANSLIT is supported by the specific publications and practices of the ISO, and also the Unicode consortium, the US Library of Congress, the British Standards Institution, the British Library, the Commonwealth of Independent States, the United Nations, and dictionaries and linguists worldwide. The transcription method at WT:RU TR is novel and unique in principle and detail. —Michael Z. 2013-04-24 16:21 z

@Dakdada. Re: Transliteration, is, by definition, letter-to-letter. Everybody knows this definition. The devil is in the details. Transliterating English or French into other scripts shows how absurd and useless this method can be, if followed literally. Thanks for confirming that direct transliteration is not very useful in many cases.

@Mzajac. My arguments are very concrete and address specific situations, not general rules about what letter represents what in another language. I see no difference in transliterating Russian or Japanese exceptions according to phonetic rules. FYI, the Japanese hiragana is a phonetic script, not logographic. Still, Japanese editors adopted the rule: The letter は, when used as a particle and pronounced "wah", should be transliterated as "wa" instead of "ha". (see Wiktionary:About Japanese/Transliteration). There are other exceptions and conventions.

The transcription method at WT:RU TR may be novel and unique, if you like, but that's common in a practical environment, where a purpose is to teach a language - such as dictionaries or textbooks. The method is not confronting the ISO standards, which have other applications. The surname Бендер, a famous con man character in Ilf and Petrov books would be transliterated as "Bɛ́ndɛr" for practical purposes, just once, to show that both /b/ and /d/re not palatalised and the stress is on the first syllable but by ISO standards it's "Bender", which is in no conflict.

In WT:EL TR Greek letters "μπ" (mp) and "ντ" (nt) are transliterated as "b" and "d" at the beginning of a word. Among other rules, this is an exception. I wonder what reaction you would get if you try to impose letter-to-letter transliteration to Japanese, Greek and other editors. --Anatoli ^{(обсудить}/^вклад) 01:33, 30 April 2013 (UTC)Reply

This template contains the following code: {{#ifeq:{{{1|}}}|{{#language:{{#switch:{{{1|}}}|nan=zh-min-nan|yue=zh-yue|cmn=zh|nb=no|rup=roa-rup|kmr=ku|nds-de|nds-nl|pdt=nds|{{{1|}}}}}}}|| ... }}. The three sister templates {{t+}}, {{t-}} and {{tø}} do not have this code. What is it for and why is it in this template but not the others? Can it be removed, or should it also be added to those other three? —CodeCat 18:53, 26 April 2013 (UTC)Reply

I think the language code listed are those that should use {{tø}}, not {{t}}, {{t+}} or {{t-}} but I don't quite understand it. --Anatoli ^{(обсудить}/^вклад) 01:37, 30 April 2013 (UTC)Reply

When you ask what it's for, I take it you want to know what it does? What it does is, it checks to see if the language-code is a recognized MW/WMF interlanguage-link prefix (such as fr for fr.wikt), or a language-code that we manually map to a specific project (such as kmr "Northern Kurdish", which we map to the Kurdish Wiktionary, ku.wikt); if so, it includes a superscript link to the appropriately-named page on that project, and if not, then it suppresses the link (rather than linking to a bizarrely-named page on this project: for example, we don't want {{t|hbo|foo}} to try to link to ], because the software will think it's actually an en.wikt page named hbo:foo rather than an hbo.wikt page named foo).

The way it works is, {{#language:...}} is a parser-function to generate the native language name for a specified project prefix — for example, {{#language:fr}} produces français — except that if it doesn't recognize the prefix, then it just returns it verbatim. So this code detects if the prefix exists by checking if {{#language:...}} just returns ....

I assume it's not in the sister templates because — in theory — {{tø}} is only used when we already know the project doesn't exist, and {{t+}} and {{t-}} are only used when already know that it does. Only {{t}}, as the "default" template, has to automatically handle both cases.

—Ruakh_TALK 06:28, 2 May 2013 (UTC)Reply

Ok, that makes sense. Thank you. —CodeCat 12:39, 2 May 2013 (UTC)Reply

How do I add translations into Russian (ru) or other language where "tr" is blank (i.e "tr=" or missing) to Category:Russian terms lacking transliteration (or other category)? --Anatoli ^{(обсудить}/^вклад) 09:47, 5 May 2013 (UTC)Reply

{{#ifeq:ru|{{{1}}}|{{#if:{{{tr|}}}||]}}}}. --Yair rand (talk) 18:56, 5 May 2013 (UTC)Reply

To make it more easily scalable and extendable, this is probably preferred: {{#switch:{{{1}}}|ru={{#if:{{{tr|}}}||]}}}} . —CodeCat 19:03, 5 May 2013 (UTC)Reply

Thanks you, both. @CodeCat, by extendable, do you mean adding other languages?

<!--

Lacking transliterations
-->{{#switch:{{{1}}}|ar={{#if:{{{tr|}}}||]}}}}<!--
-->{{#switch:{{{1}}}|ru={{#if:{{{tr|}}}||]}}}}<!--
-->etc., etc.<!--

So if I want to add another language, would the above be correct?

I've just created the category Category:Russian translations lacking transliteration. Please check if all linking categories are correct. --Anatoli ^{(обсудить}/^вклад) 00:23, 6 May 2013 (UTC)Reply

No, you would just replace |ru= by |ar|ru=. That is what I meant by it... it's much easier to add new languages this way. —CodeCat 00:30, 6 May 2013 (UTC)Reply

Thanks but what about adding to language-specific categories? How would they be added. Sorry, I need a full and working example, I can't follow the template code well.

Also, Category:Russian translations lacking transliteration is still empty (I've added the code to the template), although I'm sure there are many translations into Russian without transliteration, e.g. cuss#Translations. --Anatoli ^{(обсудить}/^вклад) 00:42, 6 May 2013 (UTC)Reply

Something like {{#switch:{{{1}}}|ar|ru={{#if:{{{tr|}}}||]}}}} ? There might be an even better way, which looks at the script code and then decides based on that whether the translation needs a transliteration or not. However, not all languages that are written in a foreign script need transliterations. Serbo-Croatian is a good example - it's always paired with a Latin script translation so a transliteration is not needed.

And it takes a while for categories to fill. It depends on how many updates are queued, which depends on how widely a template is used (more pages to update). This template is used very widely so it may take a very long time, a day or more, for it to fill up the category completely. —CodeCat 00:46, 6 May 2013 (UTC)Reply

Okey, thank you! I've added {{#switch:{{{1}}}|ar|be|bg|cmn|mk|ja|ru|uk={{#if:{{{tr|}}}||]}}}} for categories I have already created (Category:Translations_which_need_romanization). If it works, I will make more categories and add more languages (listing codes for shortness) - he, hi, el, fa, ka, hy, th, km, ko lo, my, bn, tg, mn, kk, ky, te, si, yi, ab, os, ba - just listing those I know we have people who could potentially help to provide transliterations or are not to hard (we have transliterations pages). --Anatoli ^{(обсудить}/^вклад) 01:36, 6 May 2013 (UTC)Reply

It's working, thank you. See also discussion at Wiktionary:Beer_parlour/2013/May#Translations_lacking_transliteration_categories --Anatoli ^{(обсудить}/^вклад) 00:12, 9 May 2013 (UTC)Reply

How do I add autotranslit for a language using modules? E.g. I'd like to test on Russian translations again.

If tr is blank or missing, then I'd like to call Module:ru-translit's "tr" function. The value of alt should be used if it exists, if not, then {{{2}}} (the 2nd parameter)

So, if only the 2nd parameter exists (the translation), no alt is provided, then invoke: {{#invoke:ru-translit|tr|болторез}} (boltorez)

• Russian: болторез m (boltorez) - {{{2}}} = болторез, no alt

If alt exists:

• Russian: болторе́з m (boltoréz), then invoke: {{#invoke:ru-translit|tr|болторе́з}} (boltoréz) - alt = болторе́з

Any of these Category:Russian_translations_lacking_transliteration can be used for testing, e.g. bolt cutter (BTW, the category is not getting populated fast enough, I'd expect many more translations without transliterations, it seems to add to the category only when somebody edits a page). --Anatoli ^{(обсудить}/^вклад) 00:18, 10 May 2013 (UTC)Reply

Something like this?

-->{{#switch:{{{1}}}|ru=&nbsp;({{{tr|{{#invoke:ru-translit|tr|{{{alt|{{{2}}}}}}}})|#default={{#if:{{{tr|}}}|&nbsp;(<span lang="">{{{tr}}}</span>)}}}}<!--

—CodeCat 01:33, 10 May 2013 (UTC)Reply

Thank you. I don't understand it very much though. How do I add other languages? "Transliterateble" languages with good translit. modules are currently - ba, bg, be, hy, el, ka, kk, ky, mn, os, ru, tg, uk. (Wyang also said bo is OK but only for six syllables?) Could you add them please, so I don't break anything? The modules names are the same as in Module:ru-translit, where "ru" is the language code.

I've just tried adding but didn't see any change in familiarity#Translations (2nd gloss). Did I do it right? --Anatoli ^{(обсудить}/^вклад) 13:20, 10 May 2013 (UTC)Reply

There isn't really an easy way to add new languages, unless we assume that all languages have a module with the same name and the same function needs to be invoked. In that case, it would become (this assumes that all transliterations are done using the "tr" function in the xx-translit module):

-->{{#switch:{{{1}}}|bg|be|el|ru|uk=&nbsp;({{{tr|{{#invoke:{{{1}}}-translit|tr|{{{alt|{{{2}}}}}}}})|#default={{#if:{{{tr|}}}|&nbsp;(<span lang="">{{{tr}}}</span>)}}}}<!--

And so on. To be honest, I think this is kind of the point where we should start to convert the template to Lua. Templates are notoriously bad at distinguishing several different cases that all end up having more or less the same outcome. I also think it's a bad idea to code the list of auto-transliterable languages into this template, because there are also {{t+}}, {{t-}} and such that would also need such a list, which of course leads to duplication. A much better place to put such information is Module:languages, but you need Lua to use that. —CodeCat 13:28, 10 May 2013 (UTC)Reply

Thank you. I don't know when this template is going to be converted. Can I just do:

-->{{#switch:{{{1}}}|ru=&nbsp;({{{tr|{{#invoke:be-translit|tr|{{{alt|{{{2}}}}}}}})|#default={{#if:{{{tr|}}}|&nbsp;(<span lang="">{{{tr}}}</span>)}}}}<!--
-->{{#switch:{{{1}}}|ru=&nbsp;({{{tr|{{#invoke:ru-translit|tr|{{{alt|{{{2}}}}}}}})|#default={{#if:{{{tr|}}}|&nbsp;(<span lang="">{{{tr}}}</span>)}}}}<!-- 

Not all languages may have the same module and function name. Will it take time to load translits as well? --Anatoli ^{(обсудить}/^вклад) 14:02, 10 May 2013 (UTC)Reply

Yes, the transliteration module will need to be loaded for every translation. That may cause a prohibitive slowdown. —CodeCat 15:47, 10 May 2013 (UTC)Reply

Something is wrong. Please see familiarity#Translations (2nd gloss). --Anatoli ^{(обсудить}/^вклад) 14:03, 10 May 2013 (UTC)Reply

Thank you, Angr. There's a problem, though. The autotranslit is added even if there is a transliteration, e.g. amber#Translations. --Anatoli ^{(обсудить}/^вклад) 07:17, 11 May 2013 (UTC)Reply

Never mind, I've fixed it. --Anatoli ^{(обсудить}/^вклад) 07:37, 11 May 2013 (UTC)Reply

I was hoping automatic transliteration will be forced even if the tr= parameter is provided. Many Armenian and Georgian translations use the old transliteration system and I don't want to change them by hand. How do we make autotranslit ovverride tr=? --Vahag (talk) 20:46, 15 May 2013 (UTC)Reply

Logically, it's easy - just call the module if language is "hy" or "ka" (I wouldn't do this for Slavic Cyrillic languages because of word stress (when ́ is not provided in alt=) and exceptions). (It needs some testing, though, I get easily lost with the template syntax). Rather than overriding the manual transliteration, perhaps the old transliteration could be replaced with a one-off job? The tr= parameter can be used for offline dictionary creation and other things. Also, when adding a new translation, the automatic transliteration could be written, rather than displaying - using User:Conrad.Irwin/editor.js? User:Rukhabot could be changed to add missing transliterations (the tr= parameter is NOT provided) for a few languages. --Anatoli ^{(обсудить}/^вклад) 22:21, 15 May 2013 (UTC)Reply

Puzzling. --Jerome Potts (talk) 21:53, 10 September 2013 (UTC)Reply

Uh never mind, it just fixed itself. --Jerome Potts (talk) 22:00, 10 September 2013 (UTC)Reply

It's actually incorrect, though. Dutch doesn't have a neuter plural gender. I was fixing those but then someone prevented me from doing it so the script errors built up. —CodeCat 22:53, 10 September 2013 (UTC)Reply

But Dutch does have neuter nouns, and those nouns do occur in the plural. goederen, for example, is the plural of the neuter noun goed. If you feel that these plural forms should be given simply as plural, rather than as neuter plural, there are plenty of appropriate ways to express that belief. Mass-breaking pages and running an undiscussed bot to "fix" them so they accord with your belief? Not an appropriate way. —Ruakh_TALK 23:28, 10 September 2013 (UTC)Reply

It's not a matter of belief, Dutch nouns really don't distinguish genders in the plural. That's just fact. If a noun has no singular there is literally no method that can determine its gender. The same applies to German as well: all three genders have the same articles, the same noun and adjective inflections, and so on. Any grammar recognises this, so any lack of consensus is a result of lack of being informed, nothing more. —CodeCat 23:36, 10 September 2013 (UTC)Reply

When a neuter noun's plural is given as a translation, it is a matter of belief whether we should indicate the gender of the underlying singular noun. (For the record, I agree with your belief; but it doesn't justify your vandalism.) —Ruakh_TALK 00:19, 11 September 2013 (UTC)Reply

So why don't we start giving English nouns genders then? They have "underlying" genders too after all! —CodeCat 00:26, 11 September 2013 (UTC)Reply

What are you talking about? Did you even read my comment? —Ruakh_TALK 00:29, 11 September 2013 (UTC)Reply

(Incidentally, this is totally off-topic, but the Cambridge Grammar of the English Language argues that Modern English nouns do have gender. For example, it asserts that although there are certain animals to which either the noun "mother" or the pronoun "it" could be applied, the use of one precludes the use of the other, making e.g. *"The raccoon mother looks after its young" ungrammatical. CGEL concludes from this that "mother" is a grammatically feminine noun. But obviously that's nothing compared to the rich gender inflection of most European and many non-European languages, and personally I have no desire to see us start indicating it in entries.) —Ruakh_TALK 00:51, 11 September 2013 (UTC)Reply

English has no genders in the usual understanding because there is no inherent congruence between nouns and modifiers outside biological gender (which is semantic). In the same way, Dutch or German plural nouns have no congruence, only singular nouns do. So to give a Dutch plural a gender is like giving an English noun a gender. There is nothing about it that indicates its gender, only its relationship with the singular form. But that doesn't give the plural a gender. You could compare it to the personal pronouns, and say that they really has three different genders, or even that it's both dual and plural. But that would be silly. A more sensible analysis IMO is that the grammatical category of plural is degenerate for gender and thus does not distinguish it, and it's grammatically irrelevant. —CodeCat 01:03, 11 September 2013 (UTC)Reply

So you were rigging a subtemplate to enforce a rule that has not yet been agreed to?

I wonder whether it is the job of the template to do that. Note that for example, it seems to me that this template still offers the possibility of entering a gender even when translating a verb, an oddity with which we seem to be living quite well. --Jerome Potts (talk) 03:36, 11 September 2013 (UTC)Reply

@CodeCat: I'm really not sure what you think this discussion is about. You can't simply be arguing that we shouldn't indicate gender of Dutch nouns when we list their plural forms in translation-tables, because I already stated that I agree with that. Logically, I guess you should be arguing that this justifies vandalizing the project; but if so, your argument is missing way too many steps, and it's impossible to take it seriously. —Ruakh_TALK 03:41, 11 September 2013 (UTC)Reply

The following information passed a request for deletion.

This discussion is no longer live and is left here as an archive. Please do not modify this conversation, but feel free to discuss its conclusions.

---

No longer updated now that Tbot is dead and will never return. This was a terrible idea from the beginning. -- Liliana • 13:56, 5 May 2012 (UTC)Reply

I agree, delete. —CodeCat 15:33, 5 May 2012 (UTC)Reply

For those of us who never understood how the translation system is automated, could someone explain why we're dumping these templates? --Μετάknowledge^{discuss/deeds} 17:31, 5 May 2012 (UTC)Reply

There used to be a bot, User:Tbot, that went through every Wiktionary page, checked whether the translations exist at the respective foreign-language edition of Wiktionary, and updated the templates accordingly with {{t+}} (page exists) or {{t-}} (page doesn't exist). The only thing this changed is the color of the link. Yes, this is one of the most inefficient methods ever invented by mankind. Anyway, now the bot is gone, and the link colors haven't been updated since 2009, so we might as well ditch 'em and replace them with the generic link color.

Here's an example:
Kind (de)
Kind
Kind -- Liliana • 18:30, 5 May 2012 (UTC)Reply

Ahhh, I see. Definitely delete these misleading fragments of annoyance. I have been confused by it before, but I didn't realize that this was the reason. --Μετάknowledge^{discuss/deeds} 18:47, 5 May 2012 (UTC)Reply

Actually yeah delete. Mglovesfun (talk) 09:01, 6 May 2012 (UTC)Reply

I would fail these per unanimous decision were these templates not so widely used. Redirects to {{t}} seem to be the way to go; delinking them by bot would be a low priority, but also very simple. As of tomorrow these will have been nominated for two weeks. Does anyone at all want to keep them? Mglovesfun (talk) 00:34, 18 May 2012 (UTC)Reply

Keep, if we can get a replacement for Tbot working. For the time being, it would probably be preferable to redirect, since many uses of these may be inaccurate at the moment. Broken links should be clearly marked as such, if possible. --Yair rand (talk) 00:41, 18 May 2012 (UTC)Reply

Even if we can find another bot to do this task I'd still prefer not to have it, it's too clumsy and for too little benefit. —CodeCat 00:44, 18 May 2012 (UTC)Reply

Rather keep and ask and encourage the programming wizards (i.e., those people who resolve the issues raised at WT:GP) to prepare a new Tbot. I consider the death of Tbot (talk • contribs) a loss (less than the death of its programmer, of course). On topic, I find the colour scheme for translation links with {{t+}} and {{t-}} more consistent with the general appearance of Wiktionary; the colours also convey useful information on whether it makes sense to click to see a monolingual definition of the term in question. -- Gauss (talk) 00:57, 18 May 2012 (UTC)Reply

I agree with Yair.​—msh210℠ (talk) 20:59, 18 May 2012 (UTC)Reply

Kept for lack of consensus. --ElisaVan (talk) 16:12, 1 October 2013 (UTC)Reply

According to the RfD discussion above, it was decided to keep Template:t-. Nonetheless, it was deleted a couple of months ago, and now when we look at an old revision of an entry (as in here), instead of translations, what we see is a lot of "Template:t-" red links. For this reason I'm recreating it as a redirect to template:t. --Capmo (talk) 15:06, 7 December 2014 (UTC)Reply

is not required currently. It works perfectly. Leaving it adds "Category:LANGUAGE term requests". --Dixtosa (talk) 16:53, 15 June 2015 (UTC)Reply

Is that supposed to be a question, or are you just adding informal documentation? --WikiTiki89 17:01, 15 June 2015 (UTC)Reply

We probably need |lit= in {{t}} as well. --Z 20:59, 16 July 2015 (UTC)Reply

The template doesn't have a gloss parameter by design and per WT:TRANS, so why should it have this? —CodeCat 21:50, 16 July 2015 (UTC)Reply

|gloss= is a different issue as anything that would be passed to |gloss in a translation template is pure duplication. --Z 22:13, 16 July 2015 (UTC)Reply

Even so, WT:TRANS says there shouldn't be any literal translations either. —CodeCat 22:23, 16 July 2015 (UTC)Reply

There are in fact a lot of glosses in the translation tables, especially for sayings, where people unknowledgeable of a language might still want to know what the translated saying literally means. Another legitimate use for glosses in translations is when a translation has a slightly different meaning than the corresponding English word. Matthias Buchmeier (talk) 01:24, 17 July 2015 (UTC)Reply

I tried to enter a translation in the Bosnian language, but it didn't work. Why is the Bosnian language with the code bs not supported by this template?--Sae1962 (talk) 07:58, 16 December 2016 (UTC)Reply

Wiktionary has long unified Serbo-Croatian. If a word is only used in Bosnia, you can mark it so.--Anatoli T. ^{(обсудить}/^вклад) 08:16, 16 December 2016 (UTC)Reply

Please add the |id= parameter, so that terms can be linked to the correct meaning when there is more than one in the language. This would be useful, for instance, in the link to Catalan au in the translations section of bird, since the first listed meaning is “now!”. — Eru·tuon 06:00, 18 January 2017 (UTC)Reply

I figured out how to do it myself. — Eru·tuon 05:48, 20 January 2017 (UTC)Reply

Is there a way to get all the translations to a target language? For instance, cinnamon roll shows the translation into Navajo bááh łikaní náhineestsʼeeʼígíí (which page has not been created yet). Is there a special page or category where one could see all the Navajo words that have been proposed as translation of English words? Thx. Julien Daux (talk) 21:26, 27 February 2017 (UTC)Reply

No, you would need to analyze the XML dump or have someone do it for you. DTLHS (talk) 21:38, 27 February 2017 (UTC)Reply

OK, I'll do it myself. It's a pity because it'll so easy to implement directly in the template. It even has 3 special cases for target languages English, Multilingual, and Undefined. We would just have to make a automatic category for each of the target languages, not only those 3.... :/ Julien Daux (talk) 00:47, 28 February 2017 (UTC)Reply

Yes, that's possible but we really need to keep this template as small and simple as possible since it can be used thousands of times on a single page. DTLHS (talk) 00:56, 28 February 2017 (UTC)Reply

How can I use this template to format multi-word translations that are WT:SOP and do not deserve their own entries in the dictionary?

Typical example: a high-rise can be translated to Russian as многоэтажное здание, literally, "a multi-floor building". But there is absolutely no reason to create a многоэтажное здание article: the phrase is a literal sum of its parts in Russian and doesn't deserve its own article any more than, e.g., небольшое здание (small building) or кирпичное здание (brick building).

Ideally, I would like to get something like this:

многоэта́жное^(ru) зда́ние^(ru) n (mnogoetážnoje zdánije)

Desired features:

• each article-deserving entry in the phrase has its own link and its own t+ style interwiki pointer
• a single gender/number entry and a single transliteration for the whole phrase

Tetromino (talk) 20:34, 5 March 2017 (UTC)Reply

I oppose this request for Russian or any other language. --Anatoli T. ^{(обсудить}/^вклад) 20:39, 5 March 2017 (UTC)Reply

Please explain why. Is it technical reasons (the template would be too hard to implement or too slow to render), aesthetics (you don't like interwiki superscript links), philosophical arguments (you are campaigning to abolish the WT:SOP rule), or …? Tetromino (talk) 20:49, 5 March 2017 (UTC)Reply