Open In Lexique Pro

Author John Hatton | 06.01.2009 | Category WeSay

WeSay really wants to focus on gathering data. It really doesn’t want to become a full-powered dictionary layout system. Ideally, there would be an invisible, friction-free means of getting a simple dictionary printout at the click of a button, and customized one with a couple clicks. And perhaps a 3rd, ultra flexible, standards based, high-end dictionary publisher where that is called for.

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.

Sale Windows 7 Ultimate


Which WeSay?

Author John Hatton | 06.01.2009 | Category WeSay

Our approach to software development requires that we “ship early, ship often”. We listen carefully to you, and try to quickly respond to your requests (though at this point, we’re way behind on many requests for new capabilities).

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!

Windows 7 Ultimate


New Dashboard

Author John Hatton | 05.01.2009 | Category WeSay

It’s been a wild year for our team, and if all you do is follow this blog, you’d think we disappeared.  Eric has moved to Microsoft (lucky them!), I’ve moved from Thailand to the USA and then Papua New Guinea, and two new guys have joined our team in Thailand.  Amidst all that, I’ve fallen behind in blogging about our progress.  In this post and others which should follow shortly, I’ll try to catch up.

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.


WeSay on the Eee 900

Author John Hatton | 26.08.2008 | Category WeSay

The Eee is, so far, the best selling of the new wave of “4P” computers; laptops which are characterized by low Price, adequate Performance, portability, and low electrical Power requirements.  Now, this is no OLPC; it costs around $500 and isn’t as rugged. It does not aim at the same ultra-low power usage. But it does have two things over the OLPC today: you can buy them on Amazon and you can get them with Windows XP.  (Yes, sadly we’re still waiting on some open source pieces to mature on the Linux side before we can get WeSay running on the OLPC and other Linux boxes).

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.

WeSay on an Eee PC 900

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.


Git notes

Author cambell | 23.06.2008 | Category WeSay

Now that I’ve used git for a couple weeks, I thought I’d make a few notes of commands I’ve found helpful.

To make a local branch for development
git checkout -b name_of_new_branch

To commit changes to the local repository (although I usually use the visual gittk for this)
git commit -a

To commit changes back to subversion
git svn dcommit

To uncommit
git reset HEAD~1

To keep a local branch up to date with subversion (use git stash to hide away local uncommitted changes for later)
git svn rebase

To move the master branch up to trunk
git checkout master
git svn rebase

to handle conflicts with merge
git mergetool path_to_file_needing_merge
git mergetool -t toolname path_to_file_needing_merge

To remove untracked files (like the temps that get created during a merge resolve)
git clean -n to see what it would do
git clean -f -d (-d if you want to remove untracked directories as well)

Sale Windows 7 Ultimate


Git, Subversion and a CRLF mess

Author cambell | 23.06.2008 | Category WeSay

