Template talk:head

Right now, I think this is a great idea. I can't tell immediately what the template is doing, from looking at it though. I'd think it would be just three simple parameters, with no ParserFunction trickery, but I'll comment on that later, when I've deciphered it. Excellent initiative! --Connel MacKenzie 09:31, 16 September 2006 (UTC)Reply

• I also considered simply adding a "lang=" parameter to all the inflected form templates. That would be sort of the opposite approach to this one, with the benefit of not overloading any single template too heavily. Just a thought... --Connel MacKenzie 09:33, 16 September 2006 (UTC)Reply

  This I don't understand. The inflection line templates (en-noun) have lots of very language specific stuff; a "noun" template with a "lang=" parameter would be impossible. (well; not with language specific helper templates ...) The definition line templates (plural of) don't have any use for the language parameter? Robert Ullmann 15:41, 16 September 2006 (UTC) Okay, I understand part of it, {{past participle of}} is categorizing things as English, which is a real problem. This can be fixed in several ways. Robert Ullmann 19:48, 16 September 2006 (UTC)Reply

Thanks! It does use a lot of parser functions, but it is fairly straight-line. Just about all of the complexity is to make it simpler for the user, all of the parameters are optional in one way or another. A basic principle of computer programming is that modules should hide complexity. Most, if not all, simple forms will work the way you would expect:

* {{infl}}                     '''{{PAGENAME}}'''
* {{head|script=ARchar}}       {{ARchar|{{PAGENAME}}}}
* {{head|ru|noun|gender=f}}    '''{{PAGENAME}}''' {{f}}]
* {{head|||plural|foos}}       '''{{PAGENAME}}''' (''plural'' ''']''')
* {{head|xho}}                 '''{{PAGENAME}}''']
* and so on ...

What it does is:

• if there is a script specified, use that template, else bold of pagename
• if there is a gender specified, use the gender template
• if there are parameters after the POS, generate parenthesis
• then for each pair, italicise the first, bold and wikify the second
• generate spaces and commas as needed
• generate close paren if needed
• if the language/POS category exists, categorize there, using sort key or pagename
• else in language category if it exists, ditto

all while not generating any spurious carriage returns so things on the inflection line before or after the template will work as expected. Robert Ullmann 15:41, 16 September 2006 (UTC)Reply

This doesn't do the <span> stuff that makes the other inflection templates able to display as ugly boxes? Or did I miss that? --Connel MacKenzie 10:23, 22 September 2006 (UTC)Reply

No, it doesn't. Those templates rely heavily on knowing that they are generating a fixed number of forms. For example, en-noun knows it is generating two, and has the column width wired to 1/2 (49.75%). It might be possible to do something, but it would get pretty convoluted. I think it would take having several helper templates that did boxes (infl-box2, infl-box3) of different columns, then calling them based on whether parameter 3, 5, 7, etc was the last one used. Mind you those same helper templates might be very useful in standardizing the box-presentation of the language specific templates! Robert Ullmann 13:19, 22 September 2006 (UTC)Reply

I do not understand why you do a test whether the POS category exists, or whether the language category exists. If they don’t, they simply deserve to be created, since there is a word in our dictionary which fits in there. In the long term, they all have to be created, right? H. (talk) 09:00, 27 July 2007 (UTC)Reply

Because I envisioned it being used for a lot of rare languages in which the POS cats are probably not useful. When you consider a language (of which there are many thousands) that has few or no remaining speakers, and where we know (and will only ever know) only a very small number of words, it is probably best just to put them in the language category. Robert Ullmann 09:11, 27 July 2007 (UTC)Reply

Since many (although a definite minority) of the languages here are not inflected, we may want to reconsider our jargon inflection line. headword line seems more appropriate. There is certainly no pressing need to change the name of this template, but I reserved the name {{head}} as a redirect to {{infl}} so we have the option to migrate at some later date. Rod (A. Smith) 23:20, 29 September 2007 (UTC)Reply

Would it be possible to add "g" as a possibility under the gender parameter to include categorization for "X nouns lacking gender"? It would be like including {{g}}.
For an example, {{head|it|noun|gender=g}} would put the article under Category:Italian nouns lacking gender. I don't really know how to explain this any better, being the airhead I am :D I'd add this in myself, but I'm not the best with those codes and I don't want to screw anything up. — — 15:22, 21 October 2007 (UTC)Reply

It would be possible (easy), but somewhat "magic", therefore confusing ... I'd just put {{g|language}} on the line, so the request template is clear. You think? Robert Ullmann 15:26, 21 October 2007 (UTC)Reply

Added it (as I said, easy). But it still might be better to use the g template separately ... Robert Ullmann 15:37, 21 October 2007 (UTC)Reply

I just figured it'd be easier to have everything in one template. luna (and lunã and I'm guessing other things) don't like this new function in the infl template. lol Guess you fix'd it. :] — — 15:44, 21 October 2007 (UTC)Reply

I understand and support the desire not to bold non-Latin text, but the problem is that our script templates aren't designed for this use; they give normal-looking text, sometimes even a bit smaller/less bold-looking than English depending on fonts. I think maybe <big> tags or something should be added when a non-Latin script is specified? Alternatively, perhaps it could pass in a size=big parameter to the script template, which script templates can be updated to support. (I suppose we could simply have entirely separate script templates for inflection lines — {{Hebr-infl}} and so on — but that seems a bit kludgy.) Thoughts? —Ruakh_TALK 04:06, 11 November 2007 (UTC)Reply

yes, this isn't handled quite correctly yet (the other thing is that the sc= should be used for the forms as well as the headword). Passing a fixed parameter to the script templates isn't a bad idea. Let me noodle this a bit. Usually "125%" or something is better than "big". The Arab template does always make things bigger (the default size being teensy, to the point where I can't read it). But this case is a bit different. Robert Ullmann 10:34, 11 November 2007 (UTC)Reply

The sc=Grek argument produces non-bold text, see ανέκδοτο. Is the problem soluble - has the discussion moed on elsewhere? —Saltmarsh^{απάντηση} 10:54, 3 July 2008 (UTC)Reply

There is more discussion re Cyrillic and bold below. There are several interrelated things going on. We want to bold some specific subset of the scripts. I should spend some more time on this, I suppose ;-) Robert Ullmann 11:39, 3 July 2008 (UTC)Reply

