Fuzzy .mo compilation in buildout

Hi all,

Is there a setting I could use in buildout to have fuzzy terms included in the compiled versions of .po translations?

We maintain our translations in pootle. Whenever I sync newly translated terms with plone, I use a simple shell script that includes
/usr/local/pootle/bin/pocompile --fuzzy ./cs/LC_MESSAGES/my_theme.po ./cs/LC_MESSAGES/my_theme.mo for each of the affected languages to update the compiled language files which Plone uses.

However it's has proven to be a PITA for me to remember to include this step consistently (my forgetfulness results in befuddled users) after re-running buildout. It would be handy to be able to configure this setting in buildout...

Add that step to the script you use to sync the translations?

Hi Roel! You mean skip the .mo compilation in buildout and add my script to automatically run after buildout has finished? Pragmatic, could work :slight_smile:

Yep, that's what I went.
Maybe zest.pocompile works as well, though I haven't tested that.

Looks like the only option available on the command line is to do a dry run. Unless @mauritsvanrees chimes in with an alternate idea I'll follow your suggestion!

Edit, there is an import from python-gettext msgfmt.py - which explicitly excludes fuzzy from compilation.
https://github.com/hannosch/python-gettext/blob/master/pythongettext/msgfmt.py#L104

No, I have no alternative idea.
Well, you could remove the fuzzy markers from the .po files, and then compile it.
Perhaps in a workflow like this:

  • Remove fuzzy markers from .po files, probably with a small bash or Python script.
  • Commit this to git.
  • Compile to .mo, make a release (zest.releaser in combination with zest.pocompile helps here).
  • Revert the commit, so the markers are restored and translators can check them.

Personally, I don't want fuzzy translations to be included: when the original (English) message has changed, a translator should check if the existing translation in his or her language needs to be updated or is still accurate.

1 Like

I hear you, in a perfect world this would be the way to go. Unfortunately, it would add a lot of complexity (and discipline) to our current workflow; the corpus of terms which occur in our custom theme can now grow without (me!) having to do a complete release - just by synching pootle with plone and restarting the zope instance. Any maybe suboptimal translations, which the editors deem "good enough for now" are marked fuzzy and end up being used in zpt templates, vocabularies and such...