Clone wiki

djangolocales / Home should solve multiple problems within the increasing Django apps community and the Pinax project that uses those apps:


Illustrates the steps involved to make reusable Django apps i18n ready additionally to the official Django documentation. This is mostly based on personal experience while developing apps and working with them (and others) in the Pinax project. This includes:

  • HOWTOs, e.g. marking strings, creating and updating po files, handle external apps, creating message catalogues, ..
  • screencasts, e.g. Poedit usage, ..
  • examples for special cases that are not solved in Django (yet), e.g. number formatting, date inputs, ..

That section is mostly based on articles that I want to add gradually over time. I hope to get some guest writers to participate and wondered if it should be wiki based for easier contribution, but that's not decided yet.

App translation

The key feature of the site is based on Transifex with smaller parts from Pinax.

App authors should be able to create their apps as Transifex projects and add app repositories. If possible they should also be able to claim their apps -- in case we decide to import app data from before for example. Maby we also allow other users to create the apps, though this needs evaluation and probably agreement from the app authors.

Translators should be able to:

  • browse the translation files
  • edit already given translations
  • create a new translation (locale) by using Django's own makemessages command
  • send a patch to the app owner (or a group of users) for review
  • download the created/updated Po file for local use
  • compile translation files with Django's own compilemessages command

App owners should additionally be able to:

  • review translation changes
  • give translators review permissions
  • commit changes back to the app's repository (if possible, also later)

As mentioned by glezos on IRC, Mozilla will soon release an abstract Python wrapper around different translation formats which could be used:

Ideal features (Gulopine )

Rather than simply facilitating the traditional translation workflow, djangolocales should also strive to provide a much easier way to translate content and manage those translations. To that end, I'd like to see the following features included:

  • pool translation strings from multiple apps into a single central library
  • .po files for individual languages would be automatically created behind the scenes
  • translators associate their account with one or more languages, and are shown only those strings that need translations into those languages
  • translators can edit strings from this central library, regardless of which apps they come from
  • translation can be done on the site itself, without downloading/editing/uploading .po files
  • apps obtain strings from this central library, regardless of who translated them

This should cut down on duplication, so if 20 apps all contain the strings "Yes" and "No", a single translation should suffice for all of them. I'd also like to get to the point where neither translators nor app owners have to deal much with .po and .mo files at all, unless they're already comfortable with things like Poedit. If they can download a file and commit it to their repository (or if they can provide access for us to do it automatically), the rest should all be able to be done directly on the site.

Quality Control

Once the service is up and running, we may find that the quality of translations to be of low quality. If this happens, we should plan for a quality control system that helps raise the standard for translations. This would involve peer review by other translators in each given language, so it would also only be possible in those languages that have at least two or three translators available. We should be able to toggle it on a per-language basis.

  • when a new translation comes in for a given string, it goes into a moderation queue, rather than shipping straight to an application
  • in addition to translating strings, translators would be shown an existing translation and asked to verify it or supply a correction
  • if corrections are supplied, those new strings will be shown alongside any existing ones when asked for translator review again
  • once a certain minimum number of translators have verified a single translation string, it will be considered safe to commit to applications that need it
  • translators must not be asked to review their own translations

I'd rather not see this implemented, and instead trust our translators to do the right thing. This suggestion is only to be used if we get complaints about spam or other significant quality concerns.