The reload mechanism is independent of the development server features, it only uses the request_started signal and pyinotify features. So I expect that it should work, and after testing with uwsgi it seems to work fine.
My hesitations regarding use in staging/production were (1) I hadn’t tested it and had only thought about it as a development feature and (2) I’m not sure what pyinotify/inotify is doing at a system level and whether there might be problems for long running servers e.g. are there resources that might not be cleaned up properly in some circumstances? Are there some system calls that might block sometimes. But this is just my lack of knowledge, and for myself I think for staging it would be OK.
Current behaviour is that first one found is the winner. The app folders are searched in the order found in
INSTALLED_APPS, as per the Django convention for templates, static files etc. (I just pushed this change to django-ftl, I had it reversed before).
The idea is that apps would normally namespace their FTL files using the same convention that Django apps usually have e.g. for templates, the Django admin
change_form.html template is found at:
With this convention there would normally not be clashes, but the mechanism can be used for overriding.
My idea was that often projects would have multiple independent
django_ftl.Bundle instances. For example, if an app like django-wiki used Fluent and django-ftl it would have it’s own
Bundle instance which would list only FTL files for that app, inside a
locales/wiki/ directory, and use that bundle in all its templates and code. (This is different from the current Django gettext implementation where all the messages from different apps get combined).
This method doesn’t provide an easy way for a project to override just a few of an apps messages.
For that, we could change the behaviour so that in the case of multiple FTL files with the same relative path we would combine them all in order (using the same
INSTALLED_APPS ordering). Messages/terms defined in earlier files would get preference, because
fluent.runtime throws out the later messages in
FluentBundle.add_messages. I think this would be a helpful change, and not hard to do.
My idea was that all FTL files would live in the repo, based on the fact that this seems to be how current Django apps do it with gettext.
I was then hoping to get translators to use Pontoon to edit their translations - it seems to be set up to deal with repositories in that way, although I struggled a bit with understanding it. I also found that the editor on Pontoon often didn’t work well with more complex FTL messages (bug list). Another option would be integration with something like transifex, but I don’t know if they have even heard of Fluent.
For the time being I may manage everything using VCS and a manual process for sending files back and forward to translators, which will be OK for my very small project (compared to Mozilla standards).
I’m definitely a beginner in this regard - I’m needing to i18n an app for the first time, for a side project, and that’s why I’m working on Fluent. In fact, if I had used gettext etc. extensively in the past, or this was a project for a client, I probably would have stuck with gettext. I’m using Fluent instead because for a long time I’ve been aware of the limitations of gettext and I thought if I’m going to invest in an i18n solution it should be a good one!
So, your input on translator/developer workflow is definitely appreciated!