Django-fr

Forum

#1 24-11-2011 17:29:04

SBillion
Membre
Lieu : grenoble
Inscription : 05-08-2011
Messages : 43
Site Web

Internationalisation de contenu dynamique

Bonsoir les djangonautes,

Je viens vers vous pour savoir si quelqu'un a déjà eu à mettre en place
une internationalisation de tout les champs d'un modèle sans utiliser de
module externe? Quelle est la méthode la plus simple?
On m'a parlé de dumper la table pour insérer les champs dans le fichier
.po mais je ne vois pas trop comment m'en sortir avec ça, donc si
quelqu'un peut m'aider.

Sinon il y a la solution d'ajouter un champ par langue à mettre en place
et ensuite. Par exemple slug_fr, slug_en, slug_it.
J'ai trouvé un moyen de récupérer le bon champ en fonction de la langue
sur ce blog: http://ggendre.posterous.com/django-mini-localized-db-values

Si quelqu'un a d'autres propositions, je suis tout ouïe.

Hors ligne

#2 24-11-2011 17:49:21

Bruno Renié
Membre
Inscription : 11-08-2010
Messages : 52

Re : Internationalisation de contenu dynamique

2011/11/24 seb <sebastien.billion _AT_ gmail.com>:
> Bonsoir les djangonautes,
>
> Je viens vers vous pour savoir si quelqu'un a déjà eu à mettre en place une
> internationalisation de tout les champs d'un modèle sans utiliser de module
> externe? Quelle est la méthode la plus simple?

Pourquoi "sans utiliser de module externe" ?

> On m'a parlé de dumper la table pour insérer les champs dans le fichier .po
> mais je ne vois pas trop comment m'en sortir avec ça, donc si quelqu'un peut
> m'aider.
>
> Sinon il y a la solution d'ajouter un champ par langue à mettre en place et
> ensuite. Par exemple slug_fr, slug_en, slug_it.
> J'ai trouvé un moyen de récupérer le bon champ en fonction de la langue sur
> ce blog: http://ggendre.posterous.com/django-mini-localized-db-values
>
> Si quelqu'un a d'autres propositions, je suis tout ouïe.

L'approche la plus élégante de mon point de vue est celle de
django-hvad[0] (anciennement django-nani): les champs non
internationalisés dans une table, le reste dans une autre table avec
un champ qui spécifie la langue. Comme ça ta structure DB est
indépendante du nombre de langues et ça t'évite de faire des SELECT
sur 5 fois trop de colonnes ou une migration à chaque fois que tu veux
ajouter une langue.

En gros (code certifié iso1664) :

class Foo(models.Model):
    slug = models.SlugField()  # Non traduit

class TranslatedFoo(models.Model):  # champs traduits
    foo = models.ForeignKey(Foo, related_name='translations')
    lang = models.CharField(max_length=5, choices=LANGS)
    title = models.CharField(max_length=1023)
    # + autres champs internationalisés

    class Meta:
         unique_together = ('foo', 'lang')

Et ensuite :

instance = Foo.objects.get(slug='stuff')
en = instance.translations.get(lang='en')

Tu peux optimiser un peu en faisant des jointures mais django-hvad
facilite justement le travail avec les traductions et rend le tout
plus générique.

[0] http://django-hvad.readthedocs.org

--
Bruno

Hors ligne

#3 24-11-2011 18:00:37

SBillion
Membre
Lieu : grenoble
Inscription : 05-08-2011
Messages : 43
Site Web

Re : Internationalisation de contenu dynamique

Merci pour ta réponse mais cela fait bien plus que nécessaire et j'en
connais un qui va me dire qu'il faut faire du bottom-up d'où le "sans
module externe".
En tout cas je garde cette méthode sous la main pour un prochain projet.

Le 24/11/2011 17:49, Bruno Renié a écrit :
> 2011/11/24 seb<sebastien.billion _AT_ gmail.com>:
>> Bonsoir les djangonautes,
>>
>> Je viens vers vous pour savoir si quelqu'un a déjà eu à mettre en place une
>> internationalisation de tout les champs d'un modèle sans utiliser de module
>> externe? Quelle est la méthode la plus simple?
> Pourquoi "sans utiliser de module externe" ?
>
>> On m'a parlé de dumper la table pour insérer les champs dans le fichier .po
>> mais je ne vois pas trop comment m'en sortir avec ça, donc si quelqu'un peut
>> m'aider.
>>
>> Sinon il y a la solution d'ajouter un champ par langue à mettre en place et
>> ensuite. Par exemple slug_fr, slug_en, slug_it.
>> J'ai trouvé un moyen de récupérer le bon champ en fonction de la langue sur
>> ce blog: http://ggendre.posterous.com/django-mini-localized-db-values
>>
>> Si quelqu'un a d'autres propositions, je suis tout ouïe.
> L'approche la plus élégante de mon point de vue est celle de
> django-hvad[0] (anciennement django-nani): les champs non
> internationalisés dans une table, le reste dans une autre table avec
> un champ qui spécifie la langue. Comme ça ta structure DB est
> indépendante du nombre de langues et ça t'évite de faire des SELECT
> sur 5 fois trop de colonnes ou une migration à chaque fois que tu veux
> ajouter une langue.
>
> En gros (code certifié iso1664) :
>
> class Foo(models.Model):
>      slug = models.SlugField()  # Non traduit
>
> class TranslatedFoo(models.Model):  # champs traduits
>      foo = models.ForeignKey(Foo, related_name='translations')
>      lang = models.CharField(max_length=5, choices=LANGS)
>      title = models.CharField(max_length=1023)
>      # + autres champs internationalisés
>
>      class Meta:
>           unique_together = ('foo', 'lang')
>
> Et ensuite :
>
> instance = Foo.objects.get(slug='stuff')
> en = instance.translations.get(lang='en')
>
> Tu peux optimiser un peu en faisant des jointures mais django-hvad
> facilite justement le travail avec les traductions et rend le tout
> plus générique.
>
> [0] http://django-hvad.readthedocs.org
>
> --
> Bruno
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django

Hors ligne

Pied de page des forums