Future of POT generators

One of the first big problems that I faced when I started with WordPress was how to generate  a POT file. In the meantime have been able to look at all of the different tools and see their shortcoming with challenges that I faced when generating a POT file.

Challenges with POT generation

Recently I have been working on projects where the POT file generation needed to be different. Here are three examples:

I was working on Responsive and Responsive Pro. Responsive is currently translated in about 45 languages. A large majority of the strings in Responsive Pro were already translated in Responsive. So to reduce the workload for the translators I created a separate POT for the pro folder which is only in the pro version.

Another example from CyberChimps where we use a framework for all of our themes except for Responsive. The framework is the core folder and it is in every theme. If we created the POT files the standard way then we would have all of the same strings across all of our themes which would create extra work for the translators. We could use a constant and define that in the functions.php but it is not allowed in the current WordPress.org theme review guidelines. The core has it’s own text domain, pot file and translations.

A third example that I came across is when using TGM Plugin Activation. TGM Plugin Activation has it’s own strings with it’s own text domain tgmpa. With the current POT generation solutions the strings will be added to the POT but the translations will not load as the text domain is never loaded. A solution could be to just to load your own version of the strings with your own strings. I know a number of plugins and themes use this library. TGM Plugin Activation should load it’s text domain and have it’s own language folder. We as a community can contribute to it and then themes and plugin are able to profit from the standard strings being fully translated.

Shortcomings of current generators

I also find makepot.php is too narrow minded to use as it expects that the folder name is the same as text domain. There are multiple times where it is not so in developement. I develop the Flowplayer HTML5 WordPress plugin and the GitHub repo is named wordpress-flowplayer as it make sense to separate it from the Flowplayer player GitHub repo which is part of the same GitHub organisation. So when I use makepot it thinks the text domain is wordpress-flowplayer instead of flowplayer5 which is the WordPress.org plugin slug. Another case would be if when developing a plugin in the same WordPress.org svn structure. The main plugin is most times in the trunk folder and makepot.php would then think that the theme slug should be trunk.

Poedit Pro handles text domains great. It check for the header info Text Domain and uses that to define the text domain. It currently supports the WordPress translators comments but the not the plugin or theme meta data yet. This is still a very manual process of creating the POT. It also uses the folder structure to choose the files where the strings are pulled from.

Both makepot.php and Poedit use the location of the files when choosing which strings to add to the POT but neither solution can yet exclude folders.

In November 2013 Stephen Harris released a new solution grunt-pot. I was really pleased with this solution as it includes an option to define the files that you want and do not want to scan. The thing that is missing is that it does not support fetching WordPress meta data and translator comments.

Future POT generator

The perfect POT generator  for me would be one that used the text domain to choose which strings get added to POT file. The solution would need to able to define the location of the files, text domain, and the location of the language folder. For WordPress it would be very important that the translator comments and plugin/theme meta data are also included in the POT. The solution should be built using grunt as it works with every OS can be easily integrated in a build workflow.