El dv 23 de 03 de 2012 a les 10:27 +0100, en/na Jacob Nordfalk va
escriure:
> 
> 
> 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.

Excellent advice!

Fran



------------------------------------------------------------------------------
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

Reply via email to