Вопросы о структуре интернационализации Джанго

Question

При разработке приложений для использования на нескольких языках я вижу реальное преимущество использования локализации по сравнению с попыткой создать специальную библиотеку локализации, специфичную для вашего приложения.Я работаю над веб-сайтом, на котором будет 16 языков, и на каждом языке будут разные изображения в разных местах, а также полнотекстовые переводы для содержимого каждой страницы, причем каждый язык находится на отдельном URL (www.example.com/en/, так далее).Интернационализация Django кажется очень волшебной и хитрой.Моя идея заключалась в том, чтобы сделать что-то простое, например:

class Language(models.Model):
    name = models.CharField(max_length=50)
    code = models.CharField(max_length=2)  # (e.g. "FR")


class ContentSection(models.Model):
    page = models.ForeignKey('mysite.Page')
    name = models.CharField(max_length=50)  # (e.g. ("main body text")
    content = models.TextField(max_length=5000)

    class Meta:
        unique_together = (('name', 'page'),)


class ContentTranslation(models.Model):
    content_section = models.ForeignKey(ContentSection)
    language = models.ForeignKey(Language)
    content = models.TextField(max_length=5000)

    class Meta:
        unique_together = (('content_section', 'language'),)

Я бы использовал промежуточное ПО для установки текущего языка на основе первого сегмента URL, а в своих представлениях я бы извлек содержимое для данной страницыпредставление с чем-то вроде:

# In views.view_page
left_content = ContentSection.objects.filter(page=current_page, name='left column text')
if not request.language.code == 'EN':
    left_content = ContentTranslation.objects.get(content_section=left_content, language=request.language)

Конечно, в производстве я бы, вероятно, создал шаблонный тег, который получает содержимое (с правильным языком) по имени, а не явно вытягивал каждую область содержимого в представлении..

Не кажется ли вам настолько смешным делать это вместо использования i18n?Я скучаю по большей картине с интернационализацией?

(имейте в виду: сайт будет просматриваться пользователями на других языках, но вся административная работа, включая вставку переводов, будет сделана в США)

Answer 1

Это разумный подход, если вам нужно, чтобы ваши пользователи могли изменять контент на всех разных языках.Вы также можете создать хороший интерфейс для всего.

Однако вы не используете фреймворк Django i18n.Так какой у тебя вопрос?:)

Я пробовал как использовать фреймворк i18n для контента, так и использовать ваш подход.Хранение переводов в po-файлах отлично подходит для «системного» текста, так как вы можете использовать все свои инструменты, такие как контроль версий, отслеживание ошибок и т. Д. Однако, если у вас есть пользователи, которые действительно хотят изменить контент, это неприятновсе время, что, как я полагаю, имеет место практически для любого веб-сайта некоторого размера.

В качестве дополнительного примечания, включение языка в URL облегчает кэширование страниц на внешнем прокси-сервере, которыйвсе должны использовать, так что +1 для этого решения.