Difference between revisions of "A long introduction to transfer rules"

From Apertium
Jump to navigation Jump to search
Line 22: Line 22:
** Doesn't do reordering.
** Doesn't do reordering.
** Can be used to give a ''head's up'' to the structural transfer to draw attention to missing features, or features that cannot be decided on a no-context basis. For example:
** Can be used to give a ''head's up'' to the structural transfer to draw attention to missing features, or features that cannot be decided on a no-context basis. For example:
** the {{tag|ND}} and {{tag|GD}} tags which say "Hey, when I'm translating this word I don't know what the gender or number should be -- structural transfer! I need your help to find out", or
*** the {{tag|ND}} and {{tag|GD}} tags which say "Hey, when I'm translating this word I don't know what the gender or number should be -- structural transfer! I need your help to find out", or
** the {{tag|sint}} tag which says "¡Ojo! if you're writing a transfer rule for adjectives, and it matches this adjective then you need to think about how you're going to handle the comparative and superlative forms"
*** the {{tag|sint}} tag which says "¡Ojo! if you're writing a transfer rule for adjectives, and it matches this adjective then you need to think about how you're going to handle the comparative and superlative forms"


* '''Structural transfer''':
* '''Structural transfer''':

Revision as of 17:37, 30 September 2012

Writing transfer rules seems to be tricky. People generally understand the basic concepts, but they struggle with the formalism. We think the formalism isn't that bad. And compared to many other formalisms,[1] it's fairly straightforward. Maybe one of the reasons people struggle is that we mix declarative and procedural programming. Could be.

Some formalities

Before starting, it is important to give some idea of what we can't do, before explaining what we can. If you come at rule-learning expecting something else, then it's likely to be confusing.

  • There are no recursive rules. Rules match fixed-length patterns. There is no optionality at the level of words. There is no way of saying one-or-more, it's just one.
  • Apertium's rules are very tied to the Apertium stream format. If you don't understand the stream format, it will be a lot more difficult to understand the rules.
  • Rules contain both declarative parts and procedural parts. You can't just expect to say what you want or how you want to do it. You need to do both -- but in different places (but it's quite intuitive).
  • Patterns match only on the source side. Not on the target side.

Lexical transfer and structural transfer

See also: Bilingual dictionaries

At this point it's worth not confusing the rôles of lexical transfer and structural transfer. There is a grey area between the two, but there are also big parts that don't overlap.

  • Lexical transfer:
    • Nearly always gives translations between words, not tags.
    • Can add or change tags, on a per-lemma basis.
    • Doesn't do reordering.
    • Can be used to give a head's up to the structural transfer to draw attention to missing features, or features that cannot be decided on a no-context basis. For example:
      • the <ND> and <GD> tags which say "Hey, when I'm translating this word I don't know what the gender or number should be -- structural transfer! I need your help to find out", or
      • the <sint> tag which says "¡Ojo! if you're writing a transfer rule for adjectives, and it matches this adjective then you need to think about how you're going to handle the comparative and superlative forms"
  • Structural transfer:
    • Rarely gives translations between single words.
    • Often adds or changes tags on a per-category (groups of lemmas) basis.
    • Can change the order of words.

Some preliminaries

  • Pattern:
  • Action:

Overview of a transfer file

It's hard to give a step-by-step overview of what a transfer file looks like because there is quite a lot of obligatory parts that need to go into even the most basic file. But, it's important to get a general view before we go into the details. Here is an example in which I'm deliberately not going to use linguistic names for the different parts, to try and avoid assumptions.

<?xml version="1.0" encoding="utf-8"?>
<transfer>
  <section-def-cats>
    <def-cat n="some_word_category">
      <cat-item tags="mytag.*"/>
    </def-cat>
  </section-def-cats>
  <section-def-attrs>
    <def-attr n="some_feature_of_a_word">
      <attr-item tags="myfeature"/>
      <attr-item tags="myotherfeature"/>
    </def-attr>
  </section-def-attrs>
  <section-def-vars>
    <def-var n="blank"/>
  </section-def-vars>  
  <section-rules>
    <rule>
      <pattern>
        <pattern-item n="some_word_category"/>
      </pattern>
      <action>
        <let><clip pos="1" side="tl" part="some_feature_of_a_word"/><lit-tag v="myotherfeature"/></let>
        <out>
          <lu><clip pos="1" side="tl" part="whole"/></lu>
        </out>
      </action>
    </rule>
  </section-rules>
</transfer>

I'll try and give a tag-by-tag account... the <transfer> and </transfer> tags don't do anything. They just encapsulate the rest of the sections.

Practical examples

Apertium 1

Otisla si tiho i bez pozdrava

She left quietly and without a word

Lexical transfer

Apertium 3

Resorni ministar je navlačio ljude, kaže sejte biljku zelenu i čudo će da bude

The minister of agriculture tricks the people, he says plant the green herb and there will be a miracle

Lexical transfer

Notes

  1. e.g. Matxin, OpenLogos, ...