Write a initialization script for local installations. Write some documentation with instructions for how to set up a local installation.

It will be possible to set up a number of entry templates in a dictionary. When the user starts a new entry, they will have the option of basing it on a template, as well as starting from a completely blank entry as they do now.

Motivation: Templates are often used in dictionary writing systems to encourage structural consistency across multiple entries that belong together, such as colour terms or country names.

Make it possible for dictionary administrators to specify QA rules that go beyond the entry schema, for example: if an entry has more than one sense then each sense must have at least one example sentence.

Suggested by K Dictionaries.

A dictionary administrator will be able to configure a dictionary such that some parts of an entry will be 'shareable' between several entries. This will ensure that, for example, phraseological subentries are able to appear under more than one headword.

Note: This will implement a suggestion from my Raslan paper http://www.lexiconista.com/raslan2016.pdf

Allow the dictionary administrator to customize which XML elements are collapsed by default in the XML editor.

Current behaviour: all XML elements are collapsed, except to top-level element and except any unrecognized elements (= elements not allowed by the schema).

Requested by Gidi Karni and Dorielle Lonke of K Dictionaries.

Hello. First of all, thank you for creating this resource! I cannot find detailed documentation for exporting data from Sketch Engine to Lexonomy. If this exists, I would be very happy if you could point me to this information.

Here are the steps I took.

1. Created Lexonomy account
2. Put Lexonomy API key into sketch Engine account
3. Created a Corpus form the Web in Sketch Engine.
4. Selected the 1-Click Dictionary Feature
5. Clicked the Go Button.
6. Click Open.

Upon completing step 6, I am taken to the dictionary but it is blank, there are no headwords or nothing. I have tried to do this with several different corpora and with no success. Here is a screenshot of the screen says after step 6:

When clicking on this dictionary you can see that no data has been imported:

Users will be able to include cross-references from one entry to another entry or to a location in another entry (such as specific sense inside a dictionary entry). Lexonomy will make sure the cross-references are clickable when the entry is formatted for display. Also, Lexonomy will keep track of what cross-references what, will make sure that cross-references are never broken, and (if the dictionary is so configured) will make sure that cross-references are reciprocated: if X cross-references Y, then Y must also cross-reference X.

Users will be able to include external links (= internet URLs with an optional caption) in entries. Lexonomy will make sure they are clickable when the entry is formatted for display.

Like in old Lexonomy:

• starts like this
• contains a word that starts like this
• contains this sequence of characters
  Requested by Iztok Kosem.

Users will be able to upload images and other media files (sound files, videos) into a dictionary and link to them from XML elements and attributes in entries. When formatting entries for display Lexonomy will make sure the media files are presented appropriately (images are displayed, sound and videos are playable).

Adam Rambousek 18 Sep, 2018
Schema: select file type (audio, video, image). Upload files to directory (separete for each dictionary). In XML link to URL.

[email protected] 26 Oct, 2018
We have already done this with audio files. Works fine but the users needs to be able to upload the files themselves (at the moment, Lexonomy administrator has to do it).

A dashboard with statistics on the dictionary, both static (how many entries, their relative sizes, their alphabetical distribution, their workflow status etc) and dynamic (what has recently happened to my dictionary, most active users recenty etc).

Suggested by K Dictionaries.

In addition to a blurb, the next version of Lexonomy will allow you to add one or more publicly visible 'about' pages to your published dictionary. Like a wiki with Markdown.

Requested by Carole Tiberius of IVDNT and by K Dictionaries.

Adam Rambousek 3 Sep, 2018

https://github.com/rambousek/xonomy-tools/tree/master/detect
use XML document(s) to detect entry structure, same internal structure as for DTD conversion
may be used to Xema or Xonomy docSpec

example
https://github.com/rambousek/xonomy-tools/blob/master/example/run_detect.js

Optionally, while editing an entry's XML, the user may want to see a live preview of the formatted entry.

Even better, the section they are editing should be highlighted somehow.

(Suggested by Iztok Kosem.)

[email protected] 18 Sep, 2018
Just a note that this is probably closely connected to the Entry formatting tasks.

Currently, a dictionary's public inteface is only viewable if the dictionary has been declared "public". The applies to both anonymous web users and logged-in dictionary editors.

The suggestion is to make it possible for logged-in dictionary editors to view the public interface even before the dictionary has been declared "public".

Suggested by Ondřej Matuška.

Instead of, or in addition of, existing view options, the user should have all XML elements visible as windows in which the information can be inserted immediately, without the need for opening the window separately and clicking on OK each time. Basically, one would edit the text and save the entry when needed (some automatic saving could be introduced).

This would need to be combined with the Dual Entry display option, which is also on the list of To-do tasks.

Rethink and fix the XML upload feature. It fails on large files and seems to have a weird problem with files not produced by Lexonomy itself.

Most complained about by Iztok Kosem.

Make it possible for dictionary administrators to create (by hand-coding in JavaScript, HTML and CSS) and upload a customized entry editor to replace the default XML entry editor (= Xonomy).

Need for dictionary projects where the users simply can't handle XML.

That, or make it possible for less technical uses to perform some editing tasks in the formatted view of the entry.

Upload feature needs to support importing large files.

In the XML editor, when a picklist is long, make it possible for the user to navigate the list by typing (the beginning of) the value.

Requested by Gidi Karni of K Dictionaries.

Lexonomy will not use any form of entry locking (= blocking other users from opening/saving an entry if someone else currently has it opened). Instead, Lexonomy will go for a light-weight approach: it will inform the user if it looks like the entry he or she is editing is currently opened by another user or if the entry has been saved by another user in the mean time.

Would be nice for each headword (in the headword list on the left-hand side) to a visual indicator of its size.

In the schema designer, make it possible to hide or disable some XML elements and attributes so that editors can't change them in the XML editor. (Requested by Carole Tiberius.)

Even better, do this as a separate feature outside the schema designer. That way it will work even when the dictionary administrator has uploaded their own DTD (ie. when they're not using the schema designer).

Send email notification when user is add as collaborator to dictionary

Features for assigning entries to users, grouping entries in batches etc, marking the status of entries (new, in progress, finished etc.) ...

Don't save Ske API keys in logfile. Add timestamps.

While editing an entry, Lexonomy will have an undo button, like you'd find in a typical word processor.

Lexonomy needs more sophistication in the alphabetical sorting of entries. The current approach in which the lexicographers can input their own alphabetical sequence, is good and very flexible but works only for languages with alphabetical (and perhaps syllabic) scripts. We need:

• A good solution for ideographic scripts like Chinese (this is an issue for user [email protected] who is working in Lexonomy on Chinese). Probably we need to let the user select a collation and simply outsource the problem to a library. This would be good for all languages, but the current "manual alphabet" must continue to be available too, as an optional override, to make sure Lexonomy continues having good support for minority languages with no standardized collations, for non-standard alphabetical sequences and so on.

• Support for explicit sorting keys encoded in the entries: this implies sorting entries by something else than the headword.

Milos Jakubicek 25 Jul, 2018
­
Pavel Rychlý on Wednesday Nov 29, 2017 10:45 AM:
why not to use standard locales:
var a = ['hlad', 'chleba','řeka', 'rok']
a.sort(function (x,y){return x.localeCompare(y,'en');})
>> ["chleba", "hlad", "řeka", "rok"]
a.sort(function (x,y){return x.localeCompare(y,'cs');})
>> ["hlad", "chleba", "rok", "řeka"]

---------------------- ­
Michal Boleslav Měchura on Wednesday Nov 29, 2017 10:49 AM:
That's more or less what I have in mind with the "let the user select a collation" option.
AR
Adam Rambousek 26 Jul, 2018
note: nodejs needs to install full locale support https://www.npmjs.com/package/full-icu

Configurable automatic saving of entry

It would be good if certain elements could be easily recategorized, for example if a subsense and all the information in it could be easily moved to sense level. At the moment, this requires opening up a new sense element and moving all the subsense information in it.

An API for e.g. reading entries that have been changed recenty, doing something with them and then pushing them back in.

Suggested by K Dictionaries.

Iztok Kosem: "One piece of feedback for you - our lexicographers are complaining that whenever they make a change and forget to click Save, they are not warned but the entry changes and they lose changes. A warning or sth would be useful."

For auto-generated dictionaries from Sketch Engine. Sense splitting/lumping, moving example sentences from one sense to another, etc.

The entry formatting (visualization) options in the current version of Lexonomy are kind of OK (they're certainly better than in the beta version) but they need more sophistication. We need two things:

• On the one hand, we need more and richer formatting options, similar to what you'd find in a WYSIWYG word processor.

• On the other hand, we need a "quick settings" option where people could choose from a pre-defined template, for example Make this XML element look like a sense or Make this XML element look like a headword.

[email protected] 18 Sep, 2018
I would say that anything to enable quicker and more user-friendly editing would be most welcome. As soon as the dictionary structure is more complex/rich and contains many items, opening different tags and entering text becomes very tedious and time-consuming.

Michal Boleslav Měchura 18 Sep, 2018
Iztok, what you're saying is true but not relevant to this task. This task is about the options Lexonomy has for the pretty-printed formatted visualizations of entries. This task is not about the XML editor.

[email protected] 18 Sep, 2018
OK, where do I move my comment then? Or even better, if you know a place, feel free to copy it there.

Internally, Lexonomy keeps track of who saved what and when, and has a complete history for each entry. Based on this, Lexonomy will offer features for viewing an entry's history and for restoring previous versions.

It will be possible for a dictionary administrator to limit a user's access to only a subset of entries, or to only some locations in an entry. For example, some users may only be allowed to add translations to entries but cannot change anything else.

Requested by Carole Tiberius of IVDNT and by K Dictionaries.

In the current version of Lexonomy, when you decide to publish your dictionary, you have no option but to publish all entries in the dictionary. In the next version you will optionally be able to select only a subset of entries for publishing, for example only entries that have a specific status.

Lexonomy reloads the entry list (on the left hand side of the screen) each time an entry is saved. This is in case the title of the entry has changed as a result of the save and the entry now needs to appear somewhere else in the alphabetical order. It turns that this was not a good idea, for two reasons:

• When the entry list is very long it takes very long to reload it and the user can erroneously assume that the entry has not been saved yet.

• When the entry has in fact changed and the entry moves somewhere else in the alphabetical list (which may be off-screen) it turns out that users find it confusing.

In the current version, Lexonomy only allows you to search for entries based on their title (= headword). The next version will bring more sophistication into this. A dictionary administrator will be able to specify which elements and attributes are to be indexed for search purposes and how their values are to be interpreted (as strings, numbers, dates...). Based in this, Lexonomy will enable users to filter the list of entries based on arbitrary combinations of criteria.

Also (suggested by Ondřej Matuška):

• Search entries based on XML markup: entries that have/do not have a specific XML element, a specific number of number of specific elements etc. XPath?

• Find entries that have validation errors (as per the schema).

This requested by Ligeia Lugli (SOAS, University of London):

Also, do you plan to add a filter feature to the Lexonomy search? For example, in the Tibetan dictionary I am working on, each word sense is categorised according to the period(s) in which it is attested. I would like the users of the dictionary on to be able to search for word-senses attested in a particular historical period (e.g. in Medieval Tibetan), and filter out the meanings of that words in other periods. Do you think this would be possible in the near future?

A dictionary administrator will be able to set up a mapping between two dictionaries. Based on this mapping, Lexonomy will guide users to make sure the dictionaries are synchronized.

Note: This will implement a suggestion from my Raslan paper http://www.lexiconista.com/raslan2016.pdf

Dictionary administrators who do not want to use Lexonomy's stylesheet editor will be able to upload their own XSL/CSS stylesheet.

I have tried to import a dictionary, but the app starts posting a huge number of sqlite errors:

Error: SQLITE_BUSY: database is locked errno: 5, code: 'SQLITE_BUSY'

By following the code and running the profiler, I see that pretty much all the time the code is computing import function from ops.js, running regex matching and copying data using memcpy. The process does not end in a couple of hours. How should I handle this?

I have also uncommented those console.log calls (CREATED, UPDATED, going to create) and they get printed from the beginning, but then everything stops, however CPU is still on 100%

EDIT: now more are being printed, I'll see if this is finished by the morning.

When creating a new dictionary, Lexonomy gives you a choice of several templates (as well as a completely blank one). All these templates are very simple, which makes them suitable for learning Lexonomy but not for real work. I will develop a few more realistic templates suitable for industrial-strength applications, replicating (subsets of) schemas from well-known standards such as TEI and LMF.

Adam Rambousek 26 Jul, 2018
TEI-Lex0 (when existing)?

Dictionary administrators who do not want to use Lexonomy's schema editor will be able to upload a schema they have written in some other formalism, such as a Xonomy document specification http://www.lexiconista.comm/xonomy/ or a DTD.

A feature to review recent changes in the dictionary, including (importantly) recent deletions.

Copying/pasting/duplicating an entire fragment of the XML (requested by Iztok Kosem).

A "lay-by area" beside the entry where you could temporarily store entry fragments: example sentences that you have not moved into a sense yet, etc (suggested by Pavel Rychlý).

Features to support the use of defining vocabularies in definitions etc. Kind of like spellcheck but with the vocabulary coming from a custom dataset and/or the dictionary itself.

Suggested by K Dictionaries.

Every screen in the configuration section (as well as the One-Click Dictionary API key screen) requires you to click the Save button but save your changes. In some cases this is unintuitive and people keep forgetting it.

When publishing a dictionary in Lexonomy, the current version allows you to supply a 'blurb': a short description which appears on the dictionary's homepage. The blurb is in plain text.

Lexonomy will allow rich-text formatting in the blurb: bold, italics, paragraph breaks, clickable links, etc. (in other words: Markdown).