As happy as I am with WeSay, it is designed with a mindset of one user working on a given computer. It can work on a number of different languages (one at a time, of course!) out of the box, but it isn’t straightforward. You have to navigate to the WeSay folder, then click on the .lift file each time you want to work in a language other than the one WeSay opened last. Since one of the goals of working in BALSA is to hide the (often confusing) directory structure from the (initiate) user, this is unideal for switching between languages in Wesay on BALSA.
Since I’m doing just that (and a fair bit of switching on my own computer between WeSay in different languages), I wrote a script to invoke WeSay with the arguments calling for a given project each time it runs, so we will never need to think about what the last project was. It has a graphical tool (Zenity) to select which project to open, which is populated by the projects actually on that computer.
It assumes a structure of projects named by Ethnologue code, each in a folder with that name, each of which is in the same WeSay folder. It also assumes that each project has the full language name defined in the palaso:languageName tag in the language’s .ldml file (if it doesn’t, it will still work, but the gui will look off, and the next language will be on the same line).
I have the gui in English and French, since that’s what we use here. 🙂
For those interested, here it is:
#!/bin/bash
Version=2011.07.28
#set -x
#Note: this assumes a directory structure of WeSay projects named after three letter ISO/Ethnologue codes.
case $HOSTNAME in
Balsa*) wsfolder=/home/balsa/WeSay/;;
*) echo “Is WeSay set up on this computer? if so, update the $0 wrapper.”;exit;;
esac
langs=
PWD=`pwd`
cd $wsfolder
for xyz in `ls -d ???`
do
langs=”$langs $xyz”
langs=”$langs `grep –after-context=1 “palaso:languageName” $xyz/WritingSystems/$xyz.ldml|tr -d ‘n’| grep -o “<palaso:languageName.*>” |grep -o ‘”.*”‘|tr -d ‘”‘`”
done
cd $PWD
lang=`zenity –width=120 –height=400 –list –title “Open/Ouvrir Wesay” –text “Choose language / Choisissez langue:” –column=”ISO 639-3″ –column=”Name/Nom de langue” –multiple $langs`
echo “Ethnologue code entered: $lang”
if [ -f $wsfolder/$lang/$lang.WeSayConfig ]
then
wesay $wsfolder/$lang/$lang.lift
else
zenity –error –text “Sorry, please check the code and try again.n Désolé, SVP verifier la code, et éssayer encore.”
$0
fi
exit
Kent, any ideas how this kind of thing should look in WeSay itself? Some ideas:
0) Always ask (Con: bad for most users)
1) when you’re in wesay, show a list of other projects you could switch to (Con: slow if you know from the outset which you’ll want)
2) provide a command line argument which puts up a list like you are generating, instead of running the last-opened project. (Con: few would ever discover it)
2a) Do 2 and have the installer create a shortcut which has that command-line option built in, e.g. an icon which says “WeSay (choose project)”.
I think the first test that should apply would be the presence of more than one project in the WeSay folder. Assuming that most people that only have one project would never want to see this (though they might need to be told to open the config to start another project), and most people that have more than one project on a given computer would want this functionality at one point or another — though not necessarily every day.
What I’ve done is essentially your 2a, but it is the only one I use, since nearly all the computers I use/support have at least two projects (my computer has 12, as of today), and I need people to be able to work on our office loaner netbooks, whether or not they have the same computer they used last time.
If WeSay itself could ask “Is there more than one project on this computer?” and either display the dialog or not, that would be ideal from my perspective. Most of the people that don’t want it would never see it, and if a dead project is the only other project on a computer, it could be removed (and archived).
All this may depend on the file structure used for WeSay projects; I’m not sure how smart WeSay is at finding projects that have moved, and knowing if they still exist. My wrapper depends on a tightly controlled file hierarchy, which is the way I want it anyway. When 12 becomes 60, I want to still have it more or less under control…