Nxaʔamxcín (Moses) Dictionary Blog

• Make <note> elements display wherever they show up in the structure.
• Make the list of <dicteg>s into an expand/collapse structure if there are more than two of them.

This feature is now complete, and appears to be working well (tested in Firefox, Opera, Chrome, IE8 and IE9). In making it work, I had to overcome problems relating to recursion. When a call is made to retrieve an entry for embedding inside another entry, my code naturally checks to see if we already have a copy of that entry on the page; if we do, it just makes a copy of it and uses it, rather than pulling it down again from the server via AJAX. However, that naturally means that any id attributes in the original tree need to be changed so that we don't have multiple elements on the page with the same id. I was already doing that with the id of th root node, but I had to make several more similar changes for nested entry lists:

• The nested entry naturally has its own "Other entries" link and container; the container had to be emptied of retrieved <div>s.
• The id of the container had to be changed to a unique id.
• The onclick event of the link had to be changed to point to the new id of the container.

This is a little messy, and in fact the same code appears in two places in the JavaScript, so my next job is to modularize it. It amounts to sanitizing a copied node tree.

I've made the following changes, which are basically working:

• At the end of the last definition, if an item is a single morpheme, a link appears for retrieving all entries containing that morpheme.
• If you click on the link, a list of entries is retrieved, looking exactly like the regular entry list.
• If you click on one of those entries, the content of the entry is retrieved and displayed.

Two problems remain to be solved:

• The content becomes recursive, in that if you click on the tab for the ancestor morpheme inside the parent entry, the ancestor morpheme entry is copied inside itself, including the list of subentries you've already retrieved. They need to be stripped out when copying an entry to a morpheme tab.
• The decision to use a margin-left of -10em when displaying entry lists is causing problems, and needs to be re-thought. It's done in order to achieve a hanging indent, but something subtle will have to be done to override it when processing entry lists retrieved through AJAX and intended for embedding in other lists.

We thought of another request for the database display:

When displaying an atomic entry, MDH will add an option to click and see all the entries which contain that morpheme.

This will be useful in the Refer To Elders list, where we are often asking them to define a root. They may never have encountered the root in isolation, so they will need to see the words it occurs in.

The functionality will also be nice to have in the Finished Entries and All Entries lists, where entries with the same root don't always sort together alphabetically due to prefixes.

MDH wrote:

Should defs contain multiple seg+bibl blocks? Yes and no. Some such bracketings already usefully exist (such as in the entry for háypx̣), and I've just tweaked the display to make them render more cleanly; on the other hand, creating such collapsed defs is interpretive and takes time, and is not a priority right now. So the existing ones will be left, but SK will not create more.

----------------------
Here is some more clarification for future reference:

-homophones are separate entries
-multiple <sense>s are only used with multiple <form>s
-all other definitions will appear in a <seg> within a <def>
-SMK will not collapse multiple defs from here on: only one <seg> per <def>.
-multiple <bibl>s on a single <seg> in a <def> means an identical English definition was given by more than one consultant

----------------------
On 2Dec11, ECH and SMK decided to continue with two levels of distinction, as described above.

In entries with multiple <seg>s per <def>, MDH can programmatically split the <seg>s out into separate <def>s again.

SMK had compiled lists of the multi-def and single-def/multi-seg examples currently in the database. There was clearly some method to the madness of using three levels of distinction thus far, but SMK identified entries which might need further adjustments if we ever want to go to three levels.

Met with SK and ECH to discuss a number of possible issues:

• Should we attempt to crystallize (in the markup) implicit links between prons and defs attested by the same informant on the same occasion? On balance, we feel not; it's insufficiently clear that such links represent anything meaningful above and beyond the fact that the same informant on the same occasion attested to a pronunciation and a definition, and there are instances of entries where it would be problematic to make explicit inferences along these lines.
• Does the current display of entries adequately reflect what a linguist would like to see? No, for a number of reasons, some good because they provide new functionality (such as embedded entries for constituent morphemes), and some bad because (for instance) the original bracketing of pron with def for a single informant event (in a Lexware "var" block) is no longer apparent. ECH will go away and imagine changes to the current display, as well as alternative renderings we might use.
• Should defs contain multiple seg+bibl blocks? Yes and no. Some such bracketings already usefully exist (such as in the entry for háypx̣), and I've just tweaked the display to make them render more cleanly; on the other hand, creating such collapsed defs is interpretive and takes time, and is not a priority right now. So the existing ones will be left, but SK will not create more.
• Who are the informants? ECH and SK will retrieve a list of them, and I'll create a personography from it. Then I'll build that information into the website, and make it possible to highlight only one informant's information in a given entry. We may also be able to display a custom dictionary based on the information from a single informant.

I've implemented support for the "referToElders" attribute values (@n on <entry>, and @type on <note>). A new page has been added to the site showing those entries which are so flagged, and in all contexts they show up with a question mark over their status traffic light, while the actual question notes themselves show up with a blue background.

Note to self: can old XQuery files be cleared out at all? It seems as though all lists are now done with wordlist.xq, and one or two of the other files might be redundant. Also look at cleaning out some of the XSLT that were written for run-once tasks, or at least moving them out of the Cocoon tree.

Here is our plan for flagging entries for the Elders to review:

-Keep existing RevisionDesc status values. As ECH reviews a file to take it from “edited” to “complete”, she will tag the relevant entries with n=”referToElders”.

-Within each <entry n=”referToElders”>, we will include a <note type=”referToElders”>, in which we will put our questions for the Elders. This will display on the database website like any other [Note:].

-MDH will create a page on the dictionary site with a list of all the entries with <entry n=”referToElders”> We still want to include these entries on the Finished Entries page, and the All Entries page. They will still have their green, amber, or red status "traffic light", but will also be flagged with a question mark.

-Language apprentices will work with the Elders to review the flagged entries. They could read the questions out to the Elders, and/or print a screen of entries with Notes.

-The changes arising out of the Elders' feedback should be input immediately. The apprentices could either update the entries directly into the xml files themselves, or send their changes / additions to ECH or SMK to enter. ECH would give the entry a final check and remove the n=”referToElders” attribute. Two Elders will each be working 10 hours a week when we get the grant, on other language documentation work as well as reviewing the dictionary entries.

-Both @resp and <bibl> will be used as appropriate to mark up contributions from the Elders.

-If the Elders want to add new material, beyond commenting on Kinkade's data, this would have to go into a new xml file, not be added to existing files. A subsequent stage of the project could expand the database beyond Kinkade's data.

Split out the permissions on SVN so that there's a moseseditors group and a mosesadmin group, and editors only have write over trunk/xml. Did this following the model of the similar changes I made when setting up the London Maps svn, documented elsewhere on the blog.

This morning there was a wrinkle getting SK started working on the newly-built Beet machine, which is running Oneiric; I'll detail it here because it may crop up again, and it took me a while to figure it out.

Symptoms: doing an initial SVN checkout of the repo would not work. The terminal challenged the user for a null gnome-keyring password, and whatever password was provided, it then failed to authenticate with the SVN server, and did not provide any opportunity to provide the SVN user name and password. This bug may be related.

Eventually I came upon this solution, which worked:

rm ~/.gnome2/keyrings/login.keyring

We were then able to checkout successfully from SVN using the --username switch.