commit 4a16ff2567a535c312b0507d4ca52ee7b16cd8fb
Author: Dominic Mayers <dominic.mayers@meditationstudies.org>
Date:   Wed Jan 3 14:45:18 2024 -0500

    Cite ext: Add a safeguard to avoid processing a second time the ref tags
    
    The previous code contained a safeguard to prevent recursion. This replaces
    it with a similar safeguard with a similar idea, but which allows recursion.
    
    Bug: T22707
    Change-Id: Ifda92ac2cf464b58cf0a8bedd2b1afe149961c31

commit 15fbc658e51659c73e80934e82b79a062237bfeb
Author: Dominic Mayers <dominic.mayers@meditationstudies.org>
Date:   Wed Jan 3 14:10:56 2024 -0500

    Cite ext: Order the notes as they appear in guardedRef()
    
    The order of the notes in <references> sections should
    be the same as the one seen when we parse the page, i.e., the one seen by
    guardedRef(). However, because the recursive calls must be done before
    we store the processed texts in the stack, the order stored in the stack
    is different. The new code keeps track of the order in which <ref> tags
    are seen in guardedRef() in the property numLink. It sends the value
    of numLink before the recursive call to the stack, which stores it as the
    value 'numlink' of the ref array. This is used at the end in formatRefsList()
    to reorder the notes.
    
    Bug: T22707
    Change-Id: Ie3bd2f3407810b19906ac61ffec522c03e61a822

commit 182a1a428b6be8008fd61c3ee122884cf4af9467
Author: Dominic Mayers <dominic.mayers@meditationstudies.org>
Date:   Wed Jan 3 13:34:49 2024 -0500

    Cite ext: Strip empty tags also when searching missing closing tags
    
    The current code search for missing closing <ref> or <references>
    tags  by stripping full tags and searching for remaining opening
    <ref> or <references> tags. That would work, but the regex used
    also matches empty <ref> or <references> tags. The new code strips
    them as well before applying the same regex. Perhaps, a better regex
    would work as well.
    
    Bug: T22707
    Change-Id: I49bb66c62f202ca33ec0279969eeb21314f2319e

commit 0fde4d6d6de4b87abe3b2776b3f267a3dd0c8396
Author: Dominic Mayers <dominic.mayers@meditationstudies.org>
Date:   Wed Jan 3 10:56:16 2024 -0500

    Cite ext: Only increase $ref['count'] in ReferenceStack when the ref is a link
    
    This is self explanatory. The value $ref['count'] should only be incremented
    when the footnote is used by a <ref> tag.
    
    Bug: T22707
    Change-Id: I38c5250b17cf03e71d58634ced2738f831821716

commit 6b80742ea1423fba7dfc28ce95c6f9f610218688
Author: Dominic Mayers <dominic.mayers@meditationstudies.org>
Date:   Wed Jan 3 09:39:26 2024 -0500

    Cite ext: Process nested <ref>s in <references> as ordinary <ref>s
    
    The current code uses $this->inRefTag to prevent recursion: the method ref()
    returns null if it is true and it sets it to true before guardedRef(). This is
    the opposite of what is needed to use the recursive power of the parser.
    This commit gets rid of this and uses $this->depthRef, the level of recursion
    in the processing of  nested <ref> tags to properly manage recursion. It is
    used to distinguisgh ref tags inside a <references> tag that are only footnotes
    (cite_note), i.e, not links (cite_ref), from the ordinary <ref> tags, which
    correspond to links. The nested <ref> tags, even those within a <references>
    tag, are ordinary <ref> tags. They must be recursively managed just like any
    other ordinary <ref> tags. Therefore, the new code sets
    $isLink = ($this->inReferencesGroup === null || $this->depthRef); The property
    $this->isLink is then used in Validator.php to validate differently the
    footnotes in a <references> tag from the ordinary <ref> tags. Note that
    it will not work to use a boolean and set it to false at the end of a level
    of recursion. It is necessary to distinguish the 0th level from the others.
    
    Bug: T22707
    Change-Id: Ie21861a43b55b782e22cb9188bb77b658fafb6d0

commit 3180e9379ea7c9255dbb78e3c8967b6bcad9df54
Author: Dominic Mayers <dominic.mayers@meditationstudies.org>
Date:   Wed Jan 3 00:41:07 2024 -0500

    Cite ext: Use recursiveTagParse in guardedRef, not after the recursion is done.
    
    The current code does not make recursive calls to the parser for each tag
    individually in guardedRef(), but twice at the end, after all ref tags have
    been processed in guardedRef(). Therefore, it does not use the natural
    recursive power of the parser. If these two calls to recursiveTagParse() at
    the end  worked, that will be fine, but they do not and it is not surprising
    that they don't. The logic of recursion in the parser is that the extension
    receives the tag (the parameters and the inner text) and returns the html
    that should replace the tag. This applies also to the processing of the
    references tag(s). The processing of the ref tags is a part of the processing
    of the references tag(s). This is accomplished by storing the processed inner
    texts of the ref tags in a referenceStack. It is necessary that the code does
    the recursive calls in guardedRef() so that the inner text of all nested ref
    tags is processed and stored in referenceStack. The current code tries to do
    the parsing at the end and it adds a few processing of individual ref tags
    there and there to compensate for this lack of recursive calls,  but it simply
    does not work. This commit does two things. First, it adds the required call
    to recursiveTagParse in guardedRef. Second, it removes all other processing
    and parsing of the individual ref tags, except what is expected from the
    extension: the html for the individual links (cite_ref)  returned by guardedRef
    and the html that wraps the recursively processed inner text (cite_note) and
    the html that wraps this list of items returned by  formatReferences. Every
    thing else is done recursively by the parser. There is a small issue: the
    current i18n translation does not create html links (<a href ...) , but wikitex
    links ([[...). The job of the extension is to produce html, not wikitex. So,
    it was necessary to create new entries in the i18n directory. This is part
    of a series of patches. All patches in the series must be applied before we can
    see the result: the correct parsing of arbitrarily nested ref tags.
    
    Bug: T22707
    Change-Id: I1a2619179bde809998d80947e6a4a3b59b86d4c4