2012/3/23 Francis Tyers <[email protected]>
> El dj 22 de 03 de 2012 a les 20:33 -0400, en/na Aaron Rubin va escriure:
> > Thanks for the suggestions, everyone! This is my tentative schedule,
> > as of now:
> >
> > Weeks 1-7, .dix files:
> > Week 1: Redundant Entry Finder
> > Week 2: Testing Full Entries in Lemmas where Part of the Lemma is
> > Specified by the Pardef
> > Week 3: Testing Misspelled Tags and Pardefs
> > Week 4: Testing Incompatible Tags
> > Week 5: Testing Tag Missing on One Side of Translation Equivalents
> > Week 6: Testing Missing Gender on Gendered Languages
> > Week 7: Bundling all of these features together in one program;
> > testing.
> > Weeks 8-10, Transfer rules:
> > Week 8: Checking inappropriate uses of <equal>, <begins-with>,
> > <ends-with>, and <let> in transfer rules. Perhaps contains substring
> > (<cmp substr>) and <in> as well? I'm having a bit of trouble figuring
> > out where and why those two are used.. if someone could point me to a
> > tutorial page with an illustrative example, I'd appreciate it. The
> > same for <begins-with> and <ends-with>, for that matter.
> > Week 9: Checking for cases where the user asks for nonexistent tags.
> > Week 10: Checking for incorrect number of arguments in calls to macro
> > (Weeks 9 and 10 will probably take less than a week, but Week 8's task
> > might be intricate enough to compensate)
> > Week 11-12: Bundling all features together into one program. Possibly
> > combining with .dix files checker, with a feature to check which type
> > of file is being input. Writing and running tests (adding deliberate
> > errors to sample .dix and transfer rules files to see whether the
> > program catches them). Writing documentation to ensure that code is
> > maintainable.
>
> It seems that the plan is time skewed in favour of .dix files (imho the
> easier task). If anything I would say that 7 weeks on transfer and 2
> weeks on dictionaries seems more sensible.
>
> I think that it might be a good idea to go through the language pair
> HOWTO, and see what kind of errors/pitfalls you come across that aren't
> handled by the validation programs.
>
I'd also suggest that you set time aside to get into the problem domain if
you haven't already done so:
1) work a little on a pair
2) interview/observe someone who has just started working on a pair
Writing a system which is supposed to help others, especially beginners,
will be better written by someone who has experienced the obstacles
themselves.
--
Jacob Nordfalk <https://plus.google.com/114820443085046080944>
http://javabog.dk
Android-udvikler og underviser på
IHK<http://cv.ihk.dk/diplomuddannelser/itd/vf/MAU>og
Lund&Bendsen <https://www.lundogbendsen.dk/undervisning/beskrivelse/LB1809/>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
