search

orgzly / orgzly-android

Outliner for taking notes and managing to-do lists
https://www.orgzly.com
GNU General Public License v3.0
2.69k stars 305 forks source link

Add support for Wiktionary links #101

Open mardukbp opened 7 years ago

mardukbp commented 7 years ago

There are several Wiktionaries packaged as Android apps and they can be called from other apps using a few lines of Java. Supporting links like en:potato or de:kartoffel would be great for language learning with orgzly.

nevenz commented 7 years ago

I'm not sure this belongs in a note-taking, task-managing app.

It's relatively easy to translate any word by selecting it and sharing it with the app that would do that.

More importantly, if you're entering words prefixed with en: or de: (which is presumably only to translate them to learn the language), you might as well do that in the app specifically designed for that.

mardukbp commented 7 years ago

I would argue that note-taking is very useful when you are learning a language. Moreover, articles, adverbs, prepositions and so on can be naturally organized in a tree structure. So this topic definitely belongs to the scope of the app.

While it is true that one can select a word and send it to the dictionary, it is much more convenient to touch the word and go directly to the definition.The use-case I have in mind is not using orgzly to write lists of words with links to their translation, but rather to organize the basic words of a language, which belong to different categories. The links would lead to the corresponding entry in the dictionary, which contains examples.

I think orgzly should retain the great versatility of org-mode and not be restricted to ToDo lists and other conventional uses. The greatness of emacs and org-mode is in the freedom to use them as you please.

nevenz commented 7 years ago

I guess my main concern is when using bunch of those prefixes, there's a higher chance that user uses them unintentionally and gets confused.

I have no issue with custom schemas in general (we'll need to have something like id: for internal linking for example anyway.). But this will need to be something like translate:/de/word.

A preference for enabling "custom links" is also worth considering.

mardukbp commented 7 years ago

Allowing the user to enable each custom prefix reduces the clutter and elevates the awareness of their meaning.Why not use en: instead of translate:? It only takes one argument and can be enabled only when the wiktionary is installed.

nevenz commented 7 years ago

Allowing the user to enable each custom prefix reduces the clutter and elevates the awareness of their meaning.Why not use en: instead of translate:? It only takes one argument and can be enabled only when the wiktionary is installed.

It's a scheme, and there are many languages, polluting scheme namespace with every language code doesn't seem like a good idea. It's in the ranks of http, mailto, dict, etc. We don't use orgmode.org:features.html for example, buthttp://orgmode.org/features.html.

There's be clashes too. Take Indonesian for example (id). It would clash with internal notes links (id:16E14B8D-AE1B-4C32-ACAC-AC066C78CE70).

mardukbp commented 7 years ago

Good point. Then I would suggest using dict:/dictionary/word

decadent commented 5 years ago

This would be much better implemented by Orgzly allowing any custom protocols, and other apps processing links to those protocols—exactly as it's currently done on websites, at least on desktop (e.g. when you open a link to iTunes or App Store on a Mac, or to desktop Evernote). In this scheme, an app would respond to a protocol such as dict, and the user would enter links with that protocol. The first part needs to be implemented in a Wiktionary app (or other ones, for different use cases), so you'd need to request it from them; the second part is where Orgzly's link processing comes into play.

Orgzly shouldn't be concerned with supporting individual third-party apps, and shouldn't dictate link protocols for all users. In Emacs, support for protocols can be added in individual configuration, but in Orgzly it would have to be added in app code for everyone. Custom protocols are an existing de-facto standard which allows third-party apps to indicate support for custom links, with little to do on the part of a linking app.

However, annoyingly enough, Emacs doesn't allow arbitrary custom protocols in links, requiring instead that protocols be registered via Elisp code. But, it should be possible to register a meta-protocol that would accept other custom protocols as the link, e.g. proto:dict:example. Then Orgzly could also freely support such links.

I'm also not sure if Android currently has support for custom protocols. It's likely to do so, though, since e.g. Firefox can open a Play Store page in the Play Store app.