Vous n'êtes pas identifié(e).
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
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
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