0

Probably a mis-leading title, sorry, but I hope I can explain better below.

I'm part of a popular open-source project and we'd like to provide translations for the project for any language code that our audience would like. Our translations are all contributed by our user-base, and we'd like to support whatever is needed by this body of supporters/users.

The project is written in Python/Django and we use gettext and ultimately Transifex for their wonderful service for managing translation suggestions.

The problem for us comes when someone wants a locale-variant of a language. Let's assume French (fr) for this question.

We have a solid translation already for the language code fr. However, if a contributor from, say, Canada, comes along and wishes to contribute fr_CA, we suddenly have a maintenance headache due to these scenarios:

  1. The fr_CA translations are incomplete. In this case gettext falls back to "untranslated", which in our project means en.

  2. If the fr_CA translations copies copious bits from the fr, then just changes some bits here and there to better match the locale, then, we discover that we need to change something in the base fr translation, suddenly, we'd have a synchronization issue that is not readily solve-able by non-fr_CA-speaking contributors.

What seems to make more sense to me is that there is some form of "overlay" setting where we could "stack" the languages. fr at the base, then fr_CA, then any even more specific locale variants on top of that. What I would like is that once these are all defined, then the translator only needs to update fr_CA with the differences between that locale and the locale "beneath" it in the stack, in this case fr. By leaving things that aren't different compared to the more general locale below any layer, we're free to make corrections/updates as required without producing a synchronization issue.

I would think that this sort of "stacking" would be ultimately resolved during the process of producing the complied MO files.

Does anyone know how we could accomplish this?

mkoistinen
  • 7,724
  • 3
  • 41
  • 56

1 Answers1

0

Django does support fallback of languages internally, which actually relies on gettext support, but as far as I can tell, it doesn't expose a way for developers to tweak it. Check out the snippet below taken from Django's code.

def _add_fallback(self, localedirs=None):
    """Sets the GNUTranslations() fallback with the default language."""
    # Don't set a fallback for the default language or any English variant
    # (as it's empty, so it'll ALWAYS fall back to the default language)
    if self.__language == settings.LANGUAGE_CODE or self.__language.startswith('en'):
        return
    if self.domain == 'django':
        # Get from cache
        default_translation = translation(settings.LANGUAGE_CODE)
    else:
        default_translation = DjangoTranslation(
            settings.LANGUAGE_CODE, domain=self.domain, localedirs=localedirs
        )
    self.add_fallback(default_translation)

It looks like the only possible solution for now, using the gettext's way of doing it, would be to monkey patch Django, tweaking _add_fallback to call self.add_fallback multiple times, depending on your needs.

diegobz
  • 71
  • 1