A preferred grammar is selected when a user visits the Minibar for the
first time. (Like before, Minibar remembers the selected grammar for future
visits.)
A preferred list of grammars can be specified in config.js in the .../minibar
directory on the server, e.g. like this:
preferred_grammars=["/grammars/Foods.pgf","/grammars/ResourceDemo.pgf"]
The first available grammar from the list is used.
When you press the "i" or "More info" button for a grammar, the info now
includes a link that can be used by anyone to open this specific grammar in
the minibar.
The documentation is taken from a file called Grammar.pgf_info, located
next to the Grammar.pgf file on the server.
The first line of the documentation is displayed below the menu bar in
the minibar. The rest of the documentation is displayed when you press
the "More info" button (or the "i" button).
The documentation can contain HTML markup. Blank lines are treated as
paragraph breaks.
The editor doesn't show delete buttons on grammars published by other
users, but it was too picky when deciding which grammars you own. Now
it should be possible to delete grammars from the device/browser
you published it from, even if you don't have a private copy of it any more.
On a related note, there seems to be problem with the way unique grammars
names are created and maintained, causing published grammars to be duplicated
in some cases. This needs to be overhauled.
This was a problem in Safari (an other similar browsers I presume), but
not in Firefox: hovering over the grammar comment (shown below the grammar
name when you edit a grammar) didn't reveal the button to edit it, thus
preventing you from adding a comment. It was till possible by selecting the
"Enable editing on touch devices." at the bottom of the screen, but most
people probably didn't notice that it is possible to add a comment.
+ The PGF service now reads and caches dependency label configuration files.
+ The grammar info returned by command=grammar has a new boolean field
'hasDependencyLabels' to indicate if dependency labels were found for
the grammar. Also, command=deptree will now fail if no labels are present.
+ The minibar only shows word dependency trees if labels are present.
+ Also changed the type of getDepLabels from [String] -> Labels to
String -> Labels, since all uses were in the form "getDepLabels . lines".
This was done to obtain speech synthesis for more languages in the Numerals
grammar, which uses neither language flags nor the standard naming for
concrete syntax.
* Automatically update the translations when the set of selected
application grammars is changed.
* Skip application grammars that do not support the currently selected
source & target languages.
Add missing initalization after a new application grammar has been selected.
Add an "X" close button in the upper left corner of the grammar selection popup.
When selecting which application grammars to use for translation, after
pressing the "Grammars..." button, it is now possible to change the order
of the selected grammars by dragging them up and down in the list.
gfse/editor.js had its own list with 34 languages, while js/langcode.js
only had 30 languages. The missing languages have been added to
js/langcode.js and all apps now use that list.
There is now a new button "Grammars..." which show a list where users can
select which application grammars to use for translation, in addition to
the wide coverage grammar. Application grammars can give higher quality
translations in the domain they cover.
TODO: make it possible control the order of the selected application grammars.
This was fixed by adding "&nodep=true" in the minibar when it requests a
parse tree from the server. The reason dependency information got included
in the first place was that all rendering options are on by default in
command=parsetree requests in PGF service API.
Because of the "heurisitc factor", the results returned by the parser might
not be in strict probability order. To compensate, a sorting pass has been
added to find and show the translation with the highest probability among the
10 first translations.
However, this means that the translation demo now immediately has to ask for
10 translations of every segment. Before, it initially asked for only one
translation of every segment, and then 9 more translations for a segment
when/if the user clicked on it. This change can slow down translation
noticeably (e.g. from 15s 30s to load an example with fiction in English).
"File/Open In Wide Coverage Translation Demo" stopped working when support
for using different grammars in the Wide Coverage Translation Demo was added
On September 2.
