Using SOLID to convert to one-ps-per-sense format

Author cambell | 27.06.2009 | Category Solid

This week saw another colleague here in Papua New Guinea deciding to move his Toolbox dictionary to FLEx.  He had a fair amount of entries like this:

\lx ba
\ps n
\sn 1
\ge brother-in-law
\de brother-in-law: reciprocal term between wife”s father”s brother”s children and father”s brother”s daughter”s husband
\sn 2
\ge brother-in-law
\de brother-in-law: reciprocal term between sister”s husband and wife”s siblings
\sn 3
\ge in-law
\de reciprocal term between father”s sister”s husband and wife”s brother”s child
\dt 18/Sep/2000

These are all nouns, and he identifies this just once, at the top of the entry.  That counts as good MDF.  The problem is, FLEx import doesn’t handle this situation.  In fact, a recent import I did left us with over 60 cases where the \ps was turned into its own sense, followed by all the actual senses which were left with no grammatical category. Neither I nor my colleague caught this until she had already been working in WeSay on the new data for too long to go back and repeat the import. Yuck.

To prevent this, we need to move that \ps down to under the \sn, and then copy it for all remaining senses which lack a \ps.  As of SOLID version 0.9.319, we can now do this:


As with all these quickfixes, I use TortoiseHG (mercurial) so that I can look at exactly what changed, verifying that nothing was messed up. Here’s what quickfix did to the above record, as seen from TortoiseHg’s Commit tool:


More control over “missing info” tasks

Author John Hatton | 22.06.2009 | Category WeSay

WeSay has always had Tasks which would show you just the words that needed some more information in a particular field.  However, the selection of which entries to show was pretty blunt:  if the field had an empty slot in any of its multiple writing systems, the task would show that entry.  This meant that you couldn’t easily set up WeSay for a user who, for example, just wanted to add vernacular definitions where English ones had already been entered. 

In another case, we might want to set a user up to add voice recordings of example sentences. But the task should only show example sentences where someone had previously entered in the example text.

The latest development release (0.5 build 2000) addresses this.  When you first create a project, tasks are configured to have the same behavior as before: an entry will be chosen if *any* of the writing systems assigned to that field are empty.

You can now limit the task to filling in the vernacular (gaw, in this example):

In addition, we can limit the task to only those entries where some other writing system has already been filled in:

Thanks, Mark, for taking the time to submit this request.  We would appreciate any feedback you can give us on this feature.  Does it work well for you?

The obvious next step would be to add a way make duplicates of some tasks, so that you could have both an “Add Examples” and an “Add Example Recordings” task.  This is now possible by editing the .wesayconfig file in a text editor.  If you want to know how, set me an message (hattonjohn at gmail).  That will tell me how much demand there is for it, and if there’s enough, we’ll make it easier.