https://github.com/livingtongues/living-dictionaries
Issue draft, possibly to post with a companion pr implementing it:
Title: Native LIFT export — a portable, tool-neutral copy of a community's dictionary
What this is
A proposal to add LIFT as a second structured export format alongside CSV (revisiting #44, closed in 2024, and complementing the export improvements discussed in #627).
LIFT ("Lexicon Interchange FormaT") is a plain-XML file format designed specifically for moving dictionary data between programs. It is a common interchange format of the language documentation ecosystem: FieldWorks, The Combine, WeSay, ELAN (for interlinearized texts), and Dictionary App Builder all read it, and archives accept it.
Spec: https://github.com/sillsdev/lift-standard (stable v0.13 is widely used; there are no active plans to proceed to the proposed v0.14 or v0.15).
Why it helps Living Dictionaries communities
- Data ownership becomes portable in practice, not just in principle. Communities own their data on the platform; a LIFT export lets them take it anywhere — into desktop tools for offline work, into The Combine for expansion via Rapid Word Collection, into a mobile-app builder, into an institutional archive — without a bespoke converter per destination.
- CSV can't carry the structure a dictionary actually has. The current CSV export flattens multi-sense entries, keeps only the first audio/photo/sentence, and exports semantic domains as translated display text. LIFT natively represents entries → senses → examples, multiple writing systems per headword, audio/photo references, and stable entry ids (so a later re-import can update rather than duplicate).
Why it's smaller than it sounds
- Writing LIFT is much easier than parsing it — an exporter only emits the subset of constructs that the Living Dictionaries model has; it never faces the full spec's optionality or malformed input. Realistically a few hundred lines of dependency-free TypeScript: a multitext helper (LD's
MultiString maps 1:1 onto LIFT's <form lang><text> pattern), per-entry/sense serialization, XML escaping, and a .lift-ranges companion file for the semantic-domain and part-of-speech vocabularies.
EntryData is already assembled identically on server and client, so the exporter is a serializer over an existing read model, not new data plumbing.
https://github.com/livingtongues/living-dictionaries
Issue draft, possibly to post with a companion pr implementing it:
Title: Native LIFT export — a portable, tool-neutral copy of a community's dictionary
What this is
A proposal to add LIFT as a second structured export format alongside CSV (revisiting
#44, closed in 2024, and complementing the export improvements discussed in#627).LIFT ("Lexicon Interchange FormaT") is a plain-XML file format designed specifically for moving dictionary data between programs. It is a common interchange format of the language documentation ecosystem: FieldWorks, The Combine, WeSay, ELAN (for interlinearized texts), and Dictionary App Builder all read it, and archives accept it.
Spec: https://github.com/sillsdev/lift-standard (stable v0.13 is widely used; there are no active plans to proceed to the proposed v0.14 or v0.15).
Why it helps Living Dictionaries communities
Why it's smaller than it sounds
MultiStringmaps 1:1 onto LIFT's<form lang><text>pattern), per-entry/sense serialization, XML escaping, and a.lift-rangescompanion file for the semantic-domain and part-of-speech vocabularies.EntryDatais already assembled identically on server and client, so the exporter is a serializer over an existing read model, not new data plumbing.