If a linked form lacks wiki markup, it should probably link directly to the language-specific section of the target page, right? Rod (A. Smith) 17:31, 29 November 2007 (UTC)Reply

I'd agree, but {{infl}} uses {{wlink}} which can't take a lang parameter. I just proposed that. We'll see if there's support for that change or if there's a workaround. --Bequw 13:23, 30 November 2007 (UTC)Reply

Kept. See archived discussion. 09:47, 19 January 2008 (UTC)

This template poorly handles {{head|cs|suffix}}, failing to place it into the proper category. From looking into the code, I conjecture the following cause: There is the Category:Czech suffixes, but the template only looks for the existence of Category:Czech suffixs, assuming that the formation of the plural is by adding "s" instead of "es". --Daniel Polansky 17:10, 9 February 2008 (UTC)Reply

You have to do {{infl|cs|suffix|cat=suffixes}}. It's annoying. I think suffix and prefix are common enough to be special-cased; or maybe we should create a {{infle}} that's identical but adds an e? —Ruakh_TALK 17:29, 9 February 2008 (UTC)Reply

Another related thing that could be stand to be fixed are things like this: {{infl|ja|hiragana|sc=Japn|cat=hiragana}} (cf. ぇ). If a category exists without the "s" suffix, it should be used without having to duplicate the POS in "cat". Mike Dillon 23:53, 10 February 2008 (UTC)Reply

Re: "If a category exists without the 's' suffix": You're brilliant! Somehow it didn't occur to me that we could make use of #ifexist:. It's a bit ugly, but we can check for the existence of -s, -es, and -Ø categories before falling back to the generic language category. No special-casing necessary. (Well, except insofar as testing three specific kinds of category naming constitutes "special-casing".) —Ruakh_TALK 01:49, 11 February 2008 (UTC)Reply

Unfortunately the implementation of #ifexist is not very good; it adds to the links table (it didn't used to), so one would end up with (say) Category:Japanese hiraganas appearing as a much-wanted entry. (*sigh*). Something might be done here though ;-) Robert Ullmann

With an un-broken #ifexist (which we used to have ...) that didn't add to the links table, I'd use that. I'd prefer now to not use the #ifexist test at all; the idea was to put "small" languages into just the "(language) language" cat, but there really isn't any reason why they can't or shouldn't have POS subcats, even if tiny. So I think I will take out the #ifexist test(s) completely, and use a short #switch (which adds little overhead, certainly much less that #ifexist, which has to do a SELECT ;-). So suffix, prefix, infix, affix will get handled, and probably a few others sometime. (Using "hiragana" as a POS cat is not correct, ぇ should be using "cat=kana") Robert Ullmann 13:13, 2 March 2008 (UTC)Reply

Done. Tell me if you see trouble. Robert Ullmann 13:48, 2 March 2008 (UTC)Reply

Please add circumfix and interfix. - TAKASUGI Shinji (talk) 07:54, 27 May 2010 (UTC)Reply

I have a problem at the Norwegian section of ministerium where the definite plural entry has two entries. Could or perhaps be made a parameter? __meco 22:03, 17 February 2008 (UTC)Reply

