Would it be possible to split extractor.php in an interface-part, doing the commandline parsing and http-request processing, and a utility include file?
I was thinking about making a module serving out a pot-file for a selectable module/file(s) in a module, so people willing to help translating could get started easier. Having a include-file with functions for the heavy-lifting would help a lot there ...

CommentFileSizeAuthor
#2 drupal-pot-make-incfile.patch39.43 KBray007

Comments

killes@www.drop.org’s picture

I wouldn't object to such a patch.

ray007’s picture

Status: Active » Needs review
StatusFileSize
new39.43 KB

All right, how about the attached patch?

It does:
- rename all function to share a common _potx_ prefix.
- move them to a file extractor_potx.inc and added a require_once() in extractor.php
- create a new function _potx_process_file($file, &$strings, &$file_versions, &$installer_strings) to encapsulate the processing a single file a bit better
- the 3 extractor_* functions at the bottom of extractor.php were probably the beginning of a module and are left untouched here

what needs to be done: improve status handling to return error strings (or codes) if we don't want random output all over the place.

ray007’s picture

Something wrong with my patch, or just no time to take a look at it?

ray007’s picture

Seems this issue is dead? Or is there anything I can do to get it going again?

gábor hojtsy’s picture

As far as I see, you are about to add a potx.module to contrib CVS, and this is a preparation to that. Given this development, it probably would be better to move this code to that module, so we have a place to submit issues/patches against the code (having the module code in two places would be confusing, hard to install, and harder to maintain). That way you would have write access to the extractor code. I would prefer to be maintainer of that project, you being a core maintainer, so we can still keep a close eye on the command line extractor functionality important for Drupal core.

That said, the patch seems to be fine, although only a first step. Given a module to extract strings, the web interface component of extractor.php would be extraneous, so it can be removed (after the module is useable). The command line interface is still required though.

About the functions at the bottom of extractor.php, they are definitely not a beginning of a module. See the comments above them:

  return;
  // These are never executed, you can run extractor.php on itself to test it

So what is a possible way forward? If it is OK, I can create the potx folder in CVS and the project, assigning you as a comaintainer. I can then commit the changed extractor code there, so you can come and add the module. I would add a remark to the README in the translation templates and to it's project page that the extractor functionality was spin off to a separate module.

ray007’s picture

Sounds good to me.
Not sure if "potx" is a good project name, I just took it as short prefix for "pot-extractor". It's not a bad name either, but if you have a better idea feel free ;-)

gábor hojtsy’s picture

Project: Translation templates for Drupal core » Translation template extractor
Component: Miscellaneous » Code
Status: Needs review » Fixed

OK, I think potx is a cool name, "extractor" is too general to be a module name. I have created the potx project, branched it off for Drupal 5.x, so we can develop stuff there (do not use HEAD for new feature development). Comitted your patch, added lots of code comments, cleaned up the command line script, so that it does not deal with "over HTTP" communication anymore.

Your module is the next step! Don't hesitate to commit it. I have added you (ray007) and killes@www.drop.org as comaintainers, so you can commit to the project.

Your patch with the cleaned up code comitted: http://drupal.org/cvs?commit=61372
The potx project: http://drupal.org/project/potx

gábor hojtsy’s picture

BTW I also tested the new potx-cli.php script, and it generates the same POT files with the same content for Drupal 5.1, so it is fine to assume that it works just like it worked before, and we did not broke it.

Anonymous’s picture

Status: Fixed » Closed (fixed)