When initializing from WeSay’s Subversion repository, (git svn init -t tags -b branches -T trunk I found that I was then told that I had a ton of files that had changed. Turns out on Windows, git has core.autocrlf = true by default — a good thing. But git-svn apparently doesn’t take this into account and if you have crlf’s stored in the svn repository, they will be pushed into the git repository as well. So for now we have a repository that has crlf’s in it instead of just lf’s which get translated depending on the platform. Setting core.autocrlf to false and then doing a hard reset will make this work for now, although not as nicely as we would like. (git config core.autocrlf=false; git reset –hard)



Merging with git

Author cambell | 12.06.2008 | Category WeSay

Git still doesn’t have good unicode support so to merge unicode files that git has labeled binary, I wanted to use a visual merger. Finally figured out how to do it — add the following lines to config:

   tool = tortoise

[mergetool "tortoise"]
   cmd = \"TortoiseMerge.exe\" /base:\"$BASE\" /theirs:\"$REMOTE\" /mine:\"$LOCAL\" /merged:\"$MERGED\"

[mergetool "p4"]
   cmd = \"p4merge.exe\"  \"$BASE\" \"$REMOTE\" \"$LOCAL\" \"$MERGED\"

If you don’t have TortoiseMerge.exe in your path then you can replace that with the full path (c:/Program Files/TortoiseSVN/bin/TortoiseMerge.exe).

google sniper 2


Upgrading user settings in C#

Author Tim | 10.06.2008 | Category WeSay

In the course of development we found it necessary to migrate an old user setting into a new one and to then remove it. This brought with it a few problems which I hope to shed some light on below.

In order to get the value of the old setting we used the Property.Settings.GetPreviousVersion() method. Initially we were getting a SettingsPropertyNotFoundException() although the setting was verifiably present in the user.config file. As it turns out we had removed the Property from the Settings designer which removed the Property in the Property.Settings class. In order for Settings to be found, they have to have a property that is tagged with the [UserScopedSettingAttribute] attribute. This tells the GetPreviousVersion() method to look for the setting in user.config. So far so good…

At this point however, the base.Upgrade() method is called to move old settings into the new file. This causes the old, unwanted setting to be moved in right along with all the old settings that we want to keep around. In order to avoid this behavior the [NoSettingsVersionUpgrade] attribute must also be used for the unwanted Property.

public override void Upgrade()
string lastConfigFilePath = (string) GetPreviousVersion(”LastConfigFilePath”);
base.Upgrade(); // bring forward our properties that are the
//  same (but also will bring forward LastConfigFilePath)

[Obsolete(”Please use MruConfigFilePaths instead”)]
public string LastConfigFilePath
throw new NotSupportedException(”LastConfigFilePath is obsolete”);
throw new NotSupportedException(”LastConfigFilePath is obsolete”);

google sniper 2


An enchant provider for LIFT

Author cambell | 13.05.2008 | Category WeSay

We wanted to allow users to edit their dictionary and use that same dictionary for spell checking. Since WeSay uses LIFT as the file format for the dictionary and keeps that file up to date, all we needed was an enchant provider that can read LIFT files.

I took the spell checking engine I had written a while back, Ascens, and refactored it so that it could read files of various formats. Currently it supports line based and XML based formats. For line based formats, the words are entered one per line. For XML based formats, an XPath expression determines what text from within the file should be selected to constitute correctly spelled words.

Ascens looks for a settings file with the same name as the language identifier that is passed to enchant. Within the settings file, the location of the dictionary and the type of the dictionary are specified. If the type is xml then the xpath expression should be defined.

The following is an example settings file for Ascens referring to a Lift file:

# This is the settings file for Ascens
# Type is either xml or line
# for xml you also need to set the XPath

# path to the dictionary
# (can be absolute or relative to the directory that this file is in)
#Path=c:\documents and settings\user\my documents\dictionaries\fr_FR.dic
Path=..\..\..\My Documents\WeSay\French\French.lift

# XPath gives the Xpath that selects the words to be used as dictionary
# it must all be on a single line
XPath=//entry[not(citation-form/form[@lang='fr'])]/lexical-unit/form[@lang='fr']/text | //entry/citation-form/form[@lang='fr']/text
# this xpath selects the forms with the language id of 'fr' from the
# citation form when there is one and from the lexical unit when
# there is no citation form (it will not select both)

Enchant looks for user Ascens settings files in the following locations:

  1. The ascens subdirectory of the value found in the registry at HKEY_CURRENT_USER\Software\Enchant\Config\Data_Dir, if there is one.
  2. %APPDATA%\enchant\ascens, where %APPDATA% is shorthand for the C:\Users\\AppData\Roaming\ folder (Windows Vista) or the C:\Documents and Settings\\Application Data\ folder (Windows XP/2000).
  3. The enchant\ascens subdirectory of the directory value found in the registry at HKEY_CURRENT_USER\Software\Enchant\Config\Home_Dir, if there is one.
  4. %USERPROFILE%\enchant\ascens, where %USERPROFILE% is shorthand for the C:\Users\ folder (Windows Vista) or the C:\Documents and Settings\ folder (Windows XP/2000).

Enchant looks for shared Ascens settings files in the following locations:

  1. Using the value found in the registry at HKEY_CURRENT_USER\Software\Enchant\ascens\Data_Dir, if there is one. Otherwise, using the value found in the registry at HKEY_LOCAL_MACHINE\Software\Enchant\ascens\Data_Dir, if there is one.
  2. \share\enchant\ascens, where is the location of libenchant.dll.

homemade body wrap to lose inches


WeSay Tests on Mono Status

Author cambell | 22.04.2008 | Category WeSay

One step toward getting WeSay to run on the OLPC is to verify that it can run with Mono. WeSay Tests on MonoWe already reported all the System.Windows.Forms bugs that we could find by running MWF on Windows as documented here. The next step has been to run all the tests under Mono. As you can see from the diagram (that actually lives on our whiteboard) at left, we have found and fixed and reported quite a few bugs that have made the number of failing tests plummet. We’re still not there yet, but I’m making good progress.

Sale Windows 7 Ultimate