A PR to make compilation of mo file optional?

[nealtodd]

As far I can tell, when a page of translations is saved in Rosetta the mo file is automatically compiled.

If it's automatically complied then, even if rosetta_settings.[U]WSGI_AUTO_RELOAD is False, a restart of the application outside of Rosetta will result in the translation going live, e.g. a restart as part of the application deployment process.

I have a use case where it'd be preferable for the mo file to not be automatically compiled: Translations need to go live in bulk as part of a scheduled 'translation deployment', but not inadvertently made live piecemeal as a result of day-to-day code deployments (which restart the application).

Is there interest in a PR that adds an Rosetta setting to make compilation optional? If so, I'll make it.

The setting would be called something like rosetta_settings.AUTO_COMPILE and default to True for backwards compatibility.

With this setting in place I think all that'd be needed is to use it in an if-block around this code which does the compilation and, optionally, auto reloading:

https://github.com/mbi/django-rosetta/blob/develop/rosetta/views.py#L164-L186

(do point out if there's anything I missed, I haven't looked in detail yet).

[mbi]

Hi Neal,

thank you, this sounds like a reasonable suggestion, I'd definitely accept a PR, especially if it includes documentation and tests ;)

Regarding the scope of the change, I was wondering whether the post_save signal should be fired, regardless of whether the mo file was compiled or not. Also I will eventually remove the [u]wsgi reload mechanisms, as that should probably happen inside signal handlers rather than being in the core view, what do you think?

[nealtodd]

Thanks Marco.

Yes, I agree, the post_save signal should be outside the if-block so it always fires.

I can see that moving the [u]wsgi reload into a signal handler makes sense, as it is a secondary action of saving the po. It separates out the logic and also gives a way for a developer to swap in their own reloading mechanism by disconnecting the handler and registering their own.

If the compile step stayed in the view, and there wasn't another AUTO_COMPILE if-block in the handler then it'd do the reload if [U]WSGI_AUTO_RELOAD was True but AUTO_COMPILE was False. No great issue there I guess, and it does completely decouple the two settings (I can't imagine one at the moment but maybe there are use cases for not compiling but still reloading).

I'll make a PR keeping the reloads in the view ready for a signal refactor (with docs and tests
bien sûr :) I have some upcoming client time to work on it.

[mbi]

👍 awesome, thanks!

[gabn88]

While creating this, maybe also add support for django-statici18n?

It is nothing more then calling ./manage.py compilejsi18n after ./manage.py compilemessages. However I don't know where rosetta does the compilemessages call.

[mbi]

@gabn88 Rosetta doesn't call compilemessages but instead "natively" compiles the gettext pofiles using polib. If you would like to automatically regenerate the statici18n catalog whenever Rosetta recompiles the catalog you could simply listen for Rosetta's post_save signal and programmatically fire off the management command.

That said, why would need to do that? The static JavaScript catalog hasn't changed and doesn't need to be updated, simply because the gettext catalog was saved, or am I missing something?

[gabn88]

I use rosetta also for the translation of my javascript files. Thus if anyone translates my javascript files (djangojs.po) I would like to have them compiled into djangojs.mo and also automatically generate djangojs.js files. This is what compilejsi18n already does, so attaching it to the post_save signals works fine. Thanks!

[gabn88]

Ah, doesn't work, as the management.call_command ('makemessages') is not in the right path :(

Maybe I have to write a polib part as well... will look into the code!

[mbi]

Closed via fa1eab7, thank you @nealtodd!