Pourquoi nous tronquons - Revision history

Bech: Lien page anglaise

2014-10-08T08:43:26Z

Lien page anglaise

Bech: Numérotation parties + ortho

2013-01-29T19:51:02Z

Numérotation parties + ortho

Bech: Création page

2012-11-11T00:24:22Z

Création page

New page

Dans les paires de langues Apertium, on conserve les dictionnaires unilingues et bilingues ''tronqués'', ainsi chaque entrée de l'analyseur aura une correspondance dans le dictionnaire bilingue, et toutes les sorties du transfert auront une entrée dans le générateur.<ref>Typiquement ça marche pour les deux directions de traduction, bien qu'une paire de langues seulement validée pour une direction puisse seulement être tronquée dans cette direction.</ref>

Il y a plusieurs raisons pour faire ça :

# Si un mot n'a pas d'entrée dans le dictionnaire bilingue, il sera envoyé en sortie comme un lemme analysé avec un '@' au début, ex : "canaux" sera envoyé en sortie comme "@canal", et pire : Un multi-mot comme "pomme de terre" sera envoyé en sortie comme "@pomme" (ou, avec les symboles de debug désactivés, "canal" et "pomme"). Cela signifie que lors de la post-édition, le post-éditeur devra constamment regarder le texte de la langue source (alors qu'un mot inconnu sera possible à traduire sur le champ). Et when gisting (???), le lecteur pourrait être trompé par une mauvaise compréhension du contenu, au lieu d'observer qu'il y a un mot inconnu.

# Les règles de transfert utilisent assez souvent l'information sur la langue cible du dictionnaire bilingue pour remplir des balises etc... Si le transfert d'anglais à espagnol lit un fragment comme "the children" (les enfants), le déterminant (article) espagnol a besoin de récupérer l'information nombre et genre du nom de la ''langue cible''. Ce n'est pas assez de regarder la sortie de l'analyseur de la langue source, le nombre peut être changé par le dictionnaire bilingue pour certains noms, et le genre n'est même pas présent dans la langue source. La règle de transfert s'attend à avoir cette information; sans elle, non seulement le nom sera écrit comme @lemme, mais le déterminant (article) ne sera pas généré correctement non plus. Cet effet devient même pire avec de plus gros fragments.

#* On pourrait travailler autour de ça en ayant des exceptions dans les règles de transfert pour par exemple deviner le nombre et le gendre si le dictionnaire bilingue n'en donne aucun, mais ça mène à un énorme accroissement de la complexité du transfert – toutes les balises doivent être présumées inconnues, et le temps du développeur est gaspillé dans la chasse aux bugs et travaux annexes au lieu d'améliorer la qualité de traduction.

# Bien qu'il pourrait y avoir une solution technique pour transporter le mot source s'il n'est pas dans le dictionnaire bilingue (<code>lt-proc -o</code>), ça mène à des problèmes avec les composants et autres multi-mots qui sont découpés en deux unités lexicales avant l'examen du dictionnaire bilingue : Que faites-vous quand une partie d'un multi-mot est inconnue ? Par exemple, si on a ^writes about/write<vblex>+about<pr>$, c'est actuellement découpé avant l'examen du dictionnaire bilingue en deux unités ^write<vblex>$ ^about<pr>$, sans les lemmes, et si seulement l'un des deux est inconnu avant l'examen du dictionnaire bilingue, l'autre sera toujours traduit : ^write<vblex>/escribir<vblex>$ ^about<pr>/@about<pr>$. Si, au contraire, on allait garder la forme de surface, on l'aurait aussi gardée comme une unité dans l'examen du dictionnaire bilingue, ainsi si des parties du multi-mot étaient inconnues, tout l'ensemble serait marqué inconnu, donnant quelque-chose comme ^@writes about/write<vblex>+@about<pr>$.

#* Ne pouvez-vous pas juste distribuer la forme de surface par delà (?) les deux unités ? ^writes/write<vblex>$ ^about/about<pr>$! Lorsque dans cet exemple construit, le découpage est sur un espace, il pourrait être n'importe où. La forme de surface ne donne pas d'indication générale sur l'endroit. Nous avons des multi-mots qui se découpent au milieu de contractions (^au/à<pr>+le<det><def><m><sg>$), ou au milieu de composants (^vasskokaren/vatn<n>+kokar<n>$)

Il y a maintenant plusieurs manières de [[tronquer automatiquement un dictionnaire morphologique]], donc il est parfaitement possible de garder un dictionnaire morphologique principal complet, utilisé par plusieurs paires de langues, qui pour chaque paire de langues individuelle est compilé comme dictionnaire morphologique tronqué pour l'analyse.

== Notes de bas de page ==

<references/>

== Voir aussi==

* [[Tronquer automatiquement un dictionnaire morphologique]]
* [[Test de vocabulaire]]
* [http://wiki.apertium.eu/index.php/Session_7 Session 7: Consistance des données et qualité] sur wiki.apertium.eu

[[Category:Quality control]]
[[Category:Development]]
[[Category:Documentation en français]]

← Older revision		Revision as of 08:43, 8 October 2014
Line 1:		Line 1:
			[[Why we trim\|In English]]

	Dans les paires de langues Apertium, on conserve les dictionnaires unilingues et bilingues ''tronqués'', ainsi chaque entrée de l'analyseur aura une correspondance dans le dictionnaire bilingue, et toutes les sorties du transfert auront une entrée dans le générateur.<ref>Typiquement ça marche pour les deux directions de traduction, bien qu'une paire de langues seulement validée pour une direction puisse seulement être tronquée dans cette direction.</ref>		Dans les paires de langues Apertium, on conserve les dictionnaires unilingues et bilingues ''tronqués'', ainsi chaque entrée de l'analyseur aura une correspondance dans le dictionnaire bilingue, et toutes les sorties du transfert auront une entrée dans le générateur.<ref>Typiquement ça marche pour les deux directions de traduction, bien qu'une paire de langues seulement validée pour une direction puisse seulement être tronquée dans cette direction.</ref>

@@ Line 3: / Line 3: @@
 Il y a plusieurs raisons pour faire ça :
-# Si un mot n'a pas d'entrée dans le dictionnaire bilingue, il sera envoyé en sortie comme un lemme analysé avec un '@' au début, ex : "canaux" sera envoyé en sortie comme "@canal", et pire : Un multi-mot comme "pomme de terre" sera envoyé en sortie comme "@pomme" (ou, avec les symboles de debug désactivés, "canal" et "pomme"). Cela signifie que lors de la post-édition, le post-éditeur devra constamment regarder le texte de la langue source (alors qu'un mot inconnu sera possible à traduire sur le champ). Et when gisting (???), le lecteur pourrait être trompé par une mauvaise compréhension du contenu, au lieu d'observer qu'il y a un mot inconnu.
+# Si un mot n'a pas d'entrée dans le dictionnaire bilingue, il sera envoyé en sortie comme un lemme analysé avec un '@' au début, ex : "canaux" sera envoyé en sortie comme "@canal", et pire : Un multi-mot comme "pomme de terre" sera envoyé en sortie comme "@pomme" (ou, avec les symboles de debug désactivés, "canal" et "pomme"). Cela signifie que lors de la post-édition, le post-éditeur devra constamment regarder le texte de la langue source (alors qu'un mot inconnu sera possible à traduire sur le champ). Et when gisting (???), le lecteur pourrait être trompé par une mauvaise compréhension du contenu, au lieu d'observer qu'il y a un mot inconnu.<br/>
+# Les règles de transfert utilisent assez souvent l'information sur la langue cible du dictionnaire bilingue pour remplir des balises etc... Si le transfert d'anglais à espagnol lit un fragment comme "the children" (les enfants), le déterminant (article) espagnol a besoin de récupérer l'information nombre et genre du nom de la ''langue cible''. Ce n'est pas assez de regarder la sortie de l'analyseur de la langue source, le nombre peut être changé par le dictionnaire bilingue pour certains noms, et le genre n'est même pas présent dans la langue source. La règle de transfert s'attend à avoir cette information; sans elle, non seulement le nom sera écrit comme @lemme, mais le déterminant (article) ne sera pas généré correctement non plus. Cet effet devient même pire avec de plus gros fragments.<br/>
+#* On pourrait travailler autour de ça en ayant des exceptions dans les règles de transfert pour par exemple deviner le nombre et le genre si le dictionnaire bilingue n'en donne aucun, mais ça mène à un énorme accroissement de la complexité du transfert – toutes les balises doivent être présumées inconnues, et le temps du développeur est gaspillé dans la chasse aux bugs et travaux annexes au lieu d'améliorer la qualité de traduction.<br/>
-# Les règles de transfert utilisent assez souvent l'information sur la langue cible du dictionnaire bilingue pour remplir des balises etc... Si le transfert d'anglais à espagnol lit un fragment comme "the children" (les enfants), le déterminant (article) espagnol a besoin de récupérer l'information nombre et genre du nom de la ''langue cible''. Ce n'est pas assez de regarder la sortie de l'analyseur de la langue source, le nombre peut être changé par le dictionnaire bilingue pour certains noms, et le genre n'est même pas présent dans la langue source. La règle de transfert s'attend à avoir cette information; sans elle, non seulement le nom sera écrit comme @lemme, mais le déterminant (article) ne sera pas généré correctement non plus. Cet effet devient même pire avec de plus gros fragments.
+# Bien qu'il pourrait y avoir une solution technique pour transporter le mot source s'il n'est pas dans le dictionnaire bilingue (<code>lt-proc -o</code>), ça mène à des problèmes avec les composants et autres multi-mots qui sont découpés en deux unités lexicales avant l'examen du dictionnaire bilingue : Que faites-vous quand une partie d'un multi-mot est inconnue ? Par exemple, si on a ^writes about/write&lt;vblex&gt;+about&lt;pr&gt;$, c'est actuellement découpé avant l'examen du dictionnaire bilingue en deux unités ^write&lt;vblex&gt;$ ^about&lt;pr&gt;$, sans les lemmes, et si seulement l'un des deux est inconnu avant l'examen du dictionnaire bilingue, l'autre sera toujours traduit : ^write&lt;vblex&gt;/escribir&lt;vblex&gt;$ ^about&lt;pr&gt;/@about&lt;pr&gt;$. Si, au contraire, on allait garder la forme de surface, on l'aurait aussi gardée comme une unité dans l'examen du dictionnaire bilingue, ainsi si des parties du multi-mot étaient inconnues, tout l'ensemble serait marqué inconnu, donnant quelque-chose comme ^@writes about/write&lt;vblex&gt;+@about&lt;pr&gt;$. <br/>
-#* On pourrait travailler autour de ça en ayant des exceptions dans les règles de transfert pour par exemple deviner le nombre et le gendre si le dictionnaire bilingue n'en donne aucun, mais ça mène à un énorme accroissement de la complexité du transfert – toutes les balises doivent être présumées inconnues, et le temps du développeur est gaspillé dans la chasse aux bugs et travaux annexes au lieu d'améliorer la qualité de traduction.
-# Bien qu'il pourrait y avoir une solution technique pour transporter le mot source s'il n'est pas dans le dictionnaire bilingue (<code>lt-proc -o</code>), ça mène à des problèmes avec les composants et autres multi-mots qui sont découpés en deux unités lexicales avant l'examen du dictionnaire bilingue : Que faites-vous quand une partie d'un multi-mot est inconnue ? Par exemple, si on a ^writes about/write&lt;vblex&gt;+about&lt;pr&gt;$, c'est actuellement découpé avant l'examen du dictionnaire bilingue en deux unités ^write&lt;vblex&gt;$ ^about&lt;pr&gt;$, sans les lemmes, et si seulement l'un des deux est inconnu avant l'examen du dictionnaire bilingue, l'autre sera toujours traduit : ^write&lt;vblex&gt;/escribir&lt;vblex&gt;$ ^about&lt;pr&gt;/@about&lt;pr&gt;$. Si, au contraire, on allait garder la forme de surface, on l'aurait aussi gardée comme une unité dans l'examen du dictionnaire bilingue, ainsi si des parties du multi-mot étaient inconnues, tout l'ensemble serait marqué inconnu, donnant quelque-chose comme ^@writes about/write&lt;vblex&gt;+@about&lt;pr&gt;$.
 #* Ne pouvez-vous pas juste distribuer la forme de surface par delà (?) les deux unités ? ^writes/write&lt;vblex&gt;$ ^about/about&lt;pr&gt;$! Lorsque dans cet exemple construit, le découpage est sur un espace, il pourrait être n'importe où. La forme de surface ne donne pas  d'indication générale sur l'endroit. Nous avons des multi-mots qui se découpent au milieu de contractions (^au/à&lt;pr&gt;+le&lt;det&gt;&lt;def&gt;&lt;m&gt;&lt;sg&gt;$), ou au milieu de composants (^vasskokaren/vatn&lt;n&gt;+kokar&lt;n&gt;$)