CREER UNE APPLICATION MULTILINGUE VRAIMENT TRES FACILEMENT (+ EDITEUR DE LANGUE)
ghuysmans99
Messages postés
2496
Date d'inscription
jeudi 14 juillet 2005
Statut
Contributeur
Dernière intervention
5 juin 2016
-
16 janv. 2007 à 22:22
nelson - 16 déc. 2015 à 10:56
nelson - 16 déc. 2015 à 10:56
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/41142-creer-une-application-multilingue-vraiment-tres-facilement-editeur-de-langue
https://codes-sources.commentcamarche.net/source/41142-creer-une-application-multilingue-vraiment-tres-facilement-editeur-de-langue
16 déc. 2015 à 10:56
24 oct. 2012 à 08:19
j'ai egalement apprécié l'ajout du support SSTab, mais celui ci ne semble par marcher.
la mise ne oeuvre a été d'ajouter les bouts de code à la fin de ta précédente source
mais sans résultats.
le fait de désactiver le "On error resume next", fait planter le programme avec une erreur tableau.
as tu des infos ?
merci par avance
5 mars 2012 à 13:07
J'ai ajouté le support des SSTab (voir code ci-dessous a ajouter au ctrl). Par contre je bute sur le TreeView. En effet j'ai ajouté la ligne "If TypeOf Obj Is TreeView Then" mais le treeview n'est pas détecté, donc ne passe pas dans la boucle. Si quelqu'un a une idée...
Public Sub LoadControlsCaption()
If TypeOf Obj Is SSTab Then
'on prend les captions des tab
'vérifie que le tag est Ok
If InStr(1, Obj.Tag, "lang_ok", vbBinaryCompare) Then
'c'est bon, ol loade
'récupère le nombre d'éléments
Y = Val(Me.GetString(s & "|Count"))
'ajoute les éléments
For X = 0 To Y
Obj.TabCaption(X) = Me.GetString(s & "|Item" & Trim$(Str$(X)))
Next X
End If
End if
End Sub
'=========================================================================================
Public Sub WriteIniFileFormIDEform()
If TypeOf Obj Is SSTab Then
'vérifie que le Tag est OK
If InStr(1, Obj.Tag, "lang_ok", vbBinaryCompare) Then
'c'est bon, on sauvegarde
'récupère le nombre d'éléments
LetPref mParent.Name, s & "|Count", Obj.Tabs.Count, sFile
Y = Val(Me.GetString(s & "|Count"))
'ajoute les éléments
For X = 0 To Y
LetPref mParent.Name, s & "|Item" & Trim$(Str$(X)), Obj.TabCaption(X), sFile
Next X
End If
End if
End Sub
27 nov. 2007 à 13:48
@+
27 nov. 2007 à 10:39
Désolé j'ai pas lu tous les posts, mais ton ocx peut il supporter plus de 2 langues?
30 avril 2007 à 16:28
Je pense que je vais en faire une classe pour éviter ce genre de bug -___-
@+
6 avril 2007 à 14:33
J'ai aussi ajouté le support des ListView (ColumnHeader) et des TabStrip (Tabs.Caption)
@+
5 avril 2007 à 23:31
Enfin bon, j'ai aujourd'hui plus que jamais la flemme de me lancer dans les bases de données ;)
Mais je note que ce serait à faire.
@+
5 avril 2007 à 23:26
Je viens juste dire que j'ai implanté cet UserControl dans mon projet qui possède tout de même 41 forms.
Résultat : le fichier de langue fait 51Ko, et le temps mis pour faire la traduction (c'est à dire dans chaque Form_Load) est négligeable !
Donc pas besoin à priori de base de donnée pour des projets de cette taille et inférieure ! Le résultat est très satisfaisant.
J'ai également créé un éditeur de fichier de langue. Si vous en avez besoin, demandez moi et je l'uploaderais avec cette source...
@+
27 mars 2007 à 14:35
@+
27 mars 2007 à 13:15
22 janv. 2007 à 22:53
22 janv. 2007 à 21:30
22 janv. 2007 à 19:46
non :
/*le fichier binaire*/
int(2) 'Nombre de clef (4 Octets)
int(7) 'Nombre de caractére de la clef 1 (4 Octets)
string("MaClef1") 'Clef 1 (7 Octets)
int(34) 'Offset fichier de la clef 1 (4 Octets)
int(7) 'Nombre de caractére de la clef 2 (4 Octets)
string("MaClef2") 'Clef 2 (7 Octets)
int(46) 'Offset fichier de la clef 2 (4 Octets)
int(8) 'Nombre de caractére de la Valeur 1 (4 Octets)
string("MaValeur") 'Valeur de la clef 1 (9 Octets)
int(9) 'Nombre de caractére de la Valeur 2 (4 Octets)
string("MaValeur2") 'Valeur de la clef 2 (9 Octets)
/*Fin du fichier*/
Au démarage :
Ouverture du fichier
DerniereClef=LireInt
Pour CompteurClef = 0 à DerniereClef-1
Lire Paire Clef + Offset et la charger dans un tableau
Fin Pour
Pour obtenir une valeur:
Rechercher la clef dans le tableau,et récupérer l'offset associé
Placer le pointeur de fichier sur l'offset trouver
Lire la chaine et la retourner.
Il n'ya pas d'octets mort dans le fichier.
/*Pour le fichier ini, là encore ce sera bien trop lont pour un fichier assez volumineux : les recherches dans un fichier ini sont très loin de valoir les recherches dans une bdd !*/
On a pas du se comprendre car effectivement c'est la moin bonne solution niveau perf.
Je parlait juste d'un petit programme qui générerai le Bin a partir du INI (a lancer une seule fois par le dévelloppeur, bien évidement seul le Bin est déployer, le ini est juste là pour faciliter le travaille en ammont. Pas facile d'écrire direct un fichier binaire!!!)
Je vais essayer de trouver un peu de temps pour faire une source pour illustrer ce que je t'ai dis et on pourat Comparer les perfs si tu fais une ch'tite version BDD.
22 janv. 2007 à 18:37
Quand à ta solution du fichier binaire, oui excellente idée, MAIS cela veut aussi dire que tout les textes soient de la même longueur... car sinon ton astuce de positionner l'offset du fichier au bon endroit pour lire uniquement la string voulue ne tient plus la route (du coup, perte énorme de place), ou alors faire une table des chaînes, cà aussi, ok, mais ca oblige quand même de coder dans l'ocx la liaison component<->key, et le stocker quelque part, donc on tourne en rond !
Pour le fichier ini, là encore ce sera bien trop lont pour un fichier assez volumineux : les recherches dans un fichier ini sont très loin de valoir les recherches dans une bdd !
Non franchement, une bdd permet un accès rapide aux données (il suffit d'indexer les quelques champs de recherches), une extension à l'infini du nombre de chaîne stockable sans trop ralentir l'exécution (chargement des données à la demande avec une requête SQL), et pas de prise de tête avec un algorithme compliqué à implémenter.
Après, on peut bénéficier de tout les apports de la BDD : index, clés primaires, procédures stockées, possibilité de stocker des images (bien que pas très recommandé) pour une interface qui contient des images textuelles, etc.
Quant au déploiement de l'application, si c'est une base access, l'installation du MDAC suffit pour accèder à la base.
22 janv. 2007 à 18:07
1 point pour toi C'est vrai que VB6 gére pas les haschTable et c'est vrai aussi que se retaper tout a la main c'est long et pas forcement facile.
mais si chiant que ca puisse paraitre une fois réaliser, les perf seront bien meileurs.
Pour un system demandant vraiment bcp de texte localisé pour ma part je passerai pas par un fichier ini, mais par un fichier binaire :construit comme ca :
int nombre_de_clef
{
string Clef
int OffsetFichier
}* nombre de clef
{
string Valeur
}* nombre de clef
avec ca on ouvre le fichier, on charge les clefs
et quand on veut une valeur, on se place sur le bon octet du fichier (OffsetFichier) et on lit la chaine.
Comme ca la totalité du fichier est pas en mémoire.
et on ferme le fichier a la fin du programme.
Le problème c'est que le fichier n'est pas human readeable mais il suffit de faire un petit prog qui converti INI-->Bin et Bin-->INI
Enfin on pourat amméliorer en faisant une indexation type B-TREE sur les clef.
Tous ca c'est un peu long a codée mais toujours plus rapide que la BDD. il ne faut pas oublier qu'entre le programme et une BDD il y'a plusieurs couchee logiciel et chacune ralentie le process de récupération.
C'est vrai, l'utilisation de base de donnée permet de s'affranchir de tous ces problèmes.
Mais je crois que créer un system comme celui énoncer(ou meilleur) apporte une meilleur réponse.
SAUF si le programme utilise déjà une base de donnée biensur.
A Toi...
22 janv. 2007 à 15:55
Je me suis mal exprimé, ce que j'entend par éditeur de propriétés ce serait une fenêtre ou une interface avec une liste des contrôles présents sur la feuille (listés par un combo par ex) et des zones de saisie pour paramètrer les propriétes (caption, text, tooltip, etc...) selont le language choisi. En gros ajouter une interface graphique à ta source.
Bonne prog @ts
22 janv. 2007 à 14:51
Surtout que tu n'as pas besoin de lire les 100 Ko, vu que ce sera (en théorie, à moins de faire un fichier par feuille, mais là cà devient vite ingérable) une lecture de quelques Ko par feuille.
> avec une bdd, pas besoin de lire tout le fichier texte afin de construire une hashtable, on a uniquement besoin de lire les enregistrements pour la feuille courante > une simple requete SQL pour récupèrer les enregistrements de la feuille à charger, une lecture de chaque enregistrement et hop, c'est chargé.
Petite remarque : là on parle vb6 et non vb.net : en vb6, il n'existe pas (à ma connaissance) de hashtable implémentée de base, donc à moins d'en trouver des implémentations libres de droits (cà doit exister quand même) et très efficace (ca c'est déjà plus dur), il faut se faire l'algorithme de la hashtable (et là, c'est pas donné à tout le monde, perso, je ne sais pas faire).
22 janv. 2007 à 14:43
C'est sur le faite que les BDD sont optimiser que tu te trompe. les BDD ne sont optimiser que dans la mesure ou leur administrateur les optimises. et pour des volumes de donnée moyen sans system relationnelc'est comme d'utiliser une masse d'arme à la place d'un marteau tout con pour planté un clou. je le répette, a mon avis la base de donnée n'est pas utile.
Pour info, fais quelque tests sur les objets de System Collection, tu trouvera Hashtable et HybridDictionary qui sont des objets perfomants, et ne néscéssite pas la création d'un code de hashage.
comme je l'ai indiquer, cette méthode convient pour des fichier qui peuvent êtres stocké en mémoire(donc pas trop gros,~100ko par langue sans soucie ce qui fais déjà un paquet de texte).
compare les temps pour recupérer la ligne depuis access et depuis la hashtable (déjà charger, on considére qu'elle est charger au démarrage du prog ou lors du changement de langue) a mon avis tu vas vite te rendre compte que c'est bcp plus rapide.
22 janv. 2007 à 13:49
Il n'est nullement besoin qu'un client possède access pour utiliser un logiciel avec une base access (et encore heureux !).
Et c'est là où c'est abhérant : sur un petit programme avec une dizaine de texte à traduire, c'est sûr que tu ne va pas y voir grande optimisation à utiliser une bdd, par contre sur une logiciel qui utilise des centaines et des centaines de ressources textes qu'il faut traduire, va stocker cà dans un fichier avec des temps de chargement raisonnable, je te souhaite bon courage ! Ton idée de hashtable c'est bien, mais ca t'oblige à faire un algorithme rapide de lecture des données (et leur parsing donc), et de stocker efficacement les données afin de pas occuper trop de mémoire.
La bdd permet justement de ne pas se prendre la tête niveau performance : elles sont déjà optimisées pour un accès rapide aux données, avec des structures de données assez efficace pour ne charger que ce dont on lui demande.
Si tu arrive à trier 2 millions de lignes avec des critères très complexes en 4 dixièmes de secondes qui comprend : la lecture des données, le parsing de celles-ci, plus l'application de l'algo, là tu m'intéresse ! On peut fonder une boîte encemble car oracle peut fermer boutique !
22 janv. 2007 à 13:11
A mon avis parler de base de donnée est un abération, plusieurs problème dont le plus important est le déploiement.
lors du déploement, on oblige l'utilisateur a avoir Access, SQL serveur express ou même Excell(Je sais c'est pas de la BDD) tout ca pour avoir son programme en francais???
Je crois que quelque classe toute simple devrait pas poser de problème et être suffisament rapide. si les fichiers de langue ne sont pas trop gros, on peu les laisser en mémoire
ensuite on utilse une béte HaschTable (prototype de la classe :
Class MesRessources
Private Ressources As new HaschTable ()
Public Sub LoadRessource(Fichier_Ressource as string)
'Chargement du fichier dans la hashtable
End Sub
Public Function GetString(StringName As string)
return Ressources(StringName)
End Function
End Class
Les base de donnée c'est super mais il faut pas les sortirs a tout bout de champ car elle sont rapide mais au pris de ressources utilisé, et y'a-t-il vraiment besoin d'un moteur de base de donnée pour les quelques opérations requise?.
Ca me rapelle un petit probléme dans un programme je devais trier des lignes de basse de donnée(2000000) avec des critères trés complex et de maniére la plus rapide possible. la base de donnée ne pouvait pas marché car certain des critères n'était pas exprimable en TSQL(RegEx Complexes...). j'ai commencé mon algo et je suis arrivé trés vite a un algo de trie qui métait ~54s puis le restant de la journée je me suis battut pour obtimiser l'algo et le soir le trie se faisait en 4 dixième de secondes!!!
Donc les Base de donnée ne sont pas la réponse à tous les mots. il faut aussi se retroussé les manches.
17 janv. 2007 à 23:51
Il suffit donc pour le programmeur de gérer le tag des composants en fonction de leur utilisation (par exemple modifiable ou non pour une listbox), d'ajouter la gestion du tag dans le code si désiré (par exemple pour les textboxes) et de sauvegarder la langue (un SaveSettings suffit) pour la charger au démarrage si désiré.
@+ et merci.
17 janv. 2007 à 23:16
17 janv. 2007 à 23:02
pit1 ==> merci pour le lien, et effectivement je vois l'intérêt de pouvoir sauver ses strings traduites dans l'IDE
poldere ==>
"Je démarre en français , je change en anglais, je ferme le prog, je ré ouvre et il est en français" ==> évidemment, ce code n'a pas pour but de sauvegarder la dernière langue utilisée. A toi de mettre une valeur dans le registre (string qui contient la langue) et de charger la langue correspondante au démarrage.
"Un fichier init devrait aider à initialiser le programme comme on l'a laissé . . . . . ou je fais une fausse manip ?" ==> ah non, pas nécessairement. En tout cas, pas les fichiers ini de langues. C'est à toi de créer un fichier ini qui contiendra les préférences (dont la langue)
"Quand on écrit un text dans les textbox il n'est pas prid en compte :
test avec " bonjour " , créer le fichier , en anglais j'ai autre chose. quand on écrit quelque chose dans un textbox c'est pour le garder malgré la traduction" ==> A toi de gérer le tag "lang_ok" (c'est à dire à l'ajouter comme condition sur tes textboxes (voir code, se calquer sur ce qui est fait avec les listboxes)). Idem pour les listboxes, (mais là c'est déjà codé) : il FAUT mettre le tag "lang_ok" pour permettre la sauvegarde de la traduction. Sinon, pas de sauvegarde est c'est alors une listbox dont les valeurs seront rentrées par l'user.
Bref, tu n'as pas vraiment compris la subtilité du tag (as tu lu la description en entier ?).
@+ et merci pour les commentaires
17 janv. 2007 à 21:39
Je démarre en français , je change en anglais, je ferme le prog, je ré ouvre et il est en français ! ! ?.
Un fichier init devrait aider à initialiser le programme comme on l'a laissé . . . . . ou je fais une fausse manip ?
Quand on écrit un text dans les textbox il n'est pas prid en compte :
test avec " bonjour " , créer le fichier , en anglais j'ai autre chose. quand on écrit quelque chose dans un textbox c'est pour le garder malgré la traduction.Pareil dans les listbox à mon humble avis . . . A méditer . .
Merci
17 janv. 2007 à 21:18
http://www.vbfrance.com/codes/GESTION-AUTOMATIQUE-FICHIER-INI-ADDIN-VB_40151.aspx
Dans l'IDE, tu pourrais demander la traduction pour un contrôle particulier ou sous forme de tableau pour tous les contrôles du form. Cela te permetterais aussi de changer les textes en mode run-time, avec l'avantage de voir si les contrôles sont suffisament dimensionnés pour afficher tout le texte (Certaines langues ont besoin de plus de place que d'autres).
Sans avoir regardé le code, cela me semble bien fait! Bravo pour l'idée!
17 janv. 2007 à 18:35
J'ajoute à contribution une idée sur le multilingue que j'ai déjà implementée dans une appli.
Le principe est le même, parcourir les objets et rechercher les propriétés de type texte. Par contre (chez moi c'est une gestion BD) au lieu d'avoir control.propriete=valeur francais ==> valeur anglais.
J'ai plutot controle.propriete= [id texte]
avec [id texte] la cle d'une table qui a en plus les champs [version francaise], [version anglaise], [Version allemande], ...
Ceci dit au moment de l'implentation de la bd des traductions tu devra specifier la langue de reference qui permet d'identifier si le texte existe deja et par consequent le grand avantage d'avoir une table commune des textes traduits partageable avec d'autres applis ou d'autres personnes, il suffit d'exporter vers excel pour se faire aider pour la traduction.
Je suis presse je dois partir s'il ya des commentaires on en reparle demain.
A+
17 janv. 2007 à 17:53
@+
17 janv. 2007 à 17:50
17 janv. 2007 à 17:12
Renfield ==> oui, c'est une erreur de ma part. Il faut en fait lire :
'récupère le nom de la langue
If IsMissing(Language) Then sLang Me.Language Else sLang Language
J'avoue que l'utilité du paramètre n'est pas forcément évidente non plus (récuperer une string d'une autre langue que celle du programme, pas très utile). Je changerais lors de la MAJ à venir ce petit bug.
Mayzz ==> c'est à dire un "éditeur de propriétés" ? Je ne cerne pas trop ce que tu veux dire par "changer les propriétés de tes contrôles en mode conception" ? Si tu veux parler d'un programme pour éditer de manière plus intuitive son fichier de langue, c'est pas un problème, j'essayerais de le faire.
Pour les fichiers de ressource, je ne connais pas vraiment, mais ce n'est peut être pas la meilleure idée si effectivement il y a beaucoup de lignes à tapper (c'est pour çà que j'ai codé çà, je me retrouve avec une form bourrée de controles et de menus (fichier ini généré qui fait quand même 15Ko) et je n'avais encore rien prévu pour la traduction, donc çà permet de minimiser le travail que je vais devoir faire.)
Pour les bases de donnée, c'est pas le sujet qui me passione le plus, mais j'avoue que c'est aussi parce que je n'y connais rien... mais c'est sûr qu'un bon tuto change tout ;)
moustachu ==> Un fichier par langue me semble aussi intéressant (plus simple d'implémenter une nouvelle langue ainsi). Et pour la base de donnée, oui, c'est presque obligatoire je pense pour les gros projets. A moins de faire un fichier ini par form... mais là c'est beaucoup moins intéressant niveau simplicité. A moins, encore une fois, de fournir un executable qui rend l'édition des fichiers très intuitive, et à ce moment inutile de trop regarder le dossier "Lang" (et les dizaines de fichier ini qui sont dedans).
guilleto ==> Effectivement, je n'ai pas du tout pensé à ce problème là... donc cela confirme l'emploi d'une base de donnée...
Donc : va falloir que je me renseigne sur les bases de données.... Erf, ce sera pas pour tout de suite je pense (bcp de boulot dans le mois à venir) mais je vais y réfléchir. De toutes manière, cette source sera ammenée à évoluer quand je rencontrerais des problèmes quant à son implémentation dans mon projet.
Merci beaucoup pour tous les commentaires ^^
@+
17 janv. 2007 à 12:17
Pour les applications que je développe il suffit de changer la Police du contrôle (MS Sans Serif) !
Il est toutefois exact (dire le contraire serait mentir) que ces applications ne fonctionnent pas très bien sur un PC français, anglais ou autres (affichage de '?' en lieu et place des caractères voulus), donc cela ne fonctionne uniquement si le PC gère les caractères cyrilliques !
Dans mon cas les programmes et donc l'affichage fonctionnent correctement en Russie, Tchéquie etc.
En espèrant que ces remarques pourront aider !
Olivier
17 janv. 2007 à 10:20
17 janv. 2007 à 10:13
J'ai moi aussi réalisé un programme (au boulot) traitant le multilangue !
J'ai travaillé avec des fichiers .txt à accès direct, des fichiers .xls et des fichiers .ini !
Ton programme fonctionne car les langues utilisées ne sont pas cyrillique (je pense au Russe et autres).
Pour résoudre ce problème j'ai opté pour une BdD sous Access.
Pour une utilisation avec des langues (non cyrilliques) ton programme est très bien. Mais dans le cas contraire tu auras des soucis d'affichage !
Olivier
Je mets 8/10 (-2 pour l'éventuel soucis dû au cyrillique)
Bonne continuation et encore bravo !
17 janv. 2007 à 08:58
C'est très courageux de s'attaquer à ce genre de problème :o)
Je suis plutôt partisan d'un fichier par langue, c'est peut être plus long mais c'est plus souple (à mon goût).
Une base de données ça ne me semble pas être du luxe, non plus...
++
Moustachu
17 janv. 2007 à 07:30
Tu as fais du beau boulot, c'est très utile ça, ça évite pas mal de galère.
Par contre dommage que ce ne soit sous la forme d'un éditeur de propriétés (un peu comme pour les éditeurs de skin), la tu es obligé de changer les propriétés de tes contrôles en mode conception, c'est un peu galère si ta form comporte beaucoup de contrôles.
Sinon pour ce qui est des fichiers de ressources, je les utilises et il est vrais que l'on peut y insérer plusieurs langages par ID mais on la sélection du langage se fait automatiquement selon les paramètres linguistiques de windows. Puis cela oblige à taper beaucoup de code (une ligne par propriété de contrôle), on peur tout aussi bien se servir d'un groupe d'ID différent pour chaque langue mais le résultat reste le même; trop de code à taper !
Pour finir je voulais juste dire qu'il est dommage que sur ce site, quasi aucun tutos sur les bases de données ne parlent des Data Environments et Data Reports car cela facilite bien l'apprentissage et l'usage des bases de données sous vb.
Bonne Prog @++
17 janv. 2007 à 07:00
If IsMissing(Language) Then sLang Me.Language Else sLang Me.Language
????
16 janv. 2007 à 23:19
@+
16 janv. 2007 à 23:14
DARKSIDIOUS ==>
1) oui, c'est une solution. Mais disons que je n'avais prévu pour mon programme de faire qu'une traduction en anglais (et peut être en allemand... qui sait...).
Donc implanter nativement plusieurs langues me semblait lourd, mais bon pourquoi pas.
2) ah, je veux bien le croire, je n'utilise jamais de fichiers de ressource donc je suis pas vraiment au courant ;)
3) oui, avec des centaines de feuilles, c'est sur ! Quoique 100,200 ou 300 feuilles c'est identique en l'état (avec un fichier par feuille). Mais si on met tout dans un seul *.ini, là oui, faut changer de méthode. Mais comme je ne maitrise pas les bases de données... ;)
4) Ah oui, c'est une bonne idée, çà. Alors certes ce ne sera pas très optimisé (si il faut charger les nouvelles propriétés à chaque fois), mais c'est sur que ce serait vraiment très pratique.
Je vais essayer d'y réfléchir demain si j'ai le temps.
@+, et merci encore pour les commentaires
16 janv. 2007 à 22:32
Nom du contrôle/Propriété à changer.
Exemple : addControl("reyTextBox", "Text")
Et tu stocke cà dans un autre fichier ini (vu que tu as l'air d'aimer les fichiers ini) afin de faire une sorte de base de données de propriétés de contrôles modifiables... là ca permettrait d'avoir un contrôle extensible très simplement !
DarK Sidious
16 janv. 2007 à 22:29
1/ je pense qu'il aurait mieux vallu gérer plusieurs langues dans un fichier : ton exemple est bien pour passer d'une langue native dans le prog à une autre, mais il n'y a pas de lien entre la langue native et celle du fichier.
Je m'explique : il aurait été mieux de faire un fichier contenant le texte en français, et la traduction en anglais/espagnol/italien/allemand, etc. Ainsi, il est plus facile de faire le fichier de traduction (c'est plus parlant et plus rapide : plutôt que Command1|Index|Text de faire : "Command1|Index|French="Texte"|English="Text"|Deutsch="Text")
Car là, ca nécessite de faire 1 fichier par langue. C'est bien pour rajouter facilement des langues, mais c'est plus long à faire je trouve !
2/ Il me semble que les fichiers de ressources permettent de faire cà directement : dans un fichier de ressource (il me semble, j'ai jamais essayé) que tu peux rajouter plusieurs langues, avec des textes pour toutes les langues avec le même ID partagé, et au lancement du prog, tu choisit telle ou telle langue à utiliser.
3/ Si ta méthode fonctionne sur de petits programmes, elle risque d'être relativement longue à effectuer pour des programmes avec des centaines de feuilles ! Peut-être qu'à la place d'un simple fichier ini, il vaudrait mieux une base de données à ce moment là (accès plus rapide aux données avec des requêtes et des index nottament).
DarK Sidious
16 janv. 2007 à 22:22
à côté de ca, ma source ne vaut RIEN ...
bravo !