Entry Tagging

[megahirt]

I have observed that users would like the ability to tag entries in a general sense for later processing. This is similar to the "star" in Gmail. The user wants to be able to "star" or "tag" an entry to remember it, and then be able to filter based upon that tag or star. @rmunn suggested we provide a set of color tags or stars, not just one star.

@alex suggested that we consider how these tags could be easily transferred back into FLEx, and we decided that a custom field option list was the best way to do that.

[alex-larkin]

Great summary of our conversation! I will just add that if there is ever any kind of entry data that is not synced with FLEx, that that limitation should be communicated with the user the first time(s) that he creates said data.

I would like to encourage the development team to always ensure all data is syncable. (Though a short-term no-sync limitation during the development of a feature would be acceptable).

[rmunn]

Here's what I wrote in #1153, which I created when I hadn't noticed that this card exists:

One user wanted the ability to mark certain entries, and then have a filter that would show only the marked entries. Something like the "star" feature in Gmail. Then a filter could be used to see only the starred entries, or only the unstarred ones.

This would involve a new boolean property on entries in MongoDB, or perhaps we could plan ahead and make it a string so that we could have multiple label colors à la Trello (red, blue, green...). There would also be UI to mark or unmark ("star" or "unstar") the entry on the entry view page, and the star would show up in the entry list view on the left.

The star status would not be sent in a Send/Receive operation; this would be in Language Forge only and would not show up in FieldWorks. (Unless user feedback suggests that they want to see the star status in FieldWorks as well, in which case we'd track that work in a separate issue).

Alternatives:

• Comments could be used right now to implement this: we have a status on comments called "To Do", along with "Resolved" and "Unresolved". But that's at a field level, not an entry level, and there's no entry-list filter for "All entries with a "To Do" comment".
• A custom field called "Status" could also be used to implement this idea, but that's also not as easy to filter for in our current entry-list implementation.

[rmunn]

Also, Alex Larkin said:

If this is implemented without FLEx support, please notify the user when he starts using the feature that stars won't be visible in FLEx.

I imagine a common reason for starring entries would be to prepare them for publication, which would generally be done via an export from FLEx. Workaround: without FLEx compatibility, I guess that the user could also manually mark the publication field, or a field custom to his project. Ensuring 100% alignment between stars and a second field would likely be difficult, though.

What are other use cases for starring?

I'm copying that comment over here as well so the whole conversation is visible here.

[rmunn]

Design decisions reached after discussing this with Chris yesterday:

• Entry field in LF data model: "tags" (a LexMultiValue, probably, or maybe just a string array)
• LfMerge will turn that field into a custom field on the FW side, probably named lf_tags or LF_Tags. Might call it "Language Forge Tags" in the UI, but probably LF_Tags as the "key" (canonical name) of the field.
• On FW side, will create a possibility list with specific, chosen GUIDs for the canonical values
• Canonical values will be star, and nine colors: red, orange, yellow, green, blue, purple, brown, lightgray, and darkgray. Note the no-space names for the last two: tags will be space-delimited
  • If custom tags are ever allowed, space characters should be forbidden in tags, and a hyphen recommended instead (so if the user chooses "to do" as a tag name, the UI should say "space characters are not allowed in tag names; to-do is recommended instead" and provide a button/link to click on to auto-accept the recommendation).
• Canonical keys for those tags will be the English names of the colors
• Canonical names will be provided localized in the major languages that FLEx is translated into. Google Translate is probably safe for this since there's no grammar for it to get wrong. 😄
• Language Forge UI can even be done by someone else, potentially, while I get the data-model side handled.
• This card will track the data-model change, and I'll create another card to track the UI

[alex-larkin]

Sounds good! Exciting stuff.

A note regarding machine translation: machines can still botch single-word translations, because words often have more than one sense. And the machine may not have the needed context. (Granted, translating all the colors together should help with context.)

Here are some examples, though my main concerns are orange and to a lesser extent, star.

Star:

1. N. Cosmic burning gas ball
2. N. Celebrity
3. V. To mark something as important

Orange:

1. Adj. The color
2. N. The fruit

Yellow:

1. Adj. The color
2. Adj. Cowardly

Green:

1. Adj. The color
2. Adj. Environmentally friendly

Blue:

1. Adj. The color
2. Adj. Depressed

Also, languages divide up colors differently. For example, our English blue is divided up into two colors in Korean and Russian. Those interested can check out this fascinating short paper on the subject

I imagine most of the translations will probably be fine. Could we do the machine translation and then message all of our Transifex volunteers and ask them to check them? (Is there a way to do that?)

Another option is to check translations in Dictionaries, like in WordReference.com. though that could be tedious.

Are we going to translate into the five non-English, non-semantic-domain-only languages listed on production?

Thanks!

[rmunn]

Figured out a UI for displaying multiple tags on an entry in the list view. We currently have an orange bar if an entry has comments. For tags, I figured we would add other color bars. Problem is, the orange bar is implemented with a CSS border-right, and you can only have one border in CSS. But you're allowed to use multiple box-shadow specifications. By making the box shadow inset the shadow appears inside the element instead of outside. Then by not using any blur, it doesn't look shadow-like at all but does achieve the desired effect. Here's a mockup of sample list entry with just a 5-pixel border-right in orange:

And here's the same list entry with red and yellow tags added:

The CSS used to add the red and yellow tags was:

box-shadow: inset -5px 0px yellow, inset -10px 0px red

Since the pixel values will be dependent on how many tags are on an entry, we can't use static CSS for this. Instead, I'll add a style attribute to the elements that need it and calculate the pixels on the fly in Angular JS.

BTW, I used https://svelte.dev/repl/f01054bf77854e7ca2b4f2582703f397?version=3.44.1 to experiment with the CSS. The immediate feedback of editing the style and seeing it "live" on the right was a great development experience.

[rmunn]

sillsdev/LfMerge#142 will track the Send/Receive portion of this feature.

[rmunn]

The feature/entry-tagging branch (not yet in a PR) is where I'm working on the LF implementation of this feature.

[megahirt]

The UI changes for the entry tagging feature manifest in a number of places:

• display colored bars in list display, both compact list and full list with rendered entry view (mocked up above by @rmunn ). Also display star.
• display colored "tags" and/or star in full list rendered entry display
• display "Gmail star" in entry, either filled out or not filled out
• UI for adding/removing tags from the entry. I like the idea of a row of colors which you can check/click on/off See "button groups" in bootstrap Another existing UI is the multi-option list e.g. semantic domains
• Filter UI for tags (drop down), so you can filter to show only those items tagged
• Filter for has star / not has star