Multilingual Option Lists
Any dictionary program needs to help the user be consistent when entering field that have a closed set of values, e.g. parts of speech.
FLEx calls these Possibility Lists, Toolbox has Range Sets. WeSay offers is something somewhat different, and yet another name (sorry).
Option Lists are multilingual, and they “fall back” to other languages if there isn’t a value in the language you’ve set it up to show. Here, I’ve set it up to show POS in Thai, but so far only noun and verb have Thai values.
A big thing we work at is forcing our programmer minds to give up on always having “good data”. For example, what if you send your dictionary to someone else, who has a different PartsOfSpeech OptionList installed? Say, you had a pos named “blah blah blah” and then tried to open lexicon up on a machine that didn’t have this pos. What should WeSay do? Show an error box? Not if we can help it. Say everything referenced in the lexicon must be in one large file? That may be hard to share with colleagues. We’ve chosen to use a human readable key that indexes into a richer set of multilingual data. If that data is missing, we do the best we can. This screenshot shows how WeSay will still show the key of the offending item, but mark it in red.
Finally, there is nothing in WeSay yet that really knows about Parts of Speech. They are just a custom field. So you could add something your language needs, like classifiers or noun classes.
Part Of Speech is now available in the default template used by new projects.
Some Nitty-Gritty Details for Techies
We are trying to make do with “human readable keys” rather than GUIDs. We use the key to look up stuff about the option, like how to show it in Spanish or what to show for an abbreviation of it. If the list is lost, the key is at least readable.
This is also our foray into “custom fields”, which I’ll blog more about some day. The pos field shown above was defined with this XML:
and the list of options is in a file that looks like this:
