[wp-hackers] Using constants for text domain

Otto otto at ottodestruct.com
Wed Nov 27 19:46:57 UTC 2013


On Wed, Nov 27, 2013 at 8:03 AM, Justas Butkus <jbutkus at time.ly> wrote:

> Given that we generate the POT files on our own (extending existing tools,
> i.e. MakePOT) - these issues seems to be related only to building of the
> release package, and not running the script itself? Or am I still missing
> something?
>

What you're missing here is that your wrapper system required you to build
a whole extra process to build the POT files yourself instead of using
standard tools that somebody else built.

If you want to manually handle your translations, then that's fine and you
can do it how you please. I'd prefer to not have to handle my own
translations, and to use standardized tools to let me crowdsource them. Or
even better, to offload the whole process to WordPress.org and gain
benefits like speed and smaller filesizes.

Imagine a system where the WordPress.org plugin/theme directory
automatically scans all plugins/themes and builds POT files for you. Then
it uploads them into a GlotPress instance, allowing translators all over
the world to work together to build various language packs for them.
Strings used in one plugin/theme can be quickly translated in a different
one, through suggestions generated by textual similarities. A big database
of all strings used in all plugin/theme code, with translations provided
and approved by the user communities themselves. Automated PO/MO file
generation. Automated updates to users, separate from the plugin/theme. No
more bumping versions just to get updated language packs out there.

For such a grandiose system to actually work, those __() function calls
need to be machine-readable. No PHP variables. No PHP constants. Just plain
strings. C'mon, work with us here.

-Otto


More information about the wp-hackers mailing list