Add a latest translations and a top translators block
Dave Reid - June 12, 2009 - 17:35
| Project: | Localization server |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Dave Reid |
| Status: | needs review |
Description
It's helpful for me to see the latest translation activity and who my top translators are. Plus, I think having these two blocks helps out the 'community' aspect as it recognizes both the top contributors and the people who have recently helped translate. It also gives me a chance to help glance and quick review the latest translations.
I could probably spruce these up a little more with configuration options and I'm not sure if I can link directly to the page for a specific translation string. But it's a start and I'm running these blocks on project.davereid.net just fine!
#1
Patch attached for review. Sorry, my IDE auto-corrects trailing whitespace, so there's not too much I can do since I don't like to disable it. :)
#2
+1
yes, especially a core committer should use a text editor which automatically removes trailing spaces. It is really bad to create and read patches like this. This is the no 2 reason when I want to contribute but I refuse to.. no 1 is the limited time..
#3
You can make SQL queries on the PHP block. It's easy ;)
I think more useful to integrate in the VotingAPI (see at: http://drupaler.ru/translate/download)
#4
@pvasili: I know that I can create an SQL PHP block, but it would be nicer if the module could provide these blocks. Using an SQL PHP block is not easy for end-users. Using VotingAPI and your links have nothing to do with this feature request either. Please create a separate issue report.
#5
The idea looks cool. However, to make this work on heavy duty sites like localize.drupal.org, we need to cache this data heavily.
#6
subscribe
looking for adding counters for suggested+approved+declined+notapproved_suggestions for every user too...
#7
@Gábor Hojtsy,
I think that implementing some cache clearing for native block caching may be enough. Administrators can enable the Block caching.
The default
BLOCK_CACHE_PER_ROLEis suitable. We only have to implement:cache_clear_all('l10n_community:latest_translations:', 'cache_block', TRUE);cache_clear_all('l10n_community:top_translators:', 'cache_block', TRUE);
where the table
{l10n_community_translations}get INSERTed/UPDATEd/DELETEed.#8
@claudiu.cristea: given how often that table changes, that would be almost identical to no caching. We need to accept some staleness of that data at least. Maybe even include the date of generation in the block and leave it stale for a day or so.
#9
one day - is a good period for recalculation...
#10
#11
This patch add caching to #1.
#12
Ups... There was a bug in the above patch...
Check this one...