Been using the client, works nicely. Thanks for writing it! I wanted to suggest something. If you change the t() function to put a div around the text, say


, then you can use jquery to attach an event to that text. The event would simply highlight the text on mouseover, say put a yellow background, and onclick would put the text in the source box. This would significantly improve the usability of the interface.


Gábor Hojtsy’s picture

Status: Active » Postponed (maintainer needs more info)

We thought about this but choose this interface instead. Because many t()-ed strings will not end up on the interface (eg. sent out in emails), or are escaped when displayed (eg. menu items), so the result would probably look broken. If you have good results with such an approach, let me know though, since this would definitely be easier, if only we would know where can we apply that div.

sami_k’s picture

Well could we not take a hybrid approach and support both cases? Because I do find that in some cases the text in the left column is more cumbersome to find than text that I am looking at.

Gábor Hojtsy’s picture

Status: Postponed (maintainer needs more info) » Active

As said, we can screw up your JavaScript string translations, your emails, etc. by wrapping each string in a div. Unfortunately we don't know what string goes out to the web interface and what goes elsewhere. Feel free to experiment with this and prove me wrong :)

Gábor Hojtsy’s picture

Title: Make the interface even more friendly » Make text on the page click-translatable
hass’s picture

Great idea... i wished this is already inside last weekend. Like Firebug "Inspect" feature...

sami_k’s picture

How about a flag approach, where we set a variable to enable string translations and then disable it. It won't be a production feature, but rather a development feature? That way it may break certain things, but only at development time...

Gábor Hojtsy’s picture

Title: Make text on the page click-translatable » Make it possible to translate by clicking on elements

We can look into how devel's theme submodule does its firebug type inspection and maybe piggy back on that or do something similar for our own needs. This can be quite useful but I'm still unsure about its general feasibility. It will not be able to replace the existing UI entirely for sure. I'd be happy to see if someone explores this direction and provides a proof-of-concept/patch.

tinker’s picture

Don't know if this is possible but what about doing a retroactive selection.

  1. I could see a pointer icon in the client that a user could click on.
  2. When activated the user could click on some text in the the page.
  3. When they click on something maybe we could have a script that identifies the first word in the container??
  4. If we know the word we could advance the source list to the first occurrence.

Is this possible?

Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)

Drupal 5 is not supported. The same problem was not reported for Drupal 7 or 8. The 8 branch has a tour-like solution which is similar but not exactly like this but that is a proof of concept. See #2730817: Localization client UI needs refactoring for modern JS and #2575401: Localization UI does not actually save any translations.