Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
in date-6.x-2.4 release inside date_api.module there is a string:
'!day-name Sunday|Monday|Tuesday|Wednesday|Thursday|Friday|Saturday' which is not registered to the 2.4 release on l.d.o
click on information (small search icon) to see the releases
Comment | File | Size | Author |
---|---|---|---|
#70 | better_exposed_filters_ldo_gui-releases.png | 8.79 KB | Thomas_Zahreddin |
#70 | better_exposed_filters-releases.png | 36.65 KB | Thomas_Zahreddin |
#17 | only-count-releases-for-published-projects.patch | 1.56 KB | Gábor Hojtsy |
#7 | broken_releases.txt | 44.46 KB | Gábor Hojtsy |
Comments
Comment #1
Gábor HojtsySimply reparsing this module made the string available. Not sure what happens, but we do experience intermittent issues with modules not fully parsed / stored. Not sure whether it is an issue with the parsing or the database storage, but given that I cannot reproduce this by just setting the last_parsed time to 0 and running cron again (therefore reusing the same stack again to redo the task), it is probably a temporary issue. A similar issue was reported at #593310: custom_breadcrumbs 6.x-1.5 parsing error. Although I'm setting this to fixed, I'll try to be alert and look for this happening again (not that I can tell whether a module was completely parsed, when our watchdog says the cron runs completed fine).
Comment #3
apadernoThere are other issues open for this problem, such as
#680700: There are no strings in the 5.x-1.2 release of Moleskine to export.,
#673122: There are no strings in the 6.x-1.3 release of Translation template extractor to export.,
#672562: There are no strings in the 6.x-1.0-beta7 release of Integrated Metatags to export.,
#662448: There are no strings in the release of Video Filter to export,
#662468: There are no strings in the 5.x-1.3 release of getID3() to export.,
#652620: There are no strings in the 6.x-1.1 release of Browscap to export.,
#627856: Backup and Migrate: No strings to export,
#649290: There are no strings in the 5.x-1.2 release of Devel to export..
Comment #4
apadernoComment #5
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedAnd another one #642252: Missing English originals in ImageCache 6.x-2.0-beta10
Comment #6
Gábor HojtsyI did some more investigation in the watchdog logs. I find regular issues with tar.gz files not being properly available (when downloaded they do not appear to be in the tar.gz format), but then l10n_project nicely recovers from this by removing the file and coming back to it later (when it parses it correctly). When the targz fails, it will not go on to try and save strings for the given release, so it might or might not be related. Opened issue at #681344: l10n_project download checking is bugos. That might also catch partially downloaded files though, which tar possibly still uncompresses.
Comment #7
Gábor HojtsyHa, here is a complete list of releases which are in the database but have no strings associated with them. Pretty impressive. Doh. Columns are project+version, release date and parse date. Looks like the date of parsing has no relation to no-string releases (and we are dealing with an extensive problem here, so good idea not to submit an issue for each of these :).
Code to produce this table was:
The key is "l.rid IS NULL", so we know that the given release has no line-string association related to it.
Comment #8
Gábor HojtsyObviously we could try to prevent this by adding some "graceful rollback" code:
- after a release is parsed, look at whether we had any string relations stored (simplified version of above query)
- if not, restore the last_parsed date, so l10n_project will automatically come around to parse it again
- try to prevent this happens in loops forever via a counter on the release record maybe and only attempt 3 or 5 times at most maybe
While this could solve the issue, I'd like to find the real cause of the problem, so we are not wasting computing cycles for doing stuff we throw away quickly after that.
Comment #9
Gábor HojtsyBTW for those interested, the above TXT contains 403 releases listed, that means about 4.5% of all releases on l.d.o are broken (assuming these releases should contain at least one translatable string, which might not be the case for all of them, but most probably for almost all of them).
Comment #10
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedThe incomplete source strings may be interesting yet: #642252: Missing English originals in ImageCache 6.x-2.0-beta10 or #593310: custom_breadcrumbs 6.x-1.5 parsing error
Or a bad release, which is contains only a css, and the licence.txt: http://drupal.org/node/244161 The last one is no l10n_server bug, but in so much relevant, that sends the planned system into an endless loop.UPDATE: I did not read through the counter part first properly.
Comment #11
Gábor HojtsyThere is a patch at #622500: Add hashkey to strings and translations for quicker comparison which can improve the speed of new release parsing (and .po imports!) by 15 times(!) in my local testing. If we are dealing with a timeout issue here, that can be a savior :)
(I've already committed and deployed #681344: l10n_project download checking is bugos).
Comment #12
Gábor HojtsyGiven that I've deployed #622500: Add hashkey to strings and translations for quicker comparison earlier today and given #681344: l10n_project download checking is bugos, we now have better download checking (which already caught a faulty release), I've reset the above 403 (404 by today) releases, so they will be parsed again on upcoming crons. We have 10 releases parsed per cron (with crons twice per hour), so this backlog will be processed in about 20 hours. I'll look at the watchdog regularly.
Comment #13
Gábor HojtsyThis is not yet our silver bullet. Of the first 10 releases parsed, 6 got back to the same broken state where they have last_parsed != 0 but no strings:
At least 4 of them passed the parsing fine. I keep monitoring the situation.
Comment #14
Gábor HojtsyThese are actually completely normal. All of these are either themes (.mobi, B7, etc) or not actually Drupal conformant code (Knowledgetree integration 5.x-2.0). The list expanded a bit with the second round of 10 items but with only 2 items which also are in the same realm. So looks like we do not have reliably reproducible problems here (yet).
Comment #15
Gábor HojtsyAfter all releases are now parsed again, we have 82 not having any strings but parsed:
As said yesterday, it looks like these are mostly themes not using t(), stub projects and/or projects which do not have Drupal conformant code.
There also seems to be a "constant backlog" of these 5 projects which does not seem to be possible to download or are not handled due to some other error (I'm not seeing any issues in cron about these and newly coming releases are parsed nicely):
So unless there are some suspicious projects in the above listings, I'd consider this "mostly fixed for now". I'll keep monitoring what happens with these 5 unparsed projects. Let me know if any of the 82 above should have strings still, in which case we identified a recurring bug :)
Comment #16
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedThese 5 projects have been unpublished.
Comment #17
Gábor HojtsySo given that parent projects for the 5 releases were unpublished, our release downloader will never attempt to download these. Unfortunately our release backlog counter still counts these as being in the queue, so I'm modifying its query to only count releases for projects which are published. Committing this one and deploying on l.d.o.
Comment #18
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedFor example, FCKeditor - WYSIWYG HTML editor 5.x-2.3-rc2 contains a lot of strings.
Comment #19
Gábor HojtsyHm, that is not entirely good news (not that I'm surprised). Will take a stab at trying to kick these into rescanning again, and see what comes out of that.
Comment #20
Pasquallecodefilter-6.x-1.0 no strings
Comment #21
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedwysiwyg 6.x-2.1 - one string
Comment #22
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedadmin_menu 6.x-3.0-alpha4 - only 17 strings instead of 76.
Comment #23
Gábor HojtsyI've kicked off a once-more-run for the no-string releases once again. Currently we had 242 releases parsed but without releases. We verified before that 82 were fine to stay the same, so I assume they'll get parsed and seen again to not contain text.
Also marked wysiwyg-6.x-2.1.tar.gz and admin_menu-6.x-3.0-alpha4.tar.gz for regeneration individually.
Comment #24
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedToken 6.x-1.13 only 42 (correct: 132)
Comment #25
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedtextsize-6.x-1.8
Comment #26
Boobaadiff-6.x-2.0
Comment #27
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedToo many strings! The views-6.x-2.11 contains 1284 strings in the package, but on l.d.o this release contains 1459. I checked some untranslated strings, but they are really not part of this release.
Comment #28
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedprint-6.x-1.12 - No strings found. Important, because this is the current release.
Comment #29
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedMemcache API and Integration 6.x-1.6 - no strings
Comment #30
Gábor HojtsyOk, I've reset parsing of the mentioned token, textsize, views, print and memcache releases. I did not find the mentioned diff module release on l.d.o. A later release is present.
Comment #31
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedThere are no strings in the 6.x-1.4 release of jQuery UI to export.
Comment #32
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedThere are no strings in the 7.x-1.0-alpha3 release of Insert to export.
Comment #33
Thomas_Zahreddin CreditAttribution: Thomas_Zahreddin commentedchanged the issue title.
Comment #34
wojtha CreditAttribution: wojtha commentedDozens of missing strings in Ubercart 2.3 and hundreds in 2.4. UC 2.4 has around 900 string less than UC 2.2/2.3 at l.d.o.
Comment #35
Thomas_Zahreddin CreditAttribution: Thomas_Zahreddin commentedfor Ubercart 6.x-2.4 ~ 1700 strings are missing …
Comment #36
Gábor HojtsyWojtha, Thomas: All right, dropped all strings for both modules (don't worry, your translations are kept), and parsing of the packages should run again in at most an hour. Thanks for the report!
Zoltan: Reset jQuery UI 1.4, so it will be reparsed similarly. Did not find a project called "Insert to export". Are you sure that is the right module name? Do you have the short name of the module (the drupal.org URL that is). Thanks!
Comment #37
Pasqualle@Gábor: http://localize.drupal.org/translate/languages/test/translate?project=in...
Comment #38
Gábor HojtsyOk, reset that release. Thanks for the info.
Comment #39
wojtha CreditAttribution: wojtha commented@Gábor: UC 2.4 has now only 2 strings at l.d.o. Re-parsing at friday probably didn't processed correctly :-(
http://localize.drupal.org/translate/languages/cs/translate?project=uber...
Comment #40
Gábor HojtsyReset again. Now will look closer at what happens with it.
Comment #41
wojtha CreditAttribution: wojtha commented@Gábor: UC 2.4 is finally 100% parsed, Thomas_Zahreddin was right - 1700 strings were missing. Do you know what's happening? Why are sometimes some releases of some modules parsed uncompletely?
Comment #42
Magnus CreditAttribution: Magnus commentedMarked #1017802: Releases broken as a duplicate of this issue.
ImageCache release 6.x-2.0-beta10 is broken. Only 43 strings shows up, should be 131 strings.With the new release of ImageCache 6.x-2.0-beta12 all strings shows up againComment #43
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedThe Memcache API and Integration 7.x-1.0-beta2 and the 7.x-1.0-beta3 contains only 1 string, instead of 19.
Comment #44
Thomas_Zahreddin CreditAttribution: Thomas_Zahreddin commentedno strings for xmlsitemap 6.x-2.0-beta2:
http://localize.drupal.org/translate/languages/de/translate?project=xmls...
Comment #45
Thomas_Zahreddin CreditAttribution: Thomas_Zahreddin commentedall strings for Google Analytics 6.x-3.2 are missing:
http://localize.drupal.org/translate/languages/de/translate?project=goog...
version 6.x-3.1 has around 160 strings
Comment #46
Gábor HojtsyI worked on #1063290: Make parsing messages shorter and more informative and more importantly on #1062120: Add count of source strings to releases and packager so we know have per-release counts of source strings in the database. This will be possible to be used to identify broken releases, but I'd be happy to have a general fix for the issue instead of building tools for the reactive more we are in. Anyway there were 503 releases where no source strings were identified. Note that most of those are valid, they are themes and other projects where people did not care to use any translation API. Well, well. Anyway, I set all these releases back to be re-parsed, so we have all these in the queue now for being looked at again. Now with better reporting and source strings stats tracking, we'll hopefully be able to find why this is happening. It frustrates me as well, let me assure you.
Comment #47
Gábor HojtsyOk, I've also built entirely new release summary pages for localize.drupal.org in #1063550: Add better release information for project inspection which should help us a LOT in identifying and tracking down these issues. Let's take a look at the affected modules/releases:
http://localize.drupal.org/translate/projects/views/releases
http://localize.drupal.org/translate/projects/memcache/releases
http://localize.drupal.org/translate/projects/imagecache/releases
What's stunning and telling us a lot is that (a) all the same files are parsed and (b) source code warnings are identified in them, its just that the strings are not saved. Its pretty interesting. So it does not look like a timeout issue or somesuch, because it actually looks like the files are parsed entirely (at least telling from the same warnings founds for them). The files themselves are recorded the first thing when a file is started to be parsed, and and the releases we find lacking strings the file records themselves are actually stored entirely. Any ideas?
Comment #48
Magnus CreditAttribution: Magnus commentedAll missing strings seems to be parsed quite a while ago and I know there has been a lot of development on the localization server.
Comment #49
Gábor HojtsyWell, the memcache project for example, had a badly parsed release in 2010 Sept and 2010 Oct as well. Not exactly too far away. I don't think the root case is solved for this bug yet.
Comment #50
Gábor HojtsyHere is some data about one broken and the previous same branch ok release for imagecache and views:
The views one shows that the recorded strings are all over the place, BUT when a file is covered, it is covered 100%. The imagecache one shows similar information, the slight difference in number of strings recorded is IMHO due to changes in the release, not because the file was not parsed 100%. So it looks like a file is either included or it is entirely missing, but its not the first few files which are parsed, all files are recorded, so again it is not about the parser timing out.
I've also looked into whether any line information is stored for the given releases, but no line information is stored either. So looking at the code, this should go wrong somewhere between l10n_drupal_save_file() and l10n_drupal_save_string(). The later would not store line and string information if the file it belongs to is unknown. From this, I've realized we don't use the Drupal APIs properly, so submitted and committed #1064542: Use db_last_insert_id instead of custom code, which might help with this issue.
We should devise some queries to find the affected releases systematically, so we can hit regeneration of them.
Comment #51
Gábor HojtsyOk, I devised this query to look for releases which might be broken (ie. they have less than 2/3rds of strings compared to the general average for the given project). Unfortunately most of these are false positives, eg. install profiles which have core and non-core packages, which greatly vary in size, or mostly just modules exploded from Drupal 5 to 6 to 7 in number of strings. If someone is interested to dig this data, I'm happy to provide a non-limited result set, but this is a sample:
Comment #52
Thomas_Zahreddin CreditAttribution: Thomas_Zahreddin commentedhi,
first: thanks very much for all your effort in the project localization server.
i pick the example google_analytics version 6.x-3.2
it was released on 7th of February:
http://drupal.org/node/1053974
it had no strings on 13th of Feb.
see #45
it was parsed also on 17th of February:
with 111 strings
http://localize.drupal.org/translate/projects/google_analytics/releases/...
=> conclusion: yes, this happens also for new releases.
Comment #53
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedVideo filter 6.x-2.8 is empty.
Comment #54
Anonymous (not verified) CreditAttribution: Anonymous commentedHi,
Revisioning 6.x-3.12 is the active version for Drupal 6, and there are no strings for it on the localization server.
Comment #55
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedLoginToboggan 6.x-1.9. Please re-scan this release.
Comment #56
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedAdmin 6.x-1-.0-beta5 - 1 string is missing.
Comment #57
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedI think, the parsed 7.x releases of the Pathauto module is bad. The scanned strings does not match with the reality. I founded more than 30 differences.
Comment #58
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedMollom 7.x-1.1 - 0 strings
Comment #59
mr.york CreditAttribution: mr.york commentedwebform 7.x-3.10 and 7.x-3.11. Please re-scan this releases.
Comment #60
Thomas_Zahreddin CreditAttribution: Thomas_Zahreddin commentedPrivatemsg 6.x-1.5 - 0 strings
Quick Tabs 6.x-3.0 - 0 strings
XML sitemap 6.x-2.0-beta3 - 0 strings
Comment #61
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedwebform 7.x-3.10 and 7.x-3.11. Please re-scan this releases again. Currently both contains 0 strings.
Comment #62
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedtagging-6.x-2.5. One string in missing.
Please, review #1267466: Start over packages without the administer localization server permission for the temporary solution.
Comment #63
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedAdmin 6.x-2.0 - 5 strings are missing.
Comment #64
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedDevel 7.x-1.2 (cca 150 instead of 336)
Comment #65
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedquova 7.x-1.0
Comment #66
Gábor HojtsyThanks to Zoltán Balogh we put in a self-service workaround for now, see http://localize.drupal.org/node/4124. I still think it would be best to fix the root cause, since this should not require manual labour, neither in tracking these down, neither rescanning them. It should work right away... Anyway, we should have a manual way to work around this issue for now until we figure out why is this happening... Thanks again Zoltán!
Comment #67
droplet CreditAttribution: droplet commentedrightly parsed but no strings ??
Why not add a strings count checker or CRON run every night to check it and re-parse it automatically
maybe add directly to l10n_drupal_drupalorg_parse_package before unlink the unzip folder/files
Comment #68
Zoltán Balogh CreditAttribution: Zoltán Balogh commentedAll mentioned releases between #52 and #65 has been updated. In a similar situation please use the Missing strings? link below the releases combo. Its shown only, after you filtered the project and the release. If you don't have enough permission to start over a release, then ask your team admin, or contact me.
Comment #69
Thomas_Zahreddin CreditAttribution: Thomas_Zahreddin commentedFor role_delegation localize server knows
http://localize.drupal.org/translate/projects/role_delegation/releases
only version 7.x-1.0 but not version 7.x-1.1
http://drupal.org/project/role_delegation from june 2011 :-(
any ideas?
Comment #70
Thomas_Zahreddin CreditAttribution: Thomas_Zahreddin commentedmaybe this is a hint:
http://localize.drupal.org/translate/projects/better_exposed_filters/rel...
-> 3 releases
but in the user interface
http://localize.drupal.org/translate/languages/de/translate?project=bef&...
only 1 release!
So any ideas?
Comment #71
droplet CreditAttribution: droplet commentedahh.
Better Exposed Filters moved from bef to better_exposed_filters. "Better Exposed Filters" matched 2 results in DB but only return the first one.
http://localize.drupal.org/translate/languages/de/translate?project=bett...
Comment #72
droplet CreditAttribution: droplet commented@Thomas_Zahreddin,
It's different issue, here's the patch:
#1380682: Fix filter to show enabled project only