Gendering smart solved: A technical solution for PDF publishing and content delivery on the web

What gendering is all about

'gender' is an English term forGeschlecht', referring here to the lived gender as opposed to 'sex', which refers to the sexual characteristics. 'Gendering' in discussions is about no longer 'co-gendering' people with the generic masculine, but finding a way to address everyone in the German language, regardless of their (lived) gender.

For this purpose, the feminine suffix is added to the masculine in various forms (e.g. AutorIn, Autor*in, author Autor:in). There are also hotly debated moves to introduce a generic feminine. That's what happened in October 2020, when a Justice Department bill was written in all-female form.

Of course, it's nice, kind, and in many cases even important to address everyone as personally as possible so as not to exclude anyone with language because of their gender. This is especially difficult if one does not know the people addressed; and therefore the discussion, if sometimes somewhat exaggerated, is justified.

At Audi, the new guideline calls on employees to use gender-sensitive language when communicating: Vorsprung beginnt im Kopf! A 13-page document produced in a year-long(!) Working group was developed. But Audi's slogan is " Vorsprung durch Technik"? If you work on a concept for a year in a task force, why don't you take the credo of the company and implement the concept (or have it implemented) accordingly technically according to this guiding principle?

Gender asterisks or colons only where necessary

If someone knows me, I want to be addressed as what or how I am, and not gendered or otherwise. I am an Autor or Entwickler, but not an Autorin Autor:in or Entwicklerin Entwickler:in. So if I am personally written to or mentioned, I would also like to be addressed in the form that suits me. This already starts with the letter, which often begins like this Sehr geehrte/r Frau/Herr Wiedenmaier or as here on LinkedIn

There I ask myself then sometimes, is it because of the systems, thus developers the respective portal are responsible for it, or one would like to show here simply only that one also masters the gender asterisk and/or the gender colon. I am an Autor and not an Autor:in.

Since a gender-sensitive approach is important to many people, we have also decided to use gender-sensitive language in our communications, and to communicate in a gender-sensitive in our documentation and on our German website. We leave it up to our target group to decide how the result should be presented and let readers read the text in the variant they like best. In this way, we go far beyond the approach taken on LinkedIn or other portals. Let's take a look at how it works technically.

A solution for systems with user profiles: evaluate existing information

Especially on the web, we are now known to the systems. The more we move around the web, the more transparent we become. Systems know what I've been looking for recently, what I like to eat, what my social status is. On the basis of this data, for example, I am regularly shown appropriate advertising that matches me, where I sometimes wonder: "How do they know that again?!"

So if systems know me, they also know what gender I am or live. In the simplest case, by putting it in my user profile. So if a system knows that, why am I tagged as an Autor:in and not an Autor, as I am on LinkedIn? In this case it would be quite easy, because this tag is stored in the system and can easily be linked to my profile to display the right term for me.

A solution approach for editorial texts: Use metadata and evaluate it during content generation

But what about free text, e.g. in blogposts, in web articles or even in technical documentation? For this purpose, there are technologies and standards that can be used to find solutions to the problem. Not entirely surprisingly, one of these solutions is called XML. Another solution is terminology management in the form of the TBX (TermBase eXchange) ISO 30042 standard, also an XML standard.

Why don't we provide the gender-specific terms with a metadatum and let the respective publication system decide, either during generation or just on-demand on the web, which gender-sensitive term is the appropriate one and should be displayed?

Gender-specific labeling of terms with TermBase eXchange

In the XCS file (extensible constraint specification), which is an extension to TBXcoreStructV02.dtd, types for gender-specific labeling of terms are already provided. And it is precisely these that we can use in terminology management:

<termNoteSpec name="grammaticalGender" datcatId="ISO12620A-020202">
    <contents datatype="picklist" forTermComp="yes">masculine feminine neuter otherGender</contents>
</termNoteSpec>
<termNoteSpec name="grammaticalNumber" datcatId="ISO12620A-020203">
    <contents datatype="picklist" forTermComp="yes">singular plural dual mass otherNumber</contents>
</termNoteSpec>
<termNoteSpec name="termType" datcatId="ISO12620A-0201">
    <contents datatype="picklist">abbreviation acronym clippedTerm commonName entryTerm
         equation formula fullForm initialism internationalScientificTerm internationalism
         logicalExpression phraseologicalUnit partNumber shortForm shortcut sku symbol
         synonym synonymousPhrase standardText string transliteratedForm transcribedForm
         variant </contents>
</termNoteSpec>

So already in the TBX standard we can use the metadata grammaticalGender (male, female) andsingular/plural) to mark up terms (terms) accordingly. Likewise, we can use the termType (shortForm, fullForm) to define an abbreviated form (asterisk or colon) or the spelled out variant. An exemplary implementation with the term Autor could look like this:

<termEntry id="term_g_author">
    <descrip type="definition">Der Autor ist der Schreiber eines Textes</descrip>
    <langSet xml:lang="de-DE">
        <tig>
            <term>Autor</term>
            <termNote type="grammaticalGender">masculine</termNote>
            <termNote type="grammaticalNumber">singular</termNote>
        </tig>
        <tig>
            <term>Autorin</term>
            <termNote type="grammaticalGender">feminine</termNote>
            <termNote type="grammaticalNumber">singular</termNote>
        </tig>
        <tig>
            <term>Autor:in</term>
            <termNote type="grammaticalGender">neuter</termNote>
            <termNote type="grammaticalNumber">singular</termNote>
            <termNote type="termType">shortForm</termNote>
        </tig>
        <tig>
            <term>Autor oder Autorin</term>
            <termNote type="grammaticalGender">neuter</termNote>
            <termNote type="grammaticalNumber">singular</termNote>
            <termNote type="termType">fullForm</termNote>
        </tig>
        <tig>
            <term>Autoren</term>
            <termNote type="grammaticalGender">masculine</termNote>
            <termNote type="grammaticalNumber">plural</termNote>
        </tig>
        <tig>
            <term>Autorinnen</term>
            <termNote type="grammaticalGender">feminine</termNote>
            <termNote type="grammaticalNumber">plural</termNote>
        </tig>
        <tig>
            <term>Autor:innen</term>
            <termNote type="grammaticalGender">neuter</termNote>
            <termNote type="grammaticalNumber">plural</termNote>
            <termNote type="termType">shortForm</termNote>
        </tig>
        <tig>
            <term>Autoren oder Autorinnen</term>
            <termNote type="grammaticalGender">neuter</termNote>
            <termNote type="grammaticalNumber">plural</termNote>
            <termNote type="termType">fullForm</termNote>
        </tig>
    </langSet>
</termEntry>

With this term entry, we have defined variants for the term Autor and assigned it corresponding meanings in the form of meta-information. Thus, we have created a database, so to speak, with which a system - of whatever kind - can recognize the corresponding gender variations.

However, a classical terminology checking system does not help us in this use case, as it usually only tells us which of these terms we should use in editing, i.e. writing, but not which one should be used in a personalized publication.

A terminology check helps us ensure in the authoring process that we are using the gender-neutral version when we write, for example. This means that our content cannot be personalized, but is universally valid - just as it is defined. So we need more if we want to share this information dynamically, in a personalized context.

Gender-specific labeling of terms in xml-based content creation systems using the example of DITA

Let's take the simple text Wie werde ich Autor? look at the topic in XML. In DITA-XML, we use the <p> element to create paragraphs and write this sentence as follows:

<p>Wie werde ich Autor?</p>

Without further logic, we do not know that we need to take care of the term Autor in the publication specifically. Therefore, we provide the word Autor with an appropriate tag, in DITA-XML with the element <term>, <keyword> or simply <ph>

<p>Wie werde ich <ph>Autor</ph>?</p>

Now we still need to establish a relationship to our term in the termbase, which we can do in DITA using the @keyref attribute. So we use one of the reuse mechanisms of DITA.

<p>Wie werde ich <ph keyref="term_g_author">Autor</term>?</p>

We have thus created the link between our content and the terminology database. Not quite yet! DITA does not understand the TBX standard and instead expects a so-called key map, which is the database for the IDs addressed via keyref. But we do have XSLT as a standard technology, which we can use to automatically generate our key maps from the TBX database. You read that right! We need multiple key maps, one for each gender variant.

In our case of the example sentence Wie werde ich Autor?, there are four:

• the variant for the generic masculineAutor)

• the variant for the generic feminineAutorin)

• the variant for the gendered short formAutor:in)

• as well as the variant for the gendered long formAutor oder Autorin)

Each key map variant contains both the singular and plural form and is referenced in the DITA-Map where the 'documentation' is compiled and placed in hierarchy.

This means that we can now easily reference this term by its ID, and can also easily replace it in other languages with the respective valid key map. This is how the process works in translations, especially when 'gendering' is not an issue in a language - and that should be pretty much all except German.

And what do we do with our PDF production?

In PDF production, we create more or less static content, some of which is still printed. Therefore, due to high printing costs, we usually have to and will choose one of the variants. If we offer the documentation for download on the web, we can also let users decide and offer all variants for download. We just need to know and decide what we want.

To solve this, we use the mechanisms of variant management and mark up the references to the key maps with the gendered terms accordingly. For this purpose, we use the @audience attribute in DITA to mark the variants accordingly.

<map>
  <title>c-rex.net Key Maps</title>
  <topicref audience="generic-masculine" href="c-rex-net-terminology_keys_gm.ditamap" format="ditamap"/>
  <topicref audience="generic-feminine" href="c-rex-net-terminology_keys_gf.ditamap" format="ditamap"/>
  <topicref audience="neuter-full" href="c-rex-net-terminology_keys_nf.ditamap" format="ditamap"/>
  <topicref audience="neuter-short" href="c-rex-net-terminology_keys_ns.ditamap" format="ditamap"/>
</map>

Now when we publish our content, we specify a DITAVAL (profiling mechanism in DITA) as a parameter to publish - as in this case - the variant with the generic masculine and filter out all other variants.

<val>
    <prop action="exclude" att="audience" val="generic-feminine"/>
    <prop action="exclude" att="audience" val="neuter-full"/>
    <prop action="exclude" att="audience" val="neuter-short"/>
</val>

The four published PDF variants can be found here:

• generic masculine

• generic feminine

• gender-neutral (short form)

• gender-neutral (long form)

And how does it look in web portals & Co? - Gendering in Content Delivery

In the previous section we considered static publications like a PDF output. Here, at the time of generation, we have to decide which variant of the term we want to use based on the target group. Either we write a letter to a specific person, for example, or we use the respective gender-neutral term in a generic context. In content delivery or in a web portal in general, however, we only know users when they are logged on to the system. Ideally, we also have multiple users who want to access our content online. In addition, if possible, they should also be able to decide in which variant they would like to read the text, in which other groups are addressed rather than themselves. Therefore, we need to provide in the HTML all the variants that come into question in this context in order to display them correctly at runtime.

<div class="gender-setting-generic-masculine">
    <p class="p">Wie werde ich 
        <span class="term-gender generic-masculine">Autor</span>
        <span class="term-gender generic-feminine">Autorin</span>
        <span class="term-gender neuter-short">Autor:in</span>
        <span class="term-gender neuter-full">Autor oder Autorin</span>
    ?</p>
</div>

This content is then shown or hidden depending on the user profile via CSS.

.term-gender
{border-bottom: 2px dotted red;}
.term-gender.generic-masculine
{display:inline;}
.term-gender.generic-feminine,
.term-gender.neuter-short,
.term-gender.neuter-full
{display:none;}
.gender-setting-generic-masculine .term-gender,
.gender-setting-generic-feminine .term-gender,
.gender-setting-neuter-short     .term-gender,
.gender-setting-neuter-full      .term-gender
{display:none !IMPORTANT;}
.gender-setting-generic-masculine .term-gender.generic-masculine,
.gender-setting-generic-feminine  .term-gender.generic-feminine,
.gender-setting-neuter-short      .term-gender.neuter-short,
.gender-setting-neuter-full       .term-gender.neuter-full
{display:inline !IMPORTANT;}

In this case, the system sets a context in the HTML in the form of a class that defines the gender of the logged-in users and which gender variant preference was chosen. Depending on this setting, the matching terms will be shown or hidden accordingly.

users can make the decision on our blog. This selection is only visible if the content actually contains gender variants:

Depending on the choice made, the contents are displayed as desired (the genderable terms are marked underlined accordingly):

What are we doing with social media?

For a tweet on Twitter, a post on LinkedIn or Facebook, it becomes inherently difficult to drop the content in multiple variations. Of course, this can be done, but it seems very questionable whether it will achieve the desired results. Therefore, one will choose a variant here. In the case of the c-rex.net bot, which in the future will automatically send tweets for our company account when new posts go online, we will use the texts from the teaser and use the gender-neutral variant there in short form and with a colon. So we too can then show that we have mastered the gender colon for the content generated with our tools.

Authoring support and validation

When creating content, the focus is usually on writing. And, of course, people often forget to label or maintain gender terms appropriately. Thus, a validation mechanism is needed that not only checks whether a term is used correctly (this is what terminology checking systems do), but more importantly, whether the correctly used term has also been tagged. So we have now moved from the specific 'gendering' to a more general question of terminology checking. And it is in tagging that these systems have their weaknesses, because they focus on text rather than structure.

c-rex.net DTS can tag terms based on a term database like the one created here. Before a blog is released, we check the content with this technology and set terms that are defined but not tagged in the database accordingly by a keyref, i.e. a reference to our DITA-Map. In addition, an entry is written in the validation log. This protocol can finally be checked again in the editorial office for correctness and, if necessary, the writing style and grammar of the sentence in which the term is used can also be adjusted.

German language, difficult language or The attempt of a conclusion

As is well known, the German language is not an easy language. And so it was non-trivial to adapt our existing blog posts to be 'gendered'. In the examples so far, we have only considered terms that are in the nominative case, i.e., the author, the authors, the der Autor, die Autorin, die Autoren, die Autorinnen usw.. But what if the terms occur in the genitive or dative case, i.e. of des Autors, der Autorin, an den Autor, an die Autorin usw. ? For example, what about a sentence like Einen Brief an den Autor schreiben that is gendered as seen on the web Einen Brief an den*die Autor*in schreiben? In a feminine context, our technical solution would make it Einen Brief an the Autorin schreiben, which would perhaps bother me less in the reading flow than in the example from the net, but still, simply because it is grammatically wrong.

For creative texts, such as in blogs or newspaper articles, we may need more advanced solutions of a technological nature here. Or else we get used to a different style of writing. My colleague has tried this for our existing blog posts and will be sharing her experience here on the blog soon.

In the field of technical documentation, however, the trend is moving more and more towards simplified writing, such as Brief an Autor schreiben, i.e. without taking the gender discussion into account. Nevertheless, existing concepts can be optimally combined and smaller and larger problems can be solved with modern and technical means. However, much will not be addressed because the effort does not seem justified in relation to the benefits.

With our solution approach, we have shown that current problems can be solved with technology and, above all, with standards. We have not developed any new standards or introduced any new software for this purpose, but have simply used what is already available today and has been in use for very many years. Even though we have focused on TBX and DITA here, this approach can also be ported to other systems, whether you are working with a CCMS, with DocBook, or even unstructured with Word or FrameMaker.

Have you already solved the issue for yourself? Or do you have ideas that support and advance the solution approach described above? We look forward to exchanging ideas with you on the conceptual and technical aspects of gender issues.

About Markus Wiedenmaier

Markus Wiedenmaier is the founder of c-rex.net GmbH, producer of a cloud-based Digital Transformation and Information Delivery Service. Since 2001 Markus has been working as a trainer, developer and system integrator in the field of XML publishing. His focus is on semi- and fully-automated XML publishing solutions, process integration, process automation, data modeling and data migration.