Module talk:ar-verb

Module for Arabic verbs
moved from User_talk:Atitarev

Hi, I can help with this. It will be a hard thing to do though, especially if we want to add irregular (mu'tall) verbs as well. --Z 04:12, 28 June 2013 (UTC)


 * Great! We're not in a hurry, though, can take time and do it properly. With Arabic, I can mostly work only from home where I have access to my grammar books with no distraction. Russian is more irregular than Arabic, AFAIK, can you give me a few examples of irregular verbs (excluding hamzated, assimilated and hollow forms, I'm also aware of quadrilateral roots)? Not sure if defective verbs (و or ي as a third radical) are considered "irregular". Working with the Russian module taught me an efficient of dealing with irregularities - just providing and overriding parameter, if they are a few. If an irregularity is common and repetitive, it's a candidate for a new function. Have you seen Module:ru-verb? Hopefully CodeCat jumps in if we get stuck with a technicality problem, even though she never replied. --Anatoli (обсудить/вклад) 04:26, 28 June 2013 (UTC)


 * That was what I meant, not irregular actually, since they are predictable, but we would have to create many functions. The Russian module seems quite big, I guess too that the Arabic one will be easier. --Z 05:19, 28 June 2013 (UTC)

I think we should work on those hard parts first, I mean w ' y verbs etc. for which we don't have conjugation templates (we do have for several hamzated forms though). Ric's templates are working well and I think there is little point in converting them to Lua. --Z 19:01, 28 June 2013 (UTC)


 * Sounds like a plan. At first I wanted to convert but it's not a small job. I should have a bit more time tomorrow. --Anatoli (обсудить/вклад) 07:05, 29 June 2013 (UTC)

Tests
Yes, I got it, I was going to write the same thing here. :) --Anatoli (обсудить/вклад) 11:49, 28 June 2013 (UTC)


 * The test template is Template:ar-conjug-I-test. Some variables are nil, trying to find out why it complains. Will make default values, so that the template doesn't generate errors. --Anatoli (обсудить/вклад) 11:56, 28 June 2013 (UTC)

It works:

gives:


 * Almost fixed, let's work on the forms. --Z 17:03, 28 June 2013 (UTC)


 * With maṣdar:

--Anatoli (обсудить/вклад) 09:51, 29 June 2013 (UTC)


 * Check intrans:

--Anatoli (обсудить/вклад) 10:02, 29 June 2013 (UTC)

conj.I:generate_forms - grouping all conjugations together
Not sure this is a good idea. Now, for each verb form (I-X) and subtype there will be a new function repeating each form? This uses separate function for tenses. E.g. perfective endings are the same for all sound verbs, hamzated (r1 or r2 = hamza), other forms. Some functions could be reused many times. --Anatoli (обсудить/вклад) 13:34, 29 June 2013 (UTC)
 * Of course, we'll need to make more function, which will will uses more than one stem - consonantal and vocalic for hollow verbs or similar. --Anatoli (обсудить/вклад) 13:40, 29 June 2013 (UTC)
 * I guess I had misunderstood your idea, please wait a bit, let me make some other changes. --Z 14:07, 29 June 2013 (UTC)
 * Ok, what about now? Now we should just give value to the stems in conj. .init functions. But in this way, we would have to override and redefine some functions in some cases, because not all verbs have the same "stem" always, e.g. for the root خ و ف: third-person m sg خَافَ xāfa but f pl خِفْنَ xifna --Z 16:19, 29 June 2013 (UTC)


 * Verbs with more than one stem is not a problem, they'll just need another function, which will use two stem parameters, e.g. (خَاف and خِفْ). We still need functions for each verb form (I-X) to create stems and call matching conjugation functions. Some can be reused, some will need to be added. Sorry, I don't understand your latest redesign. You have overwritten many changes I made, including . I'd like to go back to and remove conj. .init.
 * My challenge is not the Arabic conjugation and grammar at the moment but combining Arab forms with transliteration in the display table.


 * In the piece of code you have removed:

-- Format and and add transliterations to all forms for key, form in pairs(forms) do       -- check for empty strings and nil's        if form ~= "" and form then forms[key] = "" .. form .. " " .. "TRANSLIT" .. " "       else forms[key] = "&mdash;" end


 * I need each Arabic form to be matched with its transliteration. "TRANSLIT" in the above has to be replaced with forms_tr[key] where "key" is "3sm-perf", etc. What do you say if I go back to my last working version? I'll go through what it does, if you wish. --Anatoli (обсудить/вклад) 03:33, 30 June 2013 (UTC)

