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 ...
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | drupal-pot-make-incfile.patch | 39.43 KB | ray007 |
Comments
Comment #1
killes@www.drop.org commentedI wouldn't object to such a patch.
Comment #2
ray007 commentedAll 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.
Comment #3
ray007 commentedSomething wrong with my patch, or just no time to take a look at it?
Comment #4
ray007 commentedSeems this issue is dead? Or is there anything I can do to get it going again?
Comment #5
gábor hojtsyAs 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:
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.
Comment #6
ray007 commentedSounds 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 ;-)
Comment #7
gábor hojtsyOK, 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
Comment #8
gábor hojtsyBTW 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.
Comment #9
(not verified) commented