Assimilation and Dissemination - Revision history

ScoopGracie: /* How to make an MT system useful */ It has now expanded.

2020-01-26T15:44:16Z

How to make an MT system useful: It has now expanded.

Unhammer: /* Notes */

2014-10-02T06:36:56Z

Notes

Unhammer at 07:30, 19 June 2014

2014-06-19T07:30:44Z

Unhammer: -emacs

2014-06-13T09:32:45Z

-emacs

Unhammer at 09:31, 13 June 2014

2014-06-13T09:31:59Z

Unhammer: wops!

2014-06-13T09:05:27Z

wops!

Unhammer at 09:03, 13 June 2014

2014-06-13T09:03:39Z

Unhammer at 08:42, 13 June 2014

2014-06-13T08:42:38Z

Unhammer: Created page with "MT systems are useful for mainly two tasks:There are of course other practical uses, e.g. MT-supported language learning (see Geriouaeg). * creating almost-tra..."

2014-05-25T11:08:39Z

Created page with "MT systems are useful for mainly two tasks:<ref>There are of course other practical uses, e.g. MT-supported language learning (see Geriouaeg).</ref> * creating almost-tra..."

New page

MT systems are useful for mainly two tasks:<ref>There are of course other practical uses, e.g. MT-supported language learning (see [[Geriouaeg]]).</ref>

* creating almost-translated text that needs post-editing before being publishable, and

* creating an understandable translation of a foreign text for getting the gist of some text.

In the gisting task the user does not know the foreign language, while in the post-editing task, the user is a translator who does know the foreign/source language (and will often be reading both the source text and the translation).

MT of post-editing quality ''into'' a lesser-resourced language can help with creating more text in that language. We call this '''dissemination'''.

MT of gisting quality ''from'' a lesser-resourced language can help with letting people who don't speak that language understand text (e.g. blogs, news articles) written in that language (thus removing an argument against writing in the lesser-resourced language). We call this '''assimilation'''.

==Notes==
<references/>

@@ Line 24: / Line 24: @@
 ** Apertium pairs such as eus-spa, sme-nob and tat-rus do this (where all these language pairs are in a non-central/central situation).
 * If we focus on translating between closely-related languages, the task of getting post-editable-quality results can be easier due to more overlap in vocabulary and syntax etc.
-** This has typically been Apertium's niche.
+** This has historically been Apertium's niche.
 ==Notes==

@@ Line 29: / Line 29: @@
 ==Notes==
 <references/>
+[[Category:Evaluation]]
+[[Category:Quality control]]
+[[Category:Documentation in English]]

@@ Line 12: / Line 12: @@
 MT of gisting quality ''from'' a lesser-resourced language can help with letting people who don't speak that language understand text (e.g. blogs, news articles) written in that language (thus removing an argument against writing in the lesser-resourced language). We call this '''assimilation'''.
+Note that for many non-central/lesser-resourced/minority languages, the speakers are multilingual and understand the "central" language as well, e.g. North Sámi speakers typically understand Norwegian (but not vice versa); even for mutually intelligible, closely related language pairs, those who write the non-central language more often know how to write central language than vice versa, due to the central language having more visibility, being included in education, etc.
+A non-central language being included in an MT system can thus create more text in that language, as well as raise its profile, increase its visibility and normalcy and even contribute to standardisation.<ref>Forcada, Mikel L. (2006) "[http://dlsi.ua.es/~mlf/docum/forcada06p2.pdf Open-source machine translation: an opportunity for minor languages]"  in B. Williams (ed.): Proceedings of the Workshop "Strategies for developing machine translation for minority languages (5th SALTMIL workshop on Minority Languages)" (organised in conjunction with LREC 2006 (22-28.05.2006)). Genoa, Italy, pp. 1-6.</ref>
-One way of making MT systems more useful is to make their applications/use-cases more restricted<ref>Church and Hovy (1993), "[http://www.isi.edu/natural-language/people/hovy/papers/93churchhovy.pdf Good Applications for Crummy Machine Translation]"</ref>. The "ideal" MT system would do Fully Automatic High Quality MT of Unrestricted text between any language pair. No such system exists :-) The systems that are considered successful are the ones that have removed part of the ideal requirements. For example, [https://en.wikipedia.org/wiki/METEO_System Meteo] was successful already in the early 80's by translating only a restricted domain (weather reports). Some systems are successful because they focus on gisting, where the demand for quality is a lot lower (a reader won't mind much if you always leave out the word "the" when translating from Russian, whereas a post-editor would find it a chore). If we don't require translating between distant languages, the task of getting post-editable-quality results can be easier due to more overlap in vocabulary and syntax etc. (this has typically been Apertium's niche).
+==How to make an MT system useful==
+One way of making MT systems more useful is to make their applications/use-cases more restricted<ref>Church and Hovy (1993), "[http://www.isi.edu/natural-language/people/hovy/papers/93churchhovy.pdf Good Applications for Crummy Machine Translation]"</ref>. The "ideal" MT system would do Fully Automatic High Quality MT of Unrestricted text between any language pair. No such system exists :-) The systems that are considered successful are the ones that have removed part of the ideal requirements. For example:
+* [https://en.wikipedia.org/wiki/METEO_System Meteo] was successful already in the early 80's by translating only a restricted domain (weather reports).
+** Molto/[[GF]] has a similar focus
+* Some systems are successful because they focus on gisting, where the demand for quality is a lot lower (a reader won't mind much if you always leave out the word "the" when translating from Russian, whereas a post-editor would find it a chore).
+** Apertium pairs such as eus-spa, sme-nob and tat-rus do this (where all these language pairs are in a non-central/central situation).
+* If we focus on translating between closely-related languages, the task of getting post-editable-quality results can be easier due to more overlap in vocabulary and syntax etc.
+** This has typically been Apertium's niche.

@@ Line 1: / Line 1: @@
-;; This buffer is for notes you don't want to save, and for Lisp evaluation.
-;; If you want to create a file, visit that file with C-x C-f,
-;; then enter the text in that file's own buffer.
 MT systems are useful for mainly two tasks:<ref>There are of course other practical uses, e.g. MT-supported language learning (see [[Geriouaeg]]).</ref>

← Older revision		Revision as of 09:31, 13 June 2014
Line 17:		Line 17:


	One way of making MT systems more useful is to make their applications/use-cases more restricted<ref>Church and Hovy (1993), "[http://www.isi.edu/natural-language/people/hovy/papers/93churchhovy.pdf Good Applications for Crummy Machine Translation]"</ref>. The "ideal" MT system would do Fully Automatic High Quality MT of Unrestricted text between any language pair. No such system exists :-) The systems that are considered successful are the ones that have removed part of the ideal requirements. For example, [https://en.wikipedia.org/wiki/METEO_System Meteo] was successful already in the early 80's by translating only a restricted domain (weather reports). Some systems are successful because they focus on gisting, where the demand for quality is a lot lower (a reader won't mind much if you always leave out the word "the" when translating from Russian, whereas a post-editor would find it a chore). ~~Apertium's~~ ~~focus~~ ~~has~~ ~~typically~~ ~~been~~ on ~~closely-related~~ languages, ~~here~~ ~~it's~~ a ~~lot easier to get~~ post-editable-quality results.		One way of making MT systems more useful is to make their applications/use-cases more restricted<ref>Church and Hovy (1993), "[http://www.isi.edu/natural-language/people/hovy/papers/93churchhovy.pdf Good Applications for Crummy Machine Translation]"</ref>. The "ideal" MT system would do Fully Automatic High Quality MT of Unrestricted text between any language pair. No such system exists :-) The systems that are considered successful are the ones that have removed part of the ideal requirements. For example, [https://en.wikipedia.org/wiki/METEO_System Meteo] was successful already in the early 80's by translating only a restricted domain (weather reports). Some systems are successful because they focus on gisting, where the demand for quality is a lot lower (a reader won't mind much if you always leave out the word "the" when translating from Russian, whereas a post-editor would find it a chore). If we don't require translating between distant languages, the task of getting post-editable-quality results can be easier due to more overlap in vocabulary and syntax etc. (this has typically been Apertium's niche).

← Older revision		Revision as of 09:05, 13 June 2014
Line 17:		Line 17:


	One way of making MT systems more useful is to make their applications/use-cases more restricted<ref>Church and Hovy (1993), "[http://www.isi.edu/natural-language/people/hovy/papers/93churchhovy.pdf Good Applications for Crummy Machine Translation]"</ref>. The "ideal" MT system would do Fully Automatic High Quality MT of Unrestricted text between any language pair. No such system exists :-) The systems that are considered successful are the ones that have removed part of the ideal requirements. For example, Meteo was successful already in the 70's by translating only a restricted domain (weather reports). Some systems are successful because they focus on gisting, where the demand for quality is a lot lower (a reader won't mind much if you always leave out the word "the" when translating from Russian, whereas a post-editor would find it a chore). Apertium's focus has typically been on closely-related languages, here it's a lot easier to get post-editable-quality results.		One way of making MT systems more useful is to make their applications/use-cases more restricted<ref>Church and Hovy (1993), "[http://www.isi.edu/natural-language/people/hovy/papers/93churchhovy.pdf Good Applications for Crummy Machine Translation]"</ref>. The "ideal" MT system would do Fully Automatic High Quality MT of Unrestricted text between any language pair. No such system exists :-) The systems that are considered successful are the ones that have removed part of the ideal requirements. For example, [https://en.wikipedia.org/wiki/METEO_System Meteo] was successful already in the early 80's by translating only a restricted domain (weather reports). Some systems are successful because they focus on gisting, where the demand for quality is a lot lower (a reader won't mind much if you always leave out the word "the" when translating from Russian, whereas a post-editor would find it a chore). Apertium's focus has typically been on closely-related languages, here it's a lot easier to get post-editable-quality results.

@@ Line 14: / Line 14: @@
 ==Notes==
 <references/>
+==External links==
+* Church and Hovy (1993), "[http://www.isi.edu/natural-language/people/hovy/papers/93churchhovy.pdf Good Applications for Crummy Machine Translation]"