Sunday, April 21, 2013

Wiktionary - Recent changes [en]: Template talk:t

Wiktionary - Recent changes [en]
Track the most recent changes to the wiki in this feed. // via fulltextrssfeed.com
Template talk:t
Apr 21st 2013, 23:48

Line 475: Line 475:
   
 

:::::::::The transcription as in modules: [[:Category:Transliteration modules]], those, which are tested and approved for use, that is. --[[User:Atitarev|Anatoli]] <sup>([[User talk:Atitarev|обсудить]]</sup>/<sup>[[Special:Contributions/Atitarev|вклад]])</sup> 12:07, 19 April 2013 (UTC)

  

:::::::::The transcription as in modules: [[:Category:Transliteration modules]], those, which are tested and approved for use, that is. --[[User:Atitarev|Anatoli]] <sup>([[User talk:Atitarev|обсудить]]</sup>/<sup>[[Special:Contributions/Atitarev|вклад]])</sup> 12:07, 19 April 2013 (UTC)
  +
  +

:::::::::: 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."&nbsp;<span class="user-mzajac">''—[[User:Mzajac |Michael]]&nbsp;[[User talk:Mzajac |Z.]]&nbsp;<small>2013-04-21&nbsp;23:48&nbsp;z</small>''</span>

Latest revision as of 23:48, 21 April 2013

Contents

[edit] Creation of this template

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: [[pomme]] ''f''


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

Good work. It would be the standard in all translations and definitions in Wiktionary. --77.210.55.105 06:52, 6 October 2007 (UTC)
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)
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 %

[edit] suggestions

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)

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 (nl) m and baard (nl) 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)
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 (nl) n) over {{t|nl|ding|n}} (rendered as ding (nl) 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)
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)

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)

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)

[edit] Allow piped links

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 [[#Dutch|uniform]]. 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)

The problem is in passing the parameter to this template. The work-around I think would look something like this:
  [[{{{sc|{{{2|}}}}}}{{#if:{{{hash|}}}|#{{{hash}}}|}}|{{{dn|{{{sc|{{{2|}}}}}}}}}]] ...

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)

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)
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)
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)
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:
  [[{{{2|}}}#<compute language name here>|{{{2|}}}]] ...

henne 15:04, 7 December 2006 (UTC)

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)

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 Kurdish rather than Kurdish. Robert Ullmann 15:23, 7 December 2006 (UTC)

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}}}|[[{{{2}}}]]}}|[[{{{2}}}#{{#language:{{{1}}}|{{{2}}}]]}}   {{#switch:{{{3|}}}|f|m|mf|n|c={{{{{3}}}}} <nowiki/>|}}{{#switch:{{{4|}}}|s|p={{{{{4}}}}}   <nowiki/>|}}[[:{{#switch:{{{1}}}|nan=zh-min-nan|yue=zh-yue|cmn=zh|{{{1}}}}}:{{{2}}}|<sup>({{{1}}})</sup>]]

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

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)
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)

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)

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}}}}}}|[[{{#if:{{{3|}}}|{{{3}}}{{{2}}}|{{{2}}}}}|{{{3|{{{2}}}}}}]]}}</span> <span   class="trad-sup-code"><sup>{{#ifeq:{{{2}}}|nl|(nl)|[[:{{{1}}}:{{{3|{{{2}}}}}}|({{{1}}})]]}}</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. :-(

[edit] Language names

Can't we have the language codes instead of the language names spelt out, like vanNederlands. 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)

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)

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)

[edit] Engineering

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)

[edit] Link alternation

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)

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)

[edit] Section references

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 "[[Kurdish]]"

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

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)

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)
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)
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)

[edit] Symbol

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)

[edit] Performance

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)

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 <sup>([[:nl:word]])</sup> 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)
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)
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)
{{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)

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)

[edit] Issues implementing Template:t in translation sections

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)

[edit] FL link

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

[edit] Changed ls= to lang=

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)

[edit] Hover text

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)

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)
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)

[edit] Transliteration parameter

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)

How about "R" for "Roman alphabet"? How did this created with such an important piece missing? --Connel MacKenzie 01:08, 8 August 2007 (UTC)
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)
I added tr= as shown above. Robert Ullmann 13:08, 10 August 2007 (UTC)
Thanks, Robert. I'll start using this template for Korean translations now. Rod (A. Smith) 15:46, 10 August 2007 (UTC)
I'm eagerly awaiting the non-Roman script handling for Korean translations. Rod (A. Smith) 16:07, 10 August 2007 (UTC)
Oops. Somehow I hadn't noticed "sc". Rod (A. Smith) 16:11, 10 August 2007 (UTC)

[edit] Should use standard red for redlinks

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)

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)
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)

[edit] alt parameter

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)

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

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)

