LIFT
LIFT (Lexicon Interchange FormaT) is an XML format for storing lexicons/dictionaries. Using LIFT allows WeSay to keep your data very consistent and well structured, while exchanging rich data with other applications such as FieldWorks Language Explorer and Lexique Pro.
LIFT is not a sub-part of the WeSay project; we use it and contribute to the project. The web home for LIFT is here.
Contents |
Errata
The Lift format supports more objects and much more deeply nested data than any existing SIL dictionary program actually uses.
WeSay currently has good support for everything a WeSay user is likely to want to do. It has a growing ability to "round-trip" data coming to it from FieldWorks Language Explorer and Toolbox. This will allow you to share more linguistically-oriented databases with WeSay users, without it pruning off the stuff it doesn't understand.
The following is a guide to the state of LIFT support in WeSay.
Header
WeSay currently ignores everything in the header of the lift file. It stores this same information in the .wesayConfig file (this is just because LIFT was just being birthed when WeSay was started). We particularly like the idea of moving field and writing system definitions into the LIFT file, and hope to do so eventually. In the meantime, WeSay will round-trip anything found in the header; that is, it won't read it, but it won't remove it, either.
Entry
| Part | WeSay | FLEx |
|---|---|---|
| @id | Automatic | Automatic |
| @order | Round-Tripped (todo: integrate with our homograph numbering system) | |
| @guid | Automatic | |
| @dateCreated | Automatic | |
| @dateModified | Automatic | |
| @dateDeleted | Automatic | |
| lexical-unit | Editable | Editable |
| citation | Editable | Editable |
| pronunciation | Round-Tripped | Editable. Adds cvPattern, tone, ?source? |
| variant | Round-Tripped | |
| etymology | Round-Tripped | |
| sense | Editable | |
| note | Limited (see below) | |
| relation | Can edit relations to other entries. Relations to senses are round-tripped. | Editable |
| field* | Editable. See below for limitations. | |
| trait* | Editable. See section below. | |
| annotation* | DROPPED |
Sense
| Part | WeSay | FLEx |
|---|---|---|
| @id | Automatic | |
| @order | DROPPED | |
| @dateCreated | Automatic | |
| @dateModified | Automatic | |
| grammatical-info | Editable (any attached Traits are DROPPED) | |
| gloss | Editable | |
| definition | Editable (labeled 'meaning' in English UI) | |
| relation | Can edit relations to entries. Relations to senses are round-tripped. | |
| note | Limited (see below) | |
| example | Editable | Editable |
| example translation | Translation types other than 'free' and unspecified are round-tripped, but not editable. Only the first encountered of ('free', unspecified) will be made editable. | Editable (supports multiple translation types) |
| illustration | Editable (Only one supported?) | |
| subsense | Round-Tripped | |
| field* | Editable. See below for limitations. | |
| trait* | Editable. See section below | |
| annotation* | DROPPED |
Beyond that, WeSay has the following limitations:
note
WeSay currently only allows one note per object (e.g. one per sense), and it doesn't know about note 'types'. If you open a lift file with multiple notes, they are all joined together in one note, separated by "||". Notes with an explicit type are shown with the name of the type, in parentheses. When the LIFT is saved out to the xml file, these are not currently split back out to separate notes.
| Part | WeSay | FLEx |
|---|---|---|
| multitext contents | Editable | |
| @type | DROPPED | |
| @dateModified | DROPPED | |
| @dateCreated | DROPPED | |
| field* | DROPPED | |
| trait* | DROPPED | |
| annotation* | DROPPED |
gloss
If a sense has multiple <gloss> elements, all glosses in a given writing system are joined together with semicolons in between. When saving a LIFT file, WeSay splits glosses containing semicolons into separate <gloss>s again.
span
WeSay does not support marking up sections of text with different formats. When reading a LIFT file, it will ignore <span>s and just read their text. An entry coming in with styled text will thus lose the styling if and when WeSay writes that entry back out to the LIFT file. WeSay writes an entry when any part of it changes so you could lose styling even if that field is not modified.
field
WeSay supports custom fields using the <field> element. As with the LIFT standard itself, only one instance field with a given @type is allowed on a parent element.
| Part | WeSay | FLEx |
|---|---|---|
| multitext contents | Editable | |
| @type | Supported | |
| @dateModified | DROPPED | |
| @dateCreated | DROPPED | |
| trait* | DROPPED | |
| annotation* | DROPPED |
annotation
WeSay will drop all incoming annotations, except those it uses to remember the state of the "star" button next to each text field. WeSay allows you to "star" most items, where "star" might mean "I'm not sure" or "I want to come back to this". Starred items are saved with <annotation name='flag' value='1'/>
trait
WeSay converts traits into various kinds of widgets for editing depending on the declaration of the field in the .wesayConf file. If the multiplicity of the field is set to 1, it will be shown as a single combo-box (e.g., Noun Class). Otherwise it becomes a collection of type-ahead enabled boxes(e.g. Semantic Domains).
