Posted by Gabriel R. on March 5, 2010 at 9:24am
Dear fellow translators,
We would like to be able to translate only the strings that are visible to regular, non-admin users. We don't care about the 8000 or so strings that appear only on the administration area.
Here's how we do this:
-
Change the t() function in core to make it ignore everything coming from an /admin path. Yes, changing core is a nasty habit, but we found no sane way to do this.
-
Wipe clean the locale tables.
-
Let it rip. The locale table will be populated shortly.
We believe this is a fairly common problem, but found no other solution. What do you think about this approach?
Comments
Is it any performance
Is it any performance different ?
and how to do step 2
thanks.
no perf impact, sql
No impact on the performance, that check is only perfomed when adding new strings on admin, with variable already in the session.
To wipe the tables clean, you have to use SQL. Can't help you with that, you really must know what you're doing there.
Except it doesn't work
We changed {drupal_root}/modules/locale/locale.module file by surrounding the only SQL INSERT statement by following if statement:
<?phpif(!substr_count(request_uri(), 'admin')) { ... }
?>
However, strings in t() from modules don't get the current URL in the location. Instead, they get modules/somemodule/somemodule.inc.
Is another way to check for the current URL in those cases?
$_GET['q']
Look at $_GET['q']. However, some string will only appear in certain circumstances. Error messages, feedback notes, etc. which are of obvious importance to translate will not appear if you just rely on Drupal's "collect strings as you browse" method. So segmenting strings by where they appear could be successful to some degree but never complete with this method. (If we'd know a method, we'd tack on this information to each string, but code can and is reused on admin and front end interfaces, so there is no clean way to make this distinction).
Hi Gábor. We'll have to take
Hi Gábor.
We'll have to take the chance, as there is no point in translating the 8000 strings in the DB while we only care for something like 1000.
How about a way to check for /admin without hacking core?
As for module strings getting /somemodule/somemodule.inc instead of the current URL in the location, we discovered they were injected at installation by the translation system. We now remove manually the /translation folder from the modules before installing. This which is a pain, cause it prevents using drush to set them up. Any suggestion for where we can disable the string import? We would hack core if we have to.
Thanks for the help.
you drop the data anyway
I'm not seeing the problem with filenames being there on installation, since you drop the data anyway before you add in the admin detection part as far as you explained.
Not sure what you mean with
Not sure what you mean with "since you drop the data anyway". We are removing the /translate/ files when adding new modules to avoid importing the strings in the DB automatically when the modules are installed.
point 2
Your point 2 was about wipe cleaning the database. Since in that you drop all your locale data anyway, these location infos will also disappear.
Ah, I see. But we add new
Ah, I see. But we add new ones too as the site progresses.
Yes, and you can just drop them
Yes, and then you can just drop them as well by identifying them having filenames in their locations.
if I want to separate admin /
if I want to separate admin / user interface stings, I will use potx modules to extract strings and desktop editing.