tagging widget (and tagging in general)

1 view
Skip to first unread message

Laurent Savaete

unread,
Apr 28, 2012, 11:40:37 AM4/28/12
to ductus-d...@googlegroups.com
A few thoughts about tagging (widget):
1- we need users to have an easy way to pick pre-existing tags
2- we want users to be able to add their own tags
3- we have some special tags, like source and target language (where
applicable). Those I would show separately and only if it makes sense,
e.g. source language only if we have an audio interaction (I don't
think source makes sense otherwise, does it?). For instance,
target-language could be shown on virtually any lesson, with a
dropdown to pick the target language among those the user knows (or
that could be an autocomplete field as well).

- I seriously can't think of a better tagging widget than the one at
stackexchange/stackoverflow(SO) (see screenshot attached, with
autocomplete and help text (which we may skip)). It's the easiest one
I've seen in terms of usage.
- we use jquery-tokeninput for picking languages, which is fine
because that's a predefined set of values, but we can trick it into
accepting custom user tags, so I'd go for that one to cover 1 and 2,
and it can approach the SO widget pretty closely (barring the tag
description), with very little work. And the jquery plugin is under
active dev/maintainance.

so the result would look something like the second attachment.

Tags in general:
- we may want to support aliasing in the future, at least for
searching (see the SO screenshot under "python-3.x") with alternative
spellings. I can't think of a directly useful example for us, but I
guess this could happen in the future.
- also we may want to support localisation for tags (drupal has that
sort of feature, which is pretty neat: we could tag a lesson with
"grammar" but display "grammaire" for a user with "fr" as a UI
language, and of course, let the user type in/search with the
localised name). Typical use case: picture choice lessons for english
vocabulary, that can be used by learners of virtually any native
language.
- the above means we'd need the appropriate backend for that, not
necessarily immediately, but in the near future.
- for our immediate use, we need an AJAX url that returns a list of
tags matching the user input for the autocomplete textbox

your opinions?
stackoverflow-tagging-widget.png
20120428-tagging-widget-suggestion.png

Jim Garrison

unread,
May 1, 2012, 2:09:14 AM5/1/12
to ductus-d...@googlegroups.com
On 04/28/12 08:40, Laurent Savaete wrote:
> A few thoughts about tagging (widget):
> 1- we need users to have an easy way to pick pre-existing tags
> 2- we want users to be able to add their own tags
> 3- we have some special tags, like source and target language (where
> applicable). Those I would show separately and only if it makes sense,
> e.g. source language only if we have an audio interaction (I don't
> think source makes sense otherwise, does it?). For instance,
> target-language could be shown on virtually any lesson, with a
> dropdown to pick the target language among those the user knows (or
> that could be an autocomplete field as well).

One thing about "special" tags to keep in mind is that we would like to
localize them (or at least that's what we decided to do in New York).
The tag "source-language:en" will have a different representation if the
site is being localized into Chinese than if it is being localized into
French. The more generic tags don't get translated (obviously) -- they
are what they are.

> - I seriously can't think of a better tagging widget than the one at
> stackexchange/stackoverflow(SO) (see screenshot attached, with
> autocomplete and help text (which we may skip)). It's the easiest one
> I've seen in terms of usage.
> - we use jquery-tokeninput for picking languages, which is fine
> because that's a predefined set of values, but we can trick it into
> accepting custom user tags, so I'd go for that one to cover 1 and 2,
> and it can approach the SO widget pretty closely (barring the tag
> description), with very little work. And the jquery plugin is under
> active dev/maintainance.
>
> so the result would look something like the second attachment.
>
> Tags in general:
> - we may want to support aliasing in the future, at least for
> searching (see the SO screenshot under "python-3.x") with alternative
> spellings. I can't think of a directly useful example for us, but I
> guess this could happen in the future.
> - also we may want to support localisation for tags (drupal has that
> sort of feature, which is pretty neat: we could tag a lesson with
> "grammar" but display "grammaire" for a user with "fr" as a UI
> language, and of course, let the user type in/search with the
> localised name). Typical use case: picture choice lessons for english
> vocabulary, that can be used by learners of virtually any native
> language.

Yes, this is basically what I'm getting at above. Does drupal support
the localization of things other than pre-defined tags? I think only
supporting pre-defined tag translations is good enough, but let me know
what you think.

Laurent Savaete

unread,
May 2, 2012, 8:20:39 PM5/2/12
to ductus-d...@googlegroups.com
> Yes, this is basically what I'm getting at above.  Does drupal support
> the localization of things other than pre-defined tags?  I think only
> supporting pre-defined tag translations is good enough, but let me know
> what you think.

I looked at drupal again today. It's an utter mess. There are so many
plugins to do localisation that I couldn't figure out which one is
providing what.
Anyway, I'm thinking that custom tags can easily become "pre-defined"
by some maintainer action. I could imagine a query to mongoDB
returning a list of tags that are not translated yet, then a
maintainer matching translations, and a bot updating all lessons with
the new tag.
From an end user perspective, this would be entirely transparent, but
after that operation, users would gain access to a whole new set of
material under a given tag.
So yes, I second your opinion, let's only localise "pre defined tags",
as long as we can imagine a workflow to add more of them. (which means
we can start with custom (non translated) tags for now.

Jim Garrison

unread,
May 4, 2012, 1:47:32 AM5/4/12
to ductus-d...@googlegroups.com
On 05/02/12 17:20, Laurent Savaete wrote:
>> Yes, this is basically what I'm getting at above. Does drupal support
>> the localization of things other than pre-defined tags? I think only
>> supporting pre-defined tag translations is good enough, but let me know
>> what you think.
>
> I looked at drupal again today. It's an utter mess. There are so many
> plugins to do localisation that I couldn't figure out which one is
> providing what.
> Anyway, I'm thinking that custom tags can easily become "pre-defined"
> by some maintainer action. I could imagine a query to mongoDB
> returning a list of tags that are not translated yet, then a
> maintainer matching translations, and a bot updating all lessons with
> the new tag.
> From an end user perspective, this would be entirely transparent, but
> after that operation, users would gain access to a whole new set of
> material under a given tag.

I see this coming much later possibly, once we have decided that it is
definitely useful, and once we have worked out any possible kinks with
implementation. For instance, if we tell it that "casa" is now
synonymous with "home", do all previous tags for "casa" get updated to
instead be the tag for "home", just translated? If "casa" meant a
second thing in Spanish, how would we distinguish?

I think there are a lot of unanswered questions in making a custom tag
translatable, and I think some of the questions will have no good
answers. So I'd say to avoid doing this as long as possible. :)
Reply all
Reply to author
Forward
0 new messages