#23321: Remove .mo files from the Django Git repository
-------------------------------------+-------------------------------------
Reporter: Claude Paroz | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: | Version: dev
Internationalization |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Someday/Maybe
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Ningú):
If one reasons about this as if we were speaking about a C extension, I
think all those points made by Jannis Leidel do fall pretty short:
- Yes, people working on a repositoy checkout instead of a public release
will need the compilation toolchain. Yes, there will be sharp edges on
certain platforms because of this and that is out of reach for the Django
project.
- Yes, the test system ought to compile those binaries each time. If that
ever had a significant impact on CI times, just engineer a cache for both
those files and the toolchain setup.
- Yes, you need a writable filesystem to develop on a project. Whoever
ships a Django checkout on a read-only FS should be responsible for
compiling *.mo files before turning the FS read-only.
- Yes, the release manager also needs the compilation toolchain. If that
is cumbersome, just produce the packages on a CI pipeline; the release
manager can then download, verify, sign and publish those if your workflow
requires that. Otherwise just publish them from the CI as well!
Replacing gettext with babel might alleviate some of this but IMHO that
should exclusively be a a build-time dependency and never a run-time
dependency, just as gettext. A lot has been going on in the packaging
scene since Claude's PR, but now I'd depict this as a build-system
requirement
`
[build-system]
requires = ['setuptools>=40.8.0', 'babel>=2']
build-backend = 'setuptools.build_meta'
`
and then tell the build backend (not necessarily setuptools) to produce
*.mo files when building a wheel distribution. Either gettext or babel
would be a requirement to build either a Django checkout or a source
distribution. This would be a better fit for PEP-517 and require less
documentation than reminding people to compilemessages before installing
or packaging Django while tox could be responsible for producing *.mo
files in the CI. But maybe this is an over-engineered idea.
I have a sense this is not addressed because of certain FUD while
obviating real recurring "mo and po files out of sync" issues in the whole
django ecosystem https://code.djangoproject.com/ticket/8732 . Yes,
contributors will be pushed a new build-time dependency if they expect
their non-wheel installs to be localized. As it should always have been!
Translators should be familiar with gettext anyway, irrespective of their
platform.
--
Ticket URL: <https://code.djangoproject.com/ticket/23321#comment:12>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018a504448ab-ef26fe07-23a2-41aa-a853-bbc39924dc45-000000%40eu-central-1.amazonses.com.
