Difference between revisions of "User:Unhammer/wishlist"
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).
Contents
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
- use the local modes files with
apertium -d . nn-nb
- 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.)