Lots of strings appear

This is surely not all strings available in Drupal, there are many others (long descriptions are totally missing for example). We used to have similar issues due to modules calling out the t() API before the initialization of the language system but worked around that by nulling out our cache in the initialization. Can someone else reproduce this on D7 (there seems to be quite some users using this module on D7)?

Confirm this in FF (win) when clearing search string filter

freezes while do search.

I find that only freezes if it call from any function.

attatched a test file

ONLY in FF 3
IE6+, FF4, Chrome ok

I got the same problem, at least partly: I get a lot of extra strings, but the browser doesn't freeze. (See screendump)

Drupal 7.0-rc2
l10n client 7.x-1.0-beta2
No other contrib modules

Is there other info that would be useful?

@zirvap: is there a date field or country selector on that form? Localization client only requests the list of strings used by Drupal, it does not make up its own stuff. So there must be a country list, time zone selector or something on that page.

There are definitively strings there which don't appear in the user interface. I turned off the core admin toolbar and went to look at some pages with very few interface strings. Attached are screendumps + HTML from the pages /user and /admin/help/text. (I installed one more language, with very few translations, to make it easier to identify the extra strings.)

I noticed another bug which may be related: The pages "Translate strings" and "Translated strings" don't work:
- "Translate strings" (/locale) says "No strings found to translate". The l10n_client toolbar disappears.
- "Translated strings" (/locale/translated) have no strings on the page, but translated strings (and only translated strings) are shown in the l10n_client toolbar.
Screendumps attached. Let me know if I shall make a separate issue for that.

Yes, this is indeed an abnormally lot of strings for the given page (looked at the user page txt). Can you please try and install Drupal 7 core and l10n_client ONLY to try and avoid any other modules interfering, and then try to reproduce, so we can conclude it is indeed a problem with the module itself. If that is not reproducible, let's see what other module or setting makes it broken.

Yep, same problem.

1. Installed today's dev version of Drupal core
2. Installed l10n_client, 7.0-1.x-beta-2 (via the admin interface)
3. Went to module page, activated locale and l10n_client
4. Activated another lanuage (Norwegian bokmål), set it as default. Did not import any translations.
5. Went to account page, strings looked OK (just the expected amount of strings)
6. Went to front page, still looked OK
7. Clicked "Translate strings" in navigation menu. No strings listed on page. Translation toolbar disappeared.
8. Clikced "Translated strings", translation toolbar still gone (this is different from the first test site)
9. Went to some other pages, and now I have lots and lots of strings in the l10n toolbar again. (See attached HTML file)

It doesn't look like the exact same list as for the first test site, for instance there's no list of countries. For the first test site, I chose a country during installation. This time, I didn't.

Possibly relevant info from the status report:

Info
Drupal 7.0-dev
OK
Access to update.php Protected
OK
Configuration file Protected
OK
Cron maintenance tasks Last run 16 min 43 sec ago
You can run cron manually.
To run cron from outside the site, go to http://bilkollektiv.skurker.net/cron.php?cron_key=rS-J0m7BIvITd_d6RpaYUi...
OK
Database system MySQL, MariaDB, or equivalent
OK
Database system version 5.0.91-community
OK
Database updates Up to date
Warning
Drupal core update status No update data available
No update information available. Run cron or check manually.
OK
File system Writable (public download method)
OK
GD library PNG support bundled (2.0.34 compatible)
OK
GD library rotate and desaturate effects bundled (2.0.34 compatible)
OK
Node Access Permissions Disabled
If the site is experiencing problems with permissions to content, you may have to rebuild the permissions cache. Rebuilding will remove all privileges to content and replace them with permissions based on the current modules and settings. Rebuilding may take some time if there is a lot of content or complex permission settings. After rebuilding has completed, content will automatically use the new permissions. Rebuild permissions
Info
PHP 5.2.9
The phpinfo() function has been disabled for security reasons. To see your server's phpinfo() information, change your PHP settings or contact your server administrator. For more information, Enabling and disabling phpinfo() handbook page.
OK
PHP extensions Enabled
OK
PHP memory limit 32M
OK
PHP register globals Disabled
OK
Unicode library PHP Mbstring Extension
OK
Update notifications Enabled
OK
Upload progress Enabled (PECL uploadprogress)
OK
Web server Apache/2.2.16 (Unix) mod_ssl/2.2.16 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4

Well, this is handled by the locale() function. Localization client sets the 'locale_cache_strings' variable temporarily to 0 in the requests it runs in, so that locale() will not use the short string cache. I think in your case, that variable switch is not working for some reason. As that cache grows (ie. you click around more screens in Drupal), your l10n_client will display more and more unrelated strings on pages. You should debug if that variable is really 0 in locale(). See http://api.drupal.org/api/drupal/modules--locale--locale.module/function... (the mechanism is the same in Drupal 6).

BTW I tried to reproduce this on my Drupal 7 test setup, but could not. So looking forward to what you find. The code in l10n_client which facilitates this is:

function l10n_client_init() {
	  global $conf, $language;
	
	  if (l10n_client_access()) {
	    // Turn off the short string cache *in this request*, so we will
	    // have an accurate picture of strings used to assemble the page.
	    $conf['locale_cache_strings'] = 0;
	    // Reset locale cache. If any hook_init() implementation was invoked before
	    // this point, that would normally result in all strings loaded into memory.
	    // That would go against our goal of displaying only strings used on the page
	    // and would hang browsers. Drops any string used for the page before this point.
	    locale(NULL, NULL, NULL, TRUE);

            // [.......]
	}
}

Well, looking at this, it seems like we are not clearing the locale() internal cache in a good way. Some hook_init() implementation is probably calling t() in your case before l10n_client_init() can run, and the cache is not cleared. We should clear it differently in Drupal 7. Can you try this patch?

Hm, the patch in #11 had an effect, but I'm not sure exactly what.

For most of the pages, it seems to work now -- I get the expected strings.

For admin pages with tabs, I seem to get strings for both tabs at once (so on both /admin/people and /admin/people/permissions I get strings for both "Add user" (only visible on /admin/people tab) and the permission names (only visible on /admin/people/permissions).

On some pages I notice strings in the l10n_client interface which don't belong. For instance on /admin/modules these strings are shown (in addition to the ones in use:
about-us/team aliased to internal path node/456
member/jane-smith aliased to internal path user/123
sub-term: Country rock
sub-term: Fusion
sub-term: Hard rock
sub-term: Swing
term: Jazz

There are also additional strings on the admin/help pages.

It doesn't work at all with the overlay -- when the overlay is active, I only see strings from the home page when I'm looking at admin strings.

/locale and /locale/translated still don't work.

If it will help, I can give you access to the test site (it's online).

Re. #10: How do I check the value of a variable?

Once agan, I'd like to ask you to investigate the deep contents of the page before you make assumptions about random strings appearing :) /admin/people has a dropdown with permission names, so not surprising that permission names are displayed on the page. I think the "Add a user" text on the permissions page is an artifact of how the menu system works (it is a local task on that level - ie. admin/people/create, so its a sibling to admin/people/permissions). If you go in with a debugger, you can prove for sure.

Country tock, Jazz and others appear, because those are contained in taxonomy_help()'s help for admin/help#taxonomy. Now, in Drupal 7, indicators of help available are printed on the module page. The way Drupal does this is that it invokes the respective help hooks for these paths. So all module help will be invoked for translation on module pages by the nature of this feature.

For the overlay, I've added this note to the project page:

Known issues

The Drupal 7 version will not work well with the overlay for architectural reasons. Either use control-click to open admin pages in new tabs or disable the overlay while you translate the administration interface.

It would be absolutely confusing to refresh the l10n_client UI as you navigate through your admin UI mixing up strings from the page behind the overlay and in the overlay. So since the overlay effectively displays two pages at once, and you are already confused with too many strings to translate, imagine if we mix strings from those two pages :) Fun, isn't it? Instead just skip using the overlay while translating your administrative UI.

Looks like the patch solved your problems then and we only got things which are explained when you look at how Drupal actually builds the page (which I suggest you do when finding such strange occurrences). So patch ready to go?

Ready to go :-)

I looked closer at the unexpected strings on the help pages, and it looks as if a lot of the strings from /admin/index are loaded on the /admin/help/... pages. It's consistent, so I'll assume these strings are loaded by Drupal in the background, like you described.

Thanks. I consider this a major issue, and will see if we'll need a release soon, or should do more cleanups (JS cleanups are on the way), before a new release will be out. Committed.

This might have been mentioned already, but here I go: Please add an option so we can choose to only show the untranslated strings. This should be easy since you already use different CSS-classes.

PS! I know I can add "display: none" to "#l10n-client .string-list li.translated" in l10n_client.css, but I want to reduce the size of the HTML too.

@hansfn: this would be great suggestion in a separate issue, here it looks like unrelated. Thanks!

OK, I have just created a feature request - #1022228: Add an option so we can choose to only show the untranslated strings. I just thought the initial post was related since the size of the HTML was an issue.