Internationalisation - comment gérer la traduction de données ? [Résolu]

[pgcdn2]

Bonjour à tous,

ma société déploie son SI sur ses filiales à l'étranger. (Oracle 10g)
Un nouveau besoin apparaît:
==> permettre aux utilisateurs d'afficher des données (exemple: devis, libellés de produit) dans une autre langue.
Cela ne concerne qu'un nombre restreint de données dans la base de données. Ces données seront traduites par les utilisateurs eux-mêmes dans un nouveau module du SI.

Les problématiques sont donc:

PB1: comment paramétrer la base de données pour qu'elle accepte le maximum de langue ?
Ex: FRA, ITA, ENG, TUR, ESP obligatoire. CHI peut-être.
Faut-il par ex remplacer les VARCHAR2 par des NVARCHAR2 ?

PB2: comment mettre en place, au niveau de la base de données, la traduction de données ?

-2 solutions identifiées à ce jour:
a. ajouter, pour les colonnes à traduire, autant de colonnes que de langues à gerer. Ex: TABLE1.LIBELLE_FRA, LIBELLE_ENG, LIBELLE_TUR, LIBELLE_CHI,...
b. gerer les traductions dans des tables dédiés.
Ex: TABLE1_TRAD( CODE_LANG, LIBELLE)
Dans les 2 cas que faire de TABLE1.LIBELLE ?

PB3: comment minimiser les impacts sur les applicatifs et traitements qui exploitent la base de données ?

Solution: ne pas supprimer TABLE1.LIBELLE !
Mais du coup il faut d'assurer de la cohérence de TABLE1.LIBELLE avec les autres données. (trigger ? contraintes d'intégrité ?)

PB4: comment simplifier l'utilisation des données ?

Je n'ai par exemple pas envie que les développeurs soient obligés, pour afficher des données, de faire dans leurs requêtes SQL des DECODE(CODE_LANG,'FRA',LIBELLE_FRA,'TUR',LIBELLE_TUR,...) ou bien des jointures entre TABLE1 et TABLE1_TRAD. Je voudrais "leur cacher" les traductions.
Exemples d'utilisation "simple" souhaitée:

Code :

1
2
-call Set_MyLangIs('TUR');
SELECT LIBELLE_TRAD FROM V_TRAD_TABLE1;

ou bien quelque chose du genre:

Code :

-SELECT GetTraduction('TUR',LIBELLE) FROM TABLE1;

Mais je ne vois pas très bien comment faire...


Si quelqu'un a des idées ou a déjà été confronté à cette problématique...

Merci d'avance
Patrick.

[doc malkovich]

( vu en formation ) Si tu prends en CHARACTERSET de l'unicode ( UTF16 pour être tranquille ) ta base est internationale, il n'y a plus besoin de NVARCHAR2. Sinon en effet tu dois avoir des colonnes de ce type.

A ce que j'ai connu dans les tables de libellé tu as une colonne supplémentaire pour la langue, des vues suivant la langue et des users/synonymes qui vont bien sur les vues de la langue concernée.

Je ne sais pas si Oracle propose un mode natif d'internationalisation, ou alors il faut plusieurs instances ?

[Garuda]

J'ai une appli multi_langue sous ORAcle 11g/Oracle forms
Pour la traduction des libellés, j 'ai une table contenant

• - le code de la langue (Code ISO)
• - Le nom de la table référence à traduire
• - la valeur du code dont on doit afficher le libellé
• - le libelle traduit

Dans mes requêtes, lorsque j'ai besoin d'un libellé traduit, je fait appel a une fonction TRADUIT_LIBELLE (nom_table,valeur_code,code_langue) qui me renvoie le libellé traduit s'il existe
ex

Code :

1
2
3
 
SELECT cod_pays,NVL(traduit_libelle('PAYS',cod_pays,'eng'),lib_pays) "lib_trad",lib_pays FROM pays
ORDER BY 1

me donne

Code :

1
2
3
4
5
6
7
8
9
10
11
 
COD_PAYS    lib_trad    LIB_PAYS
AD    ANDORRA    ANDORRE
AF    AFGHANISTAN    AFGHANISTAN
AI    ANGUILLA    ANGUILLA
AL    ALBANIA    ALBANIE
AO    ANGOLA    ANGOLA
AQ    ANTARCTICA    ANTARCTIQUE
DE    GERMANY    ALLEMAGNE
DZ    ALGERIA    ALGERIE
ZA    SOUTH AFRICA    AFRIQUE DU SUD

J'ai le même fonctionnement pour

• les messages utilisateurs
• les élements d'interface des écrans forms traduit "à la volée" lors du chargement

[pgcdn2]

OK. Merci pour ces éléments.