Maybe like suppressing the comma if the descriptive word is "or" or "and"? Indeed. Will get on it (a bit busy at this very moment, and I want to look at the previous issue above as well; infl is used in enough entries that it would be good to edit it once. Robert Ullmann 11:42, 18 February 2008 (UTC)Reply

Of course, I just had to do an edit it now to remove the desc= param that produces invalid format.

For now, just use "or" and I'll get rid of the spurious comma(s) presently. Robert Ullmann 17:38, 1 March 2008 (UTC)Reply

Comma is suppressed before odd parameters = "or". Robert Ullmann 13:58, 2 March 2008 (UTC)Reply

Comma should also be suppressed before "and". For example Georgian noun has two plurals and they are not exactly the same (aka interchangeable) because there're connotation- and context- related differences. Obviously "or" is not appropriate here.--Dixtosa (talk) 15:49, 4 August 2014 (UTC)Reply

test: head (plural pl1, and pl2).

I love being invisible, it makes me feel i am a ninja. yoo XD--Dixtosa (talk) 20:04, 7 August 2014 (UTC)Reply

Without commenting on whether or not the comma should be suppressed, is it the case that "or" isn't appropriate? In entries like learn#Verb or medium#Noun, where the difference in forms is dialectal or sense-based, I always see "or", and it seems appropriate, inasmuch as form is either x 'or' y, depending on context or sense. - -sche (discuss) 20:43, 7 August 2014 (UTC)Reply

This is bad format, a "description" should be the first thing inside the parenthesis. If some text other than the standard genders is desired in the gender position, it is sufficient to use g=

Removed, entries added to a cleanup cat. (Category:infl template parameter cleanup which note doesn't have to exist) Robert Ullmann 17:29, 1 March 2008 (UTC)Reply

note that "invariant" is a number, and we have {{inv}} (noting that we may end up with a language code conflict someday, but not for now). So g=inv is valid, as is g={{m|inv}}. (Although that is a bad example, it should be g=m|g2=inv.)

other things should go in the parens, often with two pipes to skip the link parameter and go on to the form(s). Robert Ullmann 13:02, 2 March 2008 (UTC)Reply

Think we've got them all. Robert Ullmann 13:32, 2 March 2008 (UTC)Reply

I had fixed this, but Connel removed the code again. Presumably because of a number of entries that were using the POS type parameter incorrectly; it is the entries themselves that need to be fixed. This makes it possible to find them.

Template no longer incorrectly categorizes in "(name) language" where entries should never appear. Robert Ullmann 15:16, 16 March 2008 (UTC)Reply

Headwords are not bolded when I add the sc=Cyrl parameter (for Cyrillic script). From #Non-Latin bold. above, I'm guessing that this is not by design, but necessary out of expedience.

Un-bolding the headword reduces the appearance, consistency, and readability of an entry (as does the application of the Arial Unicode MS font). Can this be fixed, or should I just leave out the sc=Cyrl parameter for now?

Here's an example, from батяр. The first looks correct in my browser (Safari/Mac). The second has "sc=Cyrl" added, and includes bold links but the headword fades away in a non-matching font.

{{head|uk|noun|f|батярка|pl|батяри|f pl|батярки|head=батяр|g=m|tr=bátjar}}

батяр • (bátjar) m (f батярка, pl батяри, f pl батярки)

{{head|uk|noun|f|батярка|pl|батяри|f pl|батярки|head=батяр|g=m|tr=bátjar|sc=Cyrl}}

батяр • (bátjar) m (f батярка, pl батяри, f pl батярки)

Is there any way to correct the behaviour? —Michael Z. 17:50, 25 March 2008 (UTC)Reply

Indeed. There are non-Latin scripts we don't want to bold. So the template is using the presence or absence of sc to decide whehter to bold. This isn't the right test, and we haven't sorted it. It is similar to the issue of increasing the size for some scripts, where the same script template in running text should not.

(other note) the attributes should be spelled out:

батяр • (bátjar) m (feminine батярка, plural батяри, feminine plural батярки)

only using the abbreviated gender template(s) for the headword form. Helps make it a bit clearer and consistent with other templates (like en-noun, which spells out "plural") Robert Ullmann 18:05, 25 March 2008 (UTC)Reply

Thanks. I guess the best solution is to keep the data consistent and complete by including the "sc=Cyrl" parameter, and be patient for a fix, right? I can see problems arising from trying to use a workaround.

Will someone knowledgeable be working on this, or should I start learning about conditionals and try to improve the template? —Michael Z. 18:52, 25 March 2008 (UTC)Reply

If this template had a <span> around each element in the foreign script with a consistent class, we could use CSS rules to do the contextual bolding. The rule would target ".RU" inside of the class used by infl and set font-weight to "bold" or "bolder". Mike Dillon 04:56, 26 March 2008 (UTC)Reply

Word. Likewise, it could target ".scHebr" and ".AR" and the like and set font-size to "120%" or "125%" or so. —Ruakh_TALK 12:07, 26 March 2008 (UTC)Reply

That's one possible direction. Another point is made above under "Options": Note that most invocations of {{infl}} should be fairly simple; if a significant language requires a complex call a large amount of the time (such as using sort= in every entry), the language should probably have its own templates. A {uk-noun} template could do (force) a number of things. In at least one case (I wish I could recall) someone wrote a language-specific template that works by calling {infl}. A third way is to have a context parameter to the script templates, doing much what the CSS would. There are a number of trade-offs. (I'm a bit busy doing similar stuff for the {t} links, so don't want to dig into this right at the moment ;-) Robert Ullmann 12:30, 26 March 2008 (UTC)Reply

It seems awkward to have all those language classes in the style sheet, and be overriding them with inline CSS. Wouldn't it be better to retain simple semantic HTML, remove inline styles, and rely on classes and style sheets with contextual selectors for the presentation? This is most accessible for users of e.g., text, audio, and braille browsers, as well as for users of other skins and user style sheets. It could also be abstracted to work logically across different templates and simplify authoring and overriding. The only obstacle I see is the cache lag, but that just gives us the opportunity to plan things out well.

In terms of semantic HTML, it would be better not to remove the <b> element, but instead to restyle it for most foreign-language scripts (<strong> would be arguably better than <b>). Since we already have classes like .RU in the style sheet, it would be efficient and less redundant to use the class name in the HTML. We could keep the code simpler by inserting <strong class="RU">, and applying a stylesheet rule like strong.RU { font-weight: normal; } (depending on the HTML, the selector could be strong .RU or .RU strong). The CSS rule could coexist inline for a month until the caches catch up.

Is there a place where all of the important templates, styles and classes are listed? The cache lag gives us a chance to do some good coördination here. —Michael Z.

Omission of the language parameter leads to odd occurrences like Category:nouns (glândula) and Category:proper nouns (Aedes). Can we have some solution, like a cleanup category or something, instead? Dmcdevit·t 01:50, 19 April 2008 (UTC)Reply

The issue here is that the language code (the second parameter in this template was not given, it should be {{kea}} for Kabuverdianu. I've amended both entries accordingly. --Williamsayers79 07:39, 19 April 2008 (UTC)Reply

Doh! - should read the posts better! - yes we do need to have a tidy up category if the lang template is not used.--Williamsayers79 07:43, 19 April 2008 (UTC)Reply

Really something of a bug, the cat should have #if(lang) wrapped around it. Whether the else clause should have a cleanup cat is a separable issue; the template was intended to work without the code, but that got broken along the way. Note that {{infl}} is supposed to work by itself. I'll fix this ... do we want a cat for "language code missing"? Robert Ullmann 13:48, 19 April 2008 (UTC)Reply

I attempted to bring out each word of the phrase slå noe i hartkorn med noe but was unsuccessful. Could someone take a look at this? __meco 18:41, 17 May 2008 (UTC)Reply

Done. The parameter name for this is head, not pos. -Atelaes λάλει ἐμοί 18:45, 17 May 2008 (UTC)Reply

Help appreciated. __meco 19:06, 17 May 2008 (UTC)Reply

For a tidier appearance and following a practice I first noticed DCDuring employing, I have begun to use this template with lengthy English idioms, where a display of verb inflections is not desirable, nor a display of noun plurals or adjectival or adverbial comparatives, nor even messages like not comparable. The major advantage of using this template (rather than just a bolded header) is that it allows the POS to be specified within the template and automatically categorizes the entry by POS (see, for example, go the whole hog or in hot water). Does anyone have a problem with this practice? -- WikiPedant 14:39, 8 July 2008 (UTC)Reply

I certainly don't. Personally I do like to display inflections for the verb-y idioms up to three or four verbs (though it's annoying that they're links, since they'll just be redirects back to the lemma entry), but if another editor prefers to use {{en|infl}}, I certainly don't object. It's a wiki, we've got editorial discretion. :-) —Ruakh_TALK 23:04, 8 July 2008 (UTC)Reply

So basically I've opened संस्कृत#Sanskrit in IE and it shows empty squares where 'ṃ' and 'ṛ' should stand in the headline transliteration - obviously IE didn't load necessary fonts. Using tr={{IAST|saṃ-skṛtá, sáṃ-skṛta}} inside {infl} fixed the problem. So basically I'm saying that {infl} should automagiacally load some language-specific templates like {IAST} for Sanskrit (or other Indic languages that use IAST as default transliteration), semxlit for Semitic etc. wherever the transliteration scheme uses characters that certain browsers tend not to display properly. Should probably managed by some large switch-statement in some external template --Ivan Štambuk 14:56, 26 November 2008 (UTC)Reply

FYI: Safari/Mac, Firefox/Mac, and Firefox/WinXP seem to do fine with the default system fonts. We do need default mechanisms to set a term's script and font based on language, a transliteration's font based on script, and to set lang="" attributes everywhere. This is complex and will take a lot of editors' time and effort (I'm still half-way through undoing my style-sheet mix-up in trying to sort out what we have already built to support various browsers). In the short run, it may serve our readers who want to use a multilingual dictionary if we recommended a browser which actually supports Unicode. —Michael Z. 2008-11-26 19:56 z

That sounds fine. I always felt that there was a need for a simple skeleton template that would provide basic functionality of linking to L2 sections based on Wiktionary Language Code and displaying transliterations, and upon which {t}, {l}, {term}, {infl} and others would build upon. --Ivan Štambuk 23:36, 26 November 2008 (UTC)Reply

It isn't done because of the "large switch statement in some external template". Because of the way the template language works, it always expands every branch. So that "large switch" will get invoked for every single use of {infl} (or whatever) even though needed in a tiny fraction of cases. The explosion in server load is not acceptable. The correct solution is to use {IAST} as you mention above, or to simply create proper tempate(s) for the language, and just do everything needed. (this is also why creating a "simple skeleton" template with various options to be used by others is a very bad idea: the template language is simply not a procedural programming language even though we would like it to be, and even though the parser conditionals make it look like it is!) Robert Ullmann 10:39, 27 November 2008 (UTC)Reply

Of course, the proper solution to all such problems is "Do Not Use IE". Robert Ullmann 10:45, 27 November 2008 (UTC)Reply

In this particular case, we might consider always wrapping the tr= parameter in class=Unicode, which specifies a set of fonts to try to get coverage in IE, and defaults (:inherit) for all other browsers (e.g. has no effect on other browsers). (All {IAST} does is set class to Unicode and IAST, and the IAST class just sets text-decoration:none.) {semxlit} just sets fonts to Tahoma and Lucida Sans Unicode, both of those are in the class=Unicode list. If someone uses an explicit template inside that (as Ivan did), it will just over-ride the outer Unicode class. Robert Ullmann 11:05, 27 November 2008 (UTC)Reply

That would also be fine (if it fixes the problem for IE users). The expand-all behavior of MediaWiki template language is very strange IMHO. Its syntax is barely stomachable, and the lack of some lazy strategy for template transclusion significantly burdens the mind of the end-user and cripples the possibilities for some "clean" usage, favoring obscure tricks to established and wide-spread programming patterns.

The reason that the template language seems queer to you is that you only know of procedural programming languages. The template language is not. The "wide-spread programming patterns" are what procedural languages do (do this, then do this, then if this do that 10 times). The template language isn't thus. One reason for confusion is things like #if, and #switch, which make it look like something it isn't. For example: you see if p then a else b. In a procedural language you are telling the computer: "evaluate p, then if (true/non-blank/whatever) evaluate a, else ignore a, and evaluate b". But the template language works by successive text transclusion: {{#if:p|a|b}} means "expand p, a, and b, and pass the resulting strings to #if, which returns a if p is non-blank, and b otherwise".

If you try to think of the template language as a procedural programming language, you will fry your brain. (;-) see this extended explanation for more. Robert Ullmann 07:54, 30 November 2008 (UTC)Reply

That's a really interesting tutorial in the GP. So basically arbitrary depth recursion by redirects like what {context} is doing makes the MediaWiki template language Turing-complete? That would mean that that it's undecidable when and whether the browser will render the page powered by MW if it uses template language ^_^

I'm aware of the existence of non-procedural PL paradigms, but am still bewildered in this case why there there lacks some kind of short-circuit evaluation mechanism for template transclusion, based on the result of the preceding conditional. The end-result would be the same if the a and b got expanded after the evaluation of (expanded) p.

BTW, I think that this behaviour is a security risk too. The 2M limit on the template transclusion can be circumvented by using subpages that are themselves transclused in the upper page (like some Appendix pages that contain large listings are already doing), and by chaining this in a page/subpage/subpage/.. manner you can get exponentially growing memory consumption on the server-side (unless they keep sending data to the browser as they transclude it..I don't know how MW sw works).. --Ivan Štambuk 08:20, 30 November 2008 (UTC)Reply

There is no difference between transcluding a "template" and a subpage. The only thing "Template:" is is a default namespace when using the transclusion syntax. So using subpages (or whatever) still smacks you into the 2M limit. There is a trick for preventing expansion of one conditional branch, that is to use the result of a conditional to generate the name of a template to be included. This is how {context} stops the recursion. As to Turing: given a specific finite set of pages in a wiki, any given invocation is decidable in finite time. Could be very large, but the recursion is bounded by the number of {name N} redirects for a template, and that is in turn bounded by the finite size of the wiki (;-) Robert Ullmann 08:42, 30 November 2008 (UTC)Reply

OK but how do you explain that Appendix:List of Proto-Indo-European roots doesn't hit the 2M limit, but if you copy paste all the transcluded subpages in one page and save you hit the 2M limit and half of templates do not expand at all? Looks like the 2M limit is fixed on per-page basis..--Ivan Štambuk 08:35, 3 December 2008 (UTC)Reply

There are "pre-expand" and "post-expand" limits. For that page:

NewPP limit report
Preprocessor node count: 103524/1000000
Post-expand include size: 1538942/2048000 bytes
Template argument size: 134926/2048000 bytes
Expensive parser function count: 63/500

So it doesn't hit the 2M limit as it goes through the subpages, and ends up at ~1.5M; if you paste all the subpages in, it runs into the limit midway, as there is more text in the (overall) page at that point. One can cause the server to expand and discard many megabytes of data as it goes, but it will only have at most 2M at any given point (or it will stop expanding). So there is no way to cause a server storage over-run. There is also a limit on the CPU and/or wall time (I forget which ;-). Robert Ullmann 11:32, 3 December 2008 (UTC)Reply

The cases where class=Unicode would not be acceptable (i.e. where fonts for transliteration are specific and not handled by Unicode class) should probably be handled in language-specific set of templates. --Ivan Štambuk 14:54, 27 November 2008 (UTC)Reply

In the long run, I think it can be done by choosing a template instead of using a parser function, exactly how {term} chooses between 160 or more scripts based on the input sc=Deva choosing the template {Deva}. I suspect that {term} would send something like rom=IAST to the script template, and the script template would apply its preferred style or class to the contents of tr=foo.

That's just a guess, but I've been thinking about how to correctly add lang="fo" xml:lang="fo" everywhere. —Michael Z. 2008-11-27 17:11 z

Not that I understand you completely, but it would be great if it could work anyhow. Now that I think about this, and things like {lang2sc} (which is still unused but has potential to be, and faces the same giant-switch problem), it appears to me that it would be the best to forget the whole thing and assign AutoFormat to scan ISO code inside the specific set of templates like {t}, {term} etc. and apply appropriate script templates for both the main entries and transliterations (sc-trans=?). --Ivan Štambuk 02:43, 28 November 2008 (UTC)Reply

Yes, why not get AutoFormat to do this? I don't know of any exceptions where the script shouldn't be added, except that in most cases sc=Latn is redundant (with the exception in turn of Serbian, sr-Latn, and any other languages without a single default script).

But I will eventually develop and test a default mechanism, whereby each lang=xx tag can have its own default script associated with it—a sc=Xxxx parameter would only be used to override a language's default. If it works out, we may eventually get AutoFormat to remove most of them again, but that would be okay, too. —Michael Z. 2008-11-29 22:55 z

When trying to work it out, keep in mind that you want to cover 7000+ languages, and Latn is only the correct default for a minority. (;-) As to adding "lang=... xml:lang=...": if the template is for a specific language, that is static text. If not, the script template should take a lang parameter. (and infl and term etc can pass it along). Robert Ullmann 07:54, 30 November 2008 (UTC)Reply

Yup, exactly what I'm thinking. I'm starting with the IANA subtag registry as a reference, which has almost 500 languages and their scripts listed, although I'm not yet committing to incorporating them all explicitly. I think I might start with the Arabic script templates as a test case, since we have ten language-specific versions already in use. —Michael Z. 2008-11-30 17:18 z

Do keep in mind that the IANA registry is a total mess. I'd recommend never using anything from there; just check to see if the appropriate language and script tag is registered. (or maybe even not check ;-) Robert Ullmann 15:51, 1 December 2008 (UTC)Reply

How is the registry a mess? As far as I can tell, I would have to refer to the registry to find the names of script variant codes, and to determine which scripts are associated with which languages, and which ones are the defaults for particular languages (“suppress-scripts”). —Michael Z. 2008-12-01 16:25 z

Zero quality control. If tag xx-Yyyy exists there, it means someone asked IANA to register the tag; it does not mean script Yyyy is meaningful for lang xx. And the absence of a tag is equally not meaningful. You/we just use the tags that make sense, and we will be fine. (If they aren't in the IANA list, we might ask them to add.) What a given browser supports is an "extended subset", although I think the browser people are fairly good about asking IANA to register anything missing. There have been problems with IANA registering things that conflict with ISO (and then with WMF following IANA and not ISO). Keep in mind that we (en.wikt, wikts collectively, wps) have a far better knowledge base than IANA; the only comparable group to us is SIL. Robert Ullmann 11:32, 3 December 2008 (UTC)Reply

To return to the section topic in particular: there isn't any evidence I can see why transliteration templates based on ISO language code are needed at all: transliterations use (none), {{Unicode}}, {{IAST}}, and {{semxlit}}; IAST is just Unicode, and semxlit is a subset (Tahoma and Lucida Sans Unicode). It isn't like there is some huge n->m problem, there simply isn't a set of "transliteration templates"; in fact there appears to be essentially one (Unicode), and that only needed for IE when it is too dumb to find a font to display a character (which is really dumb, when you consider that both Tahoma and Lucida Sans are always loaded) Robert Ullmann 07:54, 30 November 2008 (UTC)Reply

I just had a look at these in my MSIE6/WinXP vanilla test system. IAST is only used in five entries, and in every case it can be replaced with {unicode} or just removed. Semxlit is only used in three, and in two of those it fails to render text correctly anyway. These should be merged and deleted. —Michael Z. 2008-12-02 06:18 z

I agree that both should be orphaned and RfD-ed (or redirected to {unicode}) They've ended up on WT from WP where they're much more used. I myself have been adding IAST transliterations of some cited Sanskrit passages wrapped with {unicode} for a long time now. --Ivan Štambuk 08:35, 3 December 2008 (UTC)Reply

I have RFD'd both of these 1 2. I have some other script template tasks to tackle first, but I will keep in mind the requirements for transliterations for later. —Michael Z. 2008-12-06 03:49 z

Would anyone mind switched this:

]

for this:

{{#if:{{{2|}}}|]}}

so that this could work in the inflection line of entries where the language requires some template so that the font is right, but doesn't require any extra categories? --Yair rand 22:56, 1 February 2010 (UTC)Reply

Please just help me get these fixed now. They now need "infl|xlc|letter" vinstead of just "infl|xlc" and so on. --> Special:Contributions/Mutante Mutante 07:13, 16 February 2010 (UTC)Reply

Sorry, I forgot about the cat parameter. The template should now work with just "infl|xlc". --Yair rand 23:55, 17 February 2010 (UTC)Reply

Hello, drive-by editor here. I would like to suggest to duplicate cat= with an optional cat2= (and cat3= to be on the safe side). For instance, Category:Finnish suffixes are subcategorized with 8 types, and some suffixes belong to more than one type.

Case study: -nen was coded like this:

===Suffix===
'''-nen'''
 ...
]
]

I couldn't upgrade it better than this:

===Suffix===
{{head|fi|suffix|cat=adjectival suffixes|sort=nen}}
 ...
]

To get rid of the second hardcoded category, a cat2 parameter would be needed like this:

===Suffix===
{{head|fi|suffix|cat=adjectival suffixes|cat2=denominal suffixes|sort=nen}}

HTH 62.147.10.167 14:54, 22 February 2010 (UTC)Reply

Words using this template that are tagged with acronym should use the <acronym> html tag and words flagged as abbreviations should be tagged with the html tag <abbr>. CyberSkull 00:42, 10 April 2010 (UTC)Reply

At the moment there is a conditional that turns off all categorisation if the namespace isn't the main namespace. However, the mainpace isn't the only place that contains 'terms': appendixes do so as well (proto- and conlangs). Is it possible to change the if statement into a switch, something like this?

{{#switch:{{NAMESPACE}}|Appendix|=(whatever was there already)|#default=}}

That way, it'll become possible to use it in appendix entries as well, which would be very useful. Manually adding all those categories and sort keys is becoming a pain. —CodeCat 14:40, 13 September 2010 (UTC)Reply

I think it's intentional that (for example) ] does not appear in any of the same categories as mainspace entries. —Ruakh_TALK 15:11, 13 September 2010 (UTC)Reply

But that's an English entry that's in an appendix because it's not 'interesting' enough for mainspace. A category like ] would be entirely empty if the articles weren't explicitly categorised. I think the real problem though is that proto-languages and 'less interesting' terms in attested languages are all lumped together in the appendix, when they are clearly different things. If non-mainspace-languages had their own namespace then it could be made to work quite easily just for that namespace, while leaving English appendixes alone. —CodeCat 17:04, 13 September 2010 (UTC)Reply

{{infl2}} or something then? I'm with Ruakh on this, I've deliberately used {{infl}} in other namespaces knowing full well it won't categorize. Mglovesfun (talk) 19:02, 27 January 2011 (UTC)Reply

Is it possible to provide for the "head" to be formatable word by word, eg, not necessarily bold? Apparently, in Scottish Gaelic, for example, proper nouns sometime require an article in all uses, so it might be desirable to show the article on the inflection line. But, as the article is not part of the headword (and probably should not be), it seems appropriate to allow it not to be bold. DCDuring TALK 18:29, 27 January 2011 (UTC)Reply

I think infl still works if not the first thing on a line. That said, I like the whole head word in bold, see Escriture which I created a few hours ago. Mglovesfun (talk) 19:04, 27 January 2011 (UTC)Reply

The effect for a single slim letter (l') is minimal compared to an in Ruis, let alone an English headword that might include the or even The. DCDuring TALK 19:16, 27 January 2011 (UTC)Reply

I am thinking of making this template include a word in one of the subcategories of Category:Gender requests if it doesn't specify the gender, and if that subcat exists. Thoughts? —Internoob (Disc•Cont) 22:44, 27 April 2011 (UTC)Reply

That's clever. I'm not sure that the existence of a gender-requests category for a given language and part of speech necessarily means that all entries in that language and part of speech require gender information inside {{infl}}, or at all. For example, a language that only has gender in the singular (like most Germanic languages) likely won't need gender information for pluralia tantum; and a noun with anomalous gender behavior (say, masculine in the singular and feminine in the plural, as three French nouns are sometimes claimed to be) may be better served with a usage note. (Each of those examples can be debated, incidentally, but I think my point stands. Language is infinitely diverse and unpredictable, and this template needs to work for every language in the world.)

Overall I think it's a good idea, as long as there's a documented way to disable it; g=-, say.

—Ruakh_TALK 00:08, 28 April 2011 (UTC)Reply

Ifexist functions are heavy, I think. I'm not sure this would be worth it. --Yair rand 00:14, 28 April 2011 (UTC)Reply

They are indeed heavier than other parser-functions, because they require a database lookup, but the same is true of links, templates, categorizations, and so on. I don't think we should use them in templates like {{term}} or {{t}} that often appear a huge number of times on a single page, but I don't think it's a problem for {{infl}} to use one. —Ruakh_TALK 00:19, 28 April 2011 (UTC)Reply

Currently there is no way for this template to categorize entries into different subcategories based on script. The sc= parameter only sets the script of the headword but it doesn't change the category. What would be the best way to do this? —CodeCat 13:19, 4 August 2011 (UTC)Reply

Are you thinking of doing so for all entries? I don't think it's wise to have "English nouns in Latin script" as a category. Or are you only thinking of doing so for languages (like Serbo-Croatian IIRC) written in multiple scripts? If so, perhaps first get consensus from any such language's editors (or the community) that such categorization is desired. As to how to do it, it should be easy enough: {{#switch:{{{2}}}--{{{sc}}}|sh--Cyrl=]}} or something.​—msh210℠ (talk) 15:56, 4 August 2011 (UTC)Reply

No it wouldn't be for all entries, only for those where it's specifically added. It would be on an entry-by-entry basis so no existing entries are changed. Changing it to work for every combination of script and language might work too though. —CodeCat 19:06, 4 August 2011 (UTC)Reply

I suppose {{infl|sh||cat=verbs in Cyrillic script|sc=Cyrl}} would do what you want. —Ruakh_TALK 21:51, 4 August 2011 (UTC)Reply

Or cat2=verbs in Cyrillic script. AFAICT only reasonable way to actually implement this is by using an #ifexist:, which would affect every entry using infl, main namespace or otherwise. Mglovesfun (talk) 21:55, 4 August 2011 (UTC)Reply

1. Oppose Liliana • 19:11, 4 August 2011 (UTC)Reply

Why? Do you prefer that entries be added to those categories in other ways? If you prefer that those categories not be used at all, then you should discuss that at BP because they are already in use. This discussion is only about what the best way would be for this template to add entries to those categories. —CodeCat 19:36, 4 August 2011 (UTC)Reply

{{sh-verb}} (and so on) should be able to do this, infl already can do this in either the way Ruakh or in the way I describe it above. The idea of doing it automatically bothers me a bit. Mglovesfun (talk) 21:56, 4 August 2011 (UTC)Reply

I was thinking more of using another parameter, maybe sccat=, which has the same effect as sc= but adds the entry to the category as well. Alternatively, something like sccat=1 could have the same effect. —CodeCat 22:02, 4 August 2011 (UTC)Reply

The point by Mglovesfun is kinda what I mean. If your language needs this, it's better off using its own inflection template, instead of the general infl. -- Liliana • 01:05, 5 August 2011 (UTC)Reply

Most languages don't have headword templates for form-of entries. But form-of entries could be in a script category. It seems a bit silly to create a template just for form-of entries... —CodeCat 01:19, 5 August 2011 (UTC)Reply

The following discussion has been moved from Wiktionary:Requests for moves, mergers and splits.

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.

---

Template:infl to Template:head

We've been using the term 'headword line' for a while now, but this template still reflects the earlier name, as a relic of earlier policies. Apparently someone had foreseen this move a long time ago, because {{head}} redirects to {{infl}} already. I'm proposing to swap this, so that {{head}} is the actual template and {{infl}} becomes a redirect. The redirect might be orphaned eventually, maybe with the help of a bot, but it's so widely used that will probably not happen anytime soon. —CodeCat 19:12, 10 December 2011 (UTC)Reply

I could run a bot to replace all uses in 12-14 days once there is consensus. -- Liliana • 19:36, 10 December 2011 (UTC)Reply

I don't really care. Mglovesfun (talk) 16:02, 11 December 2011 (UTC)Reply

I'm not sure if this really counts as consensus with only three people? —CodeCat 11:46, 24 December 2011 (UTC)Reply

Silence means "it's okay, go ahead". Usually. -- Liliana • 12:32, 24 December 2011 (UTC)Reply

Ok I've made the move now. I'd like to wait and see if anyone reacts before doing any more, because this is such a big change. —CodeCat 12:43, 24 December 2011 (UTC)Reply

Not really a big change; infl is really widely used, but in practical terms, swapping the redirect and the primary form makes no difference, I mean, quite literally none that I'm aware of. Regarding Liliana-60's comment, yes, I agree, I just decided to explicitly say 'I don't care' while others did not. Mglovesfun (talk) 12:34, 25 December 2011 (UTC)Reply

Comment: Your bot really makes the swap make a long difference, though. :-D Njardarlogar 22:33, 7 January 2012 (UTC)Reply

The cat= parameter really does the same thing, more or less, as the second numbered parameter. Both indicate the category that the entry should go in. Should the cat= parameter be orphaned and then removed? —CodeCat 19:10, 25 April 2013 (UTC)Reply

I have recently added the template_l_xform function to Module:links, which adds section anchors for a specified language to plain ]. Since some tools (like NEC) put plain links into the {{{head}}} parameter, would wrapping that function around it be a good idea? Keφr (talk) 15:04, 13 May 2013 (UTC)Reply

Yes, I definitely think that is a good idea. I was intending to eventually make that the default, so that people would no longer need to add links to the terms themselves, just ] would be enough. —CodeCat 16:41, 13 May 2013 (UTC)Reply

So... what are you waiting for? Keφr 16:25, 18 May 2013 (UTC)Reply

There is a lot of work involved in this. It needs time. —CodeCat 16:44, 18 May 2013 (UTC)Reply

Writing {{#invoke:links|template_l_xform|{{{1}}}|{{{head}}}}} (or similar) into the template is just one edit. What do you mean here? (However I tried to phrase this, it reads awfully snarky. Sorry about that.) Keφr 19:18, 18 May 2013 (UTC)Reply

The problem is how to deal with cases where people have already added links to the headword, either directly or through {{l}} or something else. It is easy to make a template that works, but much harder to make it work with all the usages that currently already exist. Backwards compatibility is difficult. —CodeCat 19:21, 18 May 2013 (UTC)Reply

Well, I would not expect much disturbance here. On #invoke time, the function is feeded with template-expanded wiki markup, so there should be no difference between plain ] and {{l}}. I expect existing uses to be rather simple - short snippets of linked text, maybe some <span> with a class or lang attribute which wraps it. As I wrote it, the function does not touch links with already specified anchors, and depending on the choice of the |autolink= parameter, it may link individual words, the whole phrase, or nothing at all (the last one I would opt for) if no links are present.

Or perhaps I am too optimistic? Keφr 19:36, 18 May 2013 (UTC)Reply

Have you checked what the function would do if you give it something like this ] {{l|en|food}} {{l/en|for}} ]? —CodeCat 19:49, 18 May 2013 (UTC)Reply

Check yourself. Keφr 19:57, 18 May 2013 (UTC)Reply

It looks ok. I think you may want to discuss this in the Beer Parlour too though. —CodeCat 20:00, 18 May 2013 (UTC)Reply

I need a <nowiki /> at the beginnig of the line since the title is sometimes started with "*". --Z 13:25, 4 June 2013 (UTC)Reply

This template isn't currently meant to support reconstructed terms. I suppose that support could be added, but more would be needed than just that. The categorisation and linking would also need to change. —CodeCat 13:27, 4 June 2013 (UTC)Reply

Could this template automatically add sort key for suffixes (i.e. words beginning with a "-")? --Ivan Štambuk (talk) 20:59, 3 July 2013 (UTC)Reply

Done. The template now removes the first - from the default sort key (page name) if present. —CodeCat 21:09, 3 July 2013 (UTC)Reply

Awesome. But, how to invoke that functionality from external templates, e.g. {{sh-suffix}} ? It used to invoke {{infl}}, the former inflection line (now apparently "headword line") template for all that sub-processing, but you've for some reason recently rewritten all of the xx-PoS templates to do sorting, categorization etc. manually.. --Ivan Štambuk (talk) 21:22, 3 July 2013 (UTC)Reply

Suppose maybe I went a little too far with the conversion. I've partially converted back again, so that it uses {{head}} for the headword itself and for the category, but not for all the extra parts. I hope that at some point, all of this will be in modules; it's much easier to make those reusable. —CodeCat 21:28, 3 July 2013 (UTC)Reply

And the same for stripping ־ from Hebrew script suffixes please (and if Arabic has its own hyphen, that too)... —Μετάknowledge^{discuss/deeds} 22:10, 3 July 2013 (UTC)Reply

Hebrew is written right to left. Is the ־ still the first character in the name, in encoding order? —CodeCat 22:25, 3 July 2013 (UTC)Reply

Well, it's the rightmost character. I don't know whether that counts as "first" or not. (PS: Infixes also start with a hyphen, so they need this treatment as well.) —Μετάknowledge^{discuss/deeds} 18:29, 16 July 2013 (UTC)Reply

An initial hyphen is removed from all words, it's not done based on the given part of speech. So it will work in all cases. —CodeCat 18:39, 16 July 2013 (UTC)Reply

{{head|sh|noun}} now generates:

<strong class="Latn headword" lang="sh">блах</strong> <span class="gender"></span> ()]

when it should generate:

<strong class="Latn headword" lang="sh">блах</strong> <span class="gender"></span> ]

without the superfluous '()'. If there is no argument to tr= provided for entries in non-Latin scripts, '()' shouldn't be displayed at all. --Ivan Štambuk (talk) 14:12, 5 July 2013 (UTC)Reply

Fixed. The () wasn't from the transliteration but from the inflections. I had used incorrect code to determine whether the list of inflections was empty (I used the way Python does it, but Lua is different). —CodeCat 14:20, 5 July 2013 (UTC)Reply

{{head}} now automatically links multiword terms, the documentation does not show this. —Saltmarsh 05:25, 16 May 2014 (UTC)Reply

I think it's because there's some disagreement still about how it's supposed to work exactly. —CodeCat 12:31, 16 May 2014 (UTC)Reply

Turns out you can specify g2 even if g isn't specified. Not saying it's a problem, but it is an 'oddity'. Renard Migrant (talk) 22:05, 30 September 2016 (UTC)Reply

It works that way by design, as it simplifies writing templates that use {{head}} somewhat. It works the same way with the inflections: you can skip a few "slots" if a word doesn't happen to have them, while still showing those that are further down. —CodeCat 22:54, 30 September 2016 (UTC)Reply

When writing {{head|cs|passive participle form}}, the template tries to categorize the entry into the category Czech passive participle forms (not founded yet), but not into the category Czech non-lemma forms (see psáni), although with {{head|cs|past participle form}} it works fine. Can this be fixed, please? --Jan Kameníček (talk) 00:28, 3 March 2017 (UTC)Reply

It should just go in "participle forms". There's no need to differentiate them by the type. —CodeCat 00:32, 3 March 2017 (UTC)Reply

I believe it would be much better if they were differentiated, because they are both completely different. I understand that for a native English speaker it may not seem so, as many English verbs have the form when creating both past simple tense or passive voice (such as played), but for Czechs they seem so different that people who are not educated in linguistics would say they do not have anything in common (e. g. psal x psán. --Jan Kameníček (talk) 00:46, 3 March 2017 (UTC)Reply

But why would a person be interested in separating inflected forms of one vs the other? psal and psán are not inflected forms, they are lemma forms, they can be differentiated just fine. —CodeCat 00:48, 3 March 2017 (UTC)Reply

Passive participle forms like zváni can can be used to create both present and past tense (jsou zváni: present passive, byli zváni: past passive). In fact people lacking linguistic education do not call them participles, but "passive voice" (although in fact passive voice is auxiliary + passive participle). Unlike these, past participle forms can be used to create only past active (e. g. zvali jsme). Again, most people do not know that forms like zvali are participles, they call them simply "past tense". It does not make sense if people looking for passive forms have them mixed up together with past participles. Most people would be confused why they are mixed together, when they (in their minds) have nothing in common. --Jan Kameníček (talk) 01:09, 3 March 2017 (UTC)Reply

See Category:Dutch participle forms, which mixes inflections of present and past participles. As for people not knowing that it's a participle; if it's not a participle then it should not be labelled as one, thus it should not go in Category:Czech passive participles nor in Category:Czech passive participle forms. If it is a participle, it should go in Category:Czech passive participles and Category:Czech participle forms. —CodeCat 01:25, 3 March 2017 (UTC)Reply

Well, I cannot see why it is not possible when it would be clearer to non-linguists. Originally I thought it would be just a matter of a couple of minutes to solve it and I still cannot see any obstacle that prevents it. Passive participles are participles, of course, but in Czech they are used in a completely different way than past participles and so non-linguists do not see any connection between them. Such unnecessary mixing does not help. I also failed to understand your suggestion of helping the non-linguists in your last contribution. Jan Kameníček (talk) 01:46, 3 March 2017 (UTC)Reply

Can someone make so that this triggers (genitive:PAGENAME+s)? Because Swedish genitive is very easy. The only exception is when the word ends in s, x or z, then the genitive is unchanged. Nils är cool - Nils is cool, Nils katt är cool - Nils's cat is cool. I see that the category already has been created Category:Swedish proper noun forms but you can't see the forms on the main page. Algeriets is not visable on Algeriet. It's the same principal as {{en-noun}} but with genitive instead of plural. The fact that {{head|en|noun}} doesn't trigger a plural form makes me think that {{sv-proper noun}} must be created for this to work. Am I wrong?Jonteemil (talk) 18:36, 4 July 2017 (UTC)Reply

This template is independent of the language. If you want a template to work in a language-specific way, you should create a template for that language such as {{sv-proper noun}}. —CodeCat 19:04, 4 July 2017 (UTC)Reply

@CodeCat: Ok, thanks!Jonteemil (talk) 19:21, 4 July 2017 (UTC)Reply

On the page for 人, the error "Lua error: not enough memory" appears many times. This seriously affects the usability of the dictionary, as a user would have to look at the source to find any of the information passed through the modules, such as, for example, how the aforementioned character is pronounced in Okinawan. My suggestion is to rewrite the templates to use Scribunto less.

IPv4 Address (talk) 21:39, 8 April 2020 (UTC)Reply

Some characters have alternative text and emoji forms, e.g. ⚪, and different readers will see them differently, depending on their browser/fonts. Could we add a param to append ︎ to the display (for in this case "⚪︎", with VS FE0E), so that all readers will see them as text? kwami (talk) 20:54, 16 May 2022 (UTC)Reply

@Benwing2: Module:gender_and_number seems to be able to handle qualifiers (Module:gender_and_number#L-136) but I currently don't see a way to make use of that using {{head}} (is there?). If the syntax {{head|g=m<q:foo>}} could be used for that, that would be nice. I would have had use for this feature just now in the entry Brocki. — Fytcha〈 T | L | C 〉 16:38, 4 January 2023 (UTC)Reply

@Fytcha Module:headword can handle them but I'm not sure {{head}} supports them, let me see about adding them. Benwing2 (talk) 20:14, 4 January 2023 (UTC)Reply

When we use DISPLAYTITLE, as at M🜨, it won't work if we also use this template. (Conflict identified at Phabricator.) I've starting deleting hte head template, but this might be something to address. kwami (talk) 02:39, 20 March 2023 (UTC)Reply

In case no one reads Module talk:languages, I'll link from here: This template incorrectly adds a capitalized sort key for Georgian. Gradilion (talk) 15:50, 13 April 2023 (UTC)Reply

See calendario dell'avvento vs calendari dell'avvento.

===Noun===
{{it-noun|m}}

{{it-noun}} automagically knows it needs to split "calendario dell'avvento" as "calendario dell'avvento", but

===Noun===
{{head|it|noun form|g=m}}

{{head|it|noun form}} doesn't, and it renders it as "calendario dell'avvento" with a "dell'avvento" red link.

o/ Emanuele6 (talk) 23:54, 30 October 2024 (UTC)Reply