Remediate Modernized Texts

Related Chapters

Priorities for Remediating Modernized Texts

When you are remediating a text, flag anything you think may be a mistake (typos, misplaced punctuation, etc.) by adding an XML comment. Do not make changes to the text without consulting an experienced team member first. Remember that it is not our work to edit the play.

Give Credit in the Metadata

Add a <respStmt> element for the LEMDO team in the TEI Header of the document. For exact practice, see Practice: Give Credit to the LEMDO Team. Record your particular contributions to the remediation of the edition by adding <change> elements under the <revisionDesc> .
Note: LEMDO Director Janelle Jenstad is responsible for liaising with the editor and/or anthology lead to ensure the rest of the metadata in the <teiHeader> is correct. However, if you notice anything that is obviously missing or problematic, leave an XML comment.

Update Document Status: In Progress

Each time you begin remediating a document, you must change the value of the @status attribute on the <revisionDesc> element.
For documents that began life in IML, change the value to "IML-TEI_INP".
For documents that began life as TCP files, change the value of "TCP-TEI_INP".
For documents that began life in the CWBJO or DBF project, change the value to "TEI_INP".
These values indicate that your remediations are in progress and trigger the full schema and Schematron on your file. Given that it often takes multiple work sessions to remediate a file to the point that it is fully valid by LEMDO standards, we have a special interim status that allows us to commit an invalid file to the repository without breaking the build. Interim status values are "IML-TEI", "TCP-TEI", and "TEI_collating". Use the latter value for CWBJO and DBF files (and any other files that have come to us in some flavour of TEI). You may save the file that you are working on with an interim status value if your file is not valid at the end of a work session. Once it is valid, save and commit your file with the "IML-TEI_INP" status.
Documents that have been converted from IML to TEI, TCP to TEI, or TEI to TEI using the LEMDO programmatic conversions will have the @status value of either "prgGenerated" or "IML-TEI". In the latter case, there should be an earlier change element with the @status value "prgGenerated". Below is an example of a file that was converted by Joey Takeda in 2018. In 2020, Janelle Jenstad began the remediation process by tidying the metadata before an RA like you began to work on the file:
<revisionDesc status="IML-TEI">
  <change who="pers:JENS1" when="2020-07-10" status="IML-TEI">Tidied metadata.</change>
  <change when="2018-06-29" who="pers:TAKE1" status="prgGenerated">Created TEI from IML file.</change>
</revisionDesc>
Note that the @status attribute appears on the <revisionDesc> element and on the <change> element. This apparent redundancy allows us to keep a full history of the document’s progress through the conversion and remediation process. Because the <change> element has the @when attribute, we can determine exactly when the document passed from one status to the next.
To change the status of the modernized text that you are remediating, do the following:
Change the value of the @status attribute on the <revisionDesc> element to "IML-TEI" or "IML-TEI_INP", "TCP-TEI_INP", or "TEI_collating".
Add a new <change> element as a child of <revisionDesc> .
Write a description of your change(s) in the text node (i.e., Began remediating document. Added space elements.).
Add a @who, a @when, and a @status attribute to the <change> element.
Add the prefix "pers:" followed by your xml:id to the @who attribute.
Add the date you began the remediation to the @when attribute.
Add the new status as the value of the @status attribute. Note that if you did not change the @status of the file you do not need to add a @status attribute to your <change> element.

Remove Square Brackets

Square brackets in converted files are left over from IML and must be deleted. Square brackets will prevent files from rendering on the LEMDO site, so deleting them is a top priority. Other remediation tasks will be easier to do if you can look at your text rendered on the LEMDO site.
The DRE Editorial Guidelines, which LEMDO supports through encoding practices and which the NISE has adopted, does not use square brackets to denote editorially supplied text in modern or born-digital documents. DRE assumes that the entire modern text is effectively supplied.
In some of the files we are remediating, the <supplied> element has been programmatically added as a replacement for square brackets denoting editorially supplied material. Only QME and MoMS allow the <supplied> tag in modernized texts; keep the <supplied> element if you are remediating a QME text. (All MoMS editions are born-LEMDO.) For DRE and NISE files, ensure that the related collation file has a linked <app> indicating what the editor has supplied. Do not remove the supplied element until there is a collation in place. If there is no <app> , leave a comment for the editor, Janelle, or a more experienced RA indicating that the word or phrase needs to be collated.
If you encounter a <supplied> element without any attributes in a DRE or NISE modernized text, delete it. If you encounter a stray <supplied> element with attributes in a DRE or NISE text, leave a comment in the file for the LEMDO Director and let her know that the file needs her attention. Stray opening or closing square brackets may not have been converted to <supplied> , and will generate a Schematron error until you delete them.

