Organize dictionary / clashing shortcuts into their own namespaces

[georgjaehnig]

A current problem around dictionaries are shortcuts for the same language pair, for different dictionaries, for instance

• de.end 1 for English-German (dict.cc)
• de.enp 1 for English-German (pons.de)
• de.enb 1 for English-German (Beolingus)

Distinguishing by one letter (d, p, b) has its limits, as multiple dictionaries can start with the same letter, obviously.

An idea to solve this:

• for every language pair with multiple dictionaries, put them into into their own namespace each, e.g.
  • dict-cc.yml
  • pons.yml
  • beolingus.yml
  • in these, a dictionary entry would have the keyword: de-en (order of the 2 language codes normalized by alphabetical order)
• enable shortcut aliases
• in language namespaces set an alias to the desired default dictionary, e.g.:
  • in de.yml, have en 1 pointing to dict-cc.de-en 1
  • in en.yml, have de 1 pointing to dict-cc.de-en 1

That way, the rest of the shortcut data is there only once, so DRY

Then, users may set their own aliases in their trovu-data-user repo.

(Potential) problems

• many new namespaces (where would be the limit?)
• parsing of aliases beyond namespaces could be challenging
  • extra HTTP requests
  • what to do when aliases point to other aliases, how deep to follow?
  • calling shortcuts directly will be tedious: dict-cc.de-en tree instead of end tree

[neubarth]

At the beginning, I was sceptical to start using namespaces for specific sites like Pons or dict.cc, because I thought they should be reserved for global concepts, like languages and countries. But then I thought that ICANN's top level domains have taken the same path recently, so I guess that's fine.

Also, I thought what seems most intuitive for me from a user perspective. These are the results:

1. de.en tree, pons
2. pons tree, de-en I assume both options are not viable, because the arguments could not be used as simple query parameters, i.e. some additional processing would need to be introduced.

Therefore, I think we should go with the namespace-approach, assuming that the number of namespaces can be scaled up easily.

parsing of aliases beyond namespaces could be challenging

Can you elaborate a little bit more on that? Thanks :)

calling shortcuts directly will be tedious: dict-cc.de-en tree instead of end tree

I think dict-cc.de-en tree is as concise and readable as it can get. And it should only be required when the default dictionary is not desired. When a user finds that he needs this structure often, he can either memorize the end tree version, or create a custom shortcut for himself.

[m4h4]

The namespace idea for dictionary families sounds good to me (although I suggest to use short strings, such as:pons, dict, beo). There should be a default dictionary in the language namespace, so if I don't care about a Finnish dictionary, I can just type fi and will get Finnish to German in the German namespace. If I want pons explicitly, I can type pons.de-fi, and if I always prefer this, I can define my own name.

[georgjaehnig]

@neubarth:

parsing of aliases beyond namespaces could be challenging

Can you elaborate a little bit more on that? Thanks :)

Sure. It's about this ticket. In fact, it was renamed in the meantime from alias: to include. With the current concept, such things will be possible:

• pons.yml:

  de-es 1: url: http://en.pons.com/translate?q={%word}&in=&l=dees title: German-Spanish PONS

• de.yml

  es 1: title: Spanisch-Deutsch (PONS) include:

  • namespace: pons key: de-es 1

• es.yml

  de 1: title: Alemán-Español (PONS) include:

  • namespace: pons key: de-es 1

So there's one spot with the dictionary URL and possibly tags & examples, and this get's included from the language namespaces de and es. Because we include only some parts, we can set custom titles in each of the language namespaces.

And as I expected: Writing the code to include accross namespaces is more challenging than I thought. :) But still possible, and it causes a lot of good cleanup.

I think dict-cc.de-en tree is as concise and readable as it can get

Well, more concise would be dict-cc.en tree from de namespace (and respectively, dict-cc.de tree from en namespace). But I just realize, this could be achived by including them:

• de.yml

  en-dict 1: title: English-Deutsch (dict.cc) include:

  • namespace: dict key: de-en 1

• en.yml

  de-dict 1: title: German-English (dict.cc) include:

  • namespace: dict key: de-en 1

he can either memorize the end tree version, or create a custom shortcut for himself.

I think I want to drop the end keywords, as they are not intuitive (see also: enl for Leo and then eni for Linguee, as the l was already in use.) and cluttered the namespace.

The longer versions a la en-dict are better memorable and still somewhat short enough.

And yes, there's always the option to set your own keyword within your user shortcuts (even soon more easier with the new include:!)

@m4h4: Thank you also for your opinion.

[georgjaehnig]

Fixed and reorganized with 35