I will ask a question on Grease pit, if you know the answer, answer here please. --Anatoli (обсудить/вклад) 03:42, 30 June 2013 (UTC)
 * We don't need another table for transliterations, I fixed Module:ar-translit, with which we can transliterate forms when we are linking to them when we want to make the table.
 * Regarding the changes, actually it's quite similar to your version, I made some changes only to avoid some duplications in code. Now we should just change the values of stems (and any other variables, if needed) from those init functions. se the  part for example, try seeing the result of  (for imperfect) --Z 05:33, 30 June 2013 (UTC)


 * Shortcuts are fine, what I have problem with is, for each new conjugation form, there must be a new function. "conjugations["I"] = function(args)" was one of them, which did the work specific to one conjugation type (form-Iof of sound verbs) and delegated building endings to generic functions (e.g. "perfective_conj") where possible. I don't know how this is going to work with "init" function. Why did you move all the logic into "init" when it should be split? Are you going to handle all verb types in one big function. Having functions for adding prefixes/endings is not enough, as the middle portion will be different for each type and subtype. --Anatoli (обсудить/вклад) 05:58, 30 June 2013 (UTC)
 * No, that's just for form I. So for form II, conj.II:init will be used and so forth, exactly like before. --Z 06:00, 30 June 2013 (UTC)


 * I see. That was not obvious, though, as there is no conjugation type and self.conj_type variable seems to suggest that this function will handle any type. Let's just call it "init-I".
 * Please work off latest versions, as I now have to put back what you have removed. --Anatoli (обсудить/вклад) 06:10, 30 June 2013 (UTC)


 * Z, could you check the conjugation table, please? Also, the translit module is not giving the expected results (I don't know if it can work eventually, there are problems with initial letters as well, they get doubled - mmaš‎, alif examples don't look good either. --Anatoli (обсудить/вклад) 06:39, 30 June 2013 (UTC)
 * The module apparently works, alif problem is because you didn't used hamzah (أ). --Z 07:15, 30 June 2013 (UTC)

I'm lost
I'm lost now. conj.I:init hardly has anything and ConjugationTable:init(args) does what a function for form should be doing. What's the purpose of ConjugationTable:init? --Anatoli (обсудить/вклад) 06:57, 30 June 2013 (UTC)
 * ConjugationTable:init is a "common" function, which those conj...init functions inherit from it. It's exactly like before, just some duplications are removed. Note that you should not change ConjugationTable:init. --Z 07:21, 30 June 2013 (UTC)
 * I just wanted to make the job easier, but it has made it harder for you, so feel free to revert to the old version (I will perform those changes at the end). --Z 07:31, 30 June 2013 (UTC)


 * Thank you for your efforts, Z. Last night I had guests and then went to bed as I was tired.
 * Your suggestion sounds good to me. I won't be able to contribute if I don't understand the code and I have my own view how to make it. I'll learn more of your tricks while we're doing but I'd prefer no radical changes, which would affect readability (from my point of view). I'm happy to focus on conjugation tables only but before that the basic structure should work. Currently, the conjugation table is incorrect (the layout). Please check the position of كَتَبَا and كَتَبْتُمَا for example? Could you please fix it? I find it hard.
 * With automatic transliteration. Do you feel confident that it can be done well for conjugations, including initial alifs and endings such as كَتَبُوا? I don't mind working on manual transliteration. This can also be done at a later stage (when all conjugations are done) or, as another option, we could without it altogether. Fully vocalised verb forms may be sufficient.
 * I'd like to add existing (Ric's templates) conjugation types as well for consistency, testing. Good functions could be reused or we may decide to convert all verbs to use this module.
 * I'd like to categorise verbs using templates - form-I to form-X, transitive/intransitive, then all irregularities - hollow, assimilated, etc. We can discuss the exact terminology. Happy to take this on.
 * I may be busy this week but I'd like to continue. --Anatoli (обсудить/вклад) 23:29, 30 June 2013 (UTC)
 * The table is fixed. I agree not to work on transliterations (automated/manual) right now (yes I'm sure we can automatically do that; but lets discuss on this at the end when we finished working on all forms). --Z 07:12, 1 July 2013 (UTC)

geminate
--Anatoli (обсудить/вклад) 13:14, 4 July 2013 (UTC)
 * Now . Benwing (talk) 00:40, 30 August 2014 (UTC)

Stems
For some forms and roots the prefixes are a bit different (their vowel is "u" instead of "a") also some forms don't have initial hamza in imperative, we can't create these forms with current functions. --Z 19:10, 11 July 2013 (UTC)


 * Sorry, missed your post.


 * Do you mean the intial vowel for imperatives in form-I? I have already added the code to determine the initial vowel (after the alif) based on the middle vowel, for "a" and "i", the initial vowel is "i", for "u" it's "u":

-- determine the imperative vowel based on imperfect vowel local imper_vowel = "a" if impf_vowel == "a" or impf_vowel == "i" then imper_vowel = "i" elseif impf_vowel == "u" then imper_vowel = "u" end

-- imperative stem local imper_stem = alif .. dia[imper_vowel] .. rad1 .. rad2 .. dia[impf_vowel] .. rad3


 * If it's not what you meant, please give an example. --Anatoli (обсудить/вклад) 06:44, 13 July 2013 (UTC)


 * I mean assimilated verbs, for example, m sg imperative of : (there's a similar problem for imperfective of some verb forms, e.g. IV: yuf3ilu) --Z 19:30, 13 July 2013 (UTC)


 * Form-I function is obviously for sound verbs only. Assimilated, hollow, etc. will get their own functions. There's a lot to do. --Anatoli (обсудить/вклад) 00:23, 14 July 2013 (UTC)


 * But in this way we would need a lot of functions, I think we should consider hamza as part of the root for imperative (as well as that initial vowel as in yuf3ilu for imperfect). --Z 09:37, 14 July 2013 (UTC)


 * I think it's OK t have a lot of functions, reusable parts can be copy-edited or separated into reusable function. Any grammar book will have separate tables not only for forms I-X but also for doubled, hamzated, assimilated, hollow, and three versions of defective verbs. Plus quadrilateral verbs, doubly weak, hamzated and weak, completely irregular, etc. I've started working on "conjugations["I-geminate"]", only have done perfect and imperfect. Haven't been very productive lately, sorry :) --Anatoli (обсудить/вклад) 10:47, 14 July 2013 (UTC)

Module:ar-verb needing testing, work, use of new
Moved from Beer_parlour/2014/August

I've done lots of work on Module:ar-verb. Currently all verb forms I through VI plus quadriliteral Iq/IIq are implemented in all weaknesses (sound, assimilated, hollow, defective, geminate, assimilated+defective), except for hamzated verbs. There is a template that uses the module. It takes the form as the first argument followed by the radicals and then past/non-past vowels (for form I). It automatically determines the weakness from the radicals but you can override this to force interpretation as a sound verb. Detailed documentation is found in. Any help would be greatly appreciated. There's still forms VII to X to do as well as individual override parameters and changes for hamzated verbs -- I've documented thoroughly how to do this in the comment at the top of the module. I could definitely use help testing the various combinations of form and weakness and verifying that the conjugations are correct. Benwing (talk) 03:53, 28 August 2014 (UTC)
 * It now handles forms VII - X as well. Working on hamza support. Benwing (talk) 08:35, 28 August 2014 (UTC)
 * Hamza support is largely done. The big thing now is testing and using the new in verb lemmas (i.e. adding conjugations to the verbs). BTW what is the fastest way to automate this? I've used AWB but there may be better ways. Are there any JavaScript tools to do something like this, and if so, how do they work? I'm not very familiar with JavaScript and Wiktionary (or Wikipedia). Benwing (talk) 23:14, 28 August 2014 (UTC)
 * What is it you want to automate? DTLHS (talk) 23:28, 28 August 2014 (UTC)
 * Adding conjugations to Arabic verb lemmas. Benwing (talk) 00:03, 29 August 2014 (UTC)
 * There's pywikibot, if you like python. DTLHS (talk) 00:27, 29 August 2014 (UTC)


 * You can probably use AWB and ask AWB experts at Grease pit/2014/August about how to replace something like  with  . The changes seem straightforward. For entries missing conjugation tables, such, especially form-I verbs, it can't be automated without making prior knowledge of supplying present tense vowels, transitivity and verbal nouns. Again, you need AWB, I think. --Anatoli T. (обсудить/вклад) 01:30, 29 August 2014 (UTC)
 * You're right that changing existing conjugations isn't too hard; in AWB you just use the appropriate regexes. I guess I was thinking of having it guess the radicals and even the form from the headword, which can be done with a fair amount of accuracy, although there are cases where it can't be done without knowing the form and even then of course it can't guess the past/non-past vowels in form I. But something semi-automated could help a lot. Benwing (talk) 03:45, 29 August 2014 (UTC)


 * The first test, a sound verb, intransitive, form-I. It looks good, only the entry got into Category:Link with section, meaning there's a link with #. --Anatoli T. (обсудить/вклад) 00:24, 29 August 2014 (UTC)
 * I don't understand this. The link for the 3rd-person masculine perfect form has a #Arabic anchor in it, but that's to be expected, right? I checked and there's no place that the code itself inserts this anchor; it must come from the call to full_link in Module:links. Benwing (talk) 03:30, 29 August 2014 (UTC)
 * I don't know either. Module:ru-verb doesn't have this problem, even if it uses explicit #Russian. --Anatoli T. (обсудить/вклад) 03:43, 29 August 2014 (UTC)


 * BTW what do you think about the possibility of inferring the consonants from the headword, assuming you specify the form but leave out the radicals? This won't work perfectly for form I but it should for all the others, and might make adding conjugation tables easier. Benwing (talk) 03:39, 29 August 2014 (UTC)


 * If you can do it and cater for hollow/defective verbs separately (supplying either "y" or "w" as R2 or R3), I don't see why not. Geminated should also work (R2=R3). --Anatoli T. (обсудить/вклад) 03:47, 29 August 2014 (UTC)
 * This is now done. It's enough to specify the form and it will infer the radicals from the headword. The only issues are with form I of course especially hollow verbs where wāw is automatically assumed (but could be a y), and form VIII beginning with itt-, which is assumed to have a t radical but could be a w or y. For augmented-form hollow and defective verbs a wāw is automatically assumed, but in this case it doesn't matter because the conjugation is the same regardless of whether the root is w or y. Benwing (talk) 06:01, 29 August 2014 (UTC)
 * I've now changed the order of arguments to so that past/non-past vowels come first in Form I, before the radicals. The idea is that radicals will almost always be omitted so don't have any numbered params that come after the radicals. Benwing (talk) 08:58, 29 August 2014 (UTC)
 * The intrans= argument now should be either yes, y, 1 etc. for an intransitive verb with no passive, prep for an intransitive verb with a prepositional object and hence an impersonal passive, or no, n, <tt>0</tt> etc. for a transitive verb with a passive. Default is transitive except for forms VII, IX, XI - XV and IIq - IVq where it's intransitive, and form VI where it's intransitive w/prepositional object.
 * BTW I'm probably going to change things so that there's a <tt>passive=</tt> argument where you directly specify whether something has a passive or an impersonal passive, and then have a separate intrans= argument that's just yes or no and takes its default from the passive= value. The "passive through preposition" is a misleading way of specifying an impersonal passive. Benwing (talk) 11:22, 29 August 2014 (UTC)
 * This is done. Benwing (talk) 12:03, 29 August 2014 (UTC)
 * Why does transitivity matter if you already have a <tt>passive=</tt> parameter? --WikiTiki89 14:05, 29 August 2014 (UTC)
 * It was there before, and puts the verb into a transitive or intransitive verb category. It also used to display the transitivity in the title, although I see you removed it. Benwing (talk) 00:45, 30 August 2014 (UTC)
 * The category should be added by the on the definition line. No need to duplicate it in the conjugation table. I think we can entirely remove this parameter. --WikiTiki89 13:29, 30 August 2014 (UTC)
 * The only thing about that is it requires duplicating the declaration on the defn line when it's already available elsewhere. Benwing (talk) 21:30, 30 August 2014 (UTC)
 * Where is elsewhere? The definition line is the place where transitivity is supposed to be indicated. Especially since it is possible for a verb to have multiple definitions, some of which are transitive and some of which are intransitive. The conjugation table only needs to know whether to omit the passive, regardless of the reason it needs to be omitted. --WikiTiki89 21:41, 30 August 2014 (UTC)
 * OK, I see what you mean. As I side note, is there such a general Wiktionary category as "transitive through a preposition"? This is like "speak to X" or "dispose of Y" where X and Y are thematic arguments in English and Arabic and hence can be passivized. In English we say "it was spoken to" or "it was disposed of"; in Arabic an impersonal passive is used that can vaguely be rendered "There was a speaking to X" or "There was as disposal of Y" where in place of "There was a speaking" or "There was a disposal" there'd be an impersonal passive -- identical in form to the normal 3sg masc passive but with no subject. It doesn't really do justice to call these uses "intransitive" IMO. Benwing (talk) 11:29, 31 August 2014 (UTC)
 * Can you give an example in Arabic? There is no need to circumvent Arabic with English. --WikiTiki89 16:22, 31 August 2014 (UTC)
 * جاء بالفلوس "he brought the money" lit. "he came with the money". For this reason the verb جاء "come" forms a passive (impersonal). Similarly احتاج إلى الفلوس "he needed the money" lit. "he needed to the money". These verbs/usages may be grammatically intransitive but semantically transitive. Benwing (talk) 18:46, 31 August 2014 (UTC)
 * I was hoping for an example of the passive. --WikiTiki89 01:29, 2 September 2014 (UTC)

From John Mace "Arabic Verbs" p. 58: يُشَكُّ فِي أَرْقَامِنَا "Our figures are doubted" where the active would be يَشُكُّونَ فِي أَرْقَامِنَا "They doubt our figures" or whatever. شَكَّ "to doubt" is transitive through the preposition فِي. Benwing (talk) 06:29, 3 September 2014 (UTC)
 * I see, it makes sense to me now. I actually think that this proves that we should not consider them to be transitive. The passive of a transitive verb takes the verbs object as a subject instead, but here this is not the case since the passive is taking it as an object as well. I think this shows that intransitive verbs can have impersonal passives, and I think that applies even when the intransitive verb does not take any sort of object at all, even through a preposition. To help clarify, the example you just gave can be thought of as (active) "They have doubt in our figures" vs (passive) "Doubt is had in our figures". --WikiTiki89 12:20, 4 September 2014 (UTC)
 * If passive forms are available, we should make them transitive, IMO. Otherwise, we could just stick to to "|passive=y" without adding transitivity categories. --Anatoli T. (обсудить/вклад) 23:21, 31 August 2014 (UTC)
 * Also, I think we should move this discussion to Module talk:ar-verb. It really isn't BP material. --WikiTiki89 14:24, 29 August 2014 (UTC)
 * Moved. --Anatoli T. (обсудить/вклад) 01:37, 3 September 2014 (UTC)

Variant forms no longer working
in the entry for isn't displaying its second Form I form and meaning, and I wasn't able to add a second Form I verb at  either. (I just merged the two meanings and their respective verbal nouns.) Could someone try to fix this;, perhaps? — Eru·tuon 19:59, 10 November 2016 (UTC)

Hmm, it's working now. I must have just been imagining things. — Eru·tuon 20:18, 10 November 2016 (UTC)

But there's another problem at : when I try to add a second Form I, the module function behind  that ب ي ن is more than 3 letters. Huh? — Eru·tuon 20:23, 10 November 2016 (UTC)
 * Pinging . --Anatoli T. (обсудить/вклад) 20:54, 10 November 2016 (UTC)
 * I'll take a look. Benwing2 (talk) 00:26, 12 November 2016 (UTC)

Jussive/subjunctive forms of verbs missing final alef
I noticed that all verbs that I have looked at that should end in وا only end in و when ar-conj is called. You can see the problem with a verb like كتب. I looked at the code, but I don't think I know enough coding to be able to make this change to the module. It seems like it should be a pretty simple fix though.

Rypervenche (talk) 23:42, 27 December 2016 (UTC)


 * Hi. Can this be fixed, please? --Anatoli T. (обсудить/вклад) 00:36, 28 December 2016 (UTC)
 * Done. Unfortunately a long time ago I created a bunch of verb non-lemma forms using the broken forms, which will be annoying to fix. Benwing2 (talk) 09:39, 2 January 2017 (UTC)
 * I wonder why I never noticed this before. --WikiTiki89 19:01, 9 January 2017 (UTC)

Haplology
I decided on a whim to add categories for haplological forms. That's unrelated to Arabic conjugation, but I was looking at the Wikipedia article on the phenomenon, and it says that in Classical Arabic, from , is simplified to , making it identical to the same form of. Rather puzzling, because I had learned, for instance, the form, with no haplology. Perhaps haplology does not occur in Modern Standard Arabic, but does occur in some Classical Arabic writings; maybe the Qur'an. Wikipedia cites a chapter in a book I do not have:. — Eru·tuon 04:40, 3 January 2017 (UTC)
 * FWIW that book is an amazing reference. Benwing2 (talk) 06:56, 4 January 2017 (UTC)

Non-past forms in root entries
Hi, non-past forms is an indispensable piece of info. necessary to conjugate verbs, so it should be added in the root entries. Is there an automatic way to do so? Thank you in advance. Backinstadiums (talk) 21:02, 23 January 2017 (UTC)

, what do you think? Should non-past forms be shown in root entries? — Eru·tuon 20:31, 24 January 2017 (UTC)
 * I really don't see the point in having them there. Root entries are meant to point to various entries from that root, not to be a grammar reference. --WikiTiki89 20:46, 24 January 2017 (UTC)
 * Which root entries are being referred to? The non-past is already listed in the headword of each verb. Are you referring to entries like ك ت ب? It's not clear to me that they need to be there. They could be added but it would be a certain amount of work for form-I verbs because the non-past vowel(s) would have to be included. Benwing2 (talk) 04:12, 25 January 2017 (UTC)
 * The entry for ك ت ب, for example, shows both their active and passive participles, which can always be formed following the general patterns, unlike what happens with the verbal nouns and the vowel of the middle consonant from the non-past form, especially فَعَلَ. Backinstadiums (talk) 10:46, 25 January 2017 (UTC)
 * I like the idea of showing non-past terms in root pages, and in the titles of conjugation tables. What if they were included, and assigned a class? Then MediaWiki:Common.css can make them not display by default, but if someone wants to see them, they can add a style specification to their common.css, as is done with serial commas . — Eru·tuon 05:09, 25 January 2017 (UTC)
 * (But I'm not sure precisely how this would be done. The function in Module:links, which is used in the verb forms function of this module, doesn't have an argument for invisible forms.) — Eru·tuon 05:13, 25 January 2017 (UTC)
 * It's not that anyone would want to shield their eyes from them, but that the work it would take to get them there is not worth the benefit. In fact I see no benefit to having them on the root pages. The title of the conjugation tables might be useful, but then again they are already shown in the headword line. --WikiTiki89 23:46, 25 January 2017 (UTC)

Behaviour of template differs in this example
Example at ء ي س. It gives me when I use the automated derivation the strange forms:

Form I: آسَ‎ (ʾāsa, “to give up hope”)

Active participle: آئِس‎ (ʾāʾis) Passive participle: مَئِيس‎ (maʾīs)

[…]

Form IV: أَآسَ‎ (ʾaʾāsa, “to lead into desperation”)

Verbal noun: إِئَاسَة‎ (ʾiʾāsa) Active participle: مُئِيس‎ (muʾīs) Passive participle: مُؤَاس‎ (muʾās)

The correct forms are now given by manual specification and automatically correct in and in. I notify  because there is presumably a wrong order in the application of grammar rules. That there exists a form with -ayi- is irregular admittedly, one expects -ā- as in the present of hollow VIIIth stem verbs. But for the IVth stem I would expect Arabic to apply the rule the /ʾVʾ/ ⭢ /ʾV̄/ first – because /ʾVʾ/ is altogether impossible in Arabic, you see it is physically vexing too, while other phonetic rules allow exceptions for alignment to paradigms (as for example it is the case for all IInd and Vth stem verbs of a root with wāw as second consonant which would have yy by applying historical phonological rules but have ww, see for example the present and  from ; or well-known adjectives of the pattern CayyiC where the second root consonant is wāw). ء و ي works however automatically, and ء و م is apparently correct too. Fay Freak (talk) 11:30, 4 September 2018 (UTC)

Stylesheet
I've moved much of the CSS for the table to Template:ar-conj/style.css, which is transcluded along with the table using TemplateStyles. So the colors of the headers and such things can be edited there. — Eru·tuon 01:02, 6 September 2018 (UTC)

V and VI with t- instead of ta-
I have just added a notice about this occurence in. contains a poem with the V-form. I also remember darkly the Saudi IP once adding such a form without the usual templates. Currently the modules are not capable of these forms. It might be indicated to add two new classes to V-sound, V-final-weak, VI-sound, VI-final-weak, VI-geminate and family. Fay Freak (talk) 02:32, 14 February 2019 (UTC)
 * How frequent are these forms? If they're only occasional poetic forms, it might be enough just to mention them in usage notes on the corresponding page. Also, your example shows complete assimilation of t- to the following consonant, which isn't the same as what happens in form VIII. This suggests to me that this might be merely an attempt to represent in writing an assimilated pronunciation. Benwing2 (talk) 02:42, 14 February 2019 (UTC)
 * OK, I see by what you added that this might be a regular feature of one of the dialects of the pre-Classical language. Benwing2 (talk) 02:43, 14 February 2019 (UTC)
 * Found the IP entry I have talked about:, . Fay Freak (talk) 14:54, 5 April 2019 (UTC)
 * seems to be another example. — Eru·tuon 23:12, 23 November 2019 (UTC)