Remove Extraneous Line Beginnings

The TEI will contain leftover <lb> tags from the IML. There are two types of <lb> elements in the IML file:
Editorial line numbers (the <lb> element with the @n attribute and a number as the value). Delete these immediately.
TLNs and/or QLNs (the <lb> element with the @type attribute and the value "tln", and the @n attribute with a number as the value). Retain these until later.
LEMDO does not ultimately need or want any <lb> tags in modernized texts. However, you must retain TLNs/QLNs until the edition is ready for publication as other remediation tasks require them to be in place.
Conversion yields:
<div><!-- … -->
  <lb n="2"/>
  <lb type="tln" n="6"/>
  <p>Good morrow, sweet <lb type="tln" n="7"/>Lodovico.</p>
  <!-- … -->
</div>
There are two <lb> milestone elements for every single line beginning: one is the editorial line number (n="2") and the other is the TLN corresponding to a compositorial line in the semi-diplomatic transcription (type="tln" n="6").
Before you delete any of those numbers, check the converted annotations file. In this case, the corresponding annotations file is keyed to the TLNs ( @target="tln:6").
Corresponding annotation:
<div type="annotations"><!-- … -->
  <note type="annotation" target="tln:6">
    <note type="label">sweet</note>
    <note type="gloss">dear (not ‘sweet’); also often = pleasant, agreeable (as in <ref target="doc:2HW/M#tln-12-12">TLN 12</ref>).</note>
  </note>
  <!-- … -->
</div>
With the knowledge that the annotations are pinned to TLNs, you can safely delete the editorial line numbers right away. Keep the TLNs until the edition is ready for pre-freeze.
Amend to:
<div><!-- … -->
  <lb type="tln" n="6"/>
  <p>Good morrow, sweet <lb type="tln" n="7"/>Lodovico.</p>
  <!-- … -->
</div>
LEMDO has developed a regular expression (regex) to programmatically delete editorial line numbers en masse. If you have not used regex before, please read Introduction to Regular Expressions for information about regular expressions, tips to safely run regex operations, and visual guides for how to run a regex. Once you are familiar with regular expressions, follow these instructions to programmatically delete editorial line numbers:
Click Ctrl+F
Check the regular expression box
In the Find field, paste <lb\sn="\d*\.*\d*"/>
Click Find All and have a look at the results to ensure you are matching with exactly what you want to match with
Leave the Replace field empty
Click Replace All
Validate your file

Remove Spaces

These <space> elements are left over from IML and can be deleted. We do not capture page layout in modernized texts, so there is no need to indicate the presence of space between blocks of text.
The <space> elements will most likely have the @unit attribute with the value "chars" and the @quantity attribute with a number as the value.

Replace Apostrophes

Convert straight apostrophes to right curly apostrophes. The easiest way to convert apostrophes is to run a find-and-replace. Note that the keyboard shortcut for a curly apostrophe in our Oxygen project is Ctrl+Shift+' (Cmd+Shift+' on Mac).

Correct the Character List

The IML-TEI conversion will have created a <listPerson> (child of <particDesc> ) in the <teiHeader> from the tagging in the IML modernized text. It generates the <person> elements, values for the @xml:id attribute, and <reg> elements from <speaker> elements and the IDs on characters in the IML.
In IML, the character list was a separate .txt file and the annotations on the character list (if any) were a separate .xml file from the modernized text. In LEMDO, the <listPerson> removes the need for the character list and its annotations to be in separate files. However, our conversion does not take the old character list or annotations thereon into account, so we have to ensure that the information in the IML character list is included in the <particDesc> of our TEI file.
Note that the text node of the <name> element is what will appear in the finalized character list.

Check Character List Against IML Character List

