Module talk:affix

English as the default language

It's a good idea to make this similar to other linking templates, by considering "und" as the default language code, and passing the language code to the first parameter, instead of a named one. --Z 20:34, 3 August 2013 (UTC)

But that would break compatibility, so it would need more discussion and work. Not to mention a new name... —CodeCat 20:42, 3 August 2013 (UTC)

We only need a new title actually. And we eventually should change the title, because "compound" is not a correct word for affixed forms I think. --Z 20:47, 3 August 2013 (UTC)

That's assuming we do merge the templates. That's still far from certain, it's only been a few hours. —CodeCat 20:50, 3 August 2013 (UTC)

Support for other scripts

Other scripts use different characters and rules for hyphen, e.g. in Persian alphabet "ـ" is used, and it shouldn't be used after certain letters, so some prefixes should be displayed without any extra sign. --Z 20:40, 3 August 2013 (UTC)

sc

Regarding

-- TODO: If we can assume that all terms will have the same script,
-- then we can do script detection before calling full_link,
-- rather than letting it try to detect the script for each term individually.

we can move this

        -- Try to detect the script if it was not provided
        if not sc then
            -- Does this language have more than one script?
            -- If not, we can bypass the detection for a speed bonus.
            if langinfo.scripts[2] then
                sc = m_utilities.detect_script(alt or term, lang) or langinfo.scripts[1]
            else
                sc = langinfo.scripts[1]
            end
        end

from Module:links to Module:utilities as a function named say determine_script with arguments lang and sc (optional) and use it in full_link in Module:links and here in Module:compound before calling full_link. --Z 19:44, 5 August 2013 (UTC)

No part of the compound specified

I think it shouldn't be required to specify at least one part of the compound. i.e.

{{compound|lang=ko}}

should return the text 'Compound[[Category:Korean compound words]]' instead of module error. It would be useful because some languages have specific link templates, for example 나가다. Wyang (talk) 00:59, 1 May 2014 (UTC)

But what should the template do if there is nothing to do it with? —CodeCat 01:02, 1 May 2014 (UTC)

Just return the word 'Compound' and place the entry in the corresponding compound category, and allow the user to write the rest. Wyang (talk) 01:08, 1 May 2014 (UTC)

Why would we want to complicate the template just for it to categorise? You can use other things if you want categories... —CodeCat 01:12, 1 May 2014 (UTC)

Like...? Wyang (talk) 01:19, 1 May 2014 (UTC)

{{categorize}}, {{catlangname}} etc. Or even just writing the plain category wikitext. —CodeCat 01:25, 1 May 2014 (UTC)

If done right, it should simplify the template rather than complicate it. --WikiTiki89 01:30, 1 May 2014 (UTC)

I agree. Wouldn't it involve just moving the category section in the code above the test for parts of the compound, and letting 'else' return 'Compound' .. categories? Wyang (talk) 01:52, 1 May 2014 (UTC)

When parts of a word are from different langauges

Suggestion: add a new langs parameter. Currently there is no easy way to do that.

Maybe like this?

langs=la&en

--Dixtosa (talk) 17:33, 26 August 2014 (UTC)

Are words ever compounded as part of the loaning process? —CodeCat 17:37, 26 August 2014 (UTC)

Solution: {{m|la|foo}} + {{m|en|bar}}. --WikiTiki89 18:01, 26 August 2014 (UTC)

That's not a solution as much as it's a workaround. I'd rather know for sure if there are legitimate reasons to add this feature. —CodeCat 18:04, 26 August 2014 (UTC)

It's a solution. What's the point of the {{compound}} template anyway? It doesn't make anyone's lives any easier. The only thing useful it does is categorize. --WikiTiki89 18:14, 26 August 2014 (UTC)

My initial thought: what to do with words like ავღანური (avɣanuri, “Of Afghanistan”)?

