in the packaging script for the new release system (http://drupal.org/node/88056) we don't currently handle translation status at all. see especially http://drupal.org/node/88056#comment-144641.

we need to get this working again fairly soon. what killes and i had previously discussed was:

  • store that info in the DB, not a flat file
  • add a simple little project_translation_stats.module that displays the info from the DB into a human-readable table at some fixed menu location

of course, we also have to modify the packaging script (modules/project/release/package-release-nodes.php on DRUPAL-4-7--2 branch) to compute the status and store the data...

i can certainly help with the packaging script side. anyone care to work on project_translation_stats.module? ;)

Comments

dww’s picture

Comment #1

dww
we/he/they
commented

for the record, here's the page i'm talking about that the project_translation_status.module would have to generate:
http://drupal.org/node/13236

gábor hojtsy’s picture

Comment #2

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

What is the code used to generate the stats page now? That should be used as a start I guess.

dww’s picture

Comment #3

dww
we/he/they
commented

i don't know, i don't have php filter rights on d.o...

killes@www.drop.org’s picture

Comment #4

killes@www.drop.org commented

the Drupal page node only includes a textfile which is generated by the packaging script using gettext tools. I think I'd like to keep it that way since a module woudl have to run a lot of code through shell commands.

dww’s picture

Comment #5

dww
we/he/they
commented

to clarify, the original design was:

  1. packaging script still does the gettext calls (since it's already doing everything else)
  2. instead of stuffing into a text file (or series of text files) it stuffs the answers into a DB table (since it's already talking to the DB)
  3. the new module just queries the DB for this data and displays it, instead of messing with the file system or shell commands at all.

is there anything wrong with that approach? i don't think so...
-derek

gerhard killesreiter’s picture

Comment #6

gerhard killesreiter commented

I am ok with this approach. We only need to find out how to proceed with existing tarballs.

gábor hojtsy’s picture

Comment #7

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Version: 4.7.x-1.x-dev » 5.x-1.x-dev
Priority: Critical » Normal
Status: Active » Closed (fixed)

My SoC project moves this functionality to the localization server, so this gets fixed elsewhere. Closing.