Difference between revisions of "User:Unhammer/wishlist"

From Apertium
Jump to navigation Jump to search
Line 59: Line 59:
   
 
The idea is that within the <code><eg></code> entries, we ''know'' that all LR's have the same <code><r></code>, and all RL's have the same <code><l></code>, and so an LR can't have an <code><r></code> specified.
 
The idea is that within the <code><eg></code> entries, we ''know'' that all LR's have the same <code><r></code>, and all RL's have the same <code><l></code>, and so an LR can't have an <code><r></code> specified.
  +
  +
  +
==Better apertium-gen-modes==
  +
The Makefile.am in apertium-nn-nb has
  +
  +
<pre>
  +
modes/$(PREFIX1).mode: modes.xml
  +
apertium-gen-modes modes.xml
  +
cp *.mode modes/
  +
  +
modes/$(PREFIX2).mode: modes.xml
  +
apertium-gen-modes modes.xml
  +
cp *.mode modes/
  +
  +
apertium_nn_nb_DATA= ...
  +
modes/$(PREFIX1).mode modes/$(PREFIX2).mode modes.xml
  +
  +
install-data-local:
  +
mv modes modes.bak
  +
apertium-gen-modes modes.xml apertium-$(PREFIX1)
  +
rm -rf modes
  +
mv modes.bak modes
  +
test -d $(apertium_nn_modesdir) || mkdir $(apertium_nn_modesdir)
  +
$(INSTALL_DATA) $(PREFIX1).mode $(apertium_nn_modesdir)
  +
$(INSTALL_DATA) $(PREFIX2).mode $(apertium_nn_modesdir)
  +
rm $(PREFIX1).mode $(PREFIX2).mode
  +
</pre>
  +
  +
just so that we can
  +
  +
# use the local modes files with <code>apertium -d . nn-nb</code>
  +
# install modes files for use with <code>apertium nn-nb</code>
  +
  +
There must be a better way. (Part of the problem is that apertium-gen-modes overwrites the modes directory, which is why I have the moving to a backup dir.)

Revision as of 14:40, 22 February 2010

My wishlist for Apertium features (mostly just useful for language pair developers).

Fallthrough option in transfer

Some times, you match an input pattern in a rule, eg. "n vblex", and you check whether the target-language n has some feature, and then only if it has that feature do you do something special with it. It would be great if we could specify in the <otherwise> that we want to fall through, ignoring that this rule matched.

There are two options for how to "ignore", the best (but possibly slowest?) would be to go on with trying to match on the rest of the rules, the other option is to act as if no rules matched. Both would be an improvement.

UTF-8 in sdefs

But, being XML id's, this is maybe not possible?

Allow the chunk tag wherever we allow other "strings"

<chunk name="foo"><tags><tag><lit-tag v="bar"/></tag></tags><lu><lit v="fie"/></lu></chunk> just outputs ^foo<bar>{fie}$ -- a simple string. We can have strings from tags, literals and variables inside variables, but not with the chunk tag, leading to this kind of mess:

        <let>
                       
           <concat>
             <lit v="^pron"/>
             <lit-tag v="@SUBJ→"/>
             <clip pos="1" part="pers"/>
             <lit-tag v="GD"/>
             <clip pos="1" part="nbr"/>
             <lit-tag v="nom"/>
             <lit v="{^"/>
             <lit v="prpers"/>
             <lit-tag v="prn"/>
             <clip pos="1" part="pers"/>
             <lit-tag v="mf"/>
             <clip pos="1" part="nbr"/>
             <lit-tag v="nom"/>
             <lit v="$}$"/>
             
           </concat>
         </let>

Wish: allow <let><chunk>...</chunk></let> and <concat><chunk>...</chunk></concat> (chunk "returns" a string, variables hold strings).

A "grouping" tag for bidix

Most of the time when LR-ing and RL-ing in bidix, we have one pair of entries that work in both directions, with possibly lots of LR's that all go to the same <r>, or lots of RL's that all go to the same <l>. Making certain these actually _do_ go to the same, where they should, means looking through lots of entries manually, since in some cases we _don't_ want it to be like that (ie. we can't just write a program to check this since there are general rules and there are exceptions).

What I'd like is just some way of keeping LR's and RL's in bidix together. One possibility would be to represent it this way:

 <eg>
   <em>       <p><l>foo</l><r>bar</r></p></em>
   <LR>        <p><l>fie</l>                    </p></LR>
   <RL>        <p>                  <r>bum</r></p></RL>
 </eg>
 <e r="LR"><p><l>foe</l><r>baz</r></p></e>

This would be equivalent to:

 <e>           <p><l>foo</l><r>bar</r></p></e>
 <e r="LR"><p><l>fie</l><r>bar</r></p></e>
 <e r="RL"><p><l>foo</l><r>bum</r></p></e>
 <e r="LR"><p><l>foe</l><r>baz</r></p></e>

The idea is that within the <eg> entries, we know that all LR's have the same <r>, and all RL's have the same <l>, and so an LR can't have an <r> specified.


Better apertium-gen-modes

The Makefile.am in apertium-nn-nb has

modes/$(PREFIX1).mode: modes.xml
	apertium-gen-modes modes.xml
	cp *.mode modes/

modes/$(PREFIX2).mode: modes.xml 
	apertium-gen-modes modes.xml
	cp *.mode modes/

apertium_nn_nb_DATA= ...
	            modes/$(PREFIX1).mode modes/$(PREFIX2).mode modes.xml

install-data-local:
	mv modes modes.bak
	apertium-gen-modes modes.xml apertium-$(PREFIX1)
	rm -rf modes
	mv modes.bak modes
	test -d $(apertium_nn_modesdir) || mkdir $(apertium_nn_modesdir)
	$(INSTALL_DATA) $(PREFIX1).mode $(apertium_nn_modesdir)
	$(INSTALL_DATA) $(PREFIX2).mode $(apertium_nn_modesdir)
	rm $(PREFIX1).mode $(PREFIX2).mode

just so that we can

  1. use the local modes files with apertium -d . nn-nb
  2. install modes files for use with apertium nn-nb

There must be a better way. (Part of the problem is that apertium-gen-modes overwrites the modes directory, which is why I have the moving to a backup dir.)