The character list generated by the conversion may not match the IML character list created by the editor because the conversion generates <person> elements from <speaker> elements in the text. Thus, a character that does not have any assigned lines (i.e., does not have at least one speech prefix) will not appear in the <listPerson> generated by the conversion. To create an accurate <listPerson> , you must check the <listPerson> against the IML list of characters to ensure all characters are included.
The character list generated by the conversion may also generate <person> elements for characters that are not listed on the IML list of characters. These extra <person> elements arise in cases where editor has referred to a character by more than one name (e.g., Prince Hal and King Henry). You will need to delete one of the <person> elements and give the remaining <person> elements two discrete <reg> elements, one for each speech prefix. You may also see extra person elements generated because of inconsistency in the editor’s speech prefixes. For example, 1 Lord, First Lord, and Lord 1 are probably the same character; you will need to merge these <person> elements into one and standardize the speech prefix. Check with the anthology lead, play editor, or LEMDO director to decide on the standardized speech prefix.
If the editor is still working on the edition (i.e., we are doing a one-time IML-TEI conversion so that the editor can continue working in TEI), the LEMDO director or project manager will send an email and a .docx file to the editor(s) to give them the opportunity to make decisions about their character list. The editor(s) will send back a file with comments and corrections. You will need to incorporate those changes into the <listPerson> of the file.

Remove Collective and Non-Character Speakers

The conversion produces spurious hybrid speakers (such as GloucesterandClarence or All in 2H4).
Delete any nonsensical hybrid persons from the <listPerson> . Add new values on @who, which can take multiple values, one for each speaker who speaks simultaneously. In this case, the <speaker> element does not have to match a <reg> element.
Conversion yields:
<div><!-- … -->
  <sp who="#emd2H4_M_GloucesterandClarence"><!-- … --></sp>
  <!-- … -->
</div>
Amend to:
<div><!-- … -->
  <sp who="#emd2H4_M_Gloucester #emd2H4_M_Clarence"><!-- … --></sp>
  <!-- … -->
</div>
Delete any auto-generated non-character speakers (like All or Voices within). See Special Case: Groups of Characters.

Match Names in Character List to Speakers

The text node of each <speaker> element in the modernized text must match with a <reg> element in the <listPerson> in order for the file to be valid. The conversion yields some incorrect <reg> elements (e.g., KingHenry), which will result in Oxygen flagging a correct speaker as incorrect. Correct the text node of the <reg> element. If conversion yields
<reg>KingHenry</reg>
remediate to
<reg>King Henry</reg>
A character may have more than one speech prefix, usually in cases where the character’s social status changes. In this case, add a <reg> element for each name so every <speaker> element has a corresponding <reg> element.
Example: Prince Hal in Henry IV Part 2, who is later crowned king. Conversion yields:
<person xml:id="emd2H4_M_Prince">
  <persName>
    <reg>Prince</reg>
  </persName>
</person>
Amend to:
<listPerson><!-- … -->
  <person xml:id="emd2H4_M_Henry">
    <persName>
      <name>Prince Henry, afterwards crowned King Henry the Fifth</name>
      <reg>Prince</reg>
      <reg>King Henry</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>

Group Characters

We also want to group characters in one <person> element when it is logical to do so. For example, there are two lords in As You Like It, both of whom have speaking roles. Whether or not these are discrete characters with distinct personalities or a dramatic convenience to facilitate dialogue is ultimately the editor’s call. If the editor wants one entry, combine both into a single <person> element and add <reg> elements to capture the contents of all <speaker> elements related to the lords in the play.
Make the value of the @xml:id attribute on the <person> element plural, along with the text node of the <name> element. Add whatever you enter as the text node of the <name> element as a <reg> element as well, because the <reg> element is what links to the <speaker> elements in the play. The example below shows each variant name of the lords in a <reg> element. Conversion yields:
<listPerson><!-- … -->
  <person xml:id="emdAYL_M_FirstLord">
    <persName>
      <reg>First Lord</reg>
    </persName>
  </person>
  <person xml:id="emdAYL_M_SecondLord">
    <persName>
      <reg>Second Lord</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>
Amend to:
<listPerson><!-- … -->
  <person xml:id="emdAYL_M_Lords">
    <persName>
      <name>Lords</name>
      <reg>Lords</reg>
      <reg>Lord</reg>
      <reg>First Lord</reg>
      <reg>Second Lord</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>
IML List of Characters shows:
Grooms
Responsible for strewing rushes at the king’s coronation (5.5).
Conversion yields:
<listPerson><!-- … -->
  <person xml:id="emd2H4_M_Groom1">
    <persName>
      <reg>Groom 1</reg>
    </persName>
  </person>
  <person xml:id="emd2H4_M_Groom2">
    <persName>
      <reg>Groom 2</reg>
    </persName>
  </person>
  <person xml:id="emd2H4_M_Groom3">
    <persName>
      <reg>Groom 3</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>
Amend to:
<listPerson><!-- … -->
  <person xml:id="emd2H4_M_Grooms">
    <persName>
      <name>Grooms</name>
      <reg>Grooms</reg>
      <reg>Groom</reg>
      <reg>Groom 1</reg>
      <reg>Groom 2</reg>
      <reg>Groom 3</reg>
    </persName>
    <note>
      <p>Responsible for strewing rushes at the king’s coronation (5.5).</p>
    </note>
  </person>
  <!-- … -->
</listPerson>

Match Names in Character List to Unique IDs of Speakers

Our conversion gives each <sp> element in the modernized text a @who attribute and a value that indicates the text it appears in and the character who is speaking. For example, the <sp> element in Q1 of Romeo and Juliet for one of Romeo’s speeches has the @who attribute with the value "#emdRom_Q1_Romeo" (with the hash tag indicating that the character’s xml:id is defined in the same file).
The value for the @who attribute must match an xml:id in the <listPerson> or the file will not be valid.
Note that the @who attribute does not function as a speech prefix. A <speaker> tag with appropriate speech prefix is still necessary.

Fix Duplicate Entries for a Single Character

LEMDO does not give new @xml:id values to characters if they change roles or names, so you may have to merge some characters. Remember to change the @xml:id values on the <sp> elements in the text as well.
Conversion yields:
<listPerson><!-- … -->
  <person xml:id="emd2H4_M_PrinceHenry">
    <persName>
      <reg>PrinceHenry</reg>
    </persName>
  </person>
  <person xml:id="emd2H4_M_KingHenry">
    <persName>
      <reg>KingHenry</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>
Amend to:
<listPerson><!-- … -->
  <person xml:id="emd2H4_M_Henry">
    <persName>
      <name>Prince Henry, later King Henry</name>
      <reg>Prince</reg>
      <reg>King</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>
Conversion yields:
<listPerson><!-- … -->
  <person xml:id="emd2H4_M_Bardolph">
    <persName>
      <reg>Bardolph</reg>
    </persName>
  </person>
  <person xml:id="emd2H4_M_LordBardolph">
    <persName>
      <reg>LordBardolph</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>
Amend to:
<listPerson><!-- … -->
  <person xml:id="emd2H4_M_Bardolph">
    <persName>
      <name>Bardolph, later Lord Bardolph</name>
      <reg>Bardolph</reg>
      <reg>Lord Bardolph</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>

Add Names

The conversion auto-generates <reg> elements from the <speaker> elements in the file. You must add a <name> element for each <person> . The content of <name> is the information that will be displayed in the list of characters online and in print.
For the content of the <name> element, follow the editor’s IML character list. The editor will give different (usually longer) names for the characters therein, along with a brief explanation. These longer names and explanations are the ones that the editor wants to have in the online and print character list.
In some cases, the <reg> element (generated from the speakers in the IML file) will be the same as the <name> element. You need to add the <name> even if it seems redundant to do so. Conversion yields:
<listPerson><!-- … -->
  <person xml:id="emd2H4_M_Porter">
    <persName>
      <reg>Rumour</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>
Amend to:
<listPerson><!-- … -->
  <person xml:id="emd2H4_M_Porter">
    <persName>
      <name>Rumour</name>
      <reg>Rumour</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>
The editor may want to add more information:
<listPerson><!-- … -->
  <person xml:id="emd2H4_M_Porter">
    <persName>
      <name>Rumour, the presenter</name>
      <reg>Rumour</reg>
    </persName>
  </person>
  <!-- … -->
</listPerson>

Reorder Character Entries

The <listPerson> arranges <person> elements in the order that the characters appear in the text. Reorder the <person> elements to match the order in which the editor lists them in the IML character list.

Add Notes to Character Entries

If the editor has prepared annotations on the characters, they will be in a separate XML file in the ../app folder. The notes will have been converted from IML but not remediated. You have to find that file and manually add those notes in a <note> element below <persName> on each <person> element. Add a @type attribute with a value of "editorial". Put the content of the note inside a <p> element.
<person xml:id="emd1H4_M_King">
  <persName>
    <name>King Henry IV</name>
    <reg>King</reg>
  </persName>
  <note type="editorial">
    <p>(1367-1413) Born in the same year as his cousin Richard II, Henry IV was eldest son to John of Gaunt. Known as Bolingbroke after the castle where he was born (spelled <mentioned>Bullingbrooke</mentioned> in Q0 and both <mentioned>Bullingbrooke</mentioned> and <mentioned>Bullenbrooke</mentioned> in Q1), he became Duke of Hereford in 1397, and Duke of Lancaster at his father’s death in 1399. In 1398 Richard II banished Henry from England for ten years and when Gaunt died the following year Richard seized his Lancastrian estates and declared Henry a traitor, banished for life. Henry responded by returning to England in July 1399 to reclaim his inheritance. With Richard in Ireland, he gathered powerful support and on Richard’s return was able to capture the king and dictate terms. By the end of September 1399 Richard was forced to abdicate and Henry was acclaimed King. Richard died while imprisoned at Pontrefract castle a few months later. Henry was well-traveled, devout and a capable king. He was initially a popular monarch, but the fact that he was a usurper and not Richard’s proclaimed heir meant that his reign was never secure. His later years were marked by debilitating bouts of illness and he had to rely heavily on his sons for support in both military and administrative affairs. He died in 1413.</p>
  </note>
</person>
Once you have added all the notes, ask the LEMDO director or programmer to move the character notes file to the lemdo/obsolete folder; most RAs do not have write permission on the lemdo/obsolete folder, which lives outside the data folder.
If the editor had not prepared character annotations, the LEMDO director or their anthology lead will liaise with the editor about annotations at the same time that the editor is given a chance to update the character list.
Link Citations in Character Notes to Entries in BIBL1.xml
If the character notes for your modernized text contain citations to external sources, you will need to check if these works are cited in our bibliography, stored in the BIBL1 folder. If the citations are not already in our bibliography, then you will need to create a new BIBL entry. If the work is cited in our bibliography, then you need to add a <ref> tag to the in-text citation to link it to the BIBL entry.
<person xml:id="emd1H4_M_Blunt">
  <persName>
    <name>Sir Walter Blunt</name>
    <reg>Blunt</reg>
  </persName>
  <note type="editorial">
    <p>(d.1403) Sir Walter Blount (spelled <mentioned>Blunt</mentioned> in QF) was a nobleman who had been a loyal Lancaster family retainer for many years before the events in this play. He accompanied John of Gaunt on several military expeditions abroad and was named an executor on his will (<ref type="bibl" target="bibl:OXFO2">DNB</ref>). He joined Henry Bolingbroke when he landed at Ravenspur in 1399 and later served him as an ambassador and diplomat. Blount was the bearer of the royal standard at the battle of Shrewsbury and was one of the men wearing the king’s armour. He died in the battle.</p>
  </note>
</person>
If the source is not yet in the LEMDO site-wide bibliography (BIBL1), you will need to add the source or ask another RA to do so.

Check Tagging of Verse and Prose

Milestones are a holdover from the IML way of indicating prose and verse. In IML, the editor inserted a <mode> tag whenever a verse or prose passage began. There was no closing <mode> tag. One mode was considered to end when another mode began. Our conversion supplies a <milestone> tag where the first <mode> tag was. It adds a @subtype to indicate whether the mode is verse or prose. Our conversion supplies a second <milestone> element with @subtype="end" immediately before the new milestone with its @subtype value of verse or prose.
Our conversion takes those <milestone> elements (which sort of stand in for XML’s container structure) and adds <p> elements in the speeches that are now contained between two kinds of <milestone> elements:
<milestone> elements with the @unit attribute and the value "nonstructural", @type attributes with the value "mode", and @subtype attributes with the value "prose".
<milestone> elements with the @unit attribute and the value "nonstructural", @type attributes with the value "mode", and @subtype attributes with the value "end".
LEMDO’s conversion does the same to <milestone> elements with the value "verse" on the @subtype attribute instead of "prose", but replaces them with <lg> and <l> elements instead of <p> elements.
If the <mode> tags were encoded correctly in the IML, then our conversion will be correct. But if the <mode> tags were incorrect by IML standards, then it’s possible that our conversion has not correctly wrapped prose in <p> tags and verse in <lg> and <l> tags. Your job is to ensure that the <lg> , <l> , and <p> elements are in place. If they are, then you can delete all the milestones with @unit="nonstructural" and @type="mode".
It should be obvious when a verse passage tagged with <p> is actually verse. You will notice capitalization in the middle of sentences (usually corresponding to the placement of one or both sets of <lb> elements). If you notice capitalization in the middle of sentences in passages wrapped in <p> tags, it’s very likely meant to be verse. Leave an XML comment and check with the LEMDO director, who will make a judgement call or confer with the anthology lead and/or play editor.
Example of mode milestones in AYL:
<div><!-- … -->
  <milestone unit="nonstructural" type="mode" subtype="verse"/>
  <quote type="verse">Wind away, Begone, I say, I will not to wedding with thee.</quote>
  <milestone unit="nonstructural" type="mode" subtype="end"/>
  <!-- … -->
</div>
Note that our more recent conversions will have deleted those milestones before you begin remediating the file. We periodically update the conversions to obviate the labour of hand remediation.
We also (as of 2026) have an Oxygen Quickfix that allows you to change a speech encoded as verse lines into prose. It works by removed all the opening and close <l> tags int the speech and wrapping the whole speech in a single <p> element. There is no easy way to convert prose to verse, however; as remediator, you will have to scan the lines, look for capitalization marking the beginning of verse lines, consult a standard edition, and/or ask for help to identify the verse lines.

Remove Mode Milestones

The remediator must confirm that the verse and prose in the text are tagged correctly using <l> and <p> tags. Once you have confirmed that verse and prose are tagged correctly with <l> and <p> tags, you can delete the <mode> milestone tags. Multiple find-and-replace operations will suffice (i.e., replace with nothing).

Check Part and Shared Lines

LEMDO adds the @part attribute to the opening <l> tag of a partial verse line that is completed by another partial verse line.
The allowed values on @part are "I", "M", and "F", for initial, medial, and final. This tagging is how we indicate that two or more characters share a single verse line.
This tagging should have been added during the conversion, so you just have to check its accuracy. As long as this tagging is in place, you can delete elements that are IML holdovers. The IML holdovers will be <milestone> elements with the @unit attribute and the value "linepart", and the @n attribute with the value "i", "m", or "f". Conversion yields:
<sp>
  <milestone unit="linepart" n="i"/>
  <speaker>Hippolito</speaker>
  <l part="I">Your business, sir? To me?</l>
  <milestone unit="linepart" n="f"/>
  <speaker>Antonio</speaker>
  <l part="F">Yes, my good lord.</l>
</sp>
Amend to:
<div>
  <sp who="#emd2HW_M_Hippolito">
    <speaker>Hippolito</speaker>
    <l part="I">
      <stage type="delivery">To Antonio</stage> Your business, sir? To me?</l>
  </sp>
  <sp who="#emd2HW_M_Antonio">
    <speaker>Antonio</speaker>
    <l part="F">Yes, my good lord.</l>
  </sp>
</div>

Check In-Line Stage Directions

Ensure that in-line stage directions are encoded in the correct line. Stage directions that state who is being addressed should appear before the corresponding line of dialogue. In the following example, To Silvius is incorrectly encoded at the end of the first line (Foul is most foul, being foul to be a scoffer), but it should appear in the second line (So take her to thee, shepherd. Fare you well). Conversion yields:
<l>Foul is most foul, being foul to be a scoffer. <stage type="delivery">To Silvius</stage>
</l> <l>So take her to thee, shepherd. Fare you well.</l>
Amend to:
<sp>
  <l>Foul is most foul, being foul to be a scoffer.</l>
  <l>
    <stage type="delivery">To Silvius</stage>So take her to thee, shepherd. Fare you well.</l>
</sp>

Replace Quotation Marks

After the IML to TEI conversion, the file will contain <q> elements in place of quotation marks. You will correct <q> elements to be more specific elements where possible. See Introduction to Quotations, Terms, Expressions, Glosses, Emphasis, and Foreign Languages.
For quotations that extend over two or more lines of verse, assign each quotation element a unique value on the @xml:id attribute and add @next and/or @prev attributes as needed to link the lines together. See Encode Split Elements.

Encode Songs

In IML, songs were usually encoded as quotations. LEMDO does not want songs wrapped in quotation tags unless the song contains explicitly quoted material. Delete any quotation marks or quotation tags that are not surrounding quoted material. Make sure that songs are wrapped in an <lg> element with a @type value of "song". See Encode Letters and Songs in Modernized Texts.

Encode Foreign Words

Tag foreign words with the <foreign> element, the @xml:lang attribute, and a standardized BCP 47 value from the list in IANA Values for Specific Languages:
<p>
  <term>Accommodated</term>—it comes of <foreign xml:lang="la">accommodo</foreign>—very good, a good phrase. </p>

Check the Text for Accuracy

Make sure that the text is complete and correct. Do this by reading the text in your file against a version of the text published elsewhere. You can check as you go or do a final check at the end.
If the text was peer-reviewed and published on one of the sibling sites (ISE, QME, or DRE), compare your file to the online rendering of the original IML. Make sure that we did not accidentally delete a passage while the IML was being run through the various conversions, which always entails some clean-up of the IML. (Note that the old QME website has now been replaced by the new LEMDO-created website. All of the QME files have been remediated.)
Keep in mind that the Broadview texts (ISE only) went through an additional phase of copyediting, and those copy edits did not always make it back into the digital editions.
We have found that some <speaker> elements seem to be missing. If you check against the ISE, DRE, or QME site, add in the intended speakers.
When you are looking at the ISE, DRE, and QME sites, make sure you are looking at the desktop view. Some editions seem to be defaulting to the mobile view, in which lines are repeated.

Copyedit the Text

It is not your job as remediator to copyedit the editor’s work, but if you notice things that you can easily fix (like missing serial commas) and you are confident in your knowledge of the LEMDO Style Guidelines and anthology’s style guide, then go ahead and implement the change. If you are unsure, always check with the LEMDO director (or the play editor/anthology lead, if you have been authorized to correspond directly with them).

Add Anchors

When you start remediating the annotations, collation, and critical paratexts, you will revisit the modernized text and add anchors to which other files can point.
If you are looking for information on remediating annotations, collations, or critical paratexts, go to Remediate Annotations, Prepare Annotations for Print, Remediate Collation Files, or Remediate Critical Paratexts.

Proofread the PDF

Some texts being remediated are converted into PDF files in preparation for publishing. Proofread the PDF after you have completed this remediation process to check for mistakes in your encoding. Ask a developer for a link to the PDF copy of your text.

Remove Lingering TLNs

We leave the TLNs on <lb> elements during the IML-TEI remediation process because the remediator needs to consult them to confirm that annotations are linked to the correct strings in the modern text. TLNs were the glue that allowed for the string-matching that IML used to tie the lemma in the annotation to the string in the modernized text.
The final task in modernized texts (to be done during pre-freeze after the annotation, collation, and critical paratext files have all been completed and the links checked in all edition files) is to remove the lingering TLNs. Removal is typically done by a senior member of the LEMDO team.
To remove lingering TLNs, run the following regex:
Find: <lb type="tln" n="\d*\.*\d*"/>
Replace with: Leave Replace with empty.

Update Document Status: Proofing

Once all remediation work is done in the modernized file, update the status of the document once more. Change the value of the @status attribute to "IML-TEI_proofing". Add a <change> element with a @status value of "IML-TEI_proofing" to leave a record of when the remediation work was completed.

Other Resources

Prosopography

Illya

Illya has a BA in English and Sociocultural Anthropology and an MA in English. Prior to joining the HCMC, he was a PhD candidate in English and Book History at the University of Toronto and worked on Records of Early English Drama and on the Modernist Archives Publishing Project. His work at the HCMC focuses on creating web-based applications for research projects led by members of the faculty of Humanities at the University of Victoria. This involves creating schemas for new and existing datasets, writing XSLT and build files to transform datasets into structured TEI and HTML formats, implementing staticSearch, and ensuring that new projects are Endings Principles compliant.

Janelle Jenstad

Janelle Jenstad is a Professor of English at the University of Victoria, Director of The Map of Early Modern London, and Director of Linked Early Modern Drama Online. With Jennifer Roberts-Smith and Mark Beatrice Kaethler, she co-edited Shakespeare’s Language in Digital Media: Old Words, New Tools (Routledge). She has edited John Stow’s A Survey of London (1598 text) for MoEML and is currently editing The Merchant of Venice (with Stephen Wittek) and Heywood’s 2 If You Know Not Me You Know Nobody for DRE. Her articles have appeared in Digital Humanities Quarterly, Elizabethan Theatre, Early Modern Literary Studies, Shakespeare Bulletin, Renaissance and Reformation, and The Journal of Medieval and Early Modern Studies. She contributed chapters to Approaches to Teaching Othello (MLA); Teaching Early Modern Literature from the Archives (MLA); Institutional Culture in Early Modern England (Brill); Shakespeare, Language, and the Stage (Arden); Performing Maternity in Early Modern England (Ashgate); New Directions in the Geohumanities (Routledge); Early Modern Studies and the Digital Turn (Iter); Placing Names: Enriching and Integrating Gazetteers (Indiana); Making Things and Drawing Boundaries (Minnesota); Rethinking Shakespeare Source Study: Audiences, Authors, and Digital Technologies (Routledge); and Civic Performance: Pageantry and Entertainments in Early Modern London (Routledge). For more details, see janellejenstad.com.

