[wp-hackers] Handling Plugin translations
TobiasBg
wp-hackers at tobias.baethge.com
Sat Jan 9 10:21:50 UTC 2010
Hi Dion,
for my plugin WP-Table Reloaded, which currently has 15 translation (of which 6 are out-of-date), I usually do it this way:
I try to change/add strings only for versions with new features (i.e. X.Y), while for bugfix releases (X.Y.Z) I try to not change any.
So far, feature releases X.Y have been published about every 6-8 weeks.
About 10 days before my scheduled publish date I start a public beta test (with a blog post announcement), which also means a "string freeze".
And I email all translators (all recipients in BCC) with a link to that post and asking if they would update their translation. In the post I usually add things to look out for (i.e. newly used translation functions, like _x in WP 2.8).
10 days is a pretty good time span, as it usually has 2 weekends in between, which is enough time for most translators.
About 3 days before the release date I send out a "Reminder" email to those translators that have not responded yet.
Translators then email me their po and mo file. I usually quickly test them (just to see if they are loaded correctly and strings are translated) and then commit them to the code repository. Additionally I have a small text file on my desktop with a list of received and not yet received translations that I update accordingly to keep track :-)
Within every release (also the betas) I include an updated pot-file (generated by wp.org extend), as some translators use poEdit with that. Some also update from the source directly. And some use the "Codestyling Localization" (http://wordpress.org/extend/plugins/codestyling-localization/) by Heiko Rabe (a plugin that I also recommend, and use myself, for the translation in the mentioned blog post as it is very easy for new translators to use).
With the latest plugin release, I have now started to set translations that were not updated in a while to "inactive".
This means that I don't include them into the final release, but in beta or dev versions (so that already translated strings are not lost forever, I just does not make sense to include them in the final, as the translation is not very useful, if it only covers half of the plugin).
As mentioned above, I had to set 6 of the 15 translations to inactive. That just happens. In two cases the translators email addresses are no longer existing, and in the rest they just don't respond.
> Personally i've taken the "Release new plugin, Let translators submit
> updated translations for the next release" approach, But i feel this is
> not the best way.. In my mind, it makes the translators less likely to
> want to help out in the future..
I don't like this approach. Translations will always be outdated by one version (to the plugin users).
With my approach, I have the feeling that the translators feel more involved, especially because they also are the first ones to have new features (in the beta) available.
> I was considering installing GlotPress and maybe getting people to update
> them there directly, Has anyone else taken this route?
I would really love to do that, but unfortunately GlotPress is not (yet) ready for that. I would love to test and play around with it, but unfortunately have severe problems, especially because of this issue: http://trac.glotpress.org/ticket/26
Regards,
Tobias
http://tobias.baethge.com/
More information about the wp-hackers
mailing list