Skip to content

Translation

POEditor

Baby Buddy uses POEditor for translation contributions. Interested contributors can join translation of Baby Buddy for access to a simple, web-based frontend for adding/editing translation files to the project.

Manual

Baby Buddy has support for translation/localization. A manual translation process will look something like this:

  1. Set up a development environment (see Development environment).

  2. Run gulp makemessages -l xx where xx is a specific locale code in the ISO 639-1 format (e.g., "il" for Italian or "es" for Spanish). This creates a new translation file at locale/xx/LC_MESSAGES/django.po, or updates one if it exists.

  3. Open the created/updated django.po file and update the header template with license and contact info.

  4. Start translating! Each translatable string will have a msgid value with the string in English and a corresponding (empty) msgstr value where a translated string can be filled in. Strings that are pluralized are the one exception: they have several msgstr values, one per plural form your language needs. See Plural forms below.

  5. Once all strings have been translated, run gulp compilemessages -l xx to compile an optimized translation file (locale/xx/LC_MESSAGES/django.mo).

  6. To expose the new translation as a user setting, add the locale code to the LANGUAGES array in the base settings file (babybuddy/settings/base.py).

  7. Check if Plotly offers a translation (in node_modules/plotly.js/dist/) for the language. If it does:

  8. Add the Plotly translation file path to gulpfile.config.js in scriptsConfig.graph.

  9. Build, collect, and commit the /static folder (see gulp updatestatic).

  10. Run the development server, log in, and update the user language to test the newly translated strings.

Once the translation is complete, commit the new files and changes to a fork and create a pull request for review.

For more information on the Django translation process, see Django's documentation section: Translation.

Plural forms

Some source strings are pluralized. Where an ordinary string has a single msgstr, a pluralized one has an English singular and plural followed by one translated string per plural form your language has:

#: dashboard/templates/cards/timer_list.html:8
#, python-format
msgid "%(count)s active timer"
msgid_plural "%(count)s active timers"
msgstr[0] "%(count)s aktywny stoper"
msgstr[1] "%(count)s stopery"
msgstr[2] "%(count)s stoperów"
msgstr[3] "%(count)s stoperów"

How many msgstr[n] entries you fill is decided by your language, not by English. Of the pluralized strings currently in the project, the shipped locale files carry:

Locale msgstr[n] entries per string
ja 1
fr, he 2
ru, cs 3
pl, uk 4

Your language's count is declared in the django.po header as Plural-Forms: nplurals=N; … (nplurals=1 for ja, nplurals=4 for pl). gulp makemessages writes it for you, and POEditor renders the same numbered fields, so you do not need to work out the rule yourself — just fill the fields the file already has.

Fill every form your language declares. An empty msgstr[n] counts as untranslated, so exactly the counts that use that form fall back to English. That produces the confusing report where a string appears in your language for some numbers and not others.

Do not use %(plural)s. Older strings written that way — for example %(count)s nap%(plural)s — are obsolete and are no longer in the code. A suffix standing in for the plural ending can only tell two cases apart, so it cannot express the three- and four-form languages above. The strings now use proper plural entries, which is why Japanese, Polish and English can each read the same string naturally.

For the placeholder rules themselves, see Django's pluralization section.