Tags about mycorrhiza HOT 5 CLOSED

Storage

Three ideas.

Number one. Store what hyphae have what tags in tags.json.

type TagStorageRecord struct {
  Tag string
  TaggedHyphae [] string
}

Disadvantages include lack of git-driven sync and exclusion from history. Advantages include ease of implementation.

Number two. Store tags of a hypha named foo in foo.mycotags. Tag operations become part of history and git, which is good. It's ugly though.

Number three. Make tags a type of hypha (alongside media and textual, and, perhaps, possibly, hypothetical future user hyphae) and store what other hyphae are tagged with this tag in foo.mycotag.

I find the third approach the most Mycorrhizal.

from mycorrhiza.

Interface

HTTP

/add-tag
/remove-tag
/tags

UI

Two ideas. Place tags in the main area or in a new sidebar placed to the left. Since the main area is already packed full, the second option seems to be better.

We could place tags vertically there. If you have JS enabled, you should be able to modify tags without page reload and, perhaps, with auto-completion (how?).

A possible arrangement:

========TAGS========
Photo            [x]
Galapagos        [x]
[       ]  [Add tag]

from mycorrhiza.

See https://mycorrhiza.lesarbr.es/hypha/idea/tags to see the three tag proposals. We'll go with the third one.

from mycorrhiza.

While writing some tag-related code, a revelation has come to me. This feature should be called categories, not tags.

• There will be less problems with phrasing. The word tag is both noun and verb, which brings weird problems, while category is noun only.
• The word Categories would look better in the sidebar, than Tags.
• The first wikis had categories, not tags. MediaWiki has categories too.
• For the Russian translation, the word категории is obvious, while with tags there is a choice of теги and тэги, both of which are ok and it's hard to pick one.

from mycorrhiza.

Categories have been implemented, localized and documented and will be part of the April release

from mycorrhiza.