Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

surname cannot come first #325

Open
Dominique-M opened this issue Jun 2, 2018 · 12 comments · May be fixed by #629
Open

surname cannot come first #325

Dominique-M opened this issue Jun 2, 2018 · 12 comments · May be fixed by #629
Assignees
Labels
conversion: html priority: low Not urgent; can be dealt with when someone has free time or is looking for a project. resp: council status: Go Council has decided the ticket should proceed. status: needsDiscussion Council has not yet been able to agree on how to proceed.

Comments

@Dominique-M
Copy link

In certain cultures the surname comes first and TEI allows surname forename in that order under persName. Though the HTML5 transformation (7.44 as a Debian package) seems to put the forename first anyway. I feel the choice should reside on the side of the author, not the stylesheets. Or do I miss something? See http://www.d-meeus.be/biblio/Tsuzuki1967.html and http://www.d-meeus.be/biblio/biblio.xml. (In the meanwhile, as a workaround, I ‘commented out’ surname forename and wrote the full name directly as content of persName.)

@jamescummings
Copy link
Member

I think this is happening because of an arbitrary(?) decision to process surname first by default in this template:

<xsl:template match="tei:editor|tei:author">
<xsl:choose>
<xsl:when test="ancestor::tei:bibl">
<xsl:apply-templates select="if (tei:surname) then * else node()"/>
</xsl:when>
<xsl:when test="self::tei:author and not(following-sibling::tei:author)">
<xsl:apply-templates select="if (tei:surname) then * else node()"/>
<xsl:call-template name="makeText">
<xsl:with-param name="letters">. </xsl:with-param>
</xsl:call-template>
</xsl:when>
<xsl:when test="self::tei:editor and not(following-sibling::tei:editor)">
<xsl:apply-templates select="if (tei:surname) then * else node()"/>
<xsl:call-template name="makeText">
<xsl:with-param name="letters">
<xsl:value-of select="if (preceding-sibling::tei:editor) then
' (eds.) ' else ' (ed.) '"/>
</xsl:with-param>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates select="if (tei:surname) then * else node()"/>
<xsl:call-template name="makeText">
<xsl:with-param name="letters">, </xsl:with-param>
</xsl:call-template>
</xsl:otherwise>
</xsl:choose>
</xsl:template>

Although you said HTML5 transformation, this just uses the underlying HTML transformation, which itself uses the transformations in common across multiple transformations.

Local Project Workaround: In your calling of the HTML5 transformation have your own XSLT which calls this but overrides the template match for tei:editor|tei:author to put forename first. (i.e. the exact same template but 'surname' changed to 'forename'. This might be a quick workaround for you depending on whether you feel comfortable doing that. The benefit is that you can return to using the markup rather than commenting it out and putting it as content of persName, which means it shows up with anything else you do with forenames and surnames.

Proposed Solution: If council agrees this is a good idea (not privileging surname in this way) then we should put in a parameter (into common_param.xsl) to either mark whether surname should come first or not (which I still think should be the default) or if we wanted to be really clever about it, pass the name of the element which should come first. The former is obviously much easier than the latter. If going for the former, maybe defaultSurnameFirst=true should be the default. If someone sets this to false then the child elements should just be processed in the document-provided order. This allows seamless backwards compatibility and total freedom in entries author to author about the order.

@Dominique-M
Copy link
Author

I am an amateur writing mostly “born digital” TEI, but if TEI is used to encode an existing text, why on earth should the stylesheets decide on such a thing, possibly against the author (and the encoder following the author). TEI is used in all the world. But even in English it doesn’t make sense: it would make difficult to encode that Mao Zedong wrote about Norman Bethune (https://en.wikipedia.org/wiki/Norman_Bethune#Legacy). There should be no default on that matter, but I can understand the need to keep backwards compatibility. Even if it goes only about authors and editors, this should be free.

@duncdrum
Copy link
Contributor

I agree with @Dominique-M here. Under no circumstances should the stylesheet change the order of fore-/surename from how encoders used them.

@jamescummings I like the proposed solution, but the default should be defaultSurnameFirst=false, this is based on many instances in bibliographies and even library catalogs that do not properly cite or sort by actual surname, and go by sequence alone. e.g. "Mao, Zedong" ,"Zedong Mao", … which are simple wrong.

@lb42
Copy link
Member

lb42 commented Jun 27, 2018

Phrase like "under no circumstances" are always a bit provocative. Imagine a situation where I am merging two or three different listBibls in which the order of encoding varies (for whatever reason). I might well want the stylesheet which renders them to impose a single coherent order, without having to go thro the tedious business of retagging the data. The order is an aspect of the formatting, not the encoding.

@duncdrum
Copy link
Contributor

@lb42 well maybe my phrasing was a bit to harsh ( I blame the ⚽️ ), but the point stands. For use in citation styles, indexes, concordance, listBibls etc there is no single correct order for the stylesheets to impose. So the stylesheet should trust creators of the listBibls to have picked the right one in the first place. I have no objections to provide a convenience function for users to override this, but it shouldn't be on by default. Why should editors have to go thought the tedious process of fixing the stylesheet or their listBibls because it magically turns

<persName>
  <surname>Mao</surename>
  <forename>Zedong</forename>
</persName>
<persName> 
  <forename>Duncan</forename>
  <surname>Paterson</surename>
</persName>

into Zedong Mao & Duncan Paterson?

@Dominique-M
Copy link
Author

Dominique-M commented Jun 27, 2018 via email

@tuurma
Copy link
Contributor

tuurma commented Sep 8, 2018

To reproduce run TEI P5 XHTML transformation scenario on

<TEI xmlns="http://www.tei-c.org/ns/1.0">
   <teiHeader>
      <fileDesc>
         <titleStmt>
            <title>Title</title>
         </titleStmt>
         <publicationStmt>
            <p>Publication Information</p>
         </publicationStmt>
         <sourceDesc>
            <p>Information about the source</p>
         </sourceDesc>
      </fileDesc>
   </teiHeader>
   <text>
      <body>
         <p>
            <persName>
               <surname>surname</surname>
               <forename>forname</forename>
            </persName>
         </p>
      </body>
   </text>
</TEI>

Expected result would be to have surname forename, current result is reverted

image

@martindholmes
Copy link
Contributor

Lines 1244 through 1265 of common_core.xsl have templates that cause this behaviour. Commenting out those templates solves the problem for @tuurma's example, but there are other places such as the lines @jamescummings points at which do similar things. The Stylesheets Coop thinks this behaviour should be changed; names should be output by default in the order they're encoded, including intervening text nodes (punctuation etc.). A parameter could be added to prevent these templates from firing unless it's explicitly set.

@sydb
Copy link
Member

sydb commented Dec 21, 2018

Stylesheets group, discussing this more, thinks that the order events should be:

  1. Remove all the special processing of <persName> and its children; thus ones output will reflect whatever is in the input, period.
  2. Post about this change here on the ticket and to TEI-L and in the Stylesheets change log.
  3. IF someone is upset by this change, THEN ask that person to post the complaint with their use case as a ticket, and at that time consider what, if any, other behaviors should be supported (likely via a parameter).

@sydb sydb self-assigned this Dec 21, 2018
@sydb
Copy link
Member

sydb commented Dec 21, 2018

Assigning myself to do step (1), above.

@sydb
Copy link
Member

sydb commented Dec 24, 2018

I tried step 1 by

  1. Creating simple test input file.
  2. Generating output HTML5.
  3. Deleting the templates we (well, @martindholmes) found as the source of the problem during the Stylesheets group conference call. They have been replaced with a comment giving the commit number before the deletion for easy reversal.
  4. Generating output HTML5.

The test file and the two output HTML5 files are here:
test_persName_for_325.tar.gz

HOWEVER, doing this causes Test/test23 to differ slightly in the HTML (which I think we won't care about), and even more in the TeX, which I am hoping someone else knows or will figure out if we care about or not (I can't really run TeX on this laptop, and may not be able to get to this until Jan 04)
test23.tar.gz

AND much worse, it causes Test/test27 to essentially fail. The loss of whitespace in the middle of a name is really a problem.
test27.tar.gz

Thoughts?

(P.S., I have not committed my changes, yet; but will put them in in a different branch if someone reminds me how to do that.)

@martindholmes
Copy link
Contributor

If whitespace is lost during processing, then the output isn't in fact reflecting what's in the input, which is weird.

@sydb sydb added this to the Release 7.50.0 milestone Apr 3, 2020
@peterstadler peterstadler added conversion: html priority: low Not urgent; can be dealt with when someone has free time or is looking for a project. resp: council status: Go Council has decided the ticket should proceed. status: needsDiscussion Council has not yet been able to agree on how to proceed. labels Jun 15, 2020
@sydb sydb removed this from the Release 7.55.0 milestone Apr 4, 2023
@sydb sydb added this to the Release 7.56.0 milestone Apr 4, 2023
@HelenaSabel HelenaSabel linked a pull request Sep 30, 2023 that will close this issue
@HelenaSabel HelenaSabel modified the milestones: Release 7.56.0, Release 7.57.0 Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conversion: html priority: low Not urgent; can be dealt with when someone has free time or is looking for a project. resp: council status: Go Council has decided the ticket should proceed. status: needsDiscussion Council has not yet been able to agree on how to proceed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.