Closed (duplicate)
Project:
Localization client
Version:
5.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
5 Feb 2008 at 11:33 UTC
Updated:
9 Aug 2016 at 08:49 UTC
Jump to comment: Most recent
Comments
Comment #1
gábor hojtsyWe 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.
Comment #2
sami_k commentedWell 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.
Comment #3
gábor hojtsyAs 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 :)
Comment #4
gábor hojtsyComment #5
hass commentedGreat idea... i wished this is already inside last weekend. Like Firebug "Inspect" feature...
Comment #6
sami_k commentedHow 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...
Comment #7
gábor hojtsyWe 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.
Comment #8
tinker commentedDon't know if this is possible but what about doing a retroactive selection.
Is this possible?
Comment #9
gábor hojtsy#1165476: if t() string has no translation or fallback language, text should have lang attribute is a related Drupal core issue.
Comment #10
gábor hojtsyDrupal 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 submodule does not work with Drupal 8/9 yet.