-*- org -*-
- Function: IE9+ (?) Safari(?) – search functionality must work
- Cosmetics: IE10+ Safari(?) – minor difference in appearance is ok
KNOWN ISSUES:
- Firefox before version 64 (Dec 2018) will show scrollbars in the textarea. On Firefox ‘overflow: hidden’ suppress scrolling of the <textarea> field when user pastes text into it, we therefore use the Firefox-specific ‘scrollbar-width: none’ for which support was added by Firefox 64.
Used to show/hide search box reset button + changing color of submit button.
| 2007 Jun | Safari 5+ | |
| 2009 Sep | Opera 10+ | |
| 2010 Sep | Safari iOS 4 | |
| 2011 Mar | Chrome 10+ | |
| 2011 Mar | Firefox 4+ | <– Not working on version <51? |
| 2011 Oct | Android 4+ | |
| 2012 Sep | IE/Edge 10+ | <– Not working? |
|---|
Caniuse.com tab ‘Known Issues’ says that ‘:invalid’ might not work on <form> element in Firefox <51 and IE/Edge.
https://caniuse.com/#feat=form-validation
Used for vertical layout in <body> and for horizontal layout of the search form.
| 2013 Dec | Android 4.4+ |
| 2012 Jun | Chrome 21+ |
| 2014 Mar | Firefox 28+ |
| 2015 Jul | IE/Edge 12+ |
| 2012 Nov | Opera 12+ |
| 2014 Oct | Safari 9+ |
| 2010 Sep | Safari iOS 9+ |
|---|
Not using vendor prefixes.
NOTE: There are good chances this will fail quite miserably on Internet Explorer (IE10 requires ‘-ms-’ vendor prefix, and IE11 is very buggy).
https://caniuse.com/#feat=flexbox
Used for filtering away newlines when user pastes into search box. (Filter is disabled if browser support isn’t present.)
| 2009 Oct | Android 2.1+ |
| 2010 Jan | Chrome 4+ |
| 2006 Oct | Firefox 2+ |
| 2011 Mar | IE/Edge 9+ |
| 2011 Jun | Opera 11.5+ |
| 2009 Jun | Safari 4+ |
| 2010 Sep | Safari iOS 4+ |
|---|
https://caniuse.com/#feat=input-selection
Used by onscreen keyboard button background color.
| 2008 Nov | Safari 3.2+ |
| 2009 Jun | Firefox 3.5+ |
| 2009 Oct | Android 2.1+ |
| 2009 Sep | Opera 10+ |
| 2010 Jan | Chrome 4+ |
| 2010 Apr | Safari iOS 3.2+ |
| 2011 Mar | IE/Edge 9+ |
|---|
https://caniuse.com/#feat=css-sel3
Used to detect touchscreen devices, and hide onscreen keyboard when submitting search box.
| 2011 Feb | Android 3+ |
| 2011 Feb | Chrome 9+ |
| 2011 Aug | Firefox 6+ |
| 2012 Sep | IE/Edge 10+ |
| 2012 Nov | Opera 12.1+ |
| 2012 Jul | Safari 12.1+ |
| 2012 Mar | Safari iOS 5+ |
|---|
NOTE: Will most likely fail catastrophically on unsupported browsers (probably making search submitting impossible).
https://caniuse.com/#feat=matchmedia
Useful one-liner for finding old files: `for x (**/*(.)) { echo $x; git l $x A 1 } M`
There should also be a link to a page with instructions for how to (re-)install the typeface.
https://jakearchibald.github.io/svgomg/
All pages should use one base CSS + an extra CSS with the styles needed for these pages, and preferably there should be no extra per-file CSS.
A wiki for “Virtual Humans” http://vh.cmp.uea.ac.uk/index.php/JASigning_Demos
These are some cool BSL examples: http://vhg.cmp.uea.ac.uk/demo/BSLExamples/
All aspect of the lexicon GUI and query language shall:- Be simple and obvious. (Low barrier of entry.) The GUI shall look simple and uncluttered, and obvious things (like just typing a few words and press the search button) shall Just Work™ and provide decent results.
- Be self-explaining. (Help the impatient achieve what they want quickly.) Tool tips and autocompletion shall provide the user with context relevant information, and allow them to explore the search space efficiently.
- Be explorable. (Help the curious user learn more.) If the user goes hunting for more information, that information shall be easily available, and structured in such a way that any user will have to read as little as possible in order to find out what they need. – The documentation should (possibly?) include interactive elements an ‘advanced search’, that when submitted add to the query in the search box.
- Be forgiving. (Allow for mistakes/sloppiness.) All queries should return a result (as long as there are matches) even if they are malformed. User should also receive simple-to-understand messages pointing out the error (e.g. a tooltip pointing an unterminated parenthesis, with the message ‘Missing end parenthesis’).
- Accommodate expert users. The query language shall include grouping, boolean operators, search prefixes (to specify which fields to search) and other advanced features that are useful to researchers and advanced users. These functions shall not intrude on the beginner’s user experience.
This actually means ‘match only empty fields’ and should definitely be retained.
There should be a clear-cut way of distinguish a search for a transcription and a translation. Normal alphabetical ‘B’ should match both transcription and translation, but one should be able to specify which one one wants to search.
Used in branch ‘devel-query-editor’ for the query editor.
Advanced search doesn’t fit very well on mobile. Need to either adjust margins (and possibly also icons in the input form).
A good example of an ‘advanced search’ dropdown can be found in Google Calendar, by looking at the calendar search, though this one does not update the main query as you type stuff.
GitHub advanced search, however, presents an advanced query feature where you may enter stuff in a multitude of fields, and updating the content of any of these fields will cause a realtime update of the main search query at the top of the screen. https://github.com/search/advanced?q=smulx
If there’s a string in the text input field that has been entered by the user during pageload, then this should replace any search query given in the URL. (Least astonishment factor.)
`då -hej -och` will find all occurrences of `då` except those also containing `-hej` or `-och` (this makes sense).
`då, -hej` will find all occurrences of either `då` or EVERYTHING (=all of lexicon) except `hej` (does that make sense, or should a all negated expressions simply be disregarded unless they are AND:ed to a positive search term?)
Would like to have some simple (preferably, though not necessarily real-time) statistics of page activity. Ideally to be able to follow a session from search to search. Primary motive of this:- Track site popularity (is anyone at all using the site?) and changes therein.
- Investigate user patterns (to be able to add better suggestions and improve design).
If a user opt out of this tracking (by means of an adblocker or whatever) then there should be no punishment for this whatsoever. (Also, since the lexicon operates on a zero-budget, the tracking service need to be free of charge for the site maintainer/me.)
The intent is to log how users refine their search to find what they want. Users should be given a (temporary) id (randomly created a user arrive at the page), and then the search string they entered should be logged. Logging should occur in unobtrusively background, and if logging fails this should not impact the user’s search in any way. Clicky account needs to be re-activated manually every 60 days, which is a hassle. Also it doesn’t actually seem to log the relevant data (the search queries). See: *Lexicon: Stop using clicky.comLeave the history of the lexicon in the zrajm page repository, but create a new repository containing the complete history of everything included in the lexicon.
Move lexicon to https://zrajm.github.io/teckenlexikon/
Hopefully this will eventually move to http(s?)://zrajm.org/teckenlexikon/, but at that point we’ll simply create a new redirect.
https://zrajm.github.io/teckentranskription/lexicon.html should forever remain valid, and redirect to the new location.
The search box should have autocompletion similar to Google.- Autocomplete textarea https://www.algolia.com/doc/guides/building-search-ui/resources/ui-and-ux-patterns/in-depth/autocomplete/tutorials/autocomplete-textarea/
- jQuery.textcomplete (Autocomplete for Textarea) http://www.jque.re/plugins/version3/jquery.textcomplete/index.html
- Autocomplete for textarea elements http://yuku.github.io/textcomplete/ GitHub repo: https://github.com/yuku/textcomplete Example site: https://yuku.takahashi.coffee/textcomplete/
After having performed a search, extra button should be presented with likely additional narrowings of the search (similar to the rounded, gray buttons on Youtube which can be used to narrow the displayed suggestions, similar buttons are also displayed at the bottom of your Google search results for related searches – though our buttons should add to, rather than replace the search query).
These buttons should all add something to the end (beginning?) of the current query and perform a new search. Possible buttons:
- (Bana enhandstecken)
- (Bara tecken med aktiv+passiv hand)
- (Bara dubbelhänta tecken)
E.g. HYFF ‘to be on the safe side’ (‘för säkerhets skull’), PAFF ‘leave’ (‘sticka iväg’), PI intensifier, ‘actually’ (förstärkningsord, ‘verkligen’) and PY ‘too’ (‘också’).
Add an icon for ‘mindre vanligt’Add a small semi-transparent map of Sweden with the relevant region hilited on top of video bottom right? (Name of region in categories + on hover.)
Signs in the lexicon that can be also found in the SSLC corpus should link to teckensprakskorpus.su.se. These lexicon entries should contain the corpus gloss for that sign – something which is not included in the weekly data import from teckensprakslexikon.su.se, but will have to be maintained separately. – Maybe use a separate file (`corpus-data.js`) so that this doesn’t have to be updated weekly, and can be cached in the user’s browser? (Or maybe this is counterproductive since that will require an extra file fetch on load?)
The frequency information could be used to indicate common signs, and to help in sort-by-relevance (in that more common sign, all other things being equal, should appear earlier in search results than less common signs).
Typing anything else should bring out a notification (in the bottom left corner?) ‘Press [/] to jump to the search box’ – The notification should probably slide in and out of view (just like Google does it) in order to catch the user’s attention.
turkos, dövlexikon, svenskt teckenspråkslexikon, dövhet, teckenspråk, svenska
Lexicon should be distinguishable from the official lexicon by name. Maybe use name ‘Snabbt teckenspråklexikon’ or ‘Snabba tecken’? ‘Turbotecken’?
Leakyness? – Does a new search completely (or as completely as possible) clear the memory before building up a new search result?
Is the search result list of an okay size? (Was it smaller with the old array, instead of object, approach?)
This isn’t needed on startup, but only when user requests it (maybe load it in the background though?) Especially when building a progressive web app it might be kinda sad if it wouldn’t be accessible when offline.
- Maybe use (drop-in replacement) alternative to jQuery?
(What do we lose if we do this? Compatibility? What compatibility do we
have now? How would that change? Which jQuery features are we actually
using in the various pages? How can that be investigated?)
- Maybe Cash? (https://kenwheeler.github.io/cash/)
- Maybe Zepto.js (https://zeptojs.com/)
- Maybe something else? http://www.guguncube.com/3297/jquery-alternatives-and-drop-in-replacement-of-jquery-javascript-library
- SVGOMG online SVG minifier
- SVG ‘fill’ attribute defaults
- SVG ‘xmlns’ and ‘version’ not needed in inline SVG
This icon is inlined since it is (a) only used once (in the search form) and (b) it is visible on page load.
Module should have methods for returning named entry properties (i.e. the ID, transcription, translation etc. of an entry).
Currently using /u regex flag, which turns out to be ES6. This program probably won’t work without it, and thus it might be better to go all the way and use `let` and `const` and all the other good stuff from ES6.
Which browsers support ES6?
Need to test (get some statistics on what browser ppl have):
Compatibility data is from here: http://kangax.github.io/compat-table/es6/
- ES5 standard released in 2009.
- ES6 standard released in 2015.
- ES8 standard released in 2017 (https://262.ecma-international.org/8.0/).
| Browser | /u support | |
|---|---|---|
| Firefox | >=v50? | 2016-06-06 |
| EdgeHTML | >=v12 | 2016-08-02 |
| Safari | >=v10 | 2016-09-20 |
| Chrome/Chromium | >=v54? | 2016-10-12 |
| Explorer | - | - |
If we need to go ES5, then splitting of the query string can be done with code found here: https://stackoverflow.com/a/38901550/351162
This would allow a user to ‘install’ the lexicon on their phone (regardless of OS!).
- This hides the URL, so probably need a separate share button
A syntax to allow for video/text search results + upcoming overlays.
Eg ‘/xx’ in the URL http://localhost/tsplex/lexicon.html#he/help/xx or the multiple ‘####’ in http://localhost/tsplex/lexicon.html####he/help/xx
This URL cleanup thing could probably reside in getStateFromUrl(). However, doing this sort of cleanup would make user lose information they’ve typed into the URL bar, and might not be such a good idea?
Since this modification of the URL would cause an immediate rewrite of the URL it shouldn’t be stored in the browser history, but the faulty URL should simply be replace by the new one using `replaceState()` rather than `pushState()`.
(Except for the video toggle part; cleaning up the number of ‘########’ sounds like it would always be good, right?)
The blog post “Index 1,600,000,000 Keys with Automata and Rust” (https://blog.burntsushi.net/transducers/) talks about building a search index in the form of a finite state machine.
It also states that it’s very fast do compute unions and intersections. Meaning, that since both query and index are automatons, calculating the search results is just a matter of intersecting the two automatons.
There is also a way to convert the query automaton into a fuzzy ditto (with the fuzzy automaton matching everything up to a certain Levenshtein distance from the original query). – If this is used, and also output a match distance for each match, we could then sort the result by relevance.
If one searches for `/språkvetenskap`, then this will hilite the translation ‘språkvetenskap’ (which matches both in translation and tags), but only the matching tag should be hilited.
Right now this is handled as an empty search term that is negated (but, since it’s empty it’s not included in the search). Is this sane? Or should a single, unquoted ‘-’ match literally (ie be treated in the same way as ‘-’ is treated inside or at the end of a word).
Either treatment is kinda surprising to be honest, not sure which one is best. (Best would prolly be to treat is as a literal ‘-’ and inform the user of a potential mistake.)
For word searches `hej` should not match `hejsan` (unless user searches for `hej*`), but this is confusing when searching in transcriptions. Transcription characters should match even in the middle of a ‘word’, e.g. searching for transcription `A` should match all signs that use the handshape `A` (even if the user did not specify `*A*`).
E.g. tag:… to search for a specific tag, sv:… to search for a translation, gloss:… to search for glosses. Also, a matching tag should mark the tag icon in the search result, and the matching tag in the tag hover/drop-down menu.
Should be able to find synonyms. Maybe using a wordnet dictionary?
Allow usage of annotation handshape in place of the transcription symbols. These are the:
| A | A-hand |
| Ao | Tumvinkelhand |
| B | Tumhand |
| D | D-hand |
| G | Knuten hand |
| .. | .. |
| Jt | Flat tumhand |
| Lbs | Liten O-hand |
| etc. |
Complete table in Wallin & Mesch (2018, s 45)
Add a prefix to specify that a match should be all within the same segment. (Maybe ‘x:’?)
This would mean that a query like ‘*##:’ cannot match across segment borders.
In practice this means that in fields with this prefix, an asterisk (’’) should match ‘[^/]’ (where ‘/’ is the segment separator) instead of ‘.*’.
Motion left/right/forward/backward/up/down character classes should allow short motion as well.
- ‘’: ‘[]?’, // motion left
- ‘’: ‘[]?’, // right
- ‘’: ‘[]?’, // forward
- ‘’: ‘[]?’, // backward
- ‘’: ‘[]?’, // up
- ‘’: ‘[]?’, // down
‘move right’, ‘short motion right’ and, ‘curving motion right’ and ‘hit right’, should all be matched by ‘move right’.
Mapping motion left to motion left & short motion left.
All arrows, not including ‘contact’.
Old + new circle symbols
Curving, (all types of) circling, hitting and turning.
Useful when one is searching for one of multiple hand shapes.
Example: `=(en,två,tre)` should be same as `(=en,=två,=tre)`.
Currently a query like `a(b)` will search for all entries with both the words `a` and `b`, but maybe this should instead search for the word `ab`? This would allow one to search for stuff like `ovan(för,lig)`. (Is this actually useful?)
`”om “(en,två)` should be same as `(“om en”,”om två”)`.
What happens with spaces in queries? If `a (b,c)` match differently than `a(b,c)`, what should `a( b,c)` match? I think only spaces on same level should be used (meaning that `a( b,c)` would be same as `a(b,c)`).
Returned result should have one list per subquery (and in the same order as the subqueries), and the result should be displayed in that order.
Sorting algorithm:
- Percentage of field matched
I.e. if searching for ‘2’ then the matching field ‘2–2’ should get lower relevance score than the field ‘2’ (even though ‘2–2’ contains two matches, some of the content of the field is not matched by anything).
- Should content that is matched by ‘*’ in the search query count towards relevance? (Count as half?)
- If a match is done through a synonym, it should get a lower a match score than if it matches the query as specified.
Calculated from how much of the matching field was matched by the search query? E.g. if I search for ‘hej’, this currently gives me the following search results (by order in database, <…> marks the matching part):
00032 <hej> 01602 <hej>a på 05705 <hej>are på, strong, en baddare på 07895 <hej>a på 11736 <hej> då 11770 <hej> då 12747 h-e-j <hej>
While a relevance-based algorithm should give me the following:
00032 <hej> 12747 h-e-j <hej> 11736 <hej> då 11770 <hej> då 01602 <hej>a på 07895 <hej>a på 05705 <hej>are på, strong, en baddare på
Largest match score is assigned to the two entries for which the entire field matched. The lesser percentage matching, the further down in the results the match comes.
Eventually other factors should also weigh in, we could for example have a score (in the database) for each individual sign, e.g. giving a lower score to a less common sign, e.g. fingerspelled versions of signs (like ‘h-e-j’ in list above). (This should be based on frequency data from the corpus.)
Search result should be sortable in by:
- Subquery order
- ID number
- Sign language transcription (sort order?)
- Swedish
Default should be: subquery + sign language.
Present search result in a sortable table? Should be able to sort by swedish word, and by sign language.
But opening menu using keyboard should.
Simplify CSS so that focus marking look the same for the X icon as for the links. (This will be clearer to the user.)
When selecting the URL bar in the browser, Tabbing and Shift-Tabbing the focus should only go to the menu, no other parts of the page.
An info text briefly describing design idea, nature of cooperation with ‘Svenskt teckenspråkslexikon’ and the CC license.
- Add CC license text + note data source
Something like ELAN’s [https://archive.mpi.nl/tla/elan/cite]; “When citing ELAN as a computer program in a publication, the following APA style reference can serve as an example (adjust the version and release date):
‘ELAN (Version 6.3) [Computer software]. (2022). Nijmegen: Max Planck Institute for Psycholinguistics, The Language Archive. Retrieved from https://archive.mpi.nl/tla/elan’”
If one searches for `hej` and `hej då` at the same time, the highlight should be doubled on `hej` in the search result.
Maybe the .hilite method of the query object should return a list of regexes, and these regexes should allow for any HTML expression to occur between any letter in the regex. Also if there’s HTML in between the <mark> tags might need to be broken into multiple <mark> tags. E.g.
<mark><mark>hej</mark> då</mark>
(To make HTML form more readable.)
There should be two types of focus markers: borders and icons. Menu and form icons (clear and keyboard) button should look the same.
Menu & overlays should have the same look-and-feel. Should this also apply to the onscreen keyboard?
4px rounded corner? + Textbox shadow?
Both menu and overlay should have dark scrim outside it. It should look the same for both.Current root font size is 22px, but other search engines use:
| Ecosia | 20px |
| Duckduckgo | 18px |
| 18px |
|---|
I.e. darken everything all but input form when using the onscreen keyboard?
Focusing on the onscreen keyboard should work the same as with the menu.
Should focusing be trapped to onscreen keyboard + search field when keyboard is open? (Similar to the left hand side menu.)
NOTE: Using Tab and Shift-Tab from the URL field should never activate any other part of the page when focus is locked to the onscreen keyboard.
The onscreen keyboard should be displayed on top of search results, so that dropping the keyboard does not scroll the search results.
The onscreen keyboard should be replaced with something a bit more intuitive. A proper self-explanatory interface for writing sign language transcription.
This should new interface should have dropdown icon (small downwards pointing triangle) rather than a keyboard for an icon.
Add x-button top/right inside the keyboard? Or replace onscreen keyboard icon with a slashed through keyboard to indicate that it can be used to close the onscreen keyboard?
When the onscreen keyboard is shown the caret should always be displayed in the search query. This can be done by making sure the text input element is always in focus – meaning that clicking on a onscreen keyboard key, or using tab to navigate around in the keyboard needs be handled “manually” by the script.
Ie, while the onscreen keyboard is up, use a class to show the currently selected button, and modify that based in tab.
Are there additional modifications that can be done to better give a new user a sense of how to use the search? How to make the transcription search feature more self-explanatory for users unaccustomed to the transcription system?
Article on how to make “the perfect search box”: https://uxplanet.org/design-a-perfect-search-box-b6baaf9599c
When scrolling down the search form should scroll up with the page, when scrolling up it should be immediately revealed – just like URL bar in the mobile browser.
The theme-color should be a bit darker to contrast with the search bar. (<meta name=”theme-color” content=”#07bccd”>)
Currently, if video fails to load than one have to reload the whole page in order to retry loading the video. Clicking a video that failed to load should attempt to load it again.
This is a lexicon, so for clarity, all two-hand descriptions should have a relation symbol (in my opinion). We could automatically insert this when importing the lexicon.
This means that using the browser back/forward buttons would scroll through the search history in a reasonable manner (without having overlays pop up).
When exiting an overlay, it should invoke
window.history.back();
To remove itself from history.
This also means, however, that on initial page load with an overlay specified in the URL, we first need to load a search page, then display the overlay, so that there is something to go back to when exiting the overlay.
Arrow keys to navigate between matches Up/down/left/right - in video mode. Up/down - in text mode.
Is there a non-Javascript way of doing this?
- Tab/shift-tab move focus from one video to the next
- 1234567890 – move to % percent of matches
- <space>? display video overlay info
- key to go to ID/external site
- key to search for transcription
- <Esc>(?) key to focus search input area
var videoTmpl = “video/{firstDigits}/{file}-{id}-tecken.mp4”; var imageTmpl = “lexicon/{firstDigits}/{file}-{id}-tecken.jpg”;
The htmlifyTranscription() function will probably need to insert <wbr> each segment separator in the transcript. The following snippet was previously used, for this.
return hilitedTransStr // Insert <wbr> tag after all segment separators. .replace(//gu, ‘<wbr>’)
Instead of using jQuery to apply CSS in ‘style’ attribute, should generate random ID for a prefix, and use CSS rules.
Words should be linked together with other words of the same meaning, like the following:
- One / two handed variants – BADA(05245) / BADA(00529)
- Verb–noun pairs – HETA(02892) / NAMN(02890) (Many of these differing only in repetition.)
- Close-to-synonym – HETA(02892) / KALLAS(07923)
Add a `pdf/` directory with all source articles, and each link in the article should refer to them, with page number.
There should be ‘screenshots’ from all PDF.
Especially information on where contact is made is interesting!
Hedberg (1989) is referred to like this:- “Fig 32 LO-handen (Hedberg, 1989: 63)”
Most likely they should look the same as in the rest of the document, i.e. ‘Bergman (1977)’ (and without titles).
Förklara också distinktionen ‘fritt morfem’ / ‘bundet morfem’.
Förklara också distinktionen ‘fritt signem’ / ‘bundet signem’.
Check that ID names are allowed to start with ‘_’ according to HTML5 standard before doing this.Maybe this page can help? It links to `details.js` and also mentions usage for styling <details> among people on GitHub. http://www.otsukare.info/2016/04/19/summary-details
Or possibly this one (a list of polyfills): https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
Eg ‘Förs kort åt vänster med distinkt avslutning’.
Should exist, but should not shrink when shrinking browser window.
Under ‘korskontakt’.
Contact is important enough to warrant its own heading, with explanations of contact points etc.
The filter hilite should be clearly distinguishable even when the table entries are expanded and/or focused.
Some tables now have capitalized descriptions, some have lower cased. This should be the same everywhere.
Argument for lowercase: Lowercase is used throughout the wordlist (it might make difference for some of the terms). So maybe use lowercase in all tables/lists?
The fingers should be as bent as in klohanden.
The thumb should be straight out, not semi-bent.
One should be able to filter the list using the values in Bergmans attribute value table (that I got in the course ‘Tecknets struktur och variation’ – ‘bergman_sardrag.pdf’).
If one visits to a link that contain a # part in the intro article, the the page should automatically unfold that part and go there.
Include an image explaining the relation symbols in better detail.
What are they in relation to? How do they relate to the body of the signer? This came up in discussion with Thomas Björkstrand, who argued that ‘in front of’ symbol could be interpreted in relation to the attitude of passive hand, while I argued that is is about the location of the two hand in relation to the body.
Make deprecated symbols striped red by default. https://css-tricks.com/stripes-css/
background: repeating-linear-gradient( 45deg, #606dbc, #606dbc 10px, #465298 10px, #465298 20px );
$(‘p’).css(‘background’, ‘repeating-linear-gradient(-45deg,red,red 2px,transparent 2px,transparent 20px)’)
Javascript search function that automatically unfolds the relevant/matching sections.
One unanswered question: Can we search in the DOM for text that is present in hidden <details> sections? Or is that text not present in the DOM because the element is hidden?
Article on how to do this: https://j11y.io/javascript/replacing-text-in-the-dom-solved/
Maybe using this: https://github.com/padolsey/findAndReplaceDOMText/blob/master/src/findAndReplaceDOMText.js
https://stackoverflow.com/questions/32783336/find-text-in-source-code-of-page-and-create-hyperlink https://developer.mozilla.org/en-US/docs/Web/API/TreeWalker
It would be cool if just the browser-native search function automatically opened up the relevant section when you searched… But interacting with the browser search function seems to be highly idiomatic in different browsers, and not worth the effort.
Tables that are the only content in a <figure> tag should use their own <caption>, and not need the surrounding <figure>.
Adapt CSS for this scenario, then remove the unnecessary <figure> tags.
A table like the one in Bergman (1977) p.51, but with a ‘heat map’ of combination occurrences. (Both with percentages and greyscale[?] background colors illustrating which combinations are the most common.)
http://localhost/teckentranskription/lexicon.html#02993%2C08968
‘To mean’ and ‘happening’ look very similar in transcription, but they make contact in very different places. How does the reader know where contact is made? (Is there a rule of some kind? – Or does the transcription need some way of specifying the contact point?)
Riemer (2015) has a way of describing ‘contact’ point.
Explore/ponder/research the fact that the modifier symbols ‘–> <–’ and ‘<– –>’ (which are written under circling, curving, hitting, twisting) could maybe be better written with converging and diverging symbols underneath the symbol it modifies.
To verify which handshapes are actually used in the web lexicon.
Duplicated symbols are not listed in the book appendix (except for the chest). Go through the transcriptions in the book and include the missing symbols: the eyes, ears, cheeks, shoulders and/or hips.
Also look for left ear, cheek or hip, and include those as well (if they exist in the book).
There should be comments describing that the following works are basically variations on the exact the same text, with only some minor updates. (This is especially important almost all of the example transcriptions given are retained, even though many of them are no longer to be found in the lexicon.)
- Teckenspråkstranskription (1982)
- Kompendium i teckentranskription (1993)
- Teckentranskription (2015)
Symbols for “lilla A-handen” etc. that occur in this source should be included in the article.
‘camera’ makes use of passive + active hand + body position. That this can occur (and how) should be described in the transcription rules somehow. http://teckensprakslexikon.su.se/ord/03672
‘setback’ (få tji/få bakslag) is singed in an odd way, and the passive hand sort of has a body position, but the sign isn’t transcribed that way in the lexicon: http://teckensprakslexikon.su.se/ord/00497 – Is there even a way to understand the sign from the current transcription in the lexicon?
Currently is kinda hard to see difference between an expanded source citation and the surrounding text, maybe put a border or something around it?
Instead of having two buttons, there should be only one which should (in a fashion similar to org-mode) cycle through the modes:
- Everything collapsed (default)
- All <details> without the ‘closed’ attribute opened
- ALL <details> opened
Mouseover text should clearly state what will happen upon the next click.
Use statistics on hand shape occurrence for the primary hand from the lexicon. This is not as nuanced as using a corpus, but should suffice.
This handshape occurs twice is the in the table. Can the the two rows “pek- och lillfinger” and “stort lång- och ringfinger” be merged somehow so this problem can be avoided?
Write each reference in an appropriate form.
Are they the same with two different realisations? (I have yet to find a single source that describes them both with pictures, but one adverb (“‘normally’, ‘with ease’”) is described in ”A Preliminary Analysis of Visual Mouth Segments in Swedish Sign Language” as not being among the mouth segments there described – which the other realization of [m] looks like what they there describe as bilabial.
Have we drawn similar conclusions? Categorized the same mouth shapes as similar?
Useful data can be found in:
- ”A Preliminary Analysis of Visual Mouth Segments in Swedish Sign Language” has a bunch of useful examples of reductions.
Found out that the GNU FreeFont suite is actually available in Fontforge (.sfd format). Should reimport all the glyphs using these sources. https://ftp.gnu.org/gnu/freefont/freefont-src-20120503.tar.gz
The modifier arrows (for hand external motion type) should look the same as the movement arrows (rather than the attitude direction arrows). – I.e. the arrows should be a bit longer than they currently are.
Only used in Bergman (1977), examples of use can be found on pp.85, 130, 134, 135, 156. – Looks like a eight-pronged asterisk. (Referred to as ‘repeated contact’ in list of symbols on page 89, but ‘iterative contact’ elsewhere.)
Only used in Bergman (1977), example given on page 129. – Looks like a slash through a colon (a slash with one dot above and one below the middle line of the slash, similar to the music notation ‘one bar repeat’ symbol).
First used in Bergman (1982), last seen in Wallin (1994). – Looks like capital ‘L’ with the vertical line ending in an upwards pointing arrow.
First used in Hedberg (1989), last seen in Wallin (1994). – Looks like an ‘A’ with a small capital ‘N’ written between the legs of the ‘A’.
Hedberg (1989) calls this the NO hand’, Bergman & Björkstrand (1993) uses the name ‘bent index N hand’. – Looks like an ‘O’ with a small capital ‘N’ written inside it.
First used in Hedberg (1989) where it is called the ‘LO hand’, Bergman & Björkstrand (1993) rename it ‘bent index finger’, and it is last seen in Wallin (1994) which also calls it ‘bent index finger’. – Looks like an ‘O’ with a small capital ‘L’ written inside it.
Only used in Hedberg (1989). – Looks like the ‘straight measure hand’, with an extra horizontal line in the middle (or like a mirrored ‘E’, with the top and bottom horizontal lines angled in slightly towards the middle).
First used in Bergman & Björkstrand (1993), last seen in Wallin (1994). – Looks like capital ‘N’ with the rightmost vertical line ending in an upwards pointing arrow.
Only used in Wallin (1994). – Looks like a ‘spread hand’ with an extra horizontal line on it, or like a capital ‘Y’ with two horizontal lines crossing it.
Only used in Wallin (1994). – Looks like a ‘spread hand’ with an rightmost diagonal line ending in an upwards pointing arrow. upwards pointing arrow.
Only used in Wallin (1994). – Looks like capital ‘N’ crossed by a horizontal line.
Only used in Wallin (1994). – Looks like an ‘O’ with a small capital ‘H’ written inside it.
Only used in Wallin (1994). - Looks like a capital ‘Z’ with two horizontal lines crossing it.
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Only used in Wallin (1994).
Side-to-side modifier symbols could benefit from being a bit wider, now that the circle symbols they are placed beneath allow for that.
Among others, the following symbols (excluding symbols that could be turned into references):
E.g. symbols ‘L’, ‘M’, ‘N’ etc. that are copied from latin (or other alphabets) should be identical to their originals. Verify and correct this in the .sfd file.
(Can the TTF hints be accurately copied as well?)
Something like the IPA typewriter (https://ipa.typeit.org/full/) with Alt-A (pressed once for , twice for , three times for , etc).
Currently in winds up under the <textarea>. :(
E.g. when hovering over an input button it should display information about that character in an overlay (in lower right corner?). There should an image of the handshape, or an animation of the finger/hand movements etc.
In text where only one or two single transcription symbols are used it is sometimes not very clear what’s going on, since the use of transcription is not clearly indicated. An obvious fix would be to always circumscribe transcriptions with eg […]. (This is prolly not needed in tables & figures, but only in the main text.)Currently this is pretty inconsistently done, using (…) in some parts of the text, […] in some, and no indicator at all in some parts.
This seems to be used nowadays to indicate a search field, so let’s do this here too. This also moves the search magnifying glass from the right to the left side of the search form, (hopefully) making the right side look less cluttered (as the ‘advanced search’ dropdown will be added there). Especially the search box part should use the full width of the screen. E.g. `/’kränkande’` (unquoted ’’) should match “/kan uppfattas som kränkande”, while `’/kränkande’` (quoted ’’) should not. For example: Searching for `geografi` should not match the tag `/geografi` if one does not include the leading `/`. Parsing execution of the `lexicon-data.js` file seem to be taking a lot of time (according to the Chrome profiler) so I tried a few experiments to see if I could optimize it a bit. – No such luck though, it seems that the biggest culprit simply is the data size, which seem to require some CPU to be parsed as a whole. Tweaking the .map() function that unpacks the data doesn’t do much, so in the end I left it as it was.Here are the different version I tried, which all (discounting variability) all seem to have about the same execution time.
.map(e=>{ return[ …e.slice(0,3), …e.slice(3).map(v => isNaN(v) ? v : lexiconTags[c++,v]), …(c?[‘/’+c]:[]) ] })
.map(e=>{ for(let i=3;i<e.length;i++){ if(typeof e[i]===’number’){ c++ e[i]=lexiconTags[e[i]] } } if(c)e.push(‘/’+c) return e })
Rather than solving this using the below suggestion I opted for a simpler solution, using an inlined <script> (without jQuery) just after the <body> tag. This one-liner which adds the ‘noquery’ class to the <body> tag, if the URL fragment does not contain a query (ie if it consists only of spaces).Currently, if loading the page without a query, first the ‘small’ version of the query is displayed briefly.
Fullscreen search should ONLY be show if there is NOTHING entered into the search form, if ANYTHING is entered, display the search results screen, even if the query is invalid (eg just space, or empty parenthesis).
Split this into: 1. loading screen, 2. fullscreen search, 3. result screen
The loading screen should be turquoise in color, and show the copyright and top-left menu button.
If query string is empty (after trimming space), display fullscreen, otherwise display result screen.
This should prolly be handled from inside <script> tag in lexicon.html? Though should avoid doing URL fragment decoding it two different places in code (DRY and all that).
let hash = decodeURIComponent(location.hash).replace(/^#?#?/u, ”).trim() if (hash) { $(‘body’)[queryStr.length ? ‘removeClass’ : ‘addClass’](‘noquery’) }
Clicky account needs to be re-activated manually every 60 days, which is a hassle. Also it doesn’t actually seem to log the relevant data (the search queries). This means that there are no search tips being displayed, even though there are no matches. – Lexicon SHOULD react as if a search was made that resulted in zero matches (ie display search tips).Ie the class ‘nomatch’ should be set to the <body> tag, even when the cause for the zero matches is a query language parse error.
Minus is now considered a word border character, meaning that searches which contains leading or trailing ‘-’ match sanely (eg `kabel-` or `’-tv’` will match ‘kabel-tv’, etc rather than return no matches.)Minus was originally turned into a non-word character in July 2019[1], because it caused problem with the H-Y-P-H-E-N-A-T-E-D fingerspelling transcription used back then[2].
- *Make ‘-’ alphabetic(?)
- *Lexicon: Changed fingerspelling transcription format
I implemented this counter to make it possible to search for signs with a specific number of tags, and I mistakenly thought that a tag counter of zero would be useful and/or simply consistent. BUT signs without tags can be found with `-=/*`, meaning that the zeroed tag counter is useless, and results in false positives for queries `=/*`, `/` and the like.
Solution is to keep the tag counter, EXCEPT for signs that doesn’t have tags.
The menu footer/copyright text should not overlap the last menu items if screen isn’t tall enough. (Instead there the menu should get a scrollbar.)Currently the menu footer is placed using `position: absolute` but flexbox should be used instead.
I.e. if you tab around when the menu is open the focus should only move between the links in the menu and the menu close icon.| Key | |
|---|---|
| Escape | Exit menu |
| Tab / Down | Focus next menu item |
| Shift-Tab / Up | Focus previous menu item |
The ‘/’ was previously implemented in code to separate query from overlay in fragment part of the URL, but since none of that code was actually USED, I removed it altogether.
Previously the search result wasn’t reloaded unless the query was modified, but always redoing the search is more predictable to the user.With parentheses ‘-(-a)’ is the same as ‘a’. For consistency ‘–a’ (or any even number of minuses) should also mean ‘a’.
Query ‘(a b) c’ and ‘a (b c)’ should turn into ‘a b c’.
Got some the following error message in the Chrome console, indicating that the ‘preload’ tag for the transcription font wasn’t doing its job (the ‘Network’ tab even reporting that the same font file was loaded twice on pageload). :(
> A preload for > ‘https://zrajm.github.io/teckentranskription/freesans-swl.woff2’ is found, > but is not used because the request credentials mode does not match. > Consider taking a look at crossorigin attribute.
This fix just adds the ‘crossorigin’ attribute (as suggested by the MDN documentation).
This seems to work! :)
Modified `lexicon-data.js` to include a list of tags, including only the numbers of tags (instead of the full label) in the lexicon. (This is done to speed up the loading of the page over the network.)On loading `lexicon-data.js` reprocess the `lexicon` list, so that the lexicon contain the full tag labels (meaning that we don’t have to reprocess this every time the user does a search in the lexicon).
Also the `lexiconTags` list is resorted alphabetically (when loaded this list is sorted in reverse number of occurrences, so that the tags used the most in the lexicon get the shortest numbers).
The #search-result element is resized in Javascript in an onload/onresize event handler. This cannot be done in pure CSS, since the container cannot shrink-to-fit content that has been line wrapped. :( – Well, actually, it could be done using media queries, but this would be verbose and even more finicky, so Javascript it is! The edge-of-word matcher shouldn’t hilite the space in front of a word.Since we cannot use lookahead assertions (its not supported by a majority of browsers), we’ll prolly need some subgroups to split the match into parts-to-be-hilited, and parts-not-to-be-hilited.
A search for ‘–,72,har’ should hilite three different things in entry 00072, but only the transcription is hilited. Why? http://localhost/teckentranskription.lexicon/lexicon.html#otranskr%2C%2072%2C%20har- Maybe use jQuery slim(?) (The slim build excludes the ajax and effects modules.) Need to verify that this works. https://jquery.com/download/
Converted Truetype font to WOFF2.
Modify the csvdump2json to add tags based on the CSV ‘category’, ‘genuine’ and ‘dialect’ fields in the imported CSV.my @category = split \s*\x1d\s*, $field[13]; my $genuine = $field[15]; # NOT USED YET my $comment = join “”, $field[17]; # NOT USED YET my @dialect = split \s*\x1d\s*, $field[18]; # NOT USED YET
The following shell function can be used to extract a single column from a CSV (invoke with `csvcol NUM <FILE.csv`. Use, NUM = 0 for first column).
csvcol() { perl -Mutf8 -C -0777pe’BEGIN{$q=qr/[^”]|””}s\r\n?/\n/g;s#^(?:”$q*”,){‘”$1”’}”($q*)”(?:,”$q*”)*#join”\n”,map{s/””“/g;$_}split/[\cK\c]],$1#gme’ }
teckensprakslexikon.su.se has categories (vehicle, religion, clothes, geography etc). These should be imported as well.Tags for each sign should be displayed in the search result. Hovering above a tag should provide the user with clues for how to search for them.
Previously the data we got from the lexicon did not contain fingerspellings in the transcription, but instead simply a ‘#’ which the import script replaced with a capitalized hyphenated spelling (‘E-X-A-M-P-L-E’) from the sign description. Some time back the lexicon changed this, and now the lexicon transcriptions do contain finger spellings (‘#(example)’).This fixes the import script, which has been broken since the imported lexicon data changed their transcription (causing this lexicon to have transcriptions that looked like this ‘E-X-A-M-P-L-E(example)’).
So that it looks like the form icon buttons. The “Please fill out this field.” should not appear when pressing the sumbit button without having entered a query. And modify some flex property of parent element <header> instead?Use the magnifier icon that now is the search text placeholder, and use that in the submit button instead. Add placeholder text. Maybe something like ‘Sök transkription eller översättning…’
Menu shouldn’t pop up when menu button is focused, but only on click (or enter/space) on menu button.Can’t use ‘overflow: hidden’ here because that would hide the onscreen keyboard (its element is put inside the form, but displayed outside it in the DOM).
The stuff specific to the search form should use CSS selectors containing with ‘#search’ (not ‘form’).
This is a bug since the textarea cannot handle newlines well, and user really should not be able to enter any. (Manually entered newlines are already suppressed.)Make extra sure this is compatible with all browsers (since copy/past handling is known to be finicky).
Removed irrelevant CSS, moved everything that is needed for first paint in browser to inline, and put everything else in separate CSS file. Menu should contain link to help text, info about the lexicon + links to related articles/web pages.At the bottom there should be information about where the data comes from + copyright info (and CC-license?).
In fullscreen mode the text color of the bottom screen copyright notice should be the same as for the info text specifying update date and number of signs. In Firefox the help text had only a single column which used the specified column width (ie leaving the rightmost part of the screen completely blank). Not pretty, solved by removing the CSS line ‘column-fill: auto;’. Add the following after the ‘updated date’ text. ‘<a href=>Sökhjälp</a>.’ The help button should use ‘position: absolute’ placement regardless of whether or not search is in ‘noquery’ mode. Tooltip failed if mouse pointer hovered above an element inside the element with the title. Eg on doing a search with Swedish translations containing marked content, if one moved the mouse pointer onto the marked text then the browser default tooltip text was instead used for showing ‘title’. Also, style a wrapper as a <textarea>, having the <textarea> be as plain as possible, and use this to make sure text never overlaps the keyboard icon.After this the :hover rule may also brighten the focused content again (since both keyboard and magnifier icon in <textarea> can be brightened now).
The onscreen keyboard icon button should be present in the basic HTML, so that the behavior of that button can be defined in the base CSS of the page. Only the DOM element with the onscreen keyboard itself should be inserted by `keyboard.js`.
This avoids having the DOM being updated late in the load cycle (causing repaints after rest of page has loaded).
Pressing a button on the onscreen keyboard (with space, enter or mouse click) should result in that symbol being inserted in the textarea (without submitting the form).
This should work in textarea, on textarea button in the onscreen keyboard.
Currently a tooltip is displayed even if the mouse pointer only passed through an element with a `data-title` attribute and then stopped. However tooltip should only be displayed if (a) the element is still shown on the page (ie if the element was part of a menu or overlay that has since disappeared from the screen the tooldip should not be shown and (b) mouse pointer is still hovering on the element in question (ie if the mouse pointer only passed through the element but stops outside the element the tooltip should not be displayed). It looks kinda strange when the tooltip stays in place, when stuff underneath moves away and when the tooltip resizes itself if it’s cut off by the right window border.- Make it focusable (so that one can enable/disable using keyboard).
- Currently the `search-brief` element is rendered with `opacity: .5` meaning that the focus shadow is too dim. Use ‘color: #888` (and adjust other colors) instead.
Before April 2018 the database was manually updated based on a special .tab sent to me by the Swedish Sign Language Lexicon office. Before that I used web scraping of teckensprakslexikon.su.se. Since this hasn’t been true for a great long while these old files should be cleaned away.
This Perl program was used to convert the old .tab export file to JSON. This Perl program was used to extract Swedish translations + ID-numbers from web pages scraped off of https://teckensprakslexikon.su.se/. This was an old manual export manually sent to me from the Swedish Sign Language lexicon office, before we settled on (now automated) CSV exports. Data converted (using ‘bin/mklexicon’) from .tab format to simple text format. Data only contain Sign Language Lexicon ID number + Swedish translation.Every word in search query must match word-for-word in the corresponding text. To make a query like ‘hej’ match part of a word one must use ’hej’.
Currently ‘*’ matches a partial segment in transcript if there is a ‘-’ (ie fingerspelling) in the transcription. http://localhost/teckentranskription/lexicon.html#*%C3%A5%20-*%22%20%22* ’[’ should not require ’[’ to match in ‘[HYFF]’This should not require that the search term is part of a word. Same goes for search for ” “, maybe? (or does a search for ’” ”’ make more sense?)
A (non-empty) search query that does not result in any matches should display some tips on how to search (mentioning that ‘*’ is required to match parts of transcriptions/words). The ‘help overlay’ should close automatically clicking a search example link (so that the search will be displayed). The implicit ‘*’ should not hilight anything. Currently, if the image failed to load and a broken image icon is displayed, this broken icon remains there when the video loads (displayed on top of the video). https://martin-thoma.com/search-engine-autodiscovery/#google-chrome-autodiscovery https://stackoverflow.com/questions/14082568/ https://github.com/dewitt/opensearch/blob/master/opensearch-1-1-draft-6.md It should only be horizontally flipped, but width should remain same. Already existed. Each example should have only translation + link to dictionary in caption. Long(-ish) descriptions should be in surrounding main text. <details> with collapsed quotes should all have the same format, namely like this.<details closed> <summary><a href=#1977>Bergman (1977)</a></summary>
<p>”Lorem ipsum…” (s52–54) </details>
Sources should look like this ‘Bergman (1977)’ not like this ‘[Bergman 1977]’. Some sources were previously written ‘<i>Bergman (1977)</i>’ make sure all of them now look like this ‘<a href=#1977>Bergman (1977)</a>’. Fix all occurrences of ‘[^>]Bergman’ and ‘<[^a][^>]>Bergman’ in main text. Fix all occurrences of ‘[^>]Hedberg’ and ‘<[^a][^>]>Hedberg’ in main text. Fix all occurrences of ‘[^>]Bergman’ and ‘<[^a][^>]>Bergman’ in main text. Fix all occurrences of ‘[^>]Bergman’ and ‘<[^a][^>]>Bergman’ in main text. Fix all occurrences of ‘[^>]Björkstrand’ and ‘<[^a][^>]>Björkstrand’ in main text. Fix all occurrences of ‘[^>]Bergman’ and ‘<[^a][^>]>Bergman’ in main text. There are now zero occurrences of ‘[^>]Bergman’ and ‘<[^a][^>]>Bergman’ in the main text. och ‘Polysyntetiska tecken i svenska teckenspråket’. There are now zero occurrences of ‘[^>]Wallin’ and ‘<[^a][^>]>Wallin’ in the main text.The share button should generate image as well as URL, so that when copy/pasting will include a preview of the transcription. This is good when including a transcription in an email etc. (the recipient will then have some clue of the content without having to click the link).
Incorporate a few words on the limitations of the transcription into the leading paragraphs of the document, and delete the current ‘Förord’. Target audience is better defined now, restructure text to reflect this.The handshape images in the table of handshapes should not be in separate <td>, but should instead be floated left, so that the description text of the handshape in question can fill out the entire width of the column (right now the text column becomes very narrow when there are multiple hand shapes show on the right hand side of the text).
Eg ‘x1977’ for ‘Tecknad Svenska’, ‘x2015b’ for ‘Diagonala handpositioner i svenskt teckenspråk’. So that the relation diacritic do not overlap the edge. Also ‘?’ fields should fill out the height of the description fields vertically. Some glyphs have very long descriptions which do not fit on one line (eg ‘Förs kort åt vänster med distinkt avslutning’) – these should wrap and be displayed on two lines in the lists.When done, also remove ‘TODO’ from CSS.
href=”00000” -> href=00000Display spinner while loading video (after replacing <img> with a <video> tag), replace by error msg on fail.
Tooltip didn’t always disappear on back/forward, now triggering removal on hashchange, instead of popState. Only determine columns based on line width. If the content of a page all fits in one window, then the page footer should be displayed at the bottom of the window. Currently any opened tooltip remain on screen when one navigates backward/forward in the browser.- = match ‘word’ characters (i.e. not space and segment separator, ‘’, but everything else)
Useful (complex) query: - -#:#: -:##: -* -@
Transcriptions are fiddly and finicky, rather than spending time on inputting a transcription, search for a sign that you know is similar to the one you’re looking for, then copy/paste the transcription of that sign into the search box and replace parts you’re not sure about with asterisks (‘*’).
If you get too many matches, the following search terms can be useful for ignoring some of them:
-:##: – exclude signs with two active hands -#:#: – exclude signs with one active, one passive hand -@ – exclude signs a body position - – exclude signs with more than one segment -* – exclude signs with more than two segments :##: – include only signs with two active hands #:#: – include only signs with one active, one passive hand @ – include only signs which have a body position
Display signs that contain a downward motion, and a handshape transition to the spread hand (sprethanden), but that does not contain multiple segments (-), two handed segments (excluding those with a passive secondary hand with -#:#:, and those with an active secondary hand with -:##:), more than one handshape transition, or a specified position (-@).
An unquoted ‘face’ symbol now matches all the articulation places in the face. An unquoted ‘upper face’ symbol now matches ear, nose, cheek and all other articulation places on the head above that (note that ear, nose and cheeks are matched by both the ‘upper’ and ‘lower face’ symbols). An unquoted ‘lower face’ symbol now matches ear, nose, cheek and all other articulation places on the head below that (note that ear, nose and cheeks are matched by both the ‘upper’ and ‘lower face’ symbols). This would allow us to use the exact same HTML with just slightly different to CSS to produce a search results in list form (without video). As in the list form the transcriptions need to be line breakable (ie have <wbr>s in them). Transparency (when hovering above with onscreen keyboard button). Make sure hovering image fits on screen. Originally intended to add a progress bar for the search itself as searching for ‘*’ took more that two seconds without any page updates at all. Frustrating!In my attempts make the search function asynchronous to allow for the progress bar updating, I accidentally discovered that using a `for` loop (rather than the previous `reduce`) resulted in 20 millisecond search times instead of the previous 2 seconds!
Need for progress bar therefore eliminated!
The first click on a video <im> replaces it with a <video>, and starts playing. On Firefox the first click after the element do not trigger a click event.- one have to click twice to pause video after playing it the 1st time.
- double clicking on an unviewed image does not cause it to fullscreen.
On handling broken image loads: https://css-tricks.com/snippets/jquery/better-broken-image-handling/
Retained old format as image & video names can be calculated from the translations.Link to http://teckensprakslexikon.su.se in each result
- Whole handshapes: flat hand, sprethand, S-hand, klohand, O-hand, vinkelhand, knutenhand och A-hand.
- Finger handshapes: tummen, pekfingret, krokfingret, lillfingret, N-handen, V-handen, dubbelkroken, flyghanden, M-handen, måtthanden, nyphanden och stora nyphanden.
These should work so that, when checked, all items with that attribute are displayed (but no other).
If multiple checkboxes are marked, they should be AND:ed together.
Name: ???_medial_contact Name: motion_type_bouncing Name: modifier_away_from_each_other Name: position_neutral_space Name: position_elbow_pit Name: handshape_llamaTo allow for larger simplified circles, and room for the arrows below circle/twist etc.
Set font name, copyright notice etc. for freesans-swl. Replace with the usual left/right (do this in Swedish too). I.e. each handshape (except in character classes, or in quotes) should allow for an optional diacritic. Something matching the current color theme, rather than the currently blue focus indicator border. All the HTML, CSS etc. should be in self-contained Javascript module. Only plain Esc, without qualifier keys, should result in the onscreen keyboard being displayed. Don’t use ‘_’ in function names.Replace `searchQuery` with either `queryStr` or just `query`, depending on whether it’s a parsed object or the user-inputted query string.
Query parser now process user-inputted query string character by character, instead of parsing it with a regex. This should eliminate the possibility of an infinite loop in some undetected corner case. Two warnings remain as of now, but these seem quite minor & hard to fix so leaving them for now.Unexpected ‘' before ‘1’. .replace(^([“’])(.*?)\1?$/u, “$2”) / remove quotes
Unexpected statement ‘=’ in expression position. while (m = termRegex.exec(“,” + queryStr)) {
Query should be split into OR:ed sub-queries on comma. E.g. ‘X, Y’ should search for all words containing either X or Y. Searching for ‘A<space>B’ should find lexical entries with both ‘A’ and ‘B’ in them, regardless of order. Semi-transparent arrow in lower right corner should appear if scrolling down, if pressed it should bring user to top of page. The search is always very fast, but displaying results takes time when there are a lot of entries found… Is there a way to speed this up?NO – I did some research/experiments with various ways of updating the DOM, but couldn’t find any method that was significantly faster than the one currently used.
Rewrote the updating so a search resulting in 500 matches will be displayed is the same way as before, but if there are more matches than that, then each additional chunk of 500 matches will be added chuck-by-chunk (with a progress bar at the top of the page indicating how many chunks to go).
Some words in the dictionary have upper case letters in their definition, these upper case letters cannot be matched in a search. (Since the query is translated to lowercase, and only lower case is searched for.) Update ‘#<query>’ part of the URL so that back/forward buttons work. Currently, in MSIE11, pressing <enter> does not execute search (one has to unfocus the input field for the search to update).