je développe une appli avec java-swing, pour la partie interface
graphique la gestion des langues fait partie intégrante de java, donc
pas de pb, mais, pour la bd, il faudra bien un jour que je traduise
certains termes, ne serait-ce que les noms de pays.
comment gérez-vous les différentes versions d'un texte, en fonction de
la langue ? je pense proposer, outre le français, : anglais, allemand et
italien.
je cherche un système souple où l'on puisse entre, dans le désordre
complet, les différentes traductions dans différentes langues.
par exemple, j'ai une table, en français, t_vine_plant_vp qui donne pour
un cépage donné les textes suivants :
les synonymes ;
l'origine du cépage ;
des notes diverses sur ses propriétés.
ce que j'ai envie de faire, c'est créer, dans ce cas, en parallèle sur
la table t_vine_plant_vp (français par défaut) des tables
t_vine_plant_vp_en, t_vine_plant_vp_de, etc...
dont l'id sera le même que celui de la table originale t_vine_plant_vp
avec les règles suivantes :
si l'id n'est pas trouvé dans la table *_en, on prend le français, s'il
existe et que la colonne est à NULL, on prend le français, l'anglais
dans ce cas sinon.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ph. B.
Yvon Thoraval a écrit:
je développe une appli avec java-swing, pour la partie interface graphique la gestion des langues fait partie intégrante de java, donc pas de pb, mais, pour la bd, il faudra bien un jour que je traduise certains termes, ne serait-ce que les noms de pays.
comment gérez-vous les différentes versions d'un texte, en fonction de la langue ? je pense proposer, outre le français, : anglais, allemand et italien.
je cherche un système souple où l'on puisse entre, dans le désordre complet, les différentes traductions dans différentes langues.
par exemple, j'ai une table, en français, t_vine_plant_vp qui donne pour un cépage donné les textes suivants :
les synonymes ; l'origine du cépage ; des notes diverses sur ses propriétés.
ce que j'ai envie de faire, c'est créer, dans ce cas, en parallèle sur la table t_vine_plant_vp (français par défaut) des tables t_vine_plant_vp_en, t_vine_plant_vp_de, etc...
dont l'id sera le même que celui de la table originale t_vine_plant_vp avec les règles suivantes :
si l'id n'est pas trouvé dans la table *_en, on prend le français, s'il existe et que la colonne est à NULL, on prend le français, l'anglais dans ce cas sinon.
Qu'en pensez-vous ?
Autre piste:
Tu stockes dans tes tables l'Id d'un texte et tu as une table où tu stockes tous tes labels avec leur id de langue
T_LIBELLE ( LBL_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_ID INTEGER NOT NULL, // Clé étrangère langues LBL_REF INTEGER NOT NULL, // Id du libellé indépendamment de la langue LBL CAPTION VARCHAR(64) NOT NULL // Le libellé dans la langue considérée )
TR_LANGUE_LNG ( LNG_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_NOM VARCHAR(32) // Nom de la langue )
Avec la table de ta question précédente, cela donne:
T_APPELLATION ( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, LBL_REF INTEGER NOT NULL, // "Pointeur" vers le libellé TYP_ID INTEGER NOT NULL // Clé étrangère pour le type d'appellation )
Une requete avec une jointure vers ta table de libellés et hop ! :-)
-- Philippe.
Yvon Thoraval a écrit:
je développe une appli avec java-swing, pour la partie interface
graphique la gestion des langues fait partie intégrante de java, donc
pas de pb, mais, pour la bd, il faudra bien un jour que je traduise
certains termes, ne serait-ce que les noms de pays.
comment gérez-vous les différentes versions d'un texte, en fonction de
la langue ? je pense proposer, outre le français, : anglais, allemand et
italien.
je cherche un système souple où l'on puisse entre, dans le désordre
complet, les différentes traductions dans différentes langues.
par exemple, j'ai une table, en français, t_vine_plant_vp qui donne pour
un cépage donné les textes suivants :
les synonymes ;
l'origine du cépage ;
des notes diverses sur ses propriétés.
ce que j'ai envie de faire, c'est créer, dans ce cas, en parallèle sur
la table t_vine_plant_vp (français par défaut) des tables
t_vine_plant_vp_en, t_vine_plant_vp_de, etc...
dont l'id sera le même que celui de la table originale t_vine_plant_vp
avec les règles suivantes :
si l'id n'est pas trouvé dans la table *_en, on prend le français, s'il
existe et que la colonne est à NULL, on prend le français, l'anglais
dans ce cas sinon.
Qu'en pensez-vous ?
Autre piste:
Tu stockes dans tes tables l'Id d'un texte et tu as une table où tu stockes tous
tes labels avec leur id de langue
T_LIBELLE
(
LBL_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire
LNG_ID INTEGER NOT NULL, // Clé étrangère langues
LBL_REF INTEGER NOT NULL, // Id du libellé indépendamment de la langue
LBL CAPTION VARCHAR(64) NOT NULL // Le libellé dans la langue considérée
)
TR_LANGUE_LNG
(
LNG_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire
LNG_NOM VARCHAR(32) // Nom de la langue
)
Avec la table de ta question précédente, cela donne:
T_APPELLATION
(
APP_ID INTEGER IDENTITY (1, 1) NOT NULL,
APP_BG INTEGER NOT NULL,
APP_BD INTEGER NOT NULL,
APP_NIVEAU INTEGER NOT NULL,
LBL_REF INTEGER NOT NULL, // "Pointeur" vers le libellé
TYP_ID INTEGER NOT NULL // Clé étrangère pour le type d'appellation
)
Une requete avec une jointure vers ta table de libellés et hop ! :-)
je développe une appli avec java-swing, pour la partie interface graphique la gestion des langues fait partie intégrante de java, donc pas de pb, mais, pour la bd, il faudra bien un jour que je traduise certains termes, ne serait-ce que les noms de pays.
comment gérez-vous les différentes versions d'un texte, en fonction de la langue ? je pense proposer, outre le français, : anglais, allemand et italien.
je cherche un système souple où l'on puisse entre, dans le désordre complet, les différentes traductions dans différentes langues.
par exemple, j'ai une table, en français, t_vine_plant_vp qui donne pour un cépage donné les textes suivants :
les synonymes ; l'origine du cépage ; des notes diverses sur ses propriétés.
ce que j'ai envie de faire, c'est créer, dans ce cas, en parallèle sur la table t_vine_plant_vp (français par défaut) des tables t_vine_plant_vp_en, t_vine_plant_vp_de, etc...
dont l'id sera le même que celui de la table originale t_vine_plant_vp avec les règles suivantes :
si l'id n'est pas trouvé dans la table *_en, on prend le français, s'il existe et que la colonne est à NULL, on prend le français, l'anglais dans ce cas sinon.
Qu'en pensez-vous ?
Autre piste:
Tu stockes dans tes tables l'Id d'un texte et tu as une table où tu stockes tous tes labels avec leur id de langue
T_LIBELLE ( LBL_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_ID INTEGER NOT NULL, // Clé étrangère langues LBL_REF INTEGER NOT NULL, // Id du libellé indépendamment de la langue LBL CAPTION VARCHAR(64) NOT NULL // Le libellé dans la langue considérée )
TR_LANGUE_LNG ( LNG_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_NOM VARCHAR(32) // Nom de la langue )
Avec la table de ta question précédente, cela donne:
T_APPELLATION ( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, LBL_REF INTEGER NOT NULL, // "Pointeur" vers le libellé TYP_ID INTEGER NOT NULL // Clé étrangère pour le type d'appellation )
Une requete avec une jointure vers ta table de libellés et hop ! :-)
-- Philippe.
yvon.thoravalNO-SPAM
Ph. B. wrote:
T_LIBELLE ( LBL_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_ID INTEGER NOT NULL, // Clé étrangère langues LBL_REF INTEGER NOT NULL, // Id du libellé indépendamment de la langue LBL CAPTION VARCHAR(64) NOT NULL // Le libellé dans la langue considérée )
TR_LANGUE_LNG ( LNG_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_NOM VARCHAR(32) // Nom de la langue )
Avec la table de ta question précédente, cela donne:
T_APPELLATION ( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, LBL_REF INTEGER NOT NULL, // "Pointeur" vers le libellé TYP_ID INTEGER NOT NULL // Clé étrangère pour le type d'appellation )
bien vu, il faut seulement gérer, à part, le pointeur du libellé, en fait c'est ce que tu dis ou dans la table des libelle, donner aussi la colonne et la table de ref... mais bon ta méthode est plus élégante car elle permet de retrouver le libelle directement en sql, dans ma version il fallait faire des tests (longs + coût cpu)
une jointure seule ne marche qu'à condition que tout soit traduit, amha, je veux proposer au moins le français si non traduit (comme en java avec l'anglais...) -- yt
Ph. B. <philippe.boucault@voila_N_O_S_P_A_M_.fr> wrote:
T_LIBELLE
(
LBL_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire
LNG_ID INTEGER NOT NULL, // Clé étrangère langues
LBL_REF INTEGER NOT NULL, // Id du libellé indépendamment de la langue
LBL CAPTION VARCHAR(64) NOT NULL // Le libellé dans la langue considérée
)
TR_LANGUE_LNG
(
LNG_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire
LNG_NOM VARCHAR(32) // Nom de la langue
)
Avec la table de ta question précédente, cela donne:
T_APPELLATION
(
APP_ID INTEGER IDENTITY (1, 1) NOT NULL,
APP_BG INTEGER NOT NULL,
APP_BD INTEGER NOT NULL,
APP_NIVEAU INTEGER NOT NULL,
LBL_REF INTEGER NOT NULL, // "Pointeur" vers le libellé
TYP_ID INTEGER NOT NULL // Clé étrangère pour le type d'appellation
)
bien vu, il faut seulement gérer, à part, le pointeur du libellé, en
fait c'est ce que tu dis ou dans la table des libelle, donner aussi la
colonne et la table de ref... mais bon ta méthode est plus élégante car
elle permet de retrouver le libelle directement en sql, dans ma version
il fallait faire des tests (longs + coût cpu)
une jointure seule ne marche qu'à condition que tout soit traduit, amha,
je veux proposer au moins le français si non traduit (comme en java avec
l'anglais...)
--
yt
T_LIBELLE ( LBL_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_ID INTEGER NOT NULL, // Clé étrangère langues LBL_REF INTEGER NOT NULL, // Id du libellé indépendamment de la langue LBL CAPTION VARCHAR(64) NOT NULL // Le libellé dans la langue considérée )
TR_LANGUE_LNG ( LNG_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_NOM VARCHAR(32) // Nom de la langue )
Avec la table de ta question précédente, cela donne:
T_APPELLATION ( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, LBL_REF INTEGER NOT NULL, // "Pointeur" vers le libellé TYP_ID INTEGER NOT NULL // Clé étrangère pour le type d'appellation )
bien vu, il faut seulement gérer, à part, le pointeur du libellé, en fait c'est ce que tu dis ou dans la table des libelle, donner aussi la colonne et la table de ref... mais bon ta méthode est plus élégante car elle permet de retrouver le libelle directement en sql, dans ma version il fallait faire des tests (longs + coût cpu)
une jointure seule ne marche qu'à condition que tout soit traduit, amha, je veux proposer au moins le français si non traduit (comme en java avec l'anglais...) -- yt
Fred BROUARD - SQLpro
Ne pas oublier le cas ou le libellé n'est pas traduit (oubli)...
Si libellé conçu en français... et traduit en moldave :
SELECT COALESCE(
SELECT COALESCE(LBL2.LBL_CAPTION, LBL1.LBL_CAPTION, '') AS CAPTION
FROM T_LIBELLE LBL1
INNER JOIN TR_LANGUE_LNG LNG1 ON LBL.LNG_ID = LNG1.LNG_ID AND LNG1.LLNG_NOM = 'français'
LEFT OUTER JOIN T_LIBELLE LBL2 ON LBL1.LBL_ID = LBL2.LBL_ID
LEFT OUTER JOIN TR_LANGUE_LNG LNG2 ON LBL2.LNG_ID = LNG2.LNG_ID AND LNG2.LNG_NOM = 'moldave'
WHERE LBL1.LBL_ID = ...
A +
Yvon Thoraval a écrit:
Ph. B. wrote:
T_LIBELLE ( LBL_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_ID INTEGER NOT NULL, // Clé étrangère langues LBL_REF INTEGER NOT NULL, // Id du libellé indépendamment de la langue LBL CAPTION VARCHAR(64) NOT NULL // Le libellé dans la langue considérée )
TR_LANGUE_LNG ( LNG_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_NOM VARCHAR(32) // Nom de la langue )
Avec la table de ta question précédente, cela donne:
T_APPELLATION ( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, LBL_REF INTEGER NOT NULL, // "Pointeur" vers le libellé TYP_ID INTEGER NOT NULL // Clé étrangère pour le type d'appellation )
bien vu, il faut seulement gérer, à part, le pointeur du libellé, en fait c'est ce que tu dis ou dans la table des libelle, donner aussi la colonne et la table de ref... mais bon ta méthode est plus élégante car elle permet de retrouver le libelle directement en sql, dans ma version il fallait faire des tests (longs + coût cpu)
une jointure seule ne marche qu'à condition que tout soit traduit, amha, je veux proposer au moins le français si non traduit (comme en java avec l'anglais...)
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Ne pas oublier le cas ou le libellé n'est pas traduit (oubli)...
Si libellé conçu en français... et traduit en moldave :
SELECT COALESCE(
SELECT COALESCE(LBL2.LBL_CAPTION, LBL1.LBL_CAPTION, '') AS CAPTION
FROM T_LIBELLE LBL1
INNER JOIN TR_LANGUE_LNG LNG1
ON LBL.LNG_ID = LNG1.LNG_ID AND LNG1.LLNG_NOM = 'français'
LEFT OUTER JOIN T_LIBELLE LBL2
ON LBL1.LBL_ID = LBL2.LBL_ID
LEFT OUTER JOIN TR_LANGUE_LNG LNG2
ON LBL2.LNG_ID = LNG2.LNG_ID AND LNG2.LNG_NOM = 'moldave'
WHERE LBL1.LBL_ID = ...
A +
Yvon Thoraval a écrit:
Ph. B. <philippe.boucault@voila_N_O_S_P_A_M_.fr> wrote:
T_LIBELLE
(
LBL_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire
LNG_ID INTEGER NOT NULL, // Clé étrangère langues
LBL_REF INTEGER NOT NULL, // Id du libellé indépendamment de la langue
LBL CAPTION VARCHAR(64) NOT NULL // Le libellé dans la langue considérée
)
TR_LANGUE_LNG
(
LNG_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire
LNG_NOM VARCHAR(32) // Nom de la langue
)
Avec la table de ta question précédente, cela donne:
T_APPELLATION
(
APP_ID INTEGER IDENTITY (1, 1) NOT NULL,
APP_BG INTEGER NOT NULL,
APP_BD INTEGER NOT NULL,
APP_NIVEAU INTEGER NOT NULL,
LBL_REF INTEGER NOT NULL, // "Pointeur" vers le libellé
TYP_ID INTEGER NOT NULL // Clé étrangère pour le type d'appellation
)
bien vu, il faut seulement gérer, à part, le pointeur du libellé, en
fait c'est ce que tu dis ou dans la table des libelle, donner aussi la
colonne et la table de ref... mais bon ta méthode est plus élégante car
elle permet de retrouver le libelle directement en sql, dans ma version
il fallait faire des tests (longs + coût cpu)
une jointure seule ne marche qu'à condition que tout soit traduit, amha,
je veux proposer au moins le français si non traduit (comme en java avec
l'anglais...)
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Ne pas oublier le cas ou le libellé n'est pas traduit (oubli)...
Si libellé conçu en français... et traduit en moldave :
SELECT COALESCE(
SELECT COALESCE(LBL2.LBL_CAPTION, LBL1.LBL_CAPTION, '') AS CAPTION
FROM T_LIBELLE LBL1
INNER JOIN TR_LANGUE_LNG LNG1 ON LBL.LNG_ID = LNG1.LNG_ID AND LNG1.LLNG_NOM = 'français'
LEFT OUTER JOIN T_LIBELLE LBL2 ON LBL1.LBL_ID = LBL2.LBL_ID
LEFT OUTER JOIN TR_LANGUE_LNG LNG2 ON LBL2.LNG_ID = LNG2.LNG_ID AND LNG2.LNG_NOM = 'moldave'
WHERE LBL1.LBL_ID = ...
A +
Yvon Thoraval a écrit:
Ph. B. wrote:
T_LIBELLE ( LBL_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_ID INTEGER NOT NULL, // Clé étrangère langues LBL_REF INTEGER NOT NULL, // Id du libellé indépendamment de la langue LBL CAPTION VARCHAR(64) NOT NULL // Le libellé dans la langue considérée )
TR_LANGUE_LNG ( LNG_ID INTEGER IDENTITY (1, 1) NOT NULL, // Clé primaire LNG_NOM VARCHAR(32) // Nom de la langue )
Avec la table de ta question précédente, cela donne:
T_APPELLATION ( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, LBL_REF INTEGER NOT NULL, // "Pointeur" vers le libellé TYP_ID INTEGER NOT NULL // Clé étrangère pour le type d'appellation )
bien vu, il faut seulement gérer, à part, le pointeur du libellé, en fait c'est ce que tu dis ou dans la table des libelle, donner aussi la colonne et la table de ref... mais bon ta méthode est plus élégante car elle permet de retrouver le libelle directement en sql, dans ma version il fallait faire des tests (longs + coût cpu)
une jointure seule ne marche qu'à condition que tout soit traduit, amha, je veux proposer au moins le français si non traduit (comme en java avec l'anglais...)
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
yvon.thoravalNO-SPAM
Fred BROUARD - SQLpro wrote:
Ne pas oublier le cas ou le libellé n'est pas traduit (oubli)...
Ce n'est pas qu'une question d'oubli d'ailleurs, surtout de boulot je dirais, il faut bien évidemment que la base soit fonctionnelle même si tout n'est pas traduit...
-- yt
Fred BROUARD - SQLpro <brouardf@club-internet.fr> wrote:
Ne pas oublier le cas ou le libellé n'est pas traduit (oubli)...
Ce n'est pas qu'une question d'oubli d'ailleurs, surtout de boulot je
dirais, il faut bien évidemment que la base soit fonctionnelle même si
tout n'est pas traduit...
Ne pas oublier le cas ou le libellé n'est pas traduit (oubli)...
Ce n'est pas qu'une question d'oubli d'ailleurs, surtout de boulot je dirais, il faut bien évidemment que la base soit fonctionnelle même si tout n'est pas traduit...