This word is formed by unattested ავღანი (avɣani) + -ური (-uri, “[suffix equivalent to -an]”). The first part is surely from Persian افغان (afğân, “Afghan”).

One may be tempted to think of this word as formed by some other word related to Afghanistan (like ავღან-ეთი (avɣan-eti), ავღან-ელი (avɣan-eli)), but this is obviously alogical because at least one of them was first created by suffixing to the foreign word.

P.S. in order to avoid misunderstandings ავღანი (avɣani) is actually a word nowadays, but it is a recent borrowing (from English).

@Wikitiki, And how is your solution going to categorize?

You are wrong that ავღანი (avɣani) is a recent borrowing from English. See the word in Rayfield, A Comprehensive Georgian-English Dictionary, page 50, where ავღანი (avɣani) is glossed as 1. cruel, bad-tempered; 2 (Kiziqi dialect) poor, destitute; 3 (obsolete) Afghan. So your word is formed as {{suffix|ავღანი|ური|lang=ka}}. --Vahag (talk) 19:25, 26 August 2014 (UTC)

If you remove the silly requirement of providing "at least two parts of a compound", then you could do this: {{compound|foo|lang=la}} {{m|en|bar}}. In this case, you can already do this: {{m|fa|افغان|tr=afğân}} {{suffix||ური|lang=ka}}: افغان (afğân) +‎ -ური (-uri). Even if Vahag is right and this does not apply to this particular word, it does apply to other words. --WikiTiki89 19:50, 26 August 2014 (UTC)

Vahag, that does not matter... you get the picture.

Examples again: vexillology, French neologisme, protologism, dynode and many more neologisms that btw are more prone to be mixtures, because it is more like a boss xD. There is also (I think) a very important type of words that have seemingly ordinary affixes, but actually those words predated the emergence of a particular affix. (I am still short of examples but you get the picture again xD).

Actually this type of words have a name. This pdf expands on it.

@Wikitiki89, you are adding categories, making it look like as if compound template were used and stuff, but this is less parsable. The more parsable the better.--Dixtosa (talk) 21:47, 26 August 2014 (UTC)

You mean humanly parsable? My version is definitely more humanly parsable. --WikiTiki89 22:28, 26 August 2014 (UTC)

My preference is to add lang1=, lang2= parameters to the morphology templates. They would specify the foreign language of each term. lang= would still be required, because it would be used to determine how to categorise the entry. For vexillology: {{suffix|vexillum|lang1=la|gloss1=flag|ology|lang=en}}. Is this ok? —CodeCat 23:02, 26 August 2014 (UTC)

I'm satisfied with that, although I'm personally going to continue doing it my way. --WikiTiki89 01:37, 27 August 2014 (UTC)

I've added lang1=, lang2= etc. as parameters to {{compound}}, {{prefix}} and {{suffix}}. —CodeCat 14:46, 27 August 2014 (UTC)

complex nouns?

• колхоз (2 prefixes)
• паровоз (2 prefixes + interfix -о-)

d1g (talk) 17:45, 13 April 2017 (UTC)

Question mark? —CodeCat 17:59, 13 April 2017 (UTC)

I'm not sure which template to use and how exactly d1g (talk) 18:05, 13 April 2017 (UTC)

There aren't two prefixes in these cases. колхоз is an abbreviation. паро- is the compounding form of пар. воз is a stem in and of itself, which is extracted from возить by removing the suffix -ить. --WikiTiki89 18:10, 13 April 2017 (UTC)

If there were multiple affixes you could use {{af}}, which will analyze the pattern of hyphens and categorize appropriately. DTLHS (talk) 18:12, 13 April 2017 (UTC)

I don't think it's necessary to treat паро- (paro-) as different from пар (par) though. The latter automatically turns into the former when it's added to a compound. —CodeCat 18:16, 13 April 2017 (UTC)

That's what I said, isn't it? --WikiTiki89 18:22, 13 April 2017 (UTC)

