> What do you think about implementing something like this?. -1 for various reasons, see below
> This way we would reduce the final Django distribution file count > removing abandoned translations (some of them translations that > weren't even touched since added). That’s a non-issue to me, translations are integral part of the product we call Django, and the files are simply a cost of that feature. That said, I could see the PO files and MO files being removed from the Git repo to be only pulled from Transifex as part of the release process (while providing a script to master users to do the same if they really want). I’ve also thought about even only shipping the PO files in the release tarball and compile them during installation like Mercurial does it. That implies the availability of gettext of course or a pure Python implementation of the compile script. > We can post an announcement now early in the 1.7 dev cycle to give > people time to react and perhaps this can even serve as a motivation > trigger. > > If deemed a good approach, we can discuss the value of n and what to > do with L10N formats.py files that accompany to-be-removed > translations. > > To avoid this occurring again we also could raise the bar and > implement a workflow like: We accept only new translations by teams of > at least m translators and with a translation coverage of n%. The workflow hasn’t been officially documented, but there *is* a threshold for when we add new languages to Django. It just never was openly discussed a lot since it was mostly Malcolm and me doing it. My rule of thumb is if I see activity in a language and the translators are responsive or otherwise engaged in translating Django it can be as little as 40% that needs to be translated to be merged. That’s mostly because there are main areas of need for translations, e.g. admin and core, that have the highest visibility to users, but some are only minor, e.g. the other contrib apps. > We can keep all the teams/languages on Transifex so they can have a > hub where work and coordinate. But skip pulling the ones that don't > reach the proposed minimum to the Django Git repo right before a > release. I believe this isn’t a problem that we should “solve” by punishing the smaller language communities by removing their language entirely. Instead I see this as a challenge to more actively reaching out to translators, basically the same problem we face with developers — find new contributors for the incomplete languages. Jannis
signature.asc
Description: Message signed with OpenPGP using GPGMail