[edit] Foreign-language link format

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:

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: альбатрос (uk) (al'batrós) m
  2. Superscript only: альбатрос uk (al'batrós) m
  3. Browser's default monospaced font: альбатрос uk (al'batrós) m
  4. Square brackets only: альбатрос [uk] (al'batrós) m

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

(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)
#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)
(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. [trying to say this as gently as possible:] 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)
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)
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)
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 [the superscript] 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)

[edit] Archived discussions regarding the format

  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)

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

[edit] Blue t-links are ambiguous

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)

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)

[edit] getting {fpl} and {mpl} to work

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)

Try {{t|es|PUF|f|p}}: PUF (es) f pl. —Michael Z. 17:15, 19 March 2008 (UTC)
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)

[edit] {{t|langcode|translation|g}}?

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.) —RuakhTALK 23:51, 8 September 2008 (UTC)

It wouldn't be easier just to follow the template with {g|language} when needed? Robert Ullmann 05:38, 9 September 2008 (UTC)
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.) —RuakhTALK 11:44, 9 September 2008 (UTC)
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)
Yeah, sure, fine, whatever. :-)   —RuakhTALK 14:59, 9 September 2008 (UTC)

[edit] Strange bug

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)

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

[edit] hiragana/katakana/romaji and maybe a parameter for a translation comment

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)

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=[[hiragana]], 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)

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)

[edit] Categories

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

[edit] When to use tr / t / t- / t+

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)

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

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 [[foo#Aramaic]]. 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.) —RuakhTALK 22:17, 15 May 2010 (UTC)

[edit] No category for misused t templates?

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)

[edit] Old format?

I often see translations formated like this:

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

Tdomhan 10:53, 19 December 2010 (UTC)

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 (fi) format. --Vahag 11:06, 19 December 2010 (UTC)

[edit] The language code "nb"

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)

[edit] Customization spans mess up mobile display

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 translationlanguage 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)

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)
Agreed. Someone can easily write JS to add the parens. --Bequw → τ 01:29, 12 September 2011 (UTC)
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)
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.) —RuakhTALK 23:24, 12 September 2011 (UTC)

[edit] Documentation for t+

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

No, because it doesn't have documentation. We could, of course, fake it. --Μετάknowledgediscuss/deeds 18:44, 16 August 2012 (UTC)
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}}.) —RuakhTALK 18:50, 16 August 2012 (UTC)
Could one of you add "{{documentation}}" to {{t+}}? Or, alternatively, remove it from {{t-}}? --129.125.102.126 15:52, 18 August 2012 (UTC)
Done. Mglovesfun (talk) 16:03, 27 August 2012 (UTC)
Thank you. --129.125.102.126 01:46, 13 September 2012 (UTC)

[edit] xs again

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)

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.
—RuakhTALK 17:22, 27 August 2012 (UTC)
  • 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)
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)
Hm? No, it doesn't. {{t-simple}}'s entire code is [[{{{2}}}#{{{{{1}}}}}|{{{2}}}]]. No xs=. --Yair rand (talk) 13:02, 18 November 2012 (UTC)
Oh, I missed that. Well, you could change it to [[{{{2}}}#{{{xs|{{{{{1}}}}}}}}|{{{2}}}]] right? Or maybe even [[{{{2}}}#{{{xs}}}|{{{2}}}]]? —CodeCat 13:09, 18 November 2012 (UTC)
The first one, I think. No reason not to leave a backup option, is there? --Yair rand (talk) 13:23, 18 November 2012 (UTC)
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)
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)
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)
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)
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)
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. —RuakhTALK 17:01, 18 November 2012 (UTC)

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)

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)
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)
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)

[edit] The language codes "nds-de" and "nds-nl"

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)

[edit] Title for foreign language link

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)

That would be helpful, if users think to hover the mouse over the link... —CodeCat 17:44, 18 February 2013 (UTC)
People don't usually think to use titletext... hence the problem with {{zh-n.}}. But still support, every little bit helps. —Μετάknowledgediscuss/deeds 17:51, 18 February 2013 (UTC)

[edit] Adding automatic transliteration?

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 ზედამხედველობა (ka), მეთვალყურეობა (ka), დაკვირვება (ka)

We could get: ზედამხედველობა (ka) (zedamxedveloba), მეთვალყურეობა (ka) (met'valqureoba), დაკვირვება (ka) (dakvirveba)

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

Why would automatic Arabic and Persian transliteration not be useful? --Yair rand (talk) 10:47, 16 April 2013 (UTC)
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)
By the way, are you not confusing transliteration and transcription here? Dakdada (talk) 08:12, 18 April 2013 (UTC)
That's immaterial. We commonly use "transliteration" etc to mean "standardised romanisation". —Μετάknowledgediscuss/deeds 21:07, 18 April 2013 (UTC)
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)
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)
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)
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)
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)
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
You are receiving this email because you subscribed to this feed at blogtrottr.com.

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions