Conversion Docbook en DITA #47

New Issue

ciri · 2023-04-26T15:40:45+02:00

ciri commented

2023-04-26 15:40:45 +02:00

J'ai essayé d'appliquer ce que l'on a vu dans le premier exercice de conversion avec XSLT pour transformer le fichier Docbook ci-joint en DITA.

Je ne suis pas encore certaine du résultat puisqu'il est différent de ce que j'obtiens en le convertissant sur oXygen.

Voici le fichier XSLT :

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:local="http://www.w3.org/2005/xquery-local-functions">
    <xsl:output
        method="xml"
        indent="yes"
        omit-xml-declaration="no"
        standalone="no"
        doctype-public="-//OASIS//DTD DITA Composite//EN"
        doctype-system="ditabase.dtd"
        />
    
	<dita>    
    <xsl:template match="/">
            <topic type="DITA" xml:lang="en">
                <title>Raccourcis OmegaT</title>
            </topic>
            <body>
                <xsl:apply-templates select="tgroup/thead/row"/>
            </body>
    </xsl:template>
    
    <xsl:template match="tgroup/thead/row">
        <entry>
            <xsl:attribute name="id">
                <xsl:value-of select="row/entry"/>
            </xsl:attribute>
            <xsl:apply-templates select="row"/>
        </entry>
    </xsl:template>
	</dita>
</xsl:stylesheet>

J'ai essayé d'appliquer ce que l'on a vu dans le premier exercice de conversion avec XSLT pour transformer le fichier Docbook ci-joint en DITA. Je ne suis pas encore certaine du résultat puisqu'il est différent de ce que j'obtiens en le convertissant sur oXygen. Voici le fichier XSLT : ``` <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:local="http://www.w3.org/2005/xquery-local-functions"> <xsl:output method="xml" indent="yes" omit-xml-declaration="no" standalone="no" doctype-public="-//OASIS//DTD DITA Composite//EN" doctype-system="ditabase.dtd" /> <dita> <xsl:template match="/"> <topic type="DITA" xml:lang="en"> <title>Raccourcis OmegaT</title> </topic> <body> <xsl:apply-templates select="tgroup/thead/row"/> </body> </xsl:template> <xsl:template match="tgroup/thead/row"> <entry> <xsl:attribute name="id"> <xsl:value-of select="row/entry"/> </xsl:attribute> <xsl:apply-templates select="row"/> </entry> </xsl:template> </dita> </xsl:stylesheet> ```

App_ShortCuts.xml.zip

8.7 KiB

🎉 1

ciri added this to the DITA project 2023-04-26 15:40:46 +02:00

brandelune commented

2023-04-26 15:55:16 +02:00

Pourriez-vous attacher le fichier de sortie oXygen et celui que vous obtenez avec cette transformation ?

ciri commented

2023-04-26 16:02:41 +02:00

Pourriez-vous attacher le fichier de sortie oXygen et celui que vous obtenez avec cette transformation ?

> Pourriez-vous attacher le fichier de sortie oXygen et celui que vous obtenez avec cette transformation ?

App_ShortCuts_oXygen.dita.zip

9.0 KiB

App_ShortCuts_TransformationXSLT.xml.zip

7.2 KiB

brandelune commented

2023-04-26 16:26:11 +02:00

Il y a plusieurs problèmes:

le <dita> ne peut pas être hors d'un modèle
le premier modèle qui cherche tgroup, etc. ne trouvera rien parce que tgroup n'est pas un enfant direct de /

Il y a plusieurs problèmes: - le `<dita>` ne peut pas être hors d'un modèle - le premier modèle qui cherche tgroup, etc. ne trouvera rien parce que tgroup n'est pas un enfant direct de /

brandelune commented

2023-04-27 02:52:15 +02:00

Une fois ces problèmes résolus, vous obtiendrez quelque chose qui fonctionne même si ça n'est pas encore satisfaisant.

Le mieux alors serait de recommencer pour tenter de reproduire la sortie d'oXygen, puis de retirer les éléments qui ne vous intéressent pas.

Une fois ces problèmes résolus, vous obtiendrez quelque chose qui fonctionne même si ça n'est pas encore satisfaisant. Le mieux alors serait de recommencer pour tenter de reproduire la sortie d'oXygen, puis de retirer les éléments qui ne vous intéressent pas.

ciri commented

2023-04-28 14:03:04 +02:00

Je pense avoir réussi à obtenir le résultat que je voulais.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:local="http://www.w3.org/2005/xquery-local-functions">

<xsl:output
        method="xml"
        indent="yes"
        omit-xml-declaration="no"
        standalone="no"
        doctype-public="-//OASIS//DTD DITA Composite//EN"
        doctype-system="ditabase.dtd"/>

<xsl:template match="/">
	<dita>
		<section id="app.shortcuts">
			<title id="app.shortcuts.title">
				<xsl:value-of select="section/title"/>
			</title>
         <section id="app.shortcuts.description">
             <title id="app.shortcuts.description.title">
                <xsl:value-of select="section/section/title"/>
            </title>
				<table id="app.shortcut.description">
					<title id="app.shortcut.description.title">
						<xsl:value-of select="section/section/table/title"/>
					</title>
					<tgroup cols="3">
						<thead>
                        	<row>
                            	<entry>
                                	<xsl:value-of select="/section/section/table/tgroup/thead/row/entry[1]"/>
                                </entry>
                                <entry>
                                    <xsl:value-of select="/section/section/table/tgroup/thead/row/entry[2]"/>
                                </entry>
                                <entry>
                                    <xsl:value-of select="/section/section/table/tgroup/thead/row/entry[3]"/>
                                </entry>
                            </row>
                        </thead>
						<tbody>
							<row>
								<entry>
                                	<xsl:value-of select="/section/section/table/tgroup/tbody/row/entry[1]/keycap"/>
                                </entry>
                                <entry>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row/entry[2]/keycap"/>
                                </entry>
                                <entry>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row/entry[3]/keycap[1]"/>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row/entry[3]/keycap[2]"/>
                                </entry>
                            </row>
                            <row>
								<entry>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[1]/keycap"/>
                                </entry>
                                <entry>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[2]/keycap"/>
                                </entry>
                                <entry>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[1]"/>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[2]"/>
                                </entry>
                            </row>
                            <row>
								<entry>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[3]/entry[1]/keycap"/>
                                </entry>
                                <entry>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[3]/entry[2]/keycap"/>
                                </entry>
                                <entry>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[3]/entry[3]/keycap[1]"/>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[3]/entry[3]/keycap[2]"/>
                                </entry>
                            </row>
                            <row>
								<entry>
                                	<xsl:value-of select="/section/section/table/tgroup/tbody/row[4]/entry[1]/keycap"/>
                                </entry>
                                <entry>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[4]/entry[2]/keycap"/>
                                </entry>
                                <entry>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[4]/entry[3]/keycap[1]"/>
                                    <xsl:value-of select="/section/section/table/tgroup/tbody/row[4]/entry[3]/keycap[2]"/>
                                </entry>
                            </row>
                        </tbody>
                    </tgroup>
                </table>
            </section>
        </section>
    </dita>
</xsl:template>
    
</xsl:stylesheet>

Il reste un seul problème à régler, dans le 3e <entry>de chaque élément <row>, il y a deux éléments <keycap> séparés par un « ou ».

Exemple :

<row>
    <entry><keycap>Shift</keycap></entry>
    <entry><keycap>S</keycap></entry>
    <entry><keycap>shift</keycap>ou<keycap>⇧</keycap></entry>
</row>

Cependant, ce « ou » ne s'affiche pas dans le résultat final...

Je pense avoir réussi à obtenir le résultat que je voulais. ``` <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:local="http://www.w3.org/2005/xquery-local-functions"> <xsl:output method="xml" indent="yes" omit-xml-declaration="no" standalone="no" doctype-public="-//OASIS//DTD DITA Composite//EN" doctype-system="ditabase.dtd"/> <xsl:template match="/"> <dita> <section id="app.shortcuts"> <title id="app.shortcuts.title"> <xsl:value-of select="section/title"/> </title> <section id="app.shortcuts.description"> <title id="app.shortcuts.description.title"> <xsl:value-of select="section/section/title"/> </title> <table id="app.shortcut.description"> <title id="app.shortcut.description.title"> <xsl:value-of select="section/section/table/title"/> </title> <tgroup cols="3"> <thead> <row> <entry> <xsl:value-of select="/section/section/table/tgroup/thead/row/entry[1]"/> </entry> <entry> <xsl:value-of select="/section/section/table/tgroup/thead/row/entry[2]"/> </entry> <entry> <xsl:value-of select="/section/section/table/tgroup/thead/row/entry[3]"/> </entry> </row> </thead> <tbody> <row> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row/entry[1]/keycap"/> </entry> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row/entry[2]/keycap"/> </entry> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row/entry[3]/keycap[1]"/> <xsl:value-of select="/section/section/table/tgroup/tbody/row/entry[3]/keycap[2]"/> </entry> </row> <row> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[1]/keycap"/> </entry> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[2]/keycap"/> </entry> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[1]"/> <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[2]"/> </entry> </row> <row> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[3]/entry[1]/keycap"/> </entry> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[3]/entry[2]/keycap"/> </entry> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[3]/entry[3]/keycap[1]"/> <xsl:value-of select="/section/section/table/tgroup/tbody/row[3]/entry[3]/keycap[2]"/> </entry> </row> <row> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[4]/entry[1]/keycap"/> </entry> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[4]/entry[2]/keycap"/> </entry> <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[4]/entry[3]/keycap[1]"/> <xsl:value-of select="/section/section/table/tgroup/tbody/row[4]/entry[3]/keycap[2]"/> </entry> </row> </tbody> </tgroup> </table> </section> </section> </dita> </xsl:template> </xsl:stylesheet> ``` Il reste un seul problème à régler, dans le 3e `<entry>`de chaque élément `<row>`, il y a deux éléments `<keycap>` séparés par un « ou ». Exemple : ``` <row> <entry><keycap>Shift</keycap></entry> <entry><keycap>S</keycap></entry> <entry><keycap>shift</keycap>ou<keycap>⇧</keycap></entry> </row> ``` Cependant, ce « ou » ne s'affiche pas dans le résultat final...

App_ShortCuts_résultat.xml.zip

1.1 KiB

👍 1

brandelune added the

question

label 2023-04-29 02:43:27 +02:00

brandelune commented

2023-04-29 03:27:23 +02:00

la raison pour laquelle "ou" n'est pas inséré

<entry>
  <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[1]"/>
  <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[2]"/>
</entry>

La cible de la 1ère ligne, c'est effectivement le contenu du premier <keycap>, donc par exemple "shift", et la cible de la 2e ligne, c'est effectivement le contenu du second <keycap>, donc "⇧".

Et à aucun moment, vous ne demandez autre chose que ces deux éléments.

Ce que vous pourriez insérer à la place

Et c'est là qu'on trouve l'intérêt des transformations. Ce qui peut être transformé, extrait ou injecté, ce n'est pas seulement les balises, mais également le contenu textuel des éléments. Ici, le code d'origine contient un "ou" entre les <keycap> mais vous pourriez utiliser <xsl:text> pour ajouter un " ou " (ou autre chose) entre le contenu des <keycap> :

<entry>
  <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[1]"/>
  <xsl:text> ou </xsl:text>
  <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[2]"/>
</entry>

Une méthode plus efficace ?

L'étape suivante serait de trouver le moyen d'extraire simplement le contenu de entry[3] en laissant les balises <keycap> de côté, mais en conservant leur contenu ? Ça nous éviterait d'avoir à utiliser 3 instructions.

Généraliser la transformation, étape finale.

Votre fichier est correct, mais il vous oblige à créer une instruction par élément du document source pour obtenir un élément du document cible. Il doit y avoir le moyen de généraliser ça, comme on l'a fait avec la transformation TMX > TBX, pour pouvoir gérer un nombre arbitraire de données.

1. la raison pour laquelle "ou" n'est pas inséré ``` <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[1]"/> <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[2]"/> </entry> ``` La cible de la 1ère ligne, c'est effectivement le contenu du premier `<keycap>`, donc par exemple "shift", et la cible de la 2e ligne, c'est effectivement le contenu du second `<keycap>`, donc "⇧". Et à aucun moment, vous ne demandez autre chose que ces deux éléments. 2. Ce que vous pourriez insérer à la place Et c'est là qu'on trouve l'intérêt des transformations. Ce qui peut être transformé, extrait ou injecté, ce n'est pas seulement les balises, mais également le contenu textuel des éléments. Ici, le code d'origine contient un "ou" entre les `<keycap>` mais vous pourriez utiliser `<xsl:text>` pour ajouter un " ou " (ou autre chose) entre le contenu des `<keycap>` : ``` <entry> <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[1]"/> <xsl:text> ou </xsl:text> <xsl:value-of select="/section/section/table/tgroup/tbody/row[2]/entry[3]/keycap[2]"/> </entry> ``` 3. Une méthode plus efficace ? L'étape suivante serait de trouver le moyen d'extraire simplement le contenu de `entry[3]` en laissant les balises `<keycap>` de côté, mais en conservant leur contenu ? Ça nous éviterait d'avoir à utiliser 3 instructions. 4. Généraliser la transformation, étape finale. Votre fichier est correct, mais il vous oblige à créer une instruction par élément du document source pour obtenir un élément du document cible. Il doit y avoir le moyen de généraliser ça, comme on l'a fait avec la transformation TMX > TBX, pour pouvoir gérer un nombre arbitraire de données.

ciri commented

2023-05-21 13:32:31 +02:00

Je n'ai pas abandonné cet exercice ! Voici ce que j'ai pu faire jusqu'à présent en revoyant la structure de DITA et en reprenant ce que nous avions vu dans l'exercice précédent (TBX > TMX) :

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output
        method="xml"
        indent="yes"
        omit-xml-declaration="no"
        standalone="no"
        doctype-public="-//OASIS//DTD DITA Composite//EN"
        doctype-system="ditabase.dtd"/>
        
  <xsl:template match="/">
	<dita type="topic" xml:lang="en">
	</dita>
	<xsl:apply-templates/>
	</xsl:template>
	

  <xsl:template match="/">
    <xsl:element name="topic">
      <xsl:attribute name="id">app.shortcuts</xsl:attribute>
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="section">
    <xsl:element name="section">
      <xsl:attribute name="id">
        <xsl:value-of select="@id"/>
      </xsl:attribute>
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="title">
    <xsl:element name="title">
      <xsl:attribute name="id">
        <xsl:value-of select="@id"/>
      </xsl:attribute>
      <xsl:value-of select="."/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="table">
    <xsl:element name="table">
      <xsl:attribute name="id">
        <xsl:value-of select="@id"/>
      </xsl:attribute>
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="tgroup">
    <xsl:element name="table">
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="row">
    <xsl:element name="row">
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="entry">
    <xsl:element name="entry">
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="keycap">
    <xsl:element name="keycap">
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

</xsl:stylesheet>

La nouveauté ici est xsl:element, qui permet de créer un élément dans le fichier de sortie (topic, section, title, table, row, entry et keycap) :
XSLT xsl:element
Topic elements - Dita

Je n'ai pas abandonné cet exercice ! Voici ce que j'ai pu faire jusqu'à présent en revoyant la structure de DITA et en reprenant ce que nous avions vu dans l'exercice précédent (TBX > TMX) : ```xml <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" indent="yes" omit-xml-declaration="no" standalone="no" doctype-public="-//OASIS//DTD DITA Composite//EN" doctype-system="ditabase.dtd"/> <xsl:template match="/"> <dita type="topic" xml:lang="en"> </dita> <xsl:apply-templates/> </xsl:template> <xsl:template match="/"> <xsl:element name="topic"> <xsl:attribute name="id">app.shortcuts</xsl:attribute> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="section"> <xsl:element name="section"> <xsl:attribute name="id"> <xsl:value-of select="@id"/> </xsl:attribute> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="title"> <xsl:element name="title"> <xsl:attribute name="id"> <xsl:value-of select="@id"/> </xsl:attribute> <xsl:value-of select="."/> </xsl:element> </xsl:template> <xsl:template match="table"> <xsl:element name="table"> <xsl:attribute name="id"> <xsl:value-of select="@id"/> </xsl:attribute> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="tgroup"> <xsl:element name="table"> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="row"> <xsl:element name="row"> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="entry"> <xsl:element name="entry"> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="keycap"> <xsl:element name="keycap"> <xsl:apply-templates/> </xsl:element> </xsl:template> </xsl:stylesheet> ``` La nouveauté ici est `xsl:element`, qui permet de créer un élément dans le fichier de sortie (`topic`, `section`, `title`, `table`, `row`, `entry` et `keycap`) : [XSLT xsl:element](https://www.w3schools.com/XML/ref_xsl_el_element.asp) [Topic elements - Dita](https://www.oxygenxml.com/dita/1.3/specs/langRef/containers/topic-elements.html)

App_ShortCuts - Résultat.xml.zip

8.6 KiB

brandelune commented

2023-05-21 14:18:48 +02:00

Ça a l'air très bien.

Je ne connais pas DITA donc j'ai quelques questions :

sous le premier title il y a un paragraphe sans balise, mais j'y verrais un truc de type para comme dans DocBook.
avant les deux points il y a une espace insécable en DocBook qui semble être mal convertie.
dans les entry, est-ce qu'il faut quelque chose pour baliser le texte « ou » ?
Après la première table et avant le second title en DocBook il aurait fallu un para, cf. plus haut. Ça se passe comment en DITA ?

Bref, toutes les parties de texte qui ne sont pas correctement balisées me paraissent suspectes. Pourriez-vous vérifier comment ça se passe en DITA ?

En tout cas, ça avance. C'est super.

Ça a l'air très bien. Je ne connais pas DITA donc j'ai quelques questions : - sous le premier `title` il y a un paragraphe sans balise, mais j'y verrais un truc de type `para` comme dans DocBook. - avant les deux points il y a une espace insécable en DocBook qui semble être mal convertie. - dans les `entry`, est-ce qu'il faut quelque chose pour baliser le texte « ou » ? - Après la première `table` et avant le second `title` en DocBook il aurait fallu un `para`, cf. plus haut. Ça se passe comment en DITA ? Bref, toutes les parties de texte qui ne sont pas correctement balisées me paraissent suspectes. Pourriez-vous vérifier comment ça se passe en DITA ? En tout cas, ça avance. C'est super.

ciri commented

2023-05-24 16:53:34 +02:00

sous le premier title il y a un paragraphe sans balise, mais j'y verrais un truc de type para comme dans DocBook.

Tout à fait ! Et c’est un oubli de ma part. En DITA on utilisera plutôt <p> donc je l’ai ajouté comme ceci :

<xsl:template match="para">
 <xsl:element name="p">
  <xsl:value-of select="."/>
 </xsl:element>
</xsl:template>

avant les deux points il y a une espace insécable en DocBook qui semble être mal convertie.

Je ne suis pas sûre d'avoir compris de quoi vous parlez. Est-ce que cela concerne le fichier de sortie ou le code ?

dans les entry, est-ce qu'il faut quelque chose pour baliser le texte « ou » ?

Non, plus besoin d'ajouter quoi que ce soit puisque xsl:element englobe tout ce qui se trouve dans la balise <entry>. Je pense que l'XPath que j'utilisais au début excluait le texte à l'intérieur des balises.

J'ai encore apporté des modifications, car en refaisant un tour sur le fichier que j'avais précédemment converti avec oXygen, j'ai remarqué que :

les balises se transformaient en
la balise qui se trouve au début du code manquait, car je l'avais simplement mal écrite dans le xslt

Voici donc à quoi cela ressemble maintenant :

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output
        method="xml"
        indent="yes"
        omit-xml-declaration="no"
        standalone="no"
        doctype-public="-//OASIS//DTD DITA Composite//EN"
        doctype-system="ditabase.dtd"/>

  <xsl:template match="/">
    <xsl:element name="dita">
    <xsl:element name="topic">
       <xsl:attribute name="xml:lang">en</xsl:attribute>
       <xsl:attribute name="id">app.shortcuts</xsl:attribute>
      <xsl:apply-templates/>
    </xsl:element>
    </xsl:element>
  </xsl:template>

  <xsl:template match="section">
    <xsl:element name="section">
      <xsl:attribute name="id">
        <xsl:value-of select="@id"/>
      </xsl:attribute>
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="title">
    <xsl:element name="title">
      <xsl:attribute name="id">
        <xsl:value-of select="@id"/>
      </xsl:attribute>
    </xsl:element>
  </xsl:template>
  
  <xsl:template match="para">
    <xsl:element name="p">
      <xsl:value-of select="."/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="table">
    <xsl:element name="table">
      <xsl:attribute name="id">
        <xsl:value-of select="@id"/>
      </xsl:attribute>
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="tgroup">
    <xsl:element name="table">
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="row">
    <xsl:element name="row">
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="entry">
    <xsl:element name="entry">
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="keycap">
    <xsl:element name="ph">
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>

</xsl:stylesheet>

> - sous le premier `title` il y a un paragraphe sans balise, mais j'y verrais un truc de type `para` comme dans DocBook. Tout à fait ! Et c’est un oubli de ma part. En DITA on utilisera plutôt `<p>` donc je l’ai ajouté comme ceci : ```xml <xsl:template match="para"> <xsl:element name="p"> <xsl:value-of select="."/> </xsl:element> </xsl:template> ``` > - avant les deux points il y a une espace insécable en DocBook qui semble être mal convertie. Je ne suis pas sûre d'avoir compris de quoi vous parlez. Est-ce que cela concerne le fichier de sortie ou le code ? > - dans les `entry`, est-ce qu'il faut quelque chose pour baliser le texte « ou » ? Non, plus besoin d'ajouter quoi que ce soit puisque `xsl:element` englobe tout ce qui se trouve dans la balise `<entry>`. Je pense que l'XPath que j'utilisais au début excluait le texte à l'intérieur des balises. J'ai encore apporté des modifications, car en refaisant un tour sur le fichier que j'avais précédemment converti avec oXygen, j'ai remarqué que : 1. les balises <keycap> se transformaient en <ph> 2. la balise <dita> qui se trouve au début du code manquait, car je l'avais simplement mal écrite dans le xslt Voici donc à quoi cela ressemble maintenant : ```xml <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" indent="yes" omit-xml-declaration="no" standalone="no" doctype-public="-//OASIS//DTD DITA Composite//EN" doctype-system="ditabase.dtd"/> <xsl:template match="/"> <xsl:element name="dita"> <xsl:element name="topic"> <xsl:attribute name="xml:lang">en</xsl:attribute> <xsl:attribute name="id">app.shortcuts</xsl:attribute> <xsl:apply-templates/> </xsl:element> </xsl:element> </xsl:template> <xsl:template match="section"> <xsl:element name="section"> <xsl:attribute name="id"> <xsl:value-of select="@id"/> </xsl:attribute> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="title"> <xsl:element name="title"> <xsl:attribute name="id"> <xsl:value-of select="@id"/> </xsl:attribute> </xsl:element> </xsl:template> <xsl:template match="para"> <xsl:element name="p"> <xsl:value-of select="."/> </xsl:element> </xsl:template> <xsl:template match="table"> <xsl:element name="table"> <xsl:attribute name="id"> <xsl:value-of select="@id"/> </xsl:attribute> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="tgroup"> <xsl:element name="table"> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="row"> <xsl:element name="row"> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="entry"> <xsl:element name="entry"> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="keycap"> <xsl:element name="ph"> <xsl:apply-templates/> </xsl:element> </xsl:template> </xsl:stylesheet> ```

App_ShortCuts.xml.zip

8.6 KiB

👍 1

brandelune commented

2023-05-24 17:25:46 +02:00

Il manque des choses :

Fichier du 21 :

            <title id="example.avoid.listing.multiple.notations.title">Comment évitons-nous d'énumérer de multiples notations :</title>
            	  Sous Windows et Linux : 
            <keycap>Ctrl</keycap>
            <keycap>Shift</keycap>
            <keycap>N</keycap>
            	  Sous macOS : 
            <keycap>Shift</keycap>
            <keycap>Command</keycap>
            <keycap>N</keycap>
            	  Dans ce manuel : 
            <keycap>C</keycap>
            <keycap>S</keycap>
            <keycap>N</keycap>

Fichier d'aujourd'hui :

                <title id="example.avoid.listing.multiple.notations.title"/>
                	  
                <p>Sous Windows et Linux : CtrlShiftN</p>
                	  
                <p>Sous macOS : ShiftCommandN</p>
                	  
                <p>Dans ce manuel : CSN</p>

Pas sur le texte, sur les balises.

et je voulais dire que ce caractère : " " ne s'affiche pas bien dans BBEdit, et je n'ai pas l'impression que c'est une espace insécable normale ici.

Il manque des choses : Fichier du 21 : ```XML <title id="example.avoid.listing.multiple.notations.title">Comment évitons-nous d'énumérer de multiples notations :</title> Sous Windows et Linux : <keycap>Ctrl</keycap> <keycap>Shift</keycap> <keycap>N</keycap> Sous macOS : <keycap>Shift</keycap> <keycap>Command</keycap> <keycap>N</keycap> Dans ce manuel : <keycap>C</keycap> <keycap>S</keycap> <keycap>N</keycap> ``` Fichier d'aujourd'hui : ```XML <title id="example.avoid.listing.multiple.notations.title"/> <p>Sous Windows et Linux : CtrlShiftN</p> <p>Sous macOS : ShiftCommandN</p> <p>Dans ce manuel : CSN</p> ``` Pas sur le texte, sur les balises. et je voulais dire que ce caractère : " " ne s'affiche pas bien dans BBEdit, et je n'ai pas l'impression que c'est une espace insécable normale ici.

kazephil closed this issue

2023-05-27 10:26:51 +02:00

brandelune reopened this issue

2023-05-27 11:47:52 +02:00

kazephil commented

2023-05-28 04:12:26 +02:00

Désolé pour la fermeture accidentelle du ticket. Je cherchais à annuler un mauvais brouillon, et j'ai évidemment cliqué le mauvais bouton. Oops ! 😰 😧

Je suis en train d'apprendre le DITA sur le tas dans le cadre de mon travail, alors je suis ce ticket avec intérêt.

J'ai enfin eu le temps de regarder les fichiers de sortie d'un peu plus près. Mes connaissances restent encore limitées, mais j'ai remarqué quelques éléments.

Un premier problème est l'imbrication d'éléments <section>. Malgré son nom, en DITA cet élément a un usage limité (généralement dans les rubriques référence) et, malgré son nom, ne représente pas tout à fait ce que l'on imagine quand on pense à une section d'un document.
L'utilisation de l'élément <dita> dans la deuxième tentative m'intrigue. D'après ce que j'ai lu, l'utilité de cet élément est de pouvoir inclure plus d'une rubrique (un élément <topic> ou une de ses versions spécialisées) dans un même fichier, mais cette pratique semble être généralement déconseillée puisque la rédaction en DITA préconise plutôt la création d'une seule rubrique par fichier.

Par contre, il a peut-être une utilité particulière dans un processus de conversion. (Je pense que Oxygen fait ça dans sa conversion, mais j'ai aussi vu des commentaires à propos du Batch Conversion plugin qui effectuerait un meilleur découpage selon les types de rubriques DITA.)

Et ce deuxième point me mène à problème sous-jacent dans l'exercice de conversion :

Même en travaillant chapitre par chapitre, le manuel se prête mal à une conversion directe
en DITA parce qu'il n'est pas suffisamment modulaire par rapport à l'approche structurée qui repose sur des rubriques autonomes courtes qui est au cœur de DITA.

Cela complique le processus de conversion.

Je pense qu'il faudrait donc procéder en quelques étapes :

Convertir le XML DocBook en XML DITA.
Modulariser les chapitres du manuel
Créer une carte (ou des cartes) DITA pour organiser les modules.

(Il faudrait aussi songer à l'ordre de étapes ; les deux premières dans ma liste pourraient être inversées.)

Dans cette optique, le regroupement d'un chapitre dans un élément <dita> pourrait présenter une approche utile si on commence par la conversion et qu'on passe à la modularisation à partir du contenu converti en XML DITA.

Toutefois, je pense qu'avec cette approche, certaines des balises <section>de DITA devraient devenir des rubriques représentées par de balises <topic> (ou encore des balises <concept>, <task> ou <reference>) en DITA. (Mais là, comment identifier les <section> qui représente des rubriques de celles qui représente autre chose ?)

De là, on pourrait peut-être extraire les rubriques dans de fichiers individuels (manuellement ? avec un outil quelconque ?) pour modulariser le contenu.

On peut aussi se demander si on pourrait découper un chapitre en plusieurs documents DITA dans le processus de transformation. Il semble que XSLT 2.0 permet de créer plusieurs documents de sortie à partir d'un seul document d'entrée, tandis qu'avec XSLT 1.0, ça dépend de l'outil utilisé. Certains outils offriraient des extensions avec cette fonctionnalité, d'autres non.

Si on tente de produire plusieurs documents DITA à partir d'un seul chapitre du manuel, il serait peut-être avantageux d'essayer de modulariser le contenu un peu plus à l'avance, peut-être en ajoutant un attribut quelconque aux éléments <section>, ou en les remplaçant par des éléments <sect1>, <sect2>, etc. un peu plus précis. Y aurait-il une meilleure solution ?

Autre point d'interrogation : une conversion du manuel mériterait-elle une réorganisation selon les rubriques techniques proposées par DITA (concept, task, et reference, peut-être avec des rubriques glossaire (glossentry) ou troubleshooting à l'occasion ?

Je n'ai pas de réponses à toutes ces questions, que je me pose autant à moi-même qu'à vous tous.

J'ai l'impression qu'une conversion complète exigera probablement un processus qui combine du XSLT avec d'autres outils, ainsi qu'un certain niveau de travail manuel. Il reste à voir à quel point on pourrait peaufiner les XSLT (ou une combinaison de XSLT et d'un autre programme) pour miniser l'effort manuel requis.

Et enfin, le caractère qui intrigue Jean-Christophe :

et je voulais dire que ce caractère : " " ne s'affiche pas bien dans BBEdit, et je n'ai pas l'impression que c'est une espace insécable normale ici.

Ça a l'air d'être une espace insécable fine.
Il semble y avoir un certain désaccord entre diverses références typographique (et régions de la francophonie) à savoir si l'on devrait précéder les deux-points d'une espace insécable fine ou normale.

Désolé pour la fermeture accidentelle du ticket. Je cherchais à annuler un mauvais brouillon, et j'ai évidemment cliqué le mauvais bouton. Oops ! 😰 😧 Je suis en train d'apprendre le DITA sur le tas dans le cadre de mon travail, alors je suis ce ticket avec intérêt. J'ai enfin eu le temps de regarder les fichiers de sortie d'un peu plus près. Mes connaissances restent encore limitées, mais j'ai remarqué quelques éléments. 1. Un premier problème est l'imbrication d'éléments `<section>`. Malgré son nom, en DITA cet élément a un usage limité (généralement dans les rubriques référence) et, malgré son nom, ne représente pas tout à fait ce que l'on imagine quand on pense à une section d'un document. 2. L'utilisation de l'élément `<dita>` dans la deuxième tentative m'intrigue. D'après ce que j'ai lu, l'utilité de cet élément est de pouvoir inclure plus d'une rubrique (un élément `<topic>` ou une de ses versions spécialisées) dans un même fichier, mais cette pratique semble être généralement déconseillée puisque la rédaction en DITA préconise plutôt la création d'une seule rubrique par fichier. Par contre, il a peut-être une utilité particulière dans un processus de conversion. (Je pense que Oxygen fait ça dans sa conversion, mais j'ai aussi vu des commentaires à propos du Batch Conversion plugin qui effectuerait un meilleur découpage selon les types de rubriques DITA.) Et ce deuxième point me mène à problème sous-jacent dans l'exercice de conversion : Même en travaillant chapitre par chapitre, le manuel se prête mal à une conversion directe en DITA parce qu'il n'est pas suffisamment modulaire par rapport à l'approche structurée qui repose sur des rubriques autonomes courtes qui est au cœur de DITA. Cela complique le processus de conversion. Je pense qu'il faudrait donc procéder en quelques étapes : - Convertir le XML DocBook en XML DITA. - Modulariser les chapitres du manuel - Créer une carte (ou des cartes) DITA pour organiser les modules. (Il faudrait aussi songer à l'ordre de étapes ; les deux premières dans ma liste pourraient être inversées.) Dans cette optique, le regroupement d'un chapitre dans un élément `<dita>` pourrait présenter une approche utile si on commence par la conversion et qu'on passe à la modularisation à partir du contenu converti en XML DITA. Toutefois, je pense qu'avec cette approche, certaines des balises `<section>`de DITA devraient devenir des rubriques représentées par de balises `<topic>` (ou encore des balises `<concept>`, `<task>` ou `<reference>`) en DITA. (Mais là, comment identifier les `<section>` qui représente des rubriques de celles qui représente autre chose ?) De là, on pourrait peut-être extraire les rubriques dans de fichiers individuels (manuellement ? avec un outil quelconque ?) pour modulariser le contenu. On peut aussi se demander si on pourrait découper un chapitre en plusieurs documents DITA dans le processus de transformation. Il semble que XSLT 2.0 permet de créer plusieurs documents de sortie à partir d'un seul document d'entrée, tandis qu'avec XSLT 1.0, ça dépend de l'outil utilisé. Certains outils offriraient des extensions avec cette fonctionnalité, d'autres non. Si on tente de produire plusieurs documents DITA à partir d'un seul chapitre du manuel, il serait peut-être avantageux d'essayer de modulariser le contenu un peu plus à l'avance, peut-être en ajoutant un attribut quelconque aux éléments `<section>`, ou en les remplaçant par des éléments `<sect1>`, `<sect2>`, etc. un peu plus précis. Y aurait-il une meilleure solution ? Autre point d'interrogation : une conversion du manuel mériterait-elle une réorganisation selon les rubriques techniques proposées par DITA (_concept_, _task_, et _reference_, peut-être avec des rubriques glossaire (_glossentry_) ou _troubleshooting_ à l'occasion ? Je n'ai pas de réponses à toutes ces questions, que je me pose autant à moi-même qu'à vous tous. J'ai l'impression qu'une conversion complète exigera probablement un processus qui combine du XSLT avec d'autres outils, ainsi qu'un certain niveau de travail manuel. Il reste à voir à quel point on pourrait peaufiner les XSLT (ou une combinaison de XSLT et d'un autre programme) pour miniser l'effort manuel requis. --- Et enfin, le caractère qui intrigue Jean-Christophe : > et je voulais dire que ce caractère : " " ne s'affiche pas bien dans BBEdit, et je n'ai pas l'impression que c'est une espace insécable normale ici. Ça a l'air d'être une espace insécable fine. Il semble y avoir un certain désaccord entre diverses références typographique (et régions de la francophonie) à savoir si l'on devrait précéder les deux-points d'une espace insécable fine ou normale.

brandelune commented

2023-05-28 04:52:18 +02:00

Désolé pour la fermeture accidentelle du ticket. Je cherchais à annuler un mauvais brouillon, et j’ai évidemment cliqué le mauvais bouton. Oops ! 😰 😧

Hahaha, je pensais que tu avais été piraté. Mais j’ai été surpris par le temps qu’il m’a fallu pour trouver comment réouvrir un ticket.

Je suis en train d’apprendre le DITA sur le tas dans le cadre de mon travail, alors je suis ce ticket avec intérêt.

Excellent !

Même en travaillant chapitre par chapitre, le manuel se prête mal à une conversion directe
en DITA parce qu’il n’est pas suffisamment modulaire par rapport à l’approche structurée qui repose sur des rubriques autonomes courtes qui est au cœur de DITA.

Et c’est là où tu mets le doigt sur l’objectif de l’exercice.

Tu sais qu’on a discuté sur dev de la réécriture du manuel de manière plus modulaire. La dernière version de DocBook semble bien se prêter à l’exercice, mais je veux aussi explorer ce que DITA propose, même si je n’ai pas envie de tomber dans un autre terrier à lapin (marrant cette expression, ça passe bien en anglais, mais moyen en français, et je ne sais même pas si on a un équivalent… Tu sais si ça vient de Lewis Carroll ?).

Bref, ici, il était question plutôt de travailler manuellement avec XSLT, puisqu’il existe déjà des outils de conversion DocBook/DITA, et de produire un document DITA valide pour lui appliquer la mémoire de traduction créée dans le processus de traduction du DocBooc que de s’intéresser en détail (mais si on le fait, c’est bien aussi) à la valeur intrinsèque du document produit en tant que document DITA.

L’idée très limitée de cet exercice, c’est avant tout d’apprendre à créer un XSLT qui propose une sortie satisfaisante, dans les limites de la structure du fichier d’origine.

Cela complique le processus de conversion.

Je pense qu’il faudrait donc procéder en quelques étapes :

Convertir le XML DocBook en XML DITA.

Modulariser les chapitres du manuel

Créer une carte (ou des cartes) DITA pour organiser les modules.

Et dans l’esprit décrit ci-dessus, ça serait intéressant de pousser la modularisation du DocBook au maximum, et de voir quels sont les avantages/désavantages des deux formats (en considérant « presque » exclusivement la chaîne de production d’une sortie utilisable, soit en HTML, soit en PDF, soit en un truc qui est directement intégrable à OmegaT, si ça existe, etc., vu que les formats en eux-mêmes n’ont pas grand intérêt).

On peut aussi se demander si on pourrait découper un chapitre en plusieurs documents DITA dans le processus de transformation. Il semble que XSLT 2.0 permet de créer plusieurs documents de sortie à partir d’un seul document d’entrée, tandis qu’avec XSLT 1.0, ça dépend de l’outil utilisé. Certains outils offriraient des extensions avec cette fonctionnalité, d’autres non.

Avec 6.n, j’envisage de mettre à jour notre chaîne d’outils DocBook pour la sortie du HTML/PDF. Je n’avais pas trop envie de mettre le doigt dans cet engrenage-là lors de la mise à jour du manuel. Mais une fois qu’on aura plus de temps, on pourra faire des essais.

Je ne peux pas dire que j’ai acquis une grosse compétence en XSLT lors de ce stage 😅, et je remercie @ciri de tenter de boucler ce projet, mais je compte bien étudier notre transformation HTML parce qu’il y a des choses qui me chagrinent. Et pour le moment, le bidouillage que j’ai fait (essentiellement, effacer des trucs sans trop savoir pourquoi, mais ça produisait ce que je voulais) c’est quand même le niveau 0 de l’écriture (pour ne pas dire -1).

Autre point d’interrogation : une conversion du manuel mériterait-elle une réorganisation selon les rubriques techniques proposées par DITA (concept, task, et reference, peut-être avec des rubriques glossaire (glossentry) ou troubleshooting à l’occasion ?

Oui, je pense. Et je pense aussi qu’on peut adopter ce type de structure dans le cadre de DocBook dans un premier temps.

Je n’ai pas de réponses à toutes ces questions, que je me pose autant à moi-même qu’à vous tous.

Bon, et bien tu vois maintenant où j’aimerais aller avec les futures versions d’OmegaT donc on pourra en discuter sur dev une fois la page de ce stage tournée.

Et enfin, le caractère qui intrigue Jean-Christophe :

et je voulais dire que ce caractère : « » ne s’affiche pas bien dans BBEdit, et je n’ai pas l’impression que c’est une espace insécable normale ici.

Ça a l’air d’être une espace insécable fine.
Il semble y avoir un certain désaccord entre diverses références typographique (et régions de la francophonie) à savoir si l’on devrait précéder les deux-points d’une espace insécable fine ou normale.

Moi, je fais confiance à Antidote. Si on doit adopter la typo canadienne comme tu l’as fait pour l’anglais (et la langue en général), ça ne me pose pas de problème.

> Désolé pour la fermeture accidentelle du ticket. Je cherchais à annuler un mauvais brouillon, et j’ai évidemment cliqué le mauvais bouton. Oops ! 😰 😧 Hahaha, je pensais que tu avais été piraté. Mais j’ai été surpris par le temps qu’il m’a fallu pour trouver comment réouvrir un ticket. > Je suis en train d’apprendre le DITA sur le tas dans le cadre de mon travail, alors je suis ce ticket avec intérêt. Excellent ! > Même en travaillant chapitre par chapitre, le manuel se prête mal à une conversion directe > en DITA parce qu’il n’est pas suffisamment modulaire par rapport à l’approche structurée qui repose sur des rubriques autonomes courtes qui est au cœur de DITA. Et c’est là où tu mets le doigt sur l’objectif de l’exercice. Tu sais qu’on a discuté sur dev de la réécriture du manuel de manière plus modulaire. La dernière version de DocBook semble bien se prêter à l’exercice, mais je veux aussi explorer ce que DITA propose, même si je n’ai pas envie de tomber dans un autre terrier à lapin (marrant cette expression, ça passe bien en anglais, mais moyen en français, et je ne sais même pas si on a un équivalent… Tu sais si ça vient de Lewis Carroll ?). Bref, ici, il était question plutôt de travailler manuellement avec XSLT, puisqu’il existe déjà des outils de conversion DocBook/DITA, et de produire un document DITA valide pour lui appliquer la mémoire de traduction créée dans le processus de traduction du DocBooc que de s’intéresser en détail (mais si on le fait, c’est bien aussi) à la valeur intrinsèque du document produit en tant que document DITA. L’idée très limitée de cet exercice, c’est avant tout d’apprendre à créer un XSLT qui propose une sortie satisfaisante, dans les limites de la structure du fichier d’origine. > Cela complique le processus de conversion. > > Je pense qu’il faudrait donc procéder en quelques étapes : > - Convertir le XML DocBook en XML DITA. > - Modulariser les chapitres du manuel > - Créer une carte (ou des cartes) DITA pour organiser les modules. Et dans l’esprit décrit ci-dessus, ça serait intéressant de pousser la modularisation du DocBook au maximum, et de voir quels sont les avantages/désavantages des deux formats (en considérant « presque » exclusivement la chaîne de production d’une sortie utilisable, soit en HTML, soit en PDF, soit en un truc qui est directement intégrable à OmegaT, si ça existe, etc., vu que les formats en eux-mêmes n’ont pas grand intérêt). > On peut aussi se demander si on pourrait découper un chapitre en plusieurs documents DITA dans le processus de transformation. Il semble que XSLT 2.0 permet de créer plusieurs documents de sortie à partir d’un seul document d’entrée, tandis qu’avec XSLT 1.0, ça dépend de l’outil utilisé. Certains outils offriraient des extensions avec cette fonctionnalité, d’autres non. Avec 6.n, j’envisage de mettre à jour notre chaîne d’outils DocBook pour la sortie du HTML/PDF. Je n’avais pas trop envie de mettre le doigt dans cet engrenage-là lors de la mise à jour du manuel. Mais une fois qu’on aura plus de temps, on pourra faire des essais. Je ne peux pas dire que j’ai acquis une grosse compétence en XSLT lors de ce stage 😅, et je remercie @ciri de tenter de boucler ce projet, mais je compte bien étudier notre transformation HTML parce qu’il y a des choses qui me chagrinent. Et pour le moment, le bidouillage que j’ai fait (essentiellement, effacer des trucs sans trop savoir pourquoi, mais ça produisait ce que je voulais) c’est quand même le niveau 0 de l’écriture (pour ne pas dire -1). > Autre point d’interrogation : une conversion du manuel mériterait-elle une réorganisation selon les rubriques techniques proposées par DITA (_concept_, _task_, et _reference_, peut-être avec des rubriques glossaire (_glossentry_) ou _troubleshooting_ à l’occasion ? Oui, je pense. Et je pense aussi qu’on peut adopter ce type de structure dans le cadre de DocBook dans un premier temps. > Je n’ai pas de réponses à toutes ces questions, que je me pose autant à moi-même qu’à vous tous. Bon, et bien tu vois maintenant où j’aimerais aller avec les futures versions d’OmegaT donc on pourra en discuter sur dev une fois la page de ce stage tournée. > Et enfin, le caractère qui intrigue Jean-Christophe : > > et je voulais dire que ce caractère : « » ne s’affiche pas bien dans BBEdit, et je n’ai pas l’impression que c’est une espace insécable normale ici. > > Ça a l’air d’être une espace insécable fine. > Il semble y avoir un certain désaccord entre diverses références typographique (et régions de la francophonie) à savoir si l’on devrait précéder les deux-points d’une espace insécable fine ou normale. Moi, je fais confiance à Antidote. Si on doit adopter la typo canadienne comme tu l’as fait pour l’anglais (et la langue en général), ça ne me pose pas de problème.

kazephil commented

2023-05-28 10:19:17 +02:00

Désolé pour la fermeture accidentelle du ticket. Je cherchais à annuler un mauvais brouillon, et j’ai évidemment cliqué le mauvais bouton. Oops ! 😰 😧

Hahaha, je pensais que tu avais été piraté. Mais j’ai été surpris par le temps qu’il m’a fallu pour trouver comment réouvrir un ticket.

Shiver me timbers!

Au moins je t'aurai donné la chance d'apprendre quelque chose de nouveau !

Même en travaillant chapitre par chapitre, le manuel se prête mal à une conversion directe
en DITA parce qu’il n’est pas suffisamment modulaire par rapport à l’approche structurée qui repose sur des rubriques autonomes courtes qui est au cœur de DITA.

Et c’est là où tu mets le doigt sur l’objectif de l’exercice.

Tu sais qu’on a discuté sur dev de la réécriture du manuel de manière plus modulaire. La dernière version de DocBook semble bien se prêter à l’exercice, mais je veux aussi explorer ce que DITA propose, même si je n’ai pas envie de tomber dans un autre terrier à lapin (marrant cette expression, ça passe bien en anglais, mais moyen en français, et je ne sais même pas si on a un équivalent… Tu sais si ça vient de Lewis Carroll ?).

Les terriers à lapin, ça vient indubitablement de Carroll, mais aucun aussi bon équivalent français ne me vient à l'esprit.

Et réécrire le manuel de façon plus modulaire, c'est quelque chose que je veux travailler une fois qu'on aura bouclé la sortie de 5.8/6.0.

Bref, ici, il était question plutôt de travailler manuellement avec XSLT, puisqu’il existe déjà des outils de conversion DocBook/DITA, et de produire un document DITA valide pour lui appliquer la mémoire de traduction créée dans le processus de traduction du DocBooc que de s’intéresser en détail (mais si on le fait, c’est bien aussi) à la valeur intrinsèque du document produit en tant que document DITA.

Le diable se cache dans les détails… 👺

L’idée très limitée de cet exercice, c’est avant tout d’apprendre à créer un XSLT qui propose une sortie satisfaisante, dans les limites de la structure du fichier d’origine.

À ce niveau, @ciri y est presque : il suffit d'éviter d'imbriquer des éléments <section> dans le document de sortie.

Cela complique le processus de conversion.

Je pense qu’il faudrait donc procéder en quelques étapes :

Convertir le XML DocBook en XML DITA.

Modulariser les chapitres du manuel

Créer une carte (ou des cartes) DITA pour organiser les modules.

Et dans l’esprit décrit ci-dessus, ça serait intéressant de pousser la modularisation du DocBook au maximum, et de voir quels sont les avantages/désavantages des deux formats (en considérant « presque » exclusivement la chaîne de production d’une sortie utilisable, soit en HTML, soit en PDF, soit en un truc qui est directement intégrable à OmegaT, si ça existe, etc., vu que les formats en eux-mêmes n’ont pas grand intérêt).

Dans un premier temps, je pense que DocBook a une orientation plus narrative par rapport à la rédaction du contenu. Même si on adopted une certaine modularité dans le processus, les modules sont généralement envisagés dans le contexte d'un livre ou autre publication complète en soi.

En DITA, tout est entièrement axé sur la création de petites unités autonomes de contenu qui doivent être assemblées pour former un tout.

Avec 6.n, j’envisage de mettre à jour notre chaîne d’outils DocBook pour la sortie du HTML/PDF. Je n’avais pas trop envie de mettre le doigt dans cet engrenage-là lors de la mise à jour du manuel. Mais une fois qu’on aura plus de temps, on pourra faire des essais.

À ce sujet, j'ai diverses idées sur les différents aspects documentation (certaines contradictoire !). Je vais les organiser de façon cohérente et envoyer un message sur la liste au cours des prochaines semaines.

De toute façon, il va bien falloir que je commence à agir en peu à titre de "documentation manager"… 😄

Je ne peux pas dire que j’ai acquis une grosse compétence en XSLT lors de ce stage 😅, et je remercie @ciri de tenter de boucler ce projet, mais je compte bien étudier notre transformation HTML parce qu’il y a des choses qui me chagrinent. Et pour le moment, le bidouillage que j’ai fait (essentiellement, effacer des trucs sans trop savoir pourquoi, mais ça produisait ce que je voulais) c’est quand même le niveau 0 de l’écriture (pour ne pas dire -1).

Le HTML et le CSS sont sur ma (longue) liste de choses à étudier et approfondir.

Autre point d’interrogation : une conversion du manuel mériterait-elle une réorganisation selon les rubriques techniques proposées par DITA (concept, task, et reference, peut-être avec des rubriques glossaire (glossentry) ou troubleshooting à l’occasion ?

Oui, je pense. Et je pense aussi qu’on peut adopter ce type de structure dans le cadre de DocBook dans un premier temps.

Probablement, surtout si on passe à DocBook 5.0.

Je n’ai pas de réponses à toutes ces questions, que je me pose autant à moi-même qu’à vous tous.

Bon, et bien tu vois maintenant où j’aimerais aller avec les futures versions d’OmegaT donc on pourra en discuter sur dev une fois la page de ce stage tournée.

En effet! D'ici là, je vais mettre un peu d'ordre dans mes idées pour les rendre présentables.

Ça a l’air d’être une espace insécable fine.
Il semble y avoir un certain désaccord entre diverses références typographique (et régions de la francophonie) à savoir si l’on devrait précéder les deux-points d’une espace insécable fine ou normale.

Moi, je fais confiance à Antidote. Si on doit adopter la typo canadienne comme tu l’as fait pour l’anglais (et la langue en général), ça ne me pose pas de problème.

J'ai entendu parler d'Antidote, mais je ne l'ai jamais utilisé. Ce n'est pas une question de devoir, mais simplement une question de choisir quelles règles typographiques on veut utiliser dans le cadre de OmegaT l10n-fr.

> > Désolé pour la fermeture accidentelle du ticket. Je cherchais à annuler un mauvais brouillon, et j’ai évidemment cliqué le mauvais bouton. Oops ! 😰 😧 > > Hahaha, je pensais que tu avais été piraté. Mais j’ai été surpris par le temps qu’il m’a fallu pour trouver comment réouvrir un ticket. Shiver me timbers! Au moins je t'aurai donné la chance d'apprendre quelque chose de nouveau ! > > Même en travaillant chapitre par chapitre, le manuel se prête mal à une conversion directe > > en DITA parce qu’il n’est pas suffisamment modulaire par rapport à l’approche structurée qui repose sur des rubriques autonomes courtes qui est au cœur de DITA. > > Et c’est là où tu mets le doigt sur l’objectif de l’exercice. > > Tu sais qu’on a discuté sur dev de la réécriture du manuel de manière plus modulaire. La dernière version de DocBook semble bien se prêter à l’exercice, mais je veux aussi explorer ce que DITA propose, même si je n’ai pas envie de tomber dans un autre terrier à lapin (marrant cette expression, ça passe bien en anglais, mais moyen en français, et je ne sais même pas si on a un équivalent… Tu sais si ça vient de Lewis Carroll ?). Les terriers à lapin, ça vient indubitablement de Carroll, mais aucun aussi bon équivalent français ne me vient à l'esprit. Et réécrire le manuel de façon plus modulaire, c'est quelque chose que je veux travailler une fois qu'on aura bouclé la sortie de 5.8/6.0. > Bref, ici, il était question plutôt de travailler manuellement avec XSLT, puisqu’il existe déjà des outils de conversion DocBook/DITA, et de produire un document DITA valide pour lui appliquer la mémoire de traduction créée dans le processus de traduction du DocBooc que de s’intéresser en détail (mais si on le fait, c’est bien aussi) à la valeur intrinsèque du document produit en tant que document DITA. Le diable se cache dans les détails… :japanese_goblin: > L’idée très limitée de cet exercice, c’est avant tout d’apprendre à créer un XSLT qui propose une sortie satisfaisante, dans les limites de la structure du fichier d’origine. À ce niveau, @ciri y est presque : il suffit d'éviter d'imbriquer des éléments `<section>` dans le document de sortie. > > Cela complique le processus de conversion. > > > > Je pense qu’il faudrait donc procéder en quelques étapes : > > - Convertir le XML DocBook en XML DITA. > > - Modulariser les chapitres du manuel > > - Créer une carte (ou des cartes) DITA pour organiser les modules. > > Et dans l’esprit décrit ci-dessus, ça serait intéressant de pousser la modularisation du DocBook au maximum, et de voir quels sont les avantages/désavantages des deux formats (en considérant « presque » exclusivement la chaîne de production d’une sortie utilisable, soit en HTML, soit en PDF, soit en un truc qui est directement intégrable à OmegaT, si ça existe, etc., vu que les formats en eux-mêmes n’ont pas grand intérêt). Dans un premier temps, je pense que DocBook a une orientation plus narrative par rapport à la rédaction du contenu. Même si on adopted une certaine modularité dans le processus, les modules sont généralement envisagés dans le contexte d'un livre ou autre publication complète en soi. En DITA, tout est entièrement axé sur la création de petites unités autonomes de contenu qui doivent être assemblées pour former un tout. > Avec 6.n, j’envisage de mettre à jour notre chaîne d’outils DocBook pour la sortie du HTML/PDF. Je n’avais pas trop envie de mettre le doigt dans cet engrenage-là lors de la mise à jour du manuel. Mais une fois qu’on aura plus de temps, on pourra faire des essais. À ce sujet, j'ai diverses idées sur les différents aspects documentation (certaines contradictoire !). Je vais les organiser de façon cohérente et envoyer un message sur la liste au cours des prochaines semaines. De toute façon, il va bien falloir que je commence à agir en peu à titre de "documentation manager"… :smile: > Je ne peux pas dire que j’ai acquis une grosse compétence en XSLT lors de ce stage 😅, et je remercie @ciri de tenter de boucler ce projet, mais je compte bien étudier notre transformation HTML parce qu’il y a des choses qui me chagrinent. Et pour le moment, le bidouillage que j’ai fait (essentiellement, effacer des trucs sans trop savoir pourquoi, mais ça produisait ce que je voulais) c’est quand même le niveau 0 de l’écriture (pour ne pas dire -1). Le HTML et le CSS sont sur ma (longue) liste de choses à étudier et approfondir. > > Autre point d’interrogation : une conversion du manuel mériterait-elle une réorganisation selon les rubriques techniques proposées par DITA (_concept_, _task_, et _reference_, peut-être avec des rubriques glossaire (_glossentry_) ou _troubleshooting_ à l’occasion ? > > Oui, je pense. Et je pense aussi qu’on peut adopter ce type de structure dans le cadre de DocBook dans un premier temps. Probablement, surtout si on passe à DocBook 5.0. > > Je n’ai pas de réponses à toutes ces questions, que je me pose autant à moi-même qu’à vous tous. > > Bon, et bien tu vois maintenant où j’aimerais aller avec les futures versions d’OmegaT donc on pourra en discuter sur dev une fois la page de ce stage tournée. En effet! D'ici là, je vais mettre un peu d'ordre dans mes idées pour les rendre présentables. --- > > > > Ça a l’air d’être une espace insécable fine. > > Il semble y avoir un certain désaccord entre diverses références typographique (et régions de la francophonie) à savoir si l’on devrait précéder les deux-points d’une espace insécable fine ou normale. > > Moi, je fais confiance à Antidote. Si on doit adopter la typo canadienne comme tu l’as fait pour l’anglais (et la langue en général), ça ne me pose pas de problème. J'ai entendu parler d'_Antidote_, mais je ne l'ai jamais utilisé. Ce n'est pas une question de devoir, mais simplement une question de choisir quelles règles typographiques on veut utiliser dans le cadre de _OmegaT l10n-fr_.

Sign in to join this conversation.