It’s not you, it’s me
Let me get the obvious out of the way, so that we can focus on what’s important in mending this relationship: I love you, I do. The way you blend into my site’s dashboard sends shivers of joy every time I open your settings page, and your Ajax-powered search and refresh make me swoon like a teenager anticipating getting to third base for the first time in his life. I was even a little naughty and looked at the source code and was amazed at the simple and efficient beauty of what is… erm… under the hood.
Truth be told, this may very well not even be a problem in our relationship, specifically; I suspect that, should I ever get as intimate with a plugin as I have with you, I would most likely have the same issues and suffered their same indifference (feigned? deliberate? unconscious? We’ll never know) in silence. My brief affairs with many other plugins made me often suspect that they too had a problem, but the one with you is one I don’t want to abandon: we’re meant to be together, and I can’t delay opening my heart to you any longer, nor can I any longer just hint at it with simple remarks on GitHub. Tough love, they call it.
You have a problem with .pot
Look, I understand: the happy buzz of seeing your code running in hundreds of languages is irresistible. I bet it gives you the munchies, even. And you’re doing it right, too: there is the soothing call to load_plugin_textdomain
, and a sexy /languages
folder.
But…
- It’s true that that you even have proper
job_manager.pot
file, but sadly, it is not properly named, i.e. it should match the plugin’s slug. Notice “should” and not “has to”. I don’t mean to be fussy, and I’ll just say that this is really Otto’s fault, who has much higher standards than myself, all with his language packs and things. - He’s also the one who would tell you to add
Domain Path: /languages
andText Domain: wp-job-manager
in your code’s header. Not I, oh no! I know you would have to change every single_e()
and__()
call’s textdomain fromjob_manager
towp-job-manage
r, and how that would mean slower updates for me. He means well, but I like updates.
Relax, I’m not breaking up with you. At least not as long as we can talk about the way you’re growing your .pot. You see, every time you update, and even though I translate every single string there, I still see many strings in English. This, in turn, invariably makes me suspect that the .pot is old, dry if you will, and forces me to run makepot.php
on your code every time, and every time it results in a .pot that’s different (fresher!) than yours. Lo and behold, if I translate that new file, everything shows up as it should, in that sweet, sweet Portuguese that you like so much.
We can fix this as if it were 4:20
It’s really, really simple: you’re a modern, independent and strong-willed plugin, and I’m sure you use Grunt or some other build tool which embraces your .less
and cuddles your .js
, right? If you don’t, you can always use a cron
or even do it by hand, but the important thing is to automate the harvesting: in other words, before new code gets committed, every single time, the .pot needs to be updated to reflect it. Automation means set once and forget, and it will make the rest of the non-English speaking world eventually fall for you in the same way that I have: hopelessly.
xoxo
Zé
Update:
It looks like you were listening after all, and there I was thinking that your sudden interest in Arsenal’s score was but a ruse to not having to think about it. For those interested, here’s what happened to the plantation:
- Textdomains were updated
- Translation files were renamed
- Plugin headers were added
- Also (even if it’s not visible on GitHub), automation was implemented to run
makepot.php
before any commit. This is done via a pre-commit hook (how modern!), that runs a script based on this very smart solution by John P. Bloch.
We have fresh .pot!
Hey, did you notice that add-textdomain.php tool in the same place as the makepot.php file? It’s kinda cool too, you know…
See, Mike? Didn’t I tell you about Otto? Didn’t I?