Joey Takeda

Joey Takeda is LEMDO’s Consulting Programmer and Designer, a role he assumed in 2020 after three years as the Lead Developer on LEMDO.

Mahayla Galliford

Project Manager, 2025-present; Assistant Project Manager, 2024-2025; Research Assistant, 2021-present. Mahayla Galliford (she/her) graduated from the University of Victoria with a BA (honours with distinction) in 2024, and an MA English in 2026. Mahayla’s undergraduate research explored early modern stage directions and civic water pageantry. Her SSHRC-funded MA thesis project focuses on transcribing, editing, and encoding early modern girls’ manuscripts, specifically Lady Rachel Fane’s May Masque in collaboration with LEMDO.

Martin Holmes

Martin Holmes has worked as a developer in the UVic’s Humanities Computing and Media Centre for over two decades, and has been involved with dozens of Digital Humanities projects. He has served on the TEI Technical Council and as Managing Editor of the Journal of the TEI. He took over from Joey Takeda as lead developer on LEMDO in 2020. He is a collaborator on the SSHRC Partnership Grant led by Janelle Jenstad.

Navarra Houldin

Training and Documentation Lead 2025–present. LEMDO project manager 2022–2025. Textual remediator 2021–present. Navarra Houldin (they/them) completed their BA with a major in history and minor in Spanish at the University of Victoria in 2022. Their primary research was on gender and sexuality in early modern Europe and Latin America. They are continuing their education through an MA program in Gender and Social Justice Studies at the University of Alberta where they will specialize in Digital Humanities.

Nicole Vatcher

Technical Documentation Writer, 2020–2022. Nicole Vatcher completed her BA (Hons.) in English at the University of Victoria in 2021. Her primary research focus was women’s writing in the modernist period.

Samuel Seaberg

Samuel Seaberg, a University of Victoria English undergrad, enjoys riding his bike. During the summer of 2025, he began working with LEMDO as a recipient of the Valerie Kuehne Undergraduate Research Award (VKURA). Unfortunately, due to his summer being spent primarily in working to establish an edition of Thomas Heywood’s If You Know Not Me, You Know Nobody, Part 2 and consequently working out how to represent multi-text works in a digital space, his bike has suffered severely of sheltered seclusion from the sun. Note: Samuel now works for LEMDO as the Assistant Project Manager, much to his bike’s chagrin.

Tracey El Hajj

Junior Programmer 2019–2020. Research Associate 2020–2021. Tracey received her PhD from the Department of English at the University of Victoria in the field of Science and Technology Studies. Her research focuses on the algorhythmics of networked communications. She was a 2019–2020 President’s Fellow in Research-Enriched Teaching at UVic, where she taught an advanced course on Artificial Intelligence and Everyday Life. Tracey was also a member of the Map of Early Modern London team, between 2018 and 2021. Between 2020 and 2021, she was a fellow in residence at the Praxis Studio for Comparative Media Studies, where she investigated the relationships between artificial intelligence, creativity, health, and justice. As of July 2021, Tracey has moved into the alt-ac world for a term position, while also teaching in the English Department at the University of Victoria.

Bibliography

Oxford Dictionary of National Biography. Oxford University Press, 2004–2013. http://www.oxforddnb.com/.

Orgography

LEMDO Team (LEMD1)

The LEMDO Team is based at the University of Victoria and normally comprises the project director, the lead developer, project manager, junior developers(s), remediators, encoders, and remediating editors.

Metadata

Authority title Remediate Modernized Texts
Type of text Documentation
Publisher University of Victoria on the Linked Early Modern Drama Online Platform
Series Linked Early Modern Drama Online
Source
TEI Customization created by Martin Holmes, Joey Takeda, and Janelle Jenstad; documentation written by members of the LEMDO Team
Editorial declaration n/a
Edition Released with Linked Early Modern Drama Online 1.0
Encoding description Encoded in TEI P5 according to the LEMDO Customization and Encoding Guidelines
Document status prgGenerated
Funder(s) Social Sciences and Humanities Research Council of Canada
License/availability
This file is licensed under a CC BY-NC_ND 4.0 license, which means that it is freely downloadable without permission under the following conditions: (1) credit must be given to the author and LEMDO in any subsequent use of the files and/or data; (2) the content cannot be adapted or repurposed (except in quotations for the purposes of academic review and citation); and (3) commercial uses are not permitted without the knowledge and consent of the editor and LEMDO. This license allows for pedagogical use of the documentation in the classroom.