salut

pour une appli web faite en php et utilisant mysql comme sgbd, j'ai besoin d'utiliser une liste d'aliments qui sera stockée dans une BDD
on pourra ajouter et supprimer des aliments dynamiquement à partir du script
pour l'instant cette appli ne sera que en français, mais je prévois de l'internationaliser plus tard

donc, je me pose la question de savoir comment stocker ça dans la BDD tout en sachant que je vais devoir l’internationaliser plus tard, et que j'ai pas envie de réécrire tout le code ou de revoir la structure de la bdd plus tard, je veux que ce soit prêt maintenant (au niveau de la structure, pas des données)

du coup je ne peux pas faire ça:

ID | nom
1 | banane
2 | pomme

etc

je ne peux pas utiliser non plus des fichiers php de chaque langues contenant des constantes, vu qu'on pourra en ajouter dynamiquement

je ne veux pas nom plus avoir 10 tables "aliments" pour chaque langues

j'avais pensé à faire ça:
ID | lang | nom
1 | fr | banane
2 | fr | pomme
3 | en | apple
4 | es | pomelo

bon déjà je trouve ça moche nan ? et puis si le mec veut changer de langue, ça va être chaud, vu qu'on pourra créer des sortes de menu etc, je devrais faire un script bourin qui modifie tous les aliments de tous les menus du mec

alors comment faire ? merci

Je pensais à un truc comme

ID | nom_fr | nom_en | nom_es | nom_de | etc...
1 | pomme | apple | pomelo | NULL |
2 | pwar | NULL | NULL | NULL
etc...

T'en penses quoi ?

La seconde solution sans hésiter pour ma part la première te forcera à devoir modifier la structure si des langues doivent venir s'ajouter et ce pour chaque champ ayant besoin d'être traduit.

La seconde implique plus de lignes dans la base de données (quoique je ne suis pas sûr que rassembler tout en une ligne ou séparer cette ligne en 2 pèse plus lourd au final) par contre tu n'as aucunes restrictions au niveau des langues, tu en peux en rajouter 50 sans le moindre soucis.

Perso je fonctionne en 2 tables, une (exemple articles) table stockant les infos n'ayant pas besoin d'être traduite, et une autre (exemple: article_i18n (merci deepblue reliée donc à la première (il s'agit du même article par exemple mais ayant une description différente) qui elle stocke le titre, le texte etc un champ TargetID pour lié à la table articles et surtout un champ LanguageID définissant la langue, et c'est sur base de ce LanguageID que tu vas chercher la bonne traduction.

merci beaucoup à vous tous pour vos réponses

je pense donc utiliser la méthode des 2 tables, c'est celle qui est la plus clean je pense, merci