Add a hook_localize()
fgm - September 4, 2008 - 10:19
| Project: | Translation template extractor |
| Version: | 5.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Description
Something which would be valuable to module writers would be a way to have modules export strings besides the automatic extraction from t() calls which potx performs.
It could look like a simple hook like:
<?php
function foo_potx_strings() {
return array(
'whatever module foo',
'wants, and ' . foo_however(),
foo_it_wants::toGenerate($_foo_them()),
);
}
?>If, like me, you think this is valuable for potx, I could try to add it to the existing module.
This would be especially interesting for Drupal 6 and above, since this rarely used function could be placed in a specific file, which would only be loaded when needed. It would at long last break us out of the "inline hardcoded strings" model.
#1
OK, I did a proof-of-concept patch for version 5.2. Hook is called hook_potx() and just returns an array of strings that need to be translated, tested with a module of mine which uses class constants like:
<?phpclass Foo_Bar {
const TR_MESSAGE = 'An individual translatable string';
}
// ....
return t(Foo_Bar::TR_MESSAGE);
?>
Current situation with this patch:
- The strings end up properly in the PO file,
- They are identified with line number 0 and the name of the module instead of the name of an actual file
- Each call to t(
<one_of_these_constants>) causes a warning in the current version of potx during extraction, but does not cause it to fail- At runtime, the string is properly translated.
This allows use of t() with named constants, be they such class constants or traditional
define()constants. Any opinion before going further (hopefully by removing the warnings in potx) ?#2
This was suggested a few times. The problem with introducing such a hook is that translation teams work with potx in the static code analyzer mode (eg. parsing source code not running on the site itself). The Localizations server uses this mode to allow translating all contrib modules. If all these contrib modules would need to run in the Drupal instance potx is running, we'd need a site running a thousands of contributed modules. This is not going to work.
So having a function you never call with t() calls in them was one workaround people used so far to get static strings into the generated templates. And you can of course add that to a never included .inc file, potx does not see whether you include it or not. Strings generated runtime are not the job of locale module to translate, so potx is not going to work with them.
#3
#4
The workaround you suggest is indeed workable and useful.
However, I noticed you set the issue to CNW instead of Won't Fix. Do you think there is still some merit to the idea, probably implemented differently for the reason you suggest ?
#5
I think there is a lot of merit in the idea of feeding potx with strings to translate, but I am unsure on the way we should do it. The workaround used is quite hackish.
#6
Maybe for localization servers we could use the mechanism found in simpletest: activate and deactivate modules on the fly. All it takes is knowing whether the module needs to be loaded outside the localization requests. Or, turning the problem on its head, strings generation could be done upon install if the instealler finds potx active.
#7
Here's a slight variation that might address some of the issues.
Modules can have a modulename.potx file. We add potx to the list of supported extensions and write a processing function for .potx files. A modulename.potx file has just the same hook function suggested. But because we've determined the modulename from the file name, we don't need the module enabled--we simply include the file and use
module_invoke($filename, 'potx').Initially, at least, we have the following restriction: the code in
hook_potx()cannot call any module methods. It's similar to code run athook_boot(). (Except that we can assume a fully booted Drupal?)@Gábor Hojtsy: Would this address the issue of not enabling modules?
@fgm: And from there we could return to the idea of enabling and disabling modules, thus allowing them access to at least their own methods.
#8
Here's an untested patch implementing the approach I sketched out in #7.
#9
Something that needs to be taken care of for automatic enabling/disabling is the dependency chain from the .info: enabling all dependent modules, then disabling them if they weren't enabled previously when extraction ends.
#10
#317432 Add a hook_localize() identifies an occurrence of non-user-input translatable variables in Gmap module that should be solved by
hook_localize(). The issue is 'postponed' pending the resolution of this issue.#11
The problem with proposing any running code again, is that potx runs as a static code analysis tool (outside of Drupal) on the command line, and modules such as l10n_server use potx just like that again. It is possible that an l10n_server runs on Drupal 5 and needs to parse Drupal 6 or 7 source code for translatable strings. Otherwise we'd need to run servers for different versions of modules separately. Huh. So since you cannot include Drupal 7 or 6 code in a Drupal 5 runtime, this hook would run most of the time unnoticed. See again comment #2.
#12
@Gábor: thanks for the additional explanation. indeed, this won't work :(.
#13
Not gonna happen for the reasons explained.