Better multilingual entry support

[azurelunatic]

Title:
Better multilingual entry support

Area:
entries, search

Summary:
Allow entries to be tagged with the language(s) that they are composed of. This can be used to power more interesting things around the site.

Description:
Entries composed of written or spoken material (text, images of writing, audio, video) usually have one or more languages in which the material is presented. Allowing entries to be voluntarily tagged by their owners to describe the language(s) they are using might allow some interesting features to be developed based on entry tagging.

If a particular spelling appears in more than one language, specifying the language of the entry in site search could help find the thing someone's looking for.

Statistics on actual use of the site by users who speak different languages might be helpful to staff, especially if the technical barriers to offering the site in translation are overcome.

It could help users better connect with people who speak their same language, especially users whose preferred language is in a minority on the site.


What would the user interface be like? A whole long list of possible languages could a) be unwieldy, b) might also leave out languages used by actual site users (sign languages and constructed languages spring to mind as languages that might be left out of even a fairly exhaustive list of languages, and entries with embedded video might have sign language, and fannish communities are reasonably likely to include Tengwar and Klingon, and goodness knows there are probably more use cases that I know nothing of).

One way to do it might be like the tags interface, where something can be typed in, and attempt to autofill from a preset list, but accept new entries gracefully. If designed properly, unique data entered here on public entries could be logged, collated, and presented to an administrator on a regular basis for review; items that are found to be actual common languages not present on the list could then be entered.

Any site function that involves searching by language should allow for synonyms -- three different people might use "tlhIngan Hol", "pIqaD", and "Klingon" to mean the same language -- to say nothing of the typos. There should be a way to bundle known synonyms and known typos -- and also a way to override this bundling.

Another challenge is that people might not tag all their entries (to say nothing of back entries). How hard/expensive would it be to autodetect languages? Failing autodetection, could a default be set by user, like the last language they used?

Poll #7733 Better multilingual entry support

Open to: Registered Users, detailed results viewable to: All, participants: 66

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
38 (57.6%)

Should be implemented with changes. (please comment)
4 (6.1%)

Shouldn't be implemented.
2 (3.0%)

(I have no opinion)
20 (30.3%)

(Other: please comment)
2 (3.0%)

Click to show the contextual popup, instead of showing it on hover

[fu]

Title:
Click to show the contextual popup, instead of showing it on hover

Area:
journals, site interaction,

Summary:
The contextual popup which contains user-specific links shows up when you hover over the userhead before a username, or someone's icon. I'd like to suggest adding an extra "click" so that it only shows up when the user calls it up and can't be summoned by accident.

Description:
The contextual popup has several subtle issues, because it's triggered by hovering over something, and closed by moving your mouse off of it:

* you can trigger it accidentally by hovering over an icon or userhead while reading a comment -- the unexpected animation can be distracting, or the box might cover up content you want to read

* it fades out after a few seconds: this may be too short for people with fine motor control issues. Conversely, it may be too long for someone who has accidentally triggered the thing and just wants it to go away!

* no way to trigger it by keyboard; no way to indicate that there's anything even like this functionality to keyboard-only users



I suggest that hovering over an icon or userhead should only show a small image within the icon or userhead. This can be clicked to open the contextutual popup menu.

Pros:
* less chance of unexpected behavior and animation
* less chance of accidentally covering up the text you're reading
* more control over how you interact with the site
* it may be possible to make this keyboard friendly, by also adding the clickable trigger when someone focuses on an icon or userhead.

cons:
* adds an extra click for people who are used to the old behavior of the contextual popup showing on hover
* might not be obvious how to open the contextual popup / may not be obvious what the button does
* unexpected animation still there, just a lot subtler
* the small image overlaying the userhead will mean that you can no longer click directly on the userhead to go to that user's profile; however the link is still in the contextual popup menu (see ETA below, which may make this less of an issue)
* the small image overlaying the icon *may* make it harder to click directly on the icon to go to that user's icon page; however that link can be added to the contextual popup menu

Here's a screenshot of how it looks now, where the contextual popup shows up when you hover right over the icon.
http://afunamatata.com/dreamwidth/journal/2011/08/contextual-hover.png

Here's a quick and dirty mockup of how the extra clickable link might work:

When you hover over an icon: http://afunamatata.com/dreamwidth/journal/2011/08/icon-on-hover.png
When you click on the trigger: http://afunamatata.com/dreamwidth/journal/2011/08/icon-on-click.png

When you hover over a userhead (see ETA below for a revised version)): http://afunamatata.com/dreamwidth/journal/2011/08/userhead-on-hover.png
When you click on the trigger: http://afunamatata.com/dreamwidth/journal/2011/08/userhead-on-click.png

Mockups were made in less than ten minutes, so please assume that fiddly bits like where the trigger overlays text in the contextual popup can be fixed (and will be!)

Poll #7732 Click to show the contextual popup, instead of showing it on hover

Open to: Registered Users, detailed results viewable to: All, participants: 76

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
10 (13.2%)

Should be implemented with changes. (please comment)
13 (17.1%)

Shouldn't be implemented.
25 (32.9%)

(I have no opinion)
22 (28.9%)

(Other: please comment)
6 (7.9%)

ETA 2011-08-10:

Some good points in the comments re: losing the ability to go to the profile!

Here's a modification of the hover behavior on the userheads. The trigger shows up to the left of the userhead, so the userhead remains clickable to go to the profile:
http://afunamatata.com/dreamwidth/journal/2011/08/fu-nohover.png
http://afunamatata.com/dreamwidth/journal/2011/08/fu-hover.png