Translate a Django App into Italian

What Italian changes in a Django message catalogue

Italian uses the Latin alphabet, runs left to right and is somewhat longer than English, close to French in length. Layouts sized for English may feel tight: Settings becomes Impostazioni, Sign up becomes Registrati or Registrazione.

Three things need care:

• Register. A professional interface addresses the user with the formal Lei: Inserisca la password, La preghiamo di riprovare. Very short button labels (Salva, Annulla, Elimina) are set forms kept even in a Lei interface. Switching between Inserisci and Inserisca from one screen to the next is the most noticeable inconsistency.
• Accents. è, perché, più, città. The capital is È, not E’: ‘È necessario accedere’ must keep its accent. The file must be UTF-8, as declared by the Content-Type: text/plain; charset=UTF-8 header Django generates.
• Gender and elision around placeholders. ‘Welcome, %(name)s’ is risky as Benvenuto, %(name)s, which assumes a man. A neutral phrasing such as Le diamo il benvenuto, %(name)s avoids the issue. Likewise, an article before a placeholder (dell’%(app)s or della %(app)s?) depends on the word inserted at runtime; nell’applicazione %(app)s is safer.

Plurals: msgid_plural, Plural-Forms and the ‘many’ category

Strings going through ngettext or {% blocktranslate count %} appear in the .po with a msgid_plural and several msgstr[n] entries. How many forms are expected is set by the file’s Plural-Forms header.

CLDR defines three categories for Italian: one, many and other. Many covers large round numbers, which take the preposition di: 1 messaggio, 5 messaggi, but 1 milione di messaggi. Depending on your gettext or Django version, the header may declare two or three forms. What matters is that every plural entry has exactly as many msgstr[n] as the header states; otherwise compilemessages will report an error.

Two Italian-specific traps:

• Zero takes the plural: 0 messaggi.
• Some nouns are invariable: 1 file, 3 file; 1 città, 2 città. Identical singular and plural forms are correct here, not a mistake.

What Manuce returns, and what it does not do

You get back the same .po file, ready to drop into locale/it/LC_MESSAGES/: indentation, entry order, quotes, comments (including # Translators: lines and #: templates/… references), line endings, encoding and BOM are preserved. Only the values change. The header, including Plural-Forms, stays as in your file.

• Placeholders %(name)s, %(count)d and {name} are checked: each translated value is compared with the source, placeholders and tags included. If a mismatch persists, the source value is kept and the report says so.
• Not translated: keys (msgid), empty values, URLs, email addresses, numbers, colours, date formats, identifiers and anything you have marked as non-translatable.
• The report lists translated strings and those left as they were, with the reason.

Manuce does not run makemessages or compilemessages for you and does not touch your code or settings.py. Nor does it provide sworn or certified translation: if your Italian terms and conditions need certification, use an accredited translator. Pricing is based on the words in the values, with keys and tags excluded.

Dates, numbers and hard-coded strings

Italian writes 1.234,56 and 3 marzo 2025, with lower-case month names. Django applies its own Italian formats to dates and numbers rendered through filters such as {{ value|date }} or localize: those never pass through the .po and Manuce leaves them alone.

The trap is strings that embed a format: _("Updated on %(date)s") is fine, whereas _("Updated on March 3") freezes an English date in the catalogue. Equally, a string built from separately translated fragments (_("You have") + " " + str(n) + " " + _("items")) can never produce correct Italian, because agreement and word order change. Rewrite it as one string with a placeholder and ngettext before extraction.

Preparing the file and checking the result

Before uploading:

• Run python manage.py makemessages -l it, plus -d djangojs if your scripts use gettext in JavaScript; that gives you a djangojs.po to translate as well.
• Add context to ambiguous words with pgettext: ‘Open’ (state or action?) becomes Aperto or Apri. The context appears as msgctxt in the .po.
• Flag strings that must stay untranslated (product names, codes) in a # Translators: comment.

After delivery:

• Read the report and deal with any strings left in the source language.
• Entries marked #, fuzzy by makemessages keep that flag, since comments are preserved, and compilemessages skips them. Remove the flag once you have checked the translation.
• Run compilemessages, switch to Italian and walk through the key screens: consistent Lei, agreement around placeholders, button widths.

In practice

1. Generate the catalogue with makemessages -l it (and -d djangojs if needed).
2. Upload locale/it/LC_MESSAGES/django.po: instant quote and a free sample before paying.
3. Download the translated .po and read the report of strings left in the source language.
4. Clear checked fuzzy flags, run compilemessages and test the interface in Italian.