The following information has failed Wiktionary's deletion process (permalink).
It should not be re-entered without careful consideration.
{{suffix}}
template does not have:
{{hu-suffix|egyetem|leg|es|pos=adj}}
{{hu-suffix||izmus|pos=n}}
. This is used in many entries.In the 2013-2014 RFDO discussion Template talk:hu-compound (to delete: {{hu-compound}}
, {{hu-suffix}}
and {{hu-prefix}}
), most people voted "Delete" but only hu-compound was deleted and Wonderfool closed the RFDO as "Kept as nobody's deleted it", which I find unconvincing as a reason for keeping the templates. It should have been: "RFD failed, waiting for all templates to be orphaned".
I did not participate in that discussion; I'd vote delete too.
Rationale:
{{suffix}}
or {{prefix}}
(better yet, in my opinion: {{affix}}
or the shortcut {{af}}
) in all cases.--Daniel Carrero (talk) 23:38, 28 June 2016 (UTC)
{{fi-suffix}}
, {{fi-prefix}}
, {{hi-suffix}}
, {{hi-prefix}}
etc. are allowed but the Hungarian templates are not? Also, I want to keep using hu-suffix for inflected forms, I think the etymology section is useful for agglutinative languages, users might want to click on the suffix to check it out. I do not understand what's the harm in this. --Panda10 (talk) 13:38, 30 June 2016 (UTC)
{{fa-prefix}}
, {{fa-suffix}}
, and {{rom-suffix}}
? --Panda10 (talk) 14:24, 30 June 2016 (UTC)
{{rom-suffix}}
(it was created in 2011 and was being used only in 6 entries: melalo, samtalo, baxtalo, shilalo, rupuno and rupalo){{affix}}
for this language (except for compounds: سیلاب); so, there's an actual need for {{fa-suffix}}
and {{fa-prefix}}
. If we can replace these two by {{affix}}
, I'm for deleting them.{{head|fa|suffix}}
and {{head|fa|prefix}}
, respectively. It's a bit confusing if some languages have the format Template:xx-suffix for actual suffix entries and other use that format for etymologies involving suffixes. --Daniel Carrero (talk) 22:32, 30 June 2016 (UTC)
{{affix}}
can do this as well, so that's not a good reason for keeping {{hu-suffix}}
, in my opinion. --Daniel Carrero (talk) 22:37, 30 June 2016 (UTC)
{{af}}
. This may take some time, though. {{hu-prefix}}
has about 900 entries, {{hu-suffix}}
has about 17,000. Re inflected forms: Adding an etymology section to English forms may have less practical value, since English is not an agglutinative language. It is different in Hungarian where nouns, adjectives, pronouns, and numerals can have more than 34 different inflected forms, verbs much much more. If a Hungarian editor is willing to add this information using {{affix}}
, what's the harm in it? --Panda10 (talk) 23:23, 30 June 2016 (UTC)
{{hu-suffix}}
ignores all suffixes except for the last one. Also, {{hu-suffix}}
has a pos2=
parameter that {{suffix}}
lacks (well, it's there, but it does something else). Finally, I disagree with putting etymologies in inflections. We don't do it for other languages, agglutinative or not. Compare Finnish. In fact, a non-agglutinative language has more use for such etymologies than an agglutinative one, because the affixes are much less obvious and harder to tell apart in a word. —CodeCat 00:22, 1 July 2016 (UTC)
{{hu-suffix}}
: If {{suffix}}
does not have the functionality of {{hu-suffix}}
, then we will have to keep {{hu-suffix}}
, just like we keep {{fa-prefix}}
and {{fa-suffix}}
.{{hu-prefix}}
: I can deal with it manually. Those entries need other standardization, so I'll do them at the same time and I will delete the orphaned template. No need for a bot.{{hu-suffix}}
categorise that way? Surely if the word is suffixed with several suffixes, we'd want categories for all of them, not just the last? And I consider the pos=
parameter to be deprecated, since we now have id2=
that gives finer control and better disambiguation (i.e. by sense of the suffix rather than part of speech of the thus-formed word). The pos2=
parameter is puzzling, as it essentially causes the entry to be categorised twice in two different suffix categories. —CodeCat 14:23, 1 July 2016 (UTC)
{{affix}}
? It makes sense to categorize Hungarian entries by part of speech. About categorizing by the last suffix: sometimes there is no Hungarian word with the middle suffix. E.g.: egyetemleges, there is no *egyetemleg. --Panda10 (talk) 14:51, 1 July 2016 (UTC){{hu-suffix}}
to something else, run the renaming bot, keep all the current functionality and be done with it. --Panda10 (talk) 15:03, 1 July 2016 (UTC)
{{hu-suffix}}
only categorizes by the last suffix? Words like egyetemleges should probably be in both suffix categories (at least if we don't want to start creating entries for "compound" suffixes like -leges). Words derived from an intermediate derivation should by contrast IMO only show the immediate base word, e.g. kérdéses from kérdés, not from kérd or from kér (though those could be of course mentioned in prose in the etymology). --Tropylium (talk) 20:08, 26 August 2016 (UTC)
: Maybe {{af}}
could have built-in language-specific rules, like "for Hungarian, categorize only the last suffix". --Daniel Carrero (talk) 05:32, 27 August 2016 (UTC)
{{hu-prefix}}
. --Panda10 (talk) 12:49, 5 August 2016 (UTC)
{{hu-suffix|festék|es|pos=adj|pos2=n|t1=paint, colour|t2=adjective-forming suffix}}
{{hu-suffix|egyetem|leg|es|pos=adj}}
{{affix}}
supports Persian hyphens. Benwing2 (talk) 22:24, 17 March 2019 (UTC)
{{hu-suffix}}
? Panda10 (talk) 16:01, 18 March 2019 (UTC)
{{affix}}
if necessary. I'm not sure what to do with the issue of creating a category only for the last suffix; you can do that in {{affix}}
by prefixing each suffix that shouldn't be categorized with a ^, but that seems an ugly solution to me. Maybe we should just categorize all suffixes? That's what we do for other languages if two suffixes are given (but the proper solution is to include the intermediate form as a full word if it exists, e.g. internationalization should be analyzed as internationalize + -ation, not as international + -ize + -ation). Benwing2 (talk) 19:21, 18 March 2019 (UTC)
: @Benwing2: The t1 to pos1 etc. conversion is good. Thanks for thinking about it. Occasionally, you may find a tr1 and tr2, those were used by mistake, obviously. I went through Category:hu-suffix with pos2 and it is now empty. You said your code will not touch items in Category:hu-suffix with multiple suffixes and categorization enabled, and that's good because they are somewhat complicated. I'm sure you are aware that nocat=y can also be nocat=hu or nocat=1.
What would the bot do with these:
{{hu-suffix|-e-|d|nocat=y|t1=linking vowel|t2=possessive suffix}}
{{hu-suffix|-i|d|nocat=y|t1=possessive plural|t2=second-person singular personal suffix}}
{{hu-suffix|-l|et|nocat=y}}
?There was another functionality in {{hu-suffix}}
where the first parameter, an actual word, is empty, and only a suffix is provided, e.g.: {{hu-suffix||n|pos=adv}}
. In those cases, an additional + sign was displayed, most of the time unnecessary, but occasionally needed. I'm really worried that I forgot to think about stuff and there is no way to catch them because of the huge volume. I think if the bot encounters something unexpected, it should collect those items in a category, so later I can take a look. Panda10 (talk) 20:04, 18 March 2019 (UTC)
{{affix|hu|^-e-|-d|nocat=y|pos1=linking vowel|pos2=possessive suffix}}
, the second and third similarly, the fourth maps to {{affix|hu|^|-n|pos=adverb}}
. These two uses of ^ were recently added by me to ensure that all uses of {{suffix}}
could be properly mapped to {{affix}}
. Benwing2 (talk) 20:12, 18 March 2019 (UTC)
|nocat=hu
, |nocat=1
, etc., these will be left alone. This param is parsed by Module:parameters; the documentation says "No value, the empty string, and the strings "0", "no", "n" and "false" are treated as false, all other values are considered true." As for tr1=, tr2=, etc. I'll have the script convert those to t1= etc. Benwing2 (talk) 20:38, 18 March 2019 (UTC)
{{hu-suffix}}
; see Special:WhatLinksHere/Template:hu-suffix. These appear to be the same as the entries in Category:hu-suffix with multiple suffixes and categorization enabled plus a few scattered non-mainspace references, which you can mostly ignore (in particular, any page in userspace and any page that is for discussion should be left alone even after the template itself gets deleted). Let's see if we can get rid of the remaining cases. As I mentioned above, you can forcibly disable categorization of a given affix by preceding it with ^
, but we should avoid doing this unless absolutely necessary (and even then, the practice in similar cases for other languages is to let all affixes be categorized). Benwing2 (talk) 02:48, 20 March 2019 (UTC)
^
sign. Can I delete the template and its documentation page? Panda10 (talk) 18:49, 20 March 2019 (UTC)