Parameters and configurability

[Frenzie]

Any half-decent web-based interface takes query parameters so you can use them in preconfigured search engines, bookmarks, etc.

Must-have

• Search term. Whether it's s, search, pattern or something else doesn't matter, but I like s. Example: ?s=amicable.
• Dictionary selection. The most sensible ones to select by are probably the slob tags label, source, and uri. Slob id could also have its uses, presumably the first 8 characters would suffice. Example: ?dics=label:Wiktionnaire (fr);label:Wiktionary (de);slob-id:7dd6ab5f.

Nice to have

• Stylesheet.
• dontClearContent.

[itkach]

This is a rather confusing request that seems to mix several feature requests with implementation suggestions.

web-based interface takes query parameters

Query parameters typically are interpreted by server. They also typically serve a certain purpose. I'm not sure what changes exactly are you asking for or what use case are you trying to address.

In this application, there's user interface, a rather naive single page app, and there's web api to serve its needs (and also needs of Android version). Web api is a separate component, and it already provides a way to perform a lookup (using query parameters!) and retrieve content identified in lookup result.

Making it usable as a search engine perhaps would be better served by server returning lookup results as rendered HTML rather than JSON data. This effectively replaces existing web ui, eliminates need for it. It doesn't sound too compelling to me, but maybe it's interesting to explore, because sometimes less is more :)

Dictionary selection already happens in the command line to start the server. User interface and web api could be modified to allow dynamic active dictionaries selection, and otherwise manage them similar to Android version, but I'm not sure what's the use case in this application.

Alternative stylesheets are specified in the rendered article html, in dictionary content. Any agent may choose to implement switcher. It used to be a standard feature in browsers at some point, but nowadays you need an extension for that, so this ui implements it's own switcher.

Without getting into another discussion about merits of not clearing content, sounds like that would be a user setting, so this app would need to grow a notion of settings and implement a system for storing and editing them.

If I wanted I a more sophisticated, full featured web UI on par with Android version it wouldn't be built with jQuery. The purpose of this tool is primarily to explore and debug local .slob file content. On a desktop, web app is unlikely to beat native apps in terms of ease of setup and integration with environment; on a desktop with internet this app is also unlikely to beat existing online "native" web interfaces for content that it can serve, such as Wikipedia or Wiktionary, in terms of data freshness or fidelity. So it's not trying to.

To add assorted features of varying complexity and implications I think there should be a better justification than just "any half-decent web-based interface takes query parameters".

[Frenzie]

If I wanted I a more sophisticated, full featured web UI on par with Android version it wouldn't be built with jQuery. The purpose of this tool is primarily to explore and debug local .slob file content. On a desktop, web app is unlikely to beat native apps in terms of ease of setup and integration with environment;

Okay, it would seem that I completely misunderstood what this is. I did take it as effectively the new desktop equivalent of the Android app on account of the homepage. For something relatively simple like this I actually consider a web app acceptable. All the current one needs to be perfectly usable (in addition to #5) is the ability to pass a search term and select specific dictionaries through the URL.

Query parameters typically are interpreted by server. They also typically serve a certain purpose. I'm not sure what changes exactly are you asking for or what use case are you trying to address.

Like I said, any decent dictionary will allow you to search using

someplace.com/?search-parameter=whatever&dictionary=whatever

Van Dale (and I'll link to the free one) is a decent enough example:

http://www.vandale.nl/opzoeken?pattern=woord&lang=nn (Dutch)
http://www.vandale.nl/opzoeken?pattern=woord&lang=ne (Dutch-English)

A hidden feature (at least I think the GUI only allows for selecting one dictionary to search in) is to search in multiple dictionaries at once:

http://www.vandale.nl/opzoeken?pattern=woord&lang=ne;nn;nf

(Interestingly, if you pass a * you get a non-hidden Fatal error: Call to a member function attributes() on boolean in /home/vandale/www/sites/all/themes/vandale/templates/views-view--free-dictionary.tpl.php on line 6)

That's how I search. w Wikipedia loads https://en.wikipedia.org/wiki/?search=Wikipedia. And so on. But I'm not always online, especially on my laptop.

To say that query parameters are something for the server is far from accurate when you're talking about a JS app. We're just talking about proper URLs, no matter how they're constructed. That's why there's history.pushState. Bad JS apps use fake query parameters in the hash (e.g., blabla.com#?param=something) that don't work well with back/forward and such. Good ones you barely even notice are JS until you turn JS off. The best still work with JS disabled. Right now this is adequate, but it wouldn't take much to make it good. I'm not talking about full-featured UI on par with Android. I'm just talking about a good web-based dictionary app. Ninjawords but better. :-)

Making it usable as a search engine perhaps would be better served by server returning lookup results as rendered HTML rather than JSON data. This effectively replaces existing web ui, eliminates need for it. It doesn't sound too compelling to me, but maybe it's interesting to explore, because sometimes less is more :)

Then you'd lose most of the speed advantage ninjawords.com as well as the current interface have over actually slugging over to Wiktionary/Wikipedia/Wordnet/etc. Plus it doesn't eliminate the need anyway because the primary point is using it offline. But things like speed and searching through very specfic sets of multiple dictionaries at once are advantages even when you're online. Also, Aard search result matching is way better than Wiktionary's.

Dictionary selection already happens in the command line to start the server. User interface and web api could be modified to allow dynamic active dictionaries selection, and otherwise manage them similar to Android version, but I'm not sure what's the use case in this application.

The use case is that, at least for me, having more than two or three dictionaries enabled at once tends to render search results borderline useless. Dictionary selection on the command line would be a joke. I'd need to run multiple servers and then reverse proxy to /wiktionary-this, /wikipedia-that, etc. Instead I'd just end up doing what I'm already doing: stick to the two dictionaries that I need the most that combine fairly well: French and German Wiktionary. This same problem applies on Android btw. I'd love to have the ability to create shortcuts to specific enabled sets of dictionaries instead of having to enable/disable stuff.

To add assorted features of varying complexity and implications I think there should be a better justification than just "any half-decent web-based interface takes query parameters".

Ultimately I don't much care how you pass relevant search parameters. Query parameters just so happen to be the right way for a web app, but if you prefer something like a JSON object in the hash I can live with that. But I'm flabbergasted that the creator of one of the best dictionary apps around would question something so basic and fundamental to heuristics. The justification is quite simply the ability to find things.