I don't know. Ignore me, I don't know what I'm doing. —CodeCat 18:59, 13 April 2017 (UTC)

@Wikitiki89, first, I confused "prefix" with "roots" and "stems".

2: according to ru:Словообразование "через соединительную гласную (о, е): корень+корень = паровоз" is similar to speedometer, but I'm not able to find this exact example in -о- (585, 775)

3: which template to use at колхоз and how? d1g (talk) 08:32, 15 April 2017 (UTC)

notext= option?

Could we add a notext option so that the template merely categorizes by suffix, or is it a bad idea? Crom daba (talk) 12:36, 17 August 2017 (UTC)

Don't put ids into generated categories

It might be useful in some cases to keep the default category when linking to a sense id with |id=. Right now it always creates "prefixed with Foo- (id)" – Jberkel 08:29, 22 March 2022 (UTC)

Agreed. The nocat=1 option works, but also removes other categories, which is not desirable. —Justin (koavf)❤T☮C☺M☯ 17:55, 22 March 2022 (UTC)

@Jberkel: Compounds don't generate these subcategories, affixes do, and in the case of affixes I strongly oppose even just making it possible to suppress the more granular categorization on the grounds that we eventually want to put all elements in their respective subcategories, a task for which the parent category serves as a cleanup todo list, see e.g. the RFC in Category:English words suffixed with -er. Furthermore, having an entry in both the most granular category as well as a parent category is usually wrong; for instance, we put English pizza in Category:en:Pizza but not in its parent category Category:en:Foods. — Fytcha〈 T | L | C 〉 21:05, 22 March 2022 (UTC)

Yeah right, but the affix template uses this module. Can you list them all in one page? I think you can have too much categorization, where it's hard to figure out in which categories the entries actually are. On the other hand, I'm not too bothered about red-linked categories. From a usability perspective anchor links are more important, especially for large entries. –Jberkel 21:12, 22 March 2022 (UTC)

Now, id1= adds categories, but not id2n= where n=/=1. E.g. see McShit. Thoughts? —Justin (koavf)❤T☮C☺M☯ 21:17, 22 March 2022 (UTC)

That's normal, only affixes are categorized. Why did you add 3 ids for non-existent sense ids? – Jberkel 21:25, 22 March 2022 (UTC)

Because there were three context labels. Why choose just one of them for the sense id? How do you choose which one? —Justin (koavf)❤T☮C☺M☯ 21:29, 22 March 2022 (UTC)

Because in {{af|en|prefix-|word|-suffix|id1=A|id2=B|id3=C}}, the ID "A" applies to prefix-, "B" to word and "C" to -suffix. Only affixes (such as prefixes and suffixes) get categories; morphemes that are not affixes, such as "dog" and "house" in {{af|en|dog|house}}, do not. 70.172.194.25 21:36, 22 March 2022 (UTC)

I think the lesson learned here is to not mess with stuff, let alone revert others, when one has no idea what's going on. Talk about being confidently incorrect... — Fytcha〈 T | L | C 〉 21:32, 22 March 2022 (UTC)

@Fytcha: Boy, it sure would be nice if you were not condescending and were instead civil and stuff. Why choose one of the labels as id1, then? —Justin (koavf)❤T☮C☺M☯ 01:36, 23 March 2022 (UTC)

Maybe this will help clarify. The number N in idN tells the module which morpheme (either an affix, like pre- or -ing, or a regular word) the label applies to. Only one ID applies per morpheme, it's not like you're stacking them on top of each other. So, for example (using made up senseids), if you had on catfisher:

{{af|en|catfish|-er|id1=fish for catfish|id2=agentive}}

The id1=fish for catfish applies to the word catfish, and disambiguates it from the online slang meaning. The id2=agentive applies to the suffix -er and disambiguates it from other meanings of the suffix (such as the comparative -er in bigger). Both IDs have the effect of making the link highlight the correct sense. However, only the -er would be categorized. This is because, in general, affixes are categorized, but words that make up parts of compounds are not.

In the example you gave (McShit), id1 seemed special because in that example the structure is prefix + word. In the example of catfisher, it is word + suffix, so id2 would be the one that gets the category. If you had another structure like prefix + word + suffix, e.g. *recatfisher, "a person who once more fishes for catfish":

{{af|en|re-|catfish|-er|id1=again|id2=fish for catfish|id3=agentive}})

You could have multiple affix categories, but you would still not have categories for non-affix morphemes. 70.172.194.25 05:02, 23 March 2022 (UTC)

@70.172.194.25: Can you make the changes you suggested regarding |noidcat=? I had more changes reverted by Koavf (talk • contribs) because of "accidental" categorization. The goal of my edits was just to avoid hardcoding fragment links in the HTML. – Jberkel 18:06, 19 April 2022 (UTC)

Well, previously the change I had implemented was to double categorize both with and without the ID. However, I can have a go at implementing the noidcat change if this is deemed preferable. 70.172.194.25 18:09, 19 April 2022 (UTC)

Yes, but the problem are the unwanted category red links, it seems. With your proposed change they'd still be there. Thanks! – Jberkel 18:20, 19 April 2022 (UTC)

User:Jberkel: [1] and [2] should implement noidcat. Whether to move this into the main modules is up to others, but the technical solution is available. 70.172.194.25 19:01, 19 April 2022 (UTC)

Looking at the code, it feels a bit strange to first add the ids to the categories, only to remove them later. – Jberkel 19:40, 19 April 2022 (UTC)

You're right, it's not the most elegant way. But the other way would require modifying all of the affix-specific functions like show_prefix, etc. I could do it the right way, if desired, though. 70.172.194.25 20:42, 19 April 2022 (UTC)

Yes if you can, it'll be less fragile if it doesn't depend on the way the category is formatted. – Jberkel 21:34, 19 April 2022 (UTC)

User:Jberkel, This should work: [3]. The /templates submodule needs the same changes as before. 70.172.194.25 03:10, 25 April 2022 (UTC)

Just to be clear, I have no problem with adding new categories: just make sure that they are part of a hierarchy in the modules and that they are sensible categories to have. Either option is fine with me, but just not redlink cats. Let me know if I can help. —Justin (koavf)❤T☮C☺M☯ 18:28, 19 April 2022 (UTC)

No hyphen for Vietnamese

Vietnamese uses Latin script, but all syllables are (usually) written with spaces in between. Given that affixes are usually separate syllables, they aren’t written together with the base word, so using a hyphen doesn’t make sense. As one can see, almost all entries in Category:Vietnamese suffixes and Category:Vietnamese prefixes are without hyphens. Could the template be edited to give the correct behaviour? Currently, most Vietnamese affixed entries are categorised as compounds, which is not always a good thing. Thank you! MuDavid 栘𩿠 (talk) 01:50, 19 October 2022 (UTC)

Italicize affix

@Benwing2: E.g., {{suffixsee}} results in the text “English terms suffixed with -ly”. The suffix should be in italics (“English terms suffixed with -ly”). J3133 (talk) 00:36, 4 June 2023 (UTC)

@Benwing2: Do you know if this is possible or do I need to clarify? Should I post this at the Grease pit instead? J3133 (talk) 14:11, 7 June 2023 (UTC)

@Benwing2: I found out that it uses the CategoryTree extension, which does not have a way to change the display. J3133 (talk) 15:26, 9 June 2023 (UTC)

@J3133 Thanks and apologies for the delay; I've been traveling. Benwing2 (talk) 21:35, 9 June 2023 (UTC)

Incomplete cats when langs don't match

See for example Proto-Georgian-Zan *s₁owel-. This should be placed into the cat "Proto-Georgian-Zan terms suffixed with *-el". კვარია (talk) 07:10, 29 October 2023 (UTC)