Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tags #125

Closed
bouncepaw opened this issue Jan 7, 2022 · 5 comments
Closed

Tags #125

bouncepaw opened this issue Jan 7, 2022 · 5 comments

Comments

@bouncepaw
Copy link
Owner

bouncepaw commented Jan 7, 2022

Turns out, we need tags.

Tags should not be part of Mycomarkup. There will not be a tags {} element.

@bouncepaw
Copy link
Owner Author

bouncepaw commented Jan 7, 2022

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.

@bouncepaw
Copy link
Owner Author

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]

This was referenced Feb 3, 2022
@bouncepaw
Copy link
Owner Author

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

@bouncepaw
Copy link
Owner Author

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.

@bouncepaw
Copy link
Owner Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant