The simplest case is where the users have been working on completely different sets of words, with no overlap. That is, they each started with completely empty dictionaries, which have never once been merged together.  In this specific case, you can merge them by hand.  Do that by opening each .lift file and copying all the <entry>…</entry> chunks of one file in next to the <entry>…</entry> chunks of the other file.    Open in WeSay to make sure you didn’t mess the lift file up.

In the more general case, you will want to merge them together using FieldWorks Language Explorer (FLEx).  To do that, follow these steps:

1) Create a new project using FLEx.

2) Import each .lift file into the project, one at a time, until you have a nice combined dictionary.

If getting/installing/using FLEx seems like to much, you can always just ask for someone to do this for you.  Write to the WeSay email list and ask someone to do the merge for you.

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.

First, let’s have a visual tour of the new feature.  Then I’ll explain about “Art Of Reading”.

To add an illustration, you just go to the Picture field and click “Search Gallery…”:

(Notice that the old “Choose Image File…” is still there.  Eventually, we should make that button hidden by default, as it violates our desire to not send the WeSay user into the confusing depths of the file system.)

WeSay looks in the English meaning and uses it to search the gallery for matching illustrations:

If that doesn’t show you the pictures you’re looking for, you can change the search terms and try again.  Once you find the one you want, you double click on it.  This closes the dialog and inserts the illustration:

Art of Reading 2.0 is a CD put out by SIL; ask around, someone near you may already have it.  If not, you can order it here.  From that page:

International Illustrations is the second artwork CD-ROM produced by the International Literacy Department of SIL International. This expanded, enhanced collection is the follow-up to Art of Reading 1.0 and contains over 11,000 indexed images collected from SIL and national artists around the world. Searchable by keywords.

Black and white line drawings (in compressed TIF format for Windows and Mac) are suitable for use in a wide variety of literacy materials, newsletters, bulletin board displays, and other cultural awareness materials.

Images come from Brazil, Cambodia, Cameroon, Canada, Colombia, D.R. of Congo, India, Indonesia, Kenya, Mexico, Nigeria, Papua New Guinea, Peru, Philippines, Senegal, Sudan, Thailand, USA

I’m told there’s a version 3 in the works, which will be a DVD with even more illustrations and an Indonesian index.

Update Sept 2009: The Version 3 DVD is now available. Note, though the product is advertised for Windows and Mac, it will work on Linux too, if you’re using WeSay.

Update Nov 2009: I’m told this new AOR version doesn’t actually add any new photos… it’s mostly about a new version of the browsing software (which WeSay doesn’t use) and the addition of an Indonesian index (which WeSay already has).  If that’s true, there’s no reason to upgrade if you’re only using AOR for WeSay.

If/when anyone produces indices for French, Spanish, Portuguese, etc., tell us and we’ll add them to WeSay, too (I suspect you could use a computer translator to generate something useful, quickly). Notice, some of the description of how the package works is irrelevant.  The included software is too unwieldy for a WeSay audience.  WeSay bypasses that software, keeping the process as simple as you see above.

Get the latest WeSay here.  As always, we rely on your feedback here on the blog, on the Google Group, or (if you have a problem) via email: issues at wesay.org.

Thanks to René van den Berg for inspiring this new feature.

Technical Details

• [Updated Nov 2009] To get started, you need to copy the images it to your hard drive.  On Windows, WeSay will look for it at “C:\Art of Reading”.  You don’t need anything but the “images” folder, which would be at “C:\Art Of Reading\Images”.  On Linux, you have 3 choices:
  /usr/share/wesay/ArtOfReading/images
  /usr/share/ArtOfReading/images
  /var/share/ArtOfReading/images
• I do not know if WeSay’s index of this package works with Art Of Reading 1.0.  It works with 2.0, and should work fine for with 3.0, though I don’t have a copy of that yet to test.
• If you have a different image library which you think would be widely used, let us know. It would be great to have one which could be downloaded for free.
• This feature is the latest (and last) major addition to WeSay 0.5, our “development” release.  Projects created or edited in 0.5 cannot be opened with WeSay 0.4, our “stable” release as of the date of this posting.

Notice the circles there?  They’re trying to be unobtrusive.   When you move the mouse near, they light up:

As long as you hold the mouse button down, your voice is recorded.  Like a walkie-talkie.  Then, the symbol changes:

and when you go near that, you have a play and a delete button:

How is this useful?  For one thing, as electronic dictionaries become more common, wouldn’t it be nice to hear the word or example sentence?  This might also be helpful for language learning, by gleaning the sounds and dictionary file to create listening exercises. 

How to set it up

In the configuration tool, go to Writing Systems and make a new one called “voice”.  Then set the “is audio” switch to “true”. 

Update: if you want that code to be a proper, future-proof one, don’t use “voice” as I showed above.  Instead, for the audio counterpart of the writing system seh, we should say seh-Zxxx-x-audio.   The abbreviation can still be “voice”.

Now go the Fields section, and tick “voice” next to any field you want to include this voice capability.

Note, you could have multiple voice writing systems, carrying different accents, genders, whatever.

Please, let us know if you have a chance to play around with this, and any experiences you have using it with a native speaker.

This is currently available in our 0.5 line, for Windows only.  Linux could follow soon, especially if we hear from you.

Technical Details

All sounds are saved as .wav files under a new “audio” subfolder of your WeSay project.  Their names are a bit unwieldy at the moment, largely to keep the code simple as long as this is still a proof-of-concept.  Files are named as the form of the word + a time stamp, so that multiple recordings in the same word (or homograph) don’t step on each other.

1. Useful for everyday WeSay users, with no training.
2. Good enough for final publication of many projects, with a little training or computer savvy.
3. Powerful enough for any project, perhaps needing a specialist.

In that post, we covered #2, at least for Windows users. Now I’m pleased to announce a big step towards #1:

Click this, and a few moments later your PDF reader (e.g. Acrobat) opens with a dictionary:

Our aims for this feature are limited:

1) provide a Linux (as well as Windows) way to get simple printouts.  (Lexique Pro is Windows only).

2) provide a very simple way to get printout when no computer-savvy advisor is available to run  a more extensive set of applications (like Lexique Pro + Microsoft Word).

Currently, the fields that this outputs are limited to:

• Headword (from Lexeme Form and Citation Form).  Multiple writing-system headword are supported.
• Definition
• Part of Speech
• Top level senses (not sub senses)
• Example sentences, and translations of them
• Illustrations, auto-captioned to the headword of the entry
• Cross references

We can easily add to the capabilities here, at you request. But we may be resistant to any enhancements which involve wizards, dialogs, etc.  For that kind of control, you really need to use Lexique Pro, FLEx, or MDF.  In other words, the request “I need to get borrowed words” would be implemented quickly, whereas “I want control over the placement of the illustrations” will not.

Future Work

Depending on feedback from you, gentle reader, we could do more interesting things here.  These include

• automatically ordering pages for booklet  printing
• a title page
• a section of words categorized by semantic-domain
• a reversal section

Technical details

As with Lexique Pro export, WeSay begins by producing a PLIFT file, which is a simplified copy of your LIFT dictionary file.  It then converts this to html (like web pages use), and produces style sheets (industry standard css3 ones).  Finally, it uses a terrific page-layout engine named PrinceXml to produce the pdf.  The stylesheets are:

• autoLayout.css
• autoFonts.css
• customLayout.css
• customFonts.css

If you are so inclined, you can edit the two “custom” ones. This has the effect of overriding the styles in the “auto” ones.  In this way, the technical user has full control.  You can also setup the dictionary the way you want using FieldWorks Language Explorer’s dictionary export function, which gives you extensive control over many aspects of the layout. WeSay’s html uses the same style names as FLEx, so you can grab the css that FLEx creates and use that for your “customLayout.css” when using WeSay.  If you do any of this kind of thing, please let us know.  We really need to know what people are using, and what they aren’t.

Have you read this far? Leave a comment.  I’m not clear if folks in the language documentation community actually read blogs.

So we’d have

1. Useful for everyday WeSay users, with no training.
2. Good enough for final publication of many projects, with a little training or computer savvy.
3. Powerful enough for any project, perhaps needing a specialist.

These three scenarios are all now in the works from various SIL software teams, and I’ll blog about them as they become available to WeSay users.

Today, I’m please to update you on #2, the growing interoperability of WeSay and Lexique Pro.  Lexique Pro is a high-regarded, free dictionary tool for MS Windows.  From the LP web site:

Lexique Pro is an interactive lexicon viewer and editor, with hyperlinks between entries, category views, dictionary reversal, search, and export tools. It’s designed to display your data in a user-friendly format so you can distribute it to others.

Starting with version 3, LP can directly read the LIFT-standard xml files which WeSay uses. No need to go through the “standard format” or “MDF” first.

Starting with version 0.5 (our current development track), opening your dictionary with Lexique Pro got really easy:

You can get the latest WeSay here.  Lexique Pro 3.0 is currently a beta, available here.  With the 31 Oct beta of LP, at least, there are a number of things still to be worked out, but I expect we’ll see first-rate LIFT-based printing in LP this year.

Technical details

When you click this button, WeSay actually writes out a modified form of your LIFT file to the “exports” subdirectory of you WeSay project.  While it is still compliant LIFT, some preprocessing is done to help printing programs show the right things.  For example, homograph numbers are computed, headwords calculated, and any fields you have turned off for the current user are stripped from this file.  We refer to this kind of file as “PLIFT” for “publication” lift.

The down-side of this approach was that the newest version is not always the safest.  We don’t have any “testers”, so if a release had great, sweeping new features, it could come with related bugs.

This has now changed.  We now make two versions available to you.  One is the safest (”stable release”).  The other has the latest stuff (”development release”).  If you are checking out WeSay’s capabilities or willing to help guide us, you want the dev release.  If you are deploying WeSay to less computer-savvy or less network-connected users, you want the stable release.

When we hear of a serious bug, we will normally fix it on both releases.  New features and non-serious bugs only get added to the development release. Make sense?

To make it easier to track which is which, we use the old Linux-kernel numbering approach.  The stable track uses even numbers, the development track uses odd ones.

Our current “stable” releases are 0.4, and the “dev” releases are 0.5. And remember, there are new versions, especially of dev releases, several times a week.  So if it’s not too inconvenient, it helps if you can check with a recent release before reporting problems. Thanks!

Starting with version 0.4, we’ve changed the “dashboard” you see when WeSay opens up.  With this change, we get more on the screen, lessening the need to scroll down.  Also, the new design organizes tasks into groups so that users can have a sense of the workflow.   Some of this will become more clear as we add tasks to the various sections.

You can see from this screenshot that we have some work to do on this still… the Word List task should display a “progress indicator” like we see in the second row.  “Review” and “refine” are two more sections, which I hope to see populated in the future.

So, how would WeSay run on this relatively slow (900 Mhz), relatively low-wattage machine?  Getting Windows installed and running, the Eee felt very sluggish.  Because of delays, I found it easy to make errors when using a web browser.  Very slowly, I grabbed .net 3.5 sp1, then WeSay build 1451.  Very slowly, I ran the installer.  By this time, I wasn’t expecting to have a happy WeSay experience.

To my surprise, WeSay runs GREAT on this box! Changing records, finding words, and bringing up new tasks were all pretty snappy.

Note: I only did a quick walk-through using the sample data, so please don’t go out and purchase a hundred Eee’s to run WeSay based on this blog post.

• See which words are missing from the dictionary, and add them along with a definition.
• Jump into the entry screen for a word in WeSay to do more advanced editing.
• Point to a word and see a list of similar words they might choose instead (thesaurus lookup).

A linguist working with the group will want to:

• Click on an unfamiliar word and see the full dictionary article for it.

If the language has any affixation, both users will need to be able to:

• see a list of entries, ordered by how similar their spellings are to the word be investigated.
• find words based on their inflected/derived forms, not just by the citation form in the dictionary.
• add variants to the word so that it is clear that this form is covered by the dictionary, and make it easier to lookup next time.

The first round of this work is now available for other application developers to use (the italicized bullet items above will come in some future version).

To help developers add these features to their programs, I’ve built a little sample application so they can see what’s possible and how to do it. Here’s a little crummy video showing it:

[kml_flashembed movie="http://www.wesay.org/downloads/movies/dsDemo/dsDemo.swf" height="464" width="512" scale="noborder"/]

A few technical details for developers

Currently, I’ve implemented support for .net applications to make use of these services. But support via any language, via xml-rpc, should be easy to add when needed. All .net applications need to do is get our Palaso library and use the DictionaryAccessor class. You currently need to tell it where on the user’s machine to find WeSay, and where the dictionary is that you’ll be accessing.

Here’s some code to show what it takes add this ability to a .net application:

Getting some HTML of matching entries to show in a WebBrowser control

DictionaryAccessor dictionary = new DictionaryAccessor("c:docsnoosupunoosupu.lift", "c:program fileswesaywesapp.exe");

string[] forms;

string[] ids;

dictionary.GetMatchingEntries(writingSystemIdForWords, "foobar",

       FindMethods.Exact, out ids, out forms);

string html = dictionary.GetHtmlForEntries(ids);

Adding a new word

dictionary.AddEntry(writingSystemIdForWords, wordBox.Text,

                    writingSystemIdForDefinitions,definitionBox.Text,

                    writingSystemIdForWords, exampleBox.Text);

Ok, so you get the idea that this will be a very easy service to add to your .net program.

A plug here for .net 3’s WCF (Windows Communication Framework), which made implementing this a very nice experience.

Update:  This has now been re-written to use cross language, cross platform “XML-RPC”messaging.  So programs written in non-.net languages can now participate.