Вопросы, касающиеся интернационализации Django

Question

При разработке приложений для использования на нескольких языках я вижу реальную выгоду от использования локализации при попытке создать определенную специальную библиотеку локализации, специфичную для вашего приложения. Я работаю над сайтом, на котором будет 16 языков, и каждый язык будет иметь разные изображения в разных местах, а также полнотекстовые переводы для содержимого каждой страницы, причем каждый язык находится на другом URL-адресе (www.example.com/ru /, и т.д). Система интернационализации 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 для этого решения.