jdee / dubsar Goto Github PK

The adjective markers (p), (a) and (ip) associated with some adjective senses are erroneously displayed at the end of the word name. This incorrectly results in separate word entries for distinct senses. For example, the adjective well has two senses available only in predicate position ("it would be well to..."). These show up as a separate word well(p) (adj.). This is being corrected in a reseed. The markers with explanatory titles will be displayed in the tooltip header for any adjective sense that has them.

The Tour, Mobile, RSS, Share and Opensearch buttons in the banner at the top of the page improperly display the icon above the text instead of to the left of it. It's not obvious why.

The ActiveSupport::Inflector was used for regular plural nouns. The WordNet(R) exception list provided irregular plurals. For any other one-word noun, the ActiveSupport String#pluralize method was used. Generally this produced correct results, but often not. For example, the plural of Man (n.) (the island) is listed as Men, and the plural of shaman (n.) comes up shamen.

Some compound verbs are not handled correctly, notably log-in (v.), which Dubsar currently conjugates log-ins, log-ined, log-ining.

Dubsar provides no regular inflections for adjectives because rules for comparative and superlative degrees produce forms like sabbaticaller and sabbaticallest.

The :inflections table will simply grow to include more and more exceptions until all cases are listed, and there is no longer any need to generate it from rules or WordNet exception files. It will just be dumped out and then reloaded on each seed.

Since converting the #word-input field to HTML 5 type search, some browsers (Safari 5 on OS X and Vista; OmniWeb 5 on OS X) will not hide the autocompleter menu when the search field is cleared using the deletion X at the right end of the input field. Ordinarily this just sets the value of the field to a blank string and triggers an HTML 5 input event. That scenario is tested in the QUnit test suite, and it passes in the browsers listed above. It's possible that the triggered event in those cases is not an HTML 5 input event, but some other type.

This is confusing the Googlebots.

When a search is submitted (via the search button or a link letter at the top), a message is displayed below the header bar reading, "working.…" An info icon is displayed, but it does not usually show up. It shows up pretty consistently in Camino 2 on OS X, but most other browsers display it intermittently. If you go into the JavaScript console in Chrome or into Firebug and examine the error div and its child ui-icon span, it will have the correct background image, background offset, etc. After examining those things, the icon will begin showing up correctly in all requests during that browser session. This seems like it might be a jquery-ui bug.

Firefox 5 for Android recognizes Dubsar as a search engine, but it redirects to the wrong page and seems to submit an invalid search right off the bat.

When the window is too narrow, the search form simply overlays the alphabet links in the header bar. This has the desirable side effect of making the search form usable in this case, but it's not very pretty.

If you type several letters into the search box, the application will autocomplete matching results. If you then backspace, it will adjust its matches accordingly. But sometimes this fails, in particular when backspacing down to a single letter. For example, type "ar," then backspace after the initial autocompleter menu is displayed. The application should show a list of top matches for "a" (beginning with "ask"). It does not always do so.

The :senses_verb_frames table has only 86 entries. For some reason, many of the frames in the data are not being processed during the migration/seed.

The original version of Dubsar never displayed synsets directly. Tooltips were the only way a user ever saw sense data. Semantic pointers (between synsets) were represented simply as pointers from a given sense to the target. Now that Dubsar has synset views, it needs to display semantic pointers as well.

Verbs ending in -w are currently conjugated like snowwing and snowwed (treating the final w like a consonant). This is being addressed right away.

Because it sorts by frequency count, smaller words like loo that occur as the first letters of many common words may not show up as exact matches in the autocompleter. If you type that into a search in any of the Dubsar interfaces (including browser search bars using the OpenSearch protocol), you will not see loo as a suggestion. The autocompleter is sorted by frequency count, so this is not necessarily a bug. It functions as designed. But it can be confusing to a user if they expect to see matching suggestions.

If you type a word quickly enough into the mobile text field and press enter, the autocompleter may display after the search has been submitted. This is a result of refactoring the view and delegating searches via AJAX to a new /m_search path. Because of the AJAX, the browser never leaves the original page, and the autocompleter can still be displayed when the request is completed. It cannot then be dismissed, and it obscures the search box, preventing further searches.

If you roll quickly over a sense in a word or search view on the main site, then quickly out and back again, finally leaving the mouse over the highlighted gloss, the tooltip will quickly appear, disappear, reappear and then remain as the mouse enters and leaves the gloss. After it appears for the second time, the close button on the right side of the tooltip header will fade in, disappear and then fade in again. It looks like the timer is not canceled on mouseleave events. It's possible this was introduced in some recent work, probably when implementing the AJAX word tab in the sense view. Since the tooltip spans in that tab are not present in the initial page load, the original hover handler was converted to a live handler. That could very well cause exactly the observed behavior.

The entire QUnit test suite passes in that browser, but anything typed into the autocompleter does not work. That applies to the main site as well. That is, if you visit either of these URLS in Firefox 5 Mobile:

http://m.dubsar-dictionary.com/m
http://dubsar-dictionary.com

And type something into the search box on either page, you will not get any autocompleter suggestions. This could be due to an issue with jQuery UI in the Firefox 5 Mobile browser. It could also be a quirk of the recent separation of routes into different domains. However, if it were the latter, it would not likely be limited to one browser. Autocompletion works quite well in Mobile Safari on Android 2.2.1 and in the Apple iOS Simulator on OS X.

When you add Dubsar as a search engine in IE 9, it shows up in the search box using the URL (http://dubsar-dictionary.com) instead of the name (Dubsar). This probably requires making use of an IE-specific extension to OpenSearch.

Currently there is some extra text because a long line was broken up in Ruby.

Search for "S(."

It should not be possible to drag a tooltip off the right side of the screen. The tooltip should automatically be positioned to the left of the cursor instead.

When loading the index view, Google Chrome on OS X will sometimes simply display a blank page. Eventually, the browser will indicate that the page is not responding. This has been observed a couple of times recently.

The Word response contains a synonym list with word ID's instead of sense ID's.

On some browsers, notably Safari on OS X, tabbing from the search box to the search button does not work. It's not clear why.

The autocompleter will not gracefully handle failure to request data from the server. It is likely just to hang in a wait state. Removing focus from the search box to hide the autocompleter should fix the problem. But it should be handled better.

When you select the match case button in the search form on the main site, the autocompleter should honor that when suggesting results. In particular, select the match case button and then type in Fran. Many results beginning with lower-case fran show up before France, for example.

Due to a bug in the db/seeds.rb code, the word count for a synset was not properly parsed as a hexadecimal number. Any synset with more than 9 words is present but empty, due to 0a, etc., being parsed as 0. Hence, some word senses were not shown. For example, four (noun) is listed with a single gloss:

• a playing card or domino or die whose upward face shows four pips
  Because the noun synset at offset 13744304:
• the cardinal number that is the sum of three and one
  has 12 (0x0c) associated words and hence does not show up as a sense of four.

If you visit the qunit test page, then go home by clicking on the Dubsar Project banner, then click the back button, the Dubsar Project banner will always appear orange (dark theme). From there, if you go back to the main Dubsar site, the theme will always be set to dark, regardless how it was set before you visited the qunit page.

Though not well advertised, the mobile interface still supports wild-card searches. Large search results (for "a%", for example) are paginated, 10 at a time. However, the pagination links do not display well under the listview div.

See jdee/dubsar_ios#44

Search for frozen. Two exact matches will appear at the top: frozen (adj.) and freeze (v.), because frozen is an inflection of that verb. They are listed in that order, however. When ordering exact matches, only the part of speech is considered out of the erroneous conviction that all matching words would have the same name. Clearly the order needs to be something like words.name ASC, words.part_of_speech ASC. This also occurs in the webapp because it uses the same SQL.

Yes, I'm aware of it. The system needs some maintenance soon. Unfortunately, I can't even deploy at the moment, so I can't even post an apologetic message on the site. If you see this, apologies. It will be fixed soon.

Since the introduction of jquery-mockjax to stub out the AJAX call in the autocompleter tests, that test no longer passes on Camino.

Apparently I made this error consistently across the board for all model types.

This was a bug in pre-release development. It was fixed, but seems to have surfaced again.

http://dubsar-dictionary.com/?term=lay#lay_v

lay (v.) is erroneously conjugated as laies

http://dubsar-dictionary.com/?term=play#play_v

play (v.) is erroneously conjugated as plaies, plaied

http://dubsar-dictionary.com/?term=toy#toy_v

toy (v.) is erroneously conjugated as toies, toied

http://dubsar-dictionary.com/?term=buy#buy_v

buy (v.) is erroneously conjugated as buies

http://dubsar-dictionary.com/?term=bogey#bogey_v

bogey (v.) is erroneously conjugated as bogeies, bogeied

Add a period to the end of a search, e.g. http://dubsar-dictionary.com?term=jurisprudence. That generates an unfriendly error. Other characters probably do the same.

When a user is viewing a list of results in an accordion, if they submit an invalid search term through the search form (e.g., "foo"), they will be redirected back to the page they were viewing, with an error that will fade shortly after the page loads. The accordion on that page will be open to the pane they were previously viewing (the information is stored in a cookie). This does not work when you click the back button after following a link (in the header bar, pagination footer or in a definition pane). The first pane in the accordion will be open after clicking back in this case.

The link should be displayed on a single line.

Look at http://dubsar-dictionary.com?term=jurisprudence . The gloss reading "the collection of rules imposed by authority" has a massive tooltip because that sense has 614 associated pointers, many semantic, so lots of synonyms make for a tooltip that won't fit on the screen. In at least one instance (Google Chrome 8, Ubuntu 10.04 and using a mouse with a tracking wheel) it is possible to scroll the tooltip to see the material at the bottom. Strangely, the entire #main div, with the word entry, scrolls along with it, but the header and footer of the page do not. The #main div may be scrolled right over the header, obscuring it.

In addition, the tooltip is currently set to have a max-width of 45% of the screen. Without that, it will in many cases be very short and wide. It is probably a good idea to handle the tooltip dimensions more dynamically. In the case of jurisprudence, above, the tooltip should probably be made quite a bit wider, since so much material disappears off the bottom of the screen.

Sometime recently, since the upgrade to jQuery 1.6.1 and jQuery 1.8.13 and the beginnings of mobile development, the SQL help link has stopped working. It no longer appears when the mouse hovers over the search text input. This may be related to the recent refactoring to separate the autocompleter code from the rest of application-ui.js. There is a unit test that only verifies that the dialog appears when shown. It doesn't test the timer.

Pressing enter after typing a word into the search box does not usually trigger a search as long as the autocomplete list is showing, even if the text field has focus. It is possible to trigger a search by selecting an item from the autocomplete list. The enter key works if you first press escape to remove the autocomplete list. You can also transfer focus to the search button using the tab key.

Currently in the production database, a search for Thucydides returns two identical results, though the entry only appears once in the seed data. It's not clear why.

Visit http://dubsar-dictionary.com/?term=turn#turn_v . The # in the URL should open to the verb pane, but it doesn't.

On the main FAQ page, http://dubsar-dictionary.com/faq#faq_21, the support address is not a mailto: link. The robots keep trying to crawl that page, which does not exist.

In IE 8 on Vista, Dubsar is added to the browser's search engine list. All works just fine, except that suggestions do not work. When a letter is typed, the browser simply reports an error. Strangely, in a non-guest account (with administrative privileges), autocompletion of suggestions works just fine. It also works in every browser that allows customization of search engines, except for Camino on OS X. There, searching works, but autocompletion does not. Notably, all functionality works very well with Google Chrome 8 and Firefox 3 on all tested operating systems. Safari does not allow customization of search engines.

The WordNet sample sentences from sents.vrb were inadvertently omitted from the application. They've now been added to the :verb_frames table.

Frequency counts are present in Sense responses from the JSON web service. They are missing from the Word and Synset responses.

The draggable tooltip sets its cursor option to 'move,' but it always displays a text cursor when dragged.

The HTML views on the main and mobile sites link from each sense to synonymous senses in the same synset, rather than to the words. The JSON Sense responses contain word ID's instead of sense ID's. They need to be sense ID's for consistency.

The WordNet irregular verb inflections in verb.exc do not tell you what is a present-tense form, what a past tense, what a participle and so on. It's difficult morphologically to determine if an existing irregular verb inflection is a past tense or participle. Consider words like was/were/been (for be), bent (for bend), done (for do) and so on. Most, perhaps all, English verbs that are irregular have irregular past tenses or participles, and that holds for most of the exceptions in WordNet. Hence, Dubsar does not attempt to build a regular past tense for any verb that has any irregular inflection at all. It must build some regular forms for even the most irregular words. WordNet provides all inflected forms of be other than being, which Dubsar produces. Fortunately, present participles are exceedingly regular.

But some verbs have only a slightly irregular present participle listed in the verb.exc file, for example, and hence do not list a past tense in Dubsar. Those are few. But there are plenty of cases where a verb ends in a short syllable with l, for example, and has one past form listed as an irregular. For example, travel is listed with the conjugations: traveling, travelled, travelling, travels. The valid inflection traveled is missing because it was not listed among the irregular inflections, and Dubsar did not build it since there were already irregular forms. In this case, in fact, there was already the irregular past tense travelled.

Then there are verbs like address, which lists the inflections addresses, addressing, addrest, but not addressed, because the irregular addrest was listed.

This question requires a bit of review.

Now that the custom tooltip has a separate header, in some instances the contents of the tooltip will be far too narrow for the tooltip. This occurs with Google Chrome on all platforms and with a number of browsers on OS X, notably Safari and OmniWeb.

To see an example, visit the page for hero. Roll over definition 4. (the sandwich). The tooltip will be very small. Now carefully mouse over another of the definitions above or below without mousing over another link in the meantime. The tooltip will be very wide, but the contents will be wrapped to the minimum width of the header. Mousing over the gloss with the larger tooltip from a different direction can clear the issue. It's not obvious what's going on.