Question

My question is regarding i18n in Python. From what I understand, it involves:

• Create a messages file per language (ONLY ONE?!).
• in this file, each message will be of the format
  • English message here
  • Message en Francais ici (yea crappy french..)
• then have this file compiled into another faster binary format
• repeat for all other langs needed
• in app code (Django) use the translate method with english (or default) language which will be translated correctly based on locale… tr('English message Here')

Probably I’m a bit off on the steps, but this seems to be the general sense right?

What I’m wondering is, is there a simpler way? I mean in the java webapp world, you set up message bundle files in the bundleName_locale.properties format. In each one you usually have a key to message relation like greeting = Hello World. You can have lots of different properties files for different sub sections of your site/app. All the locale files are hierarchical, and missing keys in a sub locale fall through to the parent etc. This is all done automatically by Java, no setup required.

Is there anything like this in the Django/Python world? Is this just insane to follow this route? Could I fake this using a module as a stand in for a java .properties file? Sorry for the long-winded question, and thanks for any input.

Answer 1

While you could do this fairly simply, I would question why.

As is:

1. Django’s i18n is based around gettext, which has never given me any performance problems.
2. You don’t have to create the message file, Django will do it for you.
3. The messages files Django creates can be sent as a text file to just about anyone for translation.
   • I spent about 5 minutes explaining to someone how to use them, and a day later got back a fantastic translation of my entire site.
4. Marking the strings in your code is very simple.
   • _("My String") is normal for .py files by using from django.utils.translation import ugettext as _.
   • {% trans "My String" %} in your templates. Again, quite simple.
   • Writing out bundle.getString("My String") seems like it would get old, quick.
5. You can easily incorporate Django’s i18n into your JavaScript, if needed.
6. There are web-based editors for the message files.
7. You don’t have to define a string more than once, it conglomerates all instances into one token across your entire app.
   • How many times do you have to define “Save” in your Java properties files?
8. Still in a nice, version-tracking friendly, text file.
9. If you hack together a .properties-like way to define your strings, you’d still want to compile them so that you don’t have to parse the text file at execution time.

Example of empty .po file:

#: templates/inquiries/settings/new_field.html:12
#: templates/inquiries/settings/new_form.html:4
msgid "Save"
msgstr ""

Personally, I don’t see a reason to bother hacking together a replacement for a solution which already exists and works well.