Template talk:affix

Compounds

I think this should also replace {{compound}} and something like this should categorize into Category:Armenian compound words and Category:Armenian words interfixed with -ա-. --Vahag (talk) 06:30, 28 August 2014 (UTC)

It works now. (By the way, it also worked in the previous version of this template, which used Module:affix. I have no idea why this was removed.) — Keφr 09:54, 6 September 2014 (UTC)

Thanks. So {{compound}} is now redundant to {{affix}}? We should probably rename the latter to something more general. “Word formation” is the catch-all term, but it is long. --Vahag (talk) 10:08, 6 September 2014 (UTC)

Different syntax aside, yes. Maybe {{formed as}}? — Keφr 10:20, 6 September 2014 (UTC)

Or {{morphology}}, because the new template will replace everything in Category:Morphology templates. We should probably discuss this in Beer Parlour but I don't like going there. --Vahag (talk) 10:29, 6 September 2014 (UTC)

Not everything; there is no way it could replace {{circumfix}}, for one. At least not without some bizarre syntax. (And frankly, neither do I.) — Keφr 10:46, 6 September 2014 (UTC)

Should signal error when there's only one part specified

Since affixes are affixed to something, this template should expect at least two parts. If not, it has been misused, e.g. like this:

{{affix|en|mono-}} + ...

When this happens, the template should display an error and put the page in an error category so mistakes can be found more easily.

This has been discussed before. {{affix|en|mono-}} + ... is often useful if the formatting of the stuff that comes after is not adequately supported by {{affix}}. --WikiTiki89 17:21, 15 August 2016 (UTC)

In that case affix shouldn't be used at all, because using affix like that results in category problems, like sorting it wrongly, and not adding all correct categories, while not making this evident. And in this case there is hardly any benefit to using affix to begin with.

And if it has been discussed before, there's no sign of it. If a single-part affix call is valid, then the documentation needs to call this special case out, complete with all the extra things you need to do to avoid the problems you're going to get. And I think there should be an extra parameter that you need to specify, a single-part override, to suppress the error. Because I still think that usually a single-part affix call will be a mistake.

Documentation needs better guidance for non-straight glosses

The documentation is clear enough about what to do with ‘straight’ glosses, like: “longsword”, but not what to with glosses like: suffix for names of fish. In that case the quotation marks (“ ”) are inappropriate. Using the posN parameters at least seems to give better formatting, but is this really the right way to do this?

Yes. That's how the parameter is often used as far as I know. It's not strictly wrong either, if you write "suffix for names of fish", then at least the "suffix" part of it does describe the part of speech. —CodeCat 17:40, 15 August 2016 (UTC)

But "suffix" is not really a POS. --WikiTiki89 17:45, 15 August 2016 (UTC)

Hence my request for more guidance. If POS is for POS and suchlike rather than only POS, I'm fine with that, but it should be in the documentation. And if it isn't, I think there should be a parameter for non-straight glosses.

To be fair, the documentation of this template points to that of {{l}} to avoid having to explain the same thing in multiple places. So that's where the explanation should be given. —CodeCat 17:52, 15 August 2016 (UTC)

We should add a new parameter to {{l}} et al. for non-gloss glosses. --WikiTiki89 17:54, 15 August 2016 (UTC)

‘non-gloss glosses’ Hihi, that made me smile.

CodeCat, {{l}} didn't explain it either. Furthermore, I believe in being explicit in these matters, if only for user-friendliness, but also because it helps maintainability. (Suppose the meaning of an argument of {{l}} has to be changed for whatever reason. If the affix documentation just points there, then this changes the meaning of the affix argument. And I think it's too easy to mishandle the resulting cascade. I'm not saying it cannot be handled correctly, but experience with documentation in another field of expertise has made me cautious in such matters.)

{{affix}} actually just forwards these parameters to the same module (Module:links) that also handles {{l}}. So if Module:links is changed, {{affix}} is too. This is done by design, to keep things consistent. —CodeCat 18:25, 15 August 2016 (UTC)

If that's your choice then that's your choice I guess. Still doesn't change the fact that the documentation of this template isn't at all user friendly (just imagine that you don't know the parameters of {{l}} by heart and read it) and that there's no guidance on what do do with these kind of glosses.

Ignores nocat=1 when a langN parameter is set

Right now, the template ignores nocat=1 when a langN parameter is set, see for example this revision. I would change this myself except this involves edits that need to be simultaneous to Module:compound, Module:etymology, and Module:etymology/templates which are very widely used so I'm hesitant.

Changes would be as follows: In Module:etymology, add a nocat parameter to format_borrowed and make it not categorize around line 157. Then set Module:etymology/templates nocat to false on line 213. And in Module:compound, add a nocat parameter to link_term, set it to nocat everywhere link_term is used, and set nocat to nocat in format_borrowed on line 25. —Enosh (talk) 18:45, 25 September 2016 (UTC)

two parameters to maintain incomplete morphology

 I was told not to use this template for morphology

• I'm using "incomplete=yes" when exact rule wasn't known or too ambiguous to find exact rule or section (one-letter *ffixes or similar)
• I would like to have "assuming=text" when grammar of the language isn't known or imprecise in exact case. d1g (talk) 17:15, 18 April 2017 (UTC)

Adding lit parameter for entire term

I'm proposing the addition of a lit= parameter which applies to the entire expression (cf. montón and others). – Jberkel 09:54, 15 January 2018 (UTC)

Allowing lang= parameter

This is just a parameter I'm used to. Please allow "lang=" to be used instead of just the first parameter being the language code. I screw this up almost every time and it's annoying. PseudoSkull (talk) 19:56, 9 April 2018 (UTC)

|gN=

Hey can someone add |gN= to this template? @Kephir, Wikitiki89, Erutuon --{{victar|talk}} 18:28, 21 January 2019 (UTC)

What is it needed for? —Rua (mew) 20:03, 21 January 2019 (UTC)

To add gender and number to elements. --{{victar|talk}} 22:23, 21 January 2019 (UTC)

But when would you need that? It hasn't been needed so far. —Rua (mew) 22:34, 21 January 2019 (UTC)

I've ran across several entries today that had to use |pos=pl. and |pos=m. as sub-ins for |g=p and |g=m. Most of those cases for for gendered and suffixes and roots from plural forms. --{{victar|talk}} 23:29, 21 January 2019 (UTC)

Too much categorizing

If three or more affixes are template arguments, all lead the entry to be categorized as 'prefixed by' or 'suffixed by'. That seems wrong. Is that not considered a problem? DCDuring (talk) 12:18, 2 November 2019 (UTC)

Undesirable addition of "Category:English twice-borrowed terms"

@Erutuon, Rua: I have been trying to think of a way to indicate that an English suffix (or prefix) has been added to a word in a foreign language, and realized that I can use {{affix}}, like this:

{{affix|en|βρυχή|lang1=grc|t1=grinding of teeth|-ism|lang2=en|pos2=''suffix forming {{glossary|noun}}s indicating a tendency of action, behaviour, condition, or state''}}

I had used |lang2=en to show that the suffix is English and not Ancient Greek, but doing to causes the template to add "Category:English twice-borrowed terms" to the entry page which is not desired. Adding |nocat=1 has no effect. Any ideas on how this can be fixed? — SGconlaw (talk) 10:23, 19 March 2020 (UTC)

Why are you italicising pos2=? It shouldn't be used like that. —Rua (mew) 12:24, 19 March 2020 (UTC)

@Rua: to indicate it's a non-gloss definition, following the formatting used by {{non-gloss definition}}. — SGconlaw (talk) 15:36, 19 March 2020 (UTC)

Ok, but that template actually formats differently, and in any case it's for formatting definitions, there's no such formatting outside of definitions. —Rua (mew) 16:32, 19 March 2020 (UTC)

Hmmm, OK. — SGconlaw (talk) 20:47, 19 March 2020 (UTC)

Please don't use that formatting. Use {{der}} on the Greek term, then {{affix}} on the suffix. PUC 13:35, 19 March 2020 (UTC)

I tried that, but it doesn't solve the addition of "Category:English twice-borrowed terms". If a change to {{affix}} or {{suffix}} is thought to be unwarranted, then I suppose I should use:

+ [[w:English language|English]] {{m|en|-ic}}

and manually add "[[Category:English words suffixed with -ic]]". That seems rather long, though. — SGconlaw (talk) 15:36, 19 March 2020 (UTC)

One solution is just to remove |lang2=en, which will make the template only add the "borrowed derived from Ancient Greek" category. Having |1=en and |langN=en has basically the same behavior as {{bor|en|en|...}}, adding the "twice-borrowed" category. — Eru·tuon 17:17, 19 March 2020 (UTC)

@Erutuon: however, then the language label "English" doesn't appear. I am trying to find a way to have the label displayed, otherwise the output is, say, "Latin [x] + [suffix -y]", which might be interpreted as meaning -y is a Latin suffix. — SGconlaw (talk) 20:46, 19 March 2020 (UTC)

@Sgconlaw: I see. Perhaps the templates could add a language label when the previous term is from a different language. — Eru·tuon 04:34, 20 March 2020 (UTC)

Failure to include categorization by terminal suffix

At [[dydrogesterone]] {{affix}} failed to place the entry in the appropriate "suffixed by -gesterone" category, forcing hard categorization. Is this some kind of delay in updating categories because we are using modules rather than templates to categorize or is it a logic error in the module? (Please ignore the question of whether -gesterone is really a suffix.) DCDuring (talk) 03:16, 23 December 2020 (UTC)

Nevermind. I'm not sure about the cause of the problem, but it's gone now. If there is a problem, we'd need a better example. DCDuring (talk) 03:19, 23 December 2020 (UTC)

lang= (or <lang:>)

I saw on an entry that uses this parameter but somehow they made it so that the output text didn't display the language name before the 2nd component because it was the same as the 1st component of the compound, but I forgot how they did it. Anyone know how that works? I couldn't find the explanation anywhere. Orexan (talk) 07:24, 25 August 2023 (UTC)

Etymology languages

Why doesn't this template support etymology languages? Is it outside the realm of possibility that a word was compounded in a prior form of a language?? It would be helpful for Persian, since so many words were compounded in classical Persian and the modern pronunciations of classical words has changed regionally. سَمِیر | Sameer (^{مشارکت‌ها} • ^{با مرا گپ بزن}) 18:06, 26 August 2023 (UTC)

@Sameerhameedy Hi, did this ever get fixed? If not it should be an easy fix. Note that in general the developers don't always monitor talk pages like this; it's better either to post in the Grease pit or ping the relevant people. Benwing2 (talk) 23:40, 27 April 2024 (UTC)

Stripped Korean capitalization?

^ is not working in {{affix}}:

• {{affix|ko|^힌두|-교(敎)|t1=Hindu}} → 힌두 (hindu, “Hindu”) +‎ 교(敎) (-gyo)
• {{compound|ko|^힌두|-교(敎)|t1=Hindu}} → 힌두 (Hindu, “Hindu”) +‎ 교(敎) (-gyo)

@Theknightwho, Benwing2. —Fish bowl (talk) 23:36, 27 April 2024 (UTC)

@Fish bowl I think this was due to a recent change by User:Theknightwho. I saw something of this sort go by. I suspect they didn't realize it would break Korean. Benwing2 (talk) 23:39, 27 April 2024 (UTC)

@Benwing2 @Fish bowl Hmm - I removed ignore_cap from Module:links and Module:links/data recently, which was only enabled for Korean, but that was just a really old (hacky) way of making sure that ^ didn't carry through to Korean links/transliterations, and was completely redundant. If removing that was the cause, it would've caused problems everywhere.

I'll see if something else might be behind it. Theknightwho (talk) 23:48, 27 April 2024 (UTC)

@Benwing2 @Fish bowl It only happens if the ^ is initial - could this be related to hyphen-stripping? Theknightwho (talk) 23:49, 27 April 2024 (UTC)

@Fish bowl @Theknightwho Hmm. ^ has a special meaning in {{affix}} that clashes with this use case in Korean. See the documentation of {{affix}}. Not sure how to fix this other than to change the use of ^ in one of the two places. Benwing2 (talk) 00:49, 28 April 2024 (UTC)