El dt 30 de 04 de 2013 a les 09:19 +0200, en/na Kevin Brubeck Unhammer va escriure: > Jonas Fromseier Mortensen > <[email protected]> writes: > > > Supporting nn→da as well should present only minor additions, > > mostly to > > your make system. You'd have two modes generated, nn→da and nb→da, > > which > > would share everything that comes _after_ bidix (ie. structural > > transfer > > and da generation). On the nn/nb side of the pipeline, you could > > probably snatch the monodixes, prob files and CG's from > > apertium-nn-nb > > without changes. > > > > The only remaining thing is bidix. Here I would keep one master > > bidix > > from no (nn+nb) to da, which is processed by an XSLT script into > > two > > different bidixes before compilation. Most entries would be the > > same, > > but some would be marked nn-only or nb-only. This kind of thing > > happens > > in a lot of apertium pairs, and should be no trouble to set up. > > > > > > Hi Kevin > > Thanks for the advice! It sounds very doable the way you put it. What > > do you think would be the best way to go about it? make a set of > > transfer rules for nb-da first, cg for the same and then work on > > adding nn support after? I'm sure there's lots of quirks and idiomatic > > expressions that my nb-da t1x wouldn't catch with nn as sl. > > You'll find lots of nn-typical syntax in nb text and the other way > around, so I'm actually pretty confident one t1x would cover both. You > could of course initially focus your testing on nb. > > CG for both nn and nb should be copied from apertium-nn-nb, so no need > to start something new there. > > A CG for da would be great, but would only be useful for the other > direction. It could probably be based on the nb CG, deleting stuff that > doesn't work before adding new stuff (actually, I would first run a big > corpus through the CG with --trace and delete any unused rules, to make > it easier to deal with). But if you work on no→da first, the da CG would > not be useful yet.
On the other hand, a Danish CG would be useful for other pairs too, like sv-da :) I really think that given the data we have available, it's worth going for a bidirectional pair. F. ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
