Only skip potx files when really needed
FrankT - July 24, 2009 - 15:37
| Project: | Translation template extractor |
| Version: | 7.x-1.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Gábor Hojtsy |
| Status: | closed |
Description
I updated the translation to match 6.x-3.0. Especially there's been a bug within the translation of 'Template file for !langname translations' which contained a wrong variable, additionally the translation made no sense, too. Also fixed only a very few minor things.
| Attachment | Size |
|---|---|
| potx.de_.po | 5.21 KB |

#1
Can you please commit this yourself?
#2
I do not have an account to write into CVS (and I had no time to learn about that to avoid any mistakes making commits), so usually I provide the translation and a maintainer submits it (I've translated dozens of modules like that)...
#3
Because of the wrong variable that is in the translation so far, I make this a bug report... Please commit the new translation to CVS. Thanks!
#4
Seems an incomplete extraction / POT file used. POTX themself requires some special extraction... I'm able to create a new POT later.
#5
Could you tell me what special treatment is required, for the future!?
#6
The problem is that potx.inc and the potx-cli.php files also have translatable strings, but they are excluded from extraction. This is why it's only possible from command line to extract *all* translatable strings from POTX module. You need to manually specify every single file.
#7
@hass: There is a @todo in the code to fix this. The reason it is excluded is exactly on the command line automated extraction, when these files are in the webroot but should not be parsed as part of Drupal core. It would be great to only exclude them in this case and when a web based on API based export is done, they would not be excluded.
#8
I know you have added this after my request :-). It's also for module extraction... we may need a check like
if ( extraction not from potx module, exclude potx files). Not only for core.#9
I have an idea... a simple check could do a
file_exists('potx.module')... should be save enough... maybe check for all potx files to be 100 %save. For extraction users should only have potx.inc and the potx-cli.php in the current folder.#10
I've developed a fix which skips the potx files only if the automated file discovery was called from the command line. If it is from the web interface, it is purposefully with a path that either includes potx or not and we should not treat potx different in that case. This should also fix localize.drupal.org not parsing potx right. We need to make the code work to be able to parse potx as an API.
Patch should be applicable to both 6.x and 7.x given the same potx.inc and command line code.
#11
I cannot follow this patch... should I now add an extra param always if I use POTX on command line? I cannot see any new option added to the patch that enables skip = FALSE as it need to skip always and only do not skip if POTX is parsed themself.
#12
The patch makes potx parse potx by default (when run under l10n_server or on the web interface of a Drupal install) and only skip potx files if running with potx-cli.php without --files set. So --auto (which is the default for potx-cli.php) will still skip potx files, but I'm not assuming any significant number of people use that to generate a potx template anyway. People will use the web interface (short term) or the centrally generated (l10n_server output) template from localize.drupal.org.
#13
Ah, ok. Aside - maybe I missed something, but does the l10n server supports splitted files per module?
#14
@hass: not sure what a "splitted file" is. l10n_server parses all files with the supported extensions under the module with the exception of files under a subdirectory tests/ and *.api.php files. Can you or @FrankT confirm that the patch works for extracting potx strings from the potx web interface?
#15
With splitted POT files I mean one pot file per modules submodule, a general.pot and a few others in the main translations directory combined into a ZIP. Therefore not only one big pot file having all strings. I will try to run this on CCK and see what will happen.
#16
@hass: this question has nothing to do with what files potx actually parses.
#17
Committed to Drupal 6-x-3.x.
#18
Also committed this to D7, since it applied straight.
#19
Automatically closed -- issue fixed for 2 weeks with no activity.