FMX et internationalisation de projet

**free07** · 05/07/2012, 15h32

Bonjour,

Avec la VCL et le développement sous windows, il y a des méthodes pour internationaliser ses projets mais avec FireMonkey, comment cela se passe ?

Déjà, si on utilises les DLL pour traduire ses programmes ( une DLL par langue utilisée ), sous windows cela ne pose pas de problèmes mais avec Mac OSX, comment cela se passe ?

En bref, est ce qu'il éxiste de bonnes méthodes pour développer un programme sous plusieurs langues sans tenir compte de l'os cible, pour que cela fonctionne sous windows, sous osx, sous ios et android ?

Thierry

**ShaiLeTroll** · 05/07/2012, 17h50

J'ignore ce qui a été prévu mais j'opterais pour un fichier type INI
Verifier si le TIniFile fait parti de la RTL
Si RTL, alors, le code a été doublé, l'un par API Windows, l'autre par ce que fourni MAC ou alors manuel, à l'époque de la CLX, le doublement était présent
Si TInifile fait parti de la VCL, oublie alors !

Sinon, tu peux utiliser un TStringList qui contiendra ta table de conversion genre

Code ini :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Form1.Edit1.Caption=Salut
Form1.Button1.Caption=Hello
Form2.Memo1.Lines.Count = 2
Form2.Memo1.Lines[0]=Salut
Form2.Memo1.Lines[0]=Hello

A toi de voir, combien de fichier, un par langue évidemment
un par langue et par écran (plus de fichier mais plus rapide à lire)

Ou un Fichier XML

**free07** · 05/07/2012, 18h42

Ok, merci Shai pour ces idées.
Jusqu'à présent, avec la VCL, j'utilisais un fichier ressource ( .rc ) par langue avec les STRINGTABLE que je récupérai par un LoadString().

Sur mac, il me semble que les ressources sont aussi utilisées mais il y a tellement longtemps que je n'ai plus développé pour mac que je ne me souviens bien plus comme c'est géré et j'ai du mal à trouver des infos sur le sujet...

Thierry

**arkhamon** · 09/07/2012, 09h40

Salut,
j'ai pas personnellement essayé, mais tu peux peut être jeter un coup d'oeil sur le composant FMX.Types.TLang (http://docwiki.embarcadero.com/Libra...MX.Types.TLang) il me semble bien que ça pourrait résoudre ton problème de façon "élégante"...

Sinon effectivement la solution proposée par Shai est rapide et simple...

**free07** · 09/07/2012, 13h13

Salut
et merci arkhamon mais je vais m'en tenir aux fichiers ini.
En travaillant sur des fichiers, c'est + simple pour faire faire la traduction ( vu que c'est pas moi qui vais m'en charger ).
J'ai quant même essayé le composant TLang pour voir ce qu'il était possible de faire, malheureusement, il faut en gérer un par dialogue, en plus, malgré son apparente facilité d'utilisation, cela ne fonctionnait pas vraiment, normalement on change la langue utilisée en modifiant la propriété Lang, mais ce n'était pas le cas, le français fonctionnait mais pas l'anglais j'ai essayé avec LoadFromFile, même combat mais à l'inverse, l'anglais fonctionnait mais pas le français.
Il y a surement quelques chose qui m'a échappé mais je n'insiste pas vu que je ne trouve pas cela très pratique.
Je ne vois qu'un avantage à utiliser TLang, c'est la facilité pour traduire les Textes des composants visuels, cela se fait trés rapidement et facilement avec le concepteur
Je vais avoir beaucoup de messages à traduire, hors composants visuels, TLang ne sera pas vraiment pratique pour cela et c'est bien dommage.
Thierry

**arkhamon** · 09/07/2012, 13h37

ok je comprends.
Il semble en effet que TLang ait une portée dnas la fiche où il est posé.
Par contre, je te propose de regarder le fiormat XML comme le proposait Shai, ça offre plusieurs avantages :

c'est cross plateforme. Pas comme les INI qui sont spécifiques à Windows. Si un jour tu passes sous FMX pour MAC OS, tu devras tout recommencer (je le sais, je suis en plein dedans...)
le format XML est vachement structuré et les types TXMLDocumetn et IXMLNode sont assez simples à utiliser, et sont cross plateforme

C'est peut être une piste assez intéressante à creuser...
D'autant que comme les fichiers XML sont structurés ca facilite la lecture. Il y a la contrainte des balises, maeis tu peux adapter l'architecture de ton fichier XML à tes fenetres et tes objets en utilisant la méthode ClassName (je crois) qui te renvoie le nom de ton objet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?xml version="1.0" encoding="UTF-8"?>
<ListeFenetres>
  <Fenetre1>
    <Bouton1>
		<FR>Ceci est el texte du bouton1</FR>
		<EN>This is bouton1 s Caption</EN>
		<DE>Es ist das bouton1 text<DE>
	</Bouton1>
	<Bouton2>
		<FR>Ceci est le texte du bouton2</FR>
		<EN>This is bouton2 s Caption</EN>
		<DE>Es ist das bouton2 text<DE>
	</Bouton2>
  </Fenetre1>
  <Fenetre2>
    <Label1>
		<FR>Ceci est le texte du Label1</FR>
		<EN>This is Label1 s Caption</EN>
		<DE>Es ist das Label1 text<DE>
	</Label1>
 
  </Fenetre2>
</ListeFenetres>

ou un truc de ce genre...

**arkhamon** · 09/07/2012, 13h47

Après tu fais comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Var Langues : TXmlDocument;
    Node : IXMLNode;
.../...
Langues := TXmlDocument.loadfromFile('NomFichier.xml');
RacineLangue := Langues.DocumentElement; // je suis un peu faineant...
.../...
// pour fixer automatiquemeent le texte du bouton1 de la fenetre1 en fonction de la langeu choisie...
Bouton1.Text := RacineLangue.childnodes[Fenetre1.ClassName].ChildNodes[bouton1.Classname].ChildNodes[LangueChoisie].Text;
.../...

Vérifier quand même pour ClassName j'ai un petit doute d'un coup, et comme j'ai pas mon Delphi sous la main...

En même temps, je suis un fanatique du fichier XML...

Après, tu as qu'à traiter l'évènement "changemetn de langue" en balançant le message à tous les composants qui doivent gérer le multi langue et hop c'est plié...

**free07** · 09/07/2012, 15h10

Envoyé par arkhamon

c'est cross plateforme. Pas comme les INI qui sont spécifiques à Windows. Si un jour tu passes sous FMX pour MAC OS, tu devras tout recommencer (je le sais, je suis en plein dedans...)
le format XML est vachement structuré et les types TXMLDocumetn et IXMLNode sont assez simples à utiliser, et sont cross plateforme

Heu... FMX pour mac os, j'y suis aussi car mes plateformes cibles sont multiples ( windows, osx, ios et pourquoi pas android )
Oui, j'ai pensé aussi que les INI ne sont présent que dans le monde Windows mais en même temps je me suis dit que cela n'est pas bloquant car les INI ne sont que des fichiers textes légèrement structurés et que je pourrai les gérer pratiquement de la même façon sous mac.
J'ai eu une petite expérience de dev sous mac ( durant 6 mois ) mais c'était il y a 20 ans !!! je me souviens même plus de l'outil que l'on utilisait, c'était du pascal mais il n'y avait même pas de débogueur intégré !

Il me faudrait une bonne doc ou un bon bouquin sur le dév pour l'OSX ( peu importe le langage utilisé ), j'en avais une à l'époque qui faisait référence mais je ne me souviens plus du titre ni du nom de l'auteur.
Si tu en connais, je suis preneur

Envoyé par arkhamon

Vérifier quand même pour ClassName j'ai un petit doute d'un coup, et comme j'ai pas mon Delphi sous la main...

En même temps, je suis un fanatique du fichier XML...

Après, tu as qu'à traiter l'évènement "changemetn de langue" en balançant le message à tous les composants qui doivent gérer le multi langue et hop c'est plié...

LE XML, c'est surement une idée intéressante par contre je me demande si c'est exploitable sous ios, surement que oui, je vais creuser cette idée.
Merci pour ton aide

**arkhamon** · 09/07/2012, 15h43

Envoyé par free07

Heu... FMX pour mac os, j'y suis aussi car mes plateformes cibles sont multiples ( windows, osx, ios et pourquoi pas android )
Oui, j'ai pensé aussi que les INI ne sont présent que dans le monde Windows mais en même temps je me suis dit que cela n'est pas bloquant car les INI ne sont que des fichiers textes légèrement structurés et que je pourrai les gérer pratiquement de la même façon sous mac.

oui le INI c'est juste un fichier texte...

Envoyé par free07

J'ai eu une petite expérience de dev sous mac ( durant 6 mois ) mais c'était il y a 20 ans !!! je me souviens même plus de l'outil que l'on utilisait, c'était du pascal mais il n'y avait même pas de débogueur intégré !

Il me faudrait une bonne doc ou un bon bouquin sur le dév pour l'OSX ( peu importe le langage utilisé ), j'en avais une à l'époque qui faisait référence mais je ne me souviens plus du titre ni du nom de l'auteur.
Si tu en connais, je suis preneur

Y a pas...

Non je déconne. Y en a, mais c'est pour Objective-C, pas pour Delphi. Mais t'inquiete pas, si tu le fais sous Delphi en FMX, pas besoin de doc spécifique pour OSX, la lib fait tout. Quelques petites bizarreries en particulier justement pour les fichiers XML dues aux spécificités d'encodage (UTF-8 et UTF-16), et une gestion un peu différente du transtypage de classe mais sinon c'est presque identique. Y a aussi la différence au niveau des chemins de fichiers mais ça tu dois maîtriser...

Envoyé par free07

Le XML, c'est surement une idée intéressante par contre je me demande si c'est exploitable sous ios, surement que oui, je vais creuser cette idée.
Merci pour ton aide

C'est vrai que j'ai pas testé sous IOS. Mais à priori ca devrait fonctionner : les classes de gestion du XML font "juste" du parsing de fichier texte, et il me semble que IOS permet d'utiliser des fichiers texte. Donc ca devrait fonctionner. Et ca a le mérite d'être dispo...

**ShaiLeTroll** · 09/07/2012, 16h48

TIniFile fait parti de la RTL
Si Windows, cela utilise les API
Sinon c'est en fait un TMemIniFile qui force le UpdateFile à sa destruction !
Et pour info, c'est le cas depuis D6\Kylix pour Linux !

Interessant ce TLang, il faudrait le pousser plus loin, cela DOIT fonctionner !
free07 as-tu testé la DEMO FMX.MultiLanguage Sample
Si l'on regarde, leur fichier sont de la forme Native=Traduction !
Cela ressemble à un système que j'ai vu chez un ancien employeur, MultiLizer, il fallait transmettre le texte à traduire !
J'espère que l'algo de recherche est plus rapide qu'une simple TStringList triée !!!

Pour XML, cela utilise l’implémentation DOM enregistré par RegisterDOMVendor
Selon VCL ou FMX, il ne doit pas utiliser la même chose !
et sous FMX, cela doit changer en fonction d'une directive de l'OS Cible donc
soit Xml.Win.msxmldom.TMSDOMImplementation
soit ADOM OpenXML - Xml.adomxmldom.Tox4DOMImplementation
ce dernier remplace TOXDOMImplementation de C++Builder 6 dans .\Source\Internet\oxmldom.pas de Kylix

FMX fait juste re-découvrir qu'il existait un multi-plateforme Delphi\Kylix, il y a de cela 10 ans et qui a été stupidement abandonné pour le .NET (qui a été l'arnaque multi-plateforme du siècle)

**free07** · 09/07/2012, 17h23

Envoyé par ShaiLeTroll

Interessant ce TLang, il faudrait le pousser plus loin, cela DOIT fonctionner !
free07 as-tu testé la DEMO FMX.MultiLanguage Sample
Si l'on regarde, leur fichier sont de la forme Native=Traduction !
Cela ressemble à un système que j'ai vu chez un ancien employeur, MultiLizer, il fallait transmettre le texte à traduire !
J'espère que l'algo de recherche est plus rapide qu'une simple TStringList triée !!!

Oui, j'ai testé la démo et elle fonctionne trés bien, c'est pour cela que j'ai précisé que quelque chose a du m'échapper mais en même temps j'ai laissé tombé car je crains de m'embêter à extraire tous les messages à faire traduire.
Avec TLang, on peut exporter ces messages dans un fichier .lng mais le format de ce fichier m'a paru bizarre, normalement un fichier lng peut être directement visualisé sous notepad mais ce n'était pas vraiment le cas, en plus, il y avait tous les messages traduis dans les 3 langues que j'ai utilisé pour essai.
Cela m'a étonné car si j'exporte tous les messages 'français' dans un fichier francais.lng, je devrais avoir que le français mais il y avait aussi les autres langues...
Par manque de temps, j'ai pas poussé mes essais plus loin.
Il y a aussi le fait que sur un dialogue, c'est bien pratique pour traduire le texte des composants visuels mais qu'en est il des messages que l'on veut afficher durant l’exécution du programme ?
A première vue, j'ai pas trouvé cela facilement exploitable.
Si quelqu'un a une expérience avec TLang, je veux bien la partager

**SergioMaster** · 10/07/2012, 08h13

Envoyé par free07

Oui, j'ai testé la démo et elle fonctionne très bien, c'est pour cela que j'ai précisé que quelque chose a du m'échapper

Et bien on est 2

, moi aussi j'ai essayé cette démo et me suis retrouvé gêné pour l'appliquer sur mon programme d'essai

[Edit]
Pour ce qui est des messages a traduire , par contre , je pense qu'il faut faire comme avec l'outil de traduction intégré de D2010 , c'est a dire extraire les chaines de ressources (via l'option du menu Refactoring) .J'ai comme l'impression qu'il y a un bug ou une incompréhension de ma part pour la construction de TLang :

Analyser les chaines ne fait rien pour ce qui concerne les messages
Quelle différence y a t'il entre un fichier lng et un fichier .TXT que l'on a généré comme fichier modèle (quand on regarde la demo il existe les fichiers TXT)

Bref l'ensemble Tlang est perfectible

J'ai encore quelques jours la version Test XE2 Architect , si je trouve un trou dans mon emploi du temps je referai un test .

Comme le dit

Envoyé par ShaiLeTroll

Interessant ce TLang, il faudrait le pousser plus loin, cela DOIT fonctionner !

**Nexavi** · 11/07/2012, 10h17

Analyser les chaines ne fait rien pour ce qui concerne les messages

. A l'époque de vgScene il y avait la fonction translate(''), j'imagine qu'elle doit toujours être disponible, peut être a-t-elle été renommée.

Translate() permettait de traduire les chaînes non détéctées automatiquement (seul les hints et la prop. text des dérivés de TTextControl sont gérés)

Si elle existe toujours, il suffit de rajouter manuellement des items dans le TLang. La fonction translate() choisira alors, au run-time, la string traduite si dispo.

Ensuite, pour faciliter le process, il est possible, par exemple, de créer un code-tool, qui parse tous les appels à Translate() dans les sources d'un projet...petite idée au passage.

**free07** · 11/07/2012, 13h31

Envoyé par SergioMaster

Et bien on est 2

, moi aussi j'ai essayé cette démo et me suis retrouvé gêné pour l'appliquer sur mon programme d'essai

[Edit]
J'ai comme l'impression qu'il y a un bug ou une incompréhension de ma part pour la construction de TLang :

J'ai la même impression, j'ai essayé la démo, cela fonctionne.
Après j'ai fait un essai avec 2 TLabel et 1 TButton qui me permet de changer de langue ( 'fr' ou 'en' )
Et bien le français fonctionne, mais lorsque je click sur le bouton pour passer en anglais, cela ne fonctionne plus, comme s'il ne trouvait pas les textes en anglais, il m'afffiche simplement les textes des labels par défaut ( lors de la conception )
Si je reclick pour passer en français, ca fonctionne.
Pire, si je met l'anglais par défaut, je lance le programme, il m'affiche bien les textes en anglais, si je click pour positionner la propriété Lang à 'en' ( anglais) , cela ne fonctionne pas, de nouveau les textes par défaut et pourtant, je vérifie bien ma propriété Lang, elle contient exactement la même valeur, à savoir 'en'.
Bon, vous me direz que c'est con d'affecter la même valeur à 'Lang', mais c'est juste un essai et cela devrait fonctionner
Je comprends vraiment pas ce qu'il se passe... Y a quelque chose qui m'échappe...
En plus, lorsque j'ajoute une langue avec le concepteur, j'ai un beau message de violation

Ca empêche pas de finir la conception mais cela crée un doute sur la fiabilité du composant.

Envoyé par SergioMaster

Analyser les chaines ne fait rien pour ce qui concerne les messages
Quelle différence y a t'il entre un fichier lng et un fichier .TXT que l'on a généré comme fichier modèle (quand on regarde la demo il existe les fichiers TXT)

Bref l'ensemble Tlang est perfectible

J'ai trouvé le format des fichiers lng assez bizarre, on ne peut même pas les visualiser correctement avec un notepad

D'ailleurs, j'ai repris la démo de TLang, je lui ai ajouté d'autres langues et le programme n'est tient jamais compte, pour lui, il y a toujours 4 langues

Alors, bon, pourtant ajouter une langue, c'est simple, on click sur le bouton ajouter du concepteur, on saisit l'abréviation de la langue sur 2 caractères et on click de nouveau sur ajouter pour confirmer
ou alors je me trompe ???

En tout cas, merci pour ton retour d'experience, je vois que je ne suis pas le seul

Invité · 25/07/2012, 15h03

Bonjour,

Comme je suis en période de choix "stratégique" qui va m'engager pour un long terme (Java Vs Pascal), le point de référence de tous mes derniers développements étant Lazarus/FPC :

Delphi FMX (voire Dephi VCL) ne gère pas le i18n comme Lazarus (ie quasi automatiquement) ? D'autre part, traduire le caption des Labels est une chose, mais les Dialogs, il faut les traduire aussi ?

Cordialement. Gilles

**ShaiLeTroll** · 25/07/2012, 15h52

Les Dialogues, ça dépend ceux dont les textes sont fourni par l'OS, il n'y a rien à faire

Pour les autres, il faut changer les resourcestring, c'est pour cela qu'il y a souvent un dossier 'fr', 'de' et 'jp' dans les sources

J'ignore comme c'est sous Lazarus, mais sous Delphi VCL, l'ITE existe depuis toujours et en plus il y a l'ETM pour le faire faire par un traducteur pro

Si c'est l'Internationalisation et la localisation qui est le choix entre Delphi et Java, ça me semble étrange !
Il y a des points plus importants, le déploiement, les matériels et OS cibles, client lourd\client léger, interop, n-tiers ( RMI ou SOAP en Java ou DataSnap REST en Delphi par exemple)

Invité · 25/07/2012, 15h59

Bonjour,

Désolé pour mon intervention mais comme je l'écrit dans un autre Post, je cherche des renseignements sur FMX et donc je parcours depuis quelques mois votre forum assidûment. Je ne traduisais pas mes programmes quand j'utilisais Delphi 7.
Mais un code comme précisé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

RacineLangue.childnodes[Fenetre1.ClassName].ChildNodes[bouton1.Classname].ChildNodes[LangueChoisie].Text;

n'est pas du tout ce que je pratique... et me fait fuir.

J'ai une unité Translation en Lazarus (fournie avec Lazarus) qui donc utilise les resourcestring. Il en est de même pour tous les contenus fixes des Forms et même des composants sans aucune complication et aucun code supplémentaire que celui qui appelle l'unité de Translation dans la Form ou le composant.

Cordialement. Gilles

**ShaiLeTroll** · 25/07/2012, 16h04

AVANT Il faudrait vérifier le TLang et sa démo FMX.MultiLanguage Sample

Semble que certains ont des difficultés avec le TLang d'où ce code manuel qui est écrit une seule fois dans un composant !
il faut écrire un code générique utilisant les RTTI (SetPublishedProp et ses copains) qui va lire le fichier XML en fonction de la XFM
Il évident qu'écrire ce code manuellement pour chaque fenêtre et chaque bouton est idiot, c'était un Exemple !
Un peu d'imagination !

Si une pauvre lecture d'un XML te fait fuir, tu vas courir très longtemps alors !

Comment gères-tu la traduction des TForm en Lazarus ?
Tu as un fichier de conversion de chaque libellé ? est-un autre DFM ?
Une fenêtre en Anglais n'aura pas la même disposition qu'une fenêtre en portugais car les textes sont parfois 2 fois plus long, il faut donc aménager les composants en fonction cela !

Tu veux multi-platforme ou pas ?

Invité · 25/07/2012, 16h11

Ok, OK... On ne s'énerve pas. On en reste là. J'utilise simplement, très simplement, i18n en Lazarus et en Java. Aussi je me demandais pourquoi ce problème en FMX ? Visiblement, j'en suis tellement loin que je n'arrive même pas à l'imaginer. Il faut des RTTI. Ok je n'arrive pas à faire le rapport avec internationalization.
Pour répondre à vos questions :
Pour le fichier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
msgid ""
msgstr "Content-Type: text/plain; charset=UTF-8"
 
#: ulzlic.rsReleaseAbbrev
msgid "rel."
msgstr "vers."
 
#: ulzlic.rsUnknownMacAddress
msgid "Unkwnow MAC address"
msgstr "Adresse MAC indéterminée"
 
#: ulzlic.rsFirstServerNotFound 
msgid "First server not found"
msgstr "Premier serveur non trouvé"

Quant à la différence de taille, on a un système d'ancrage que je trouve très bien fait et extrêmement compétitif. Vous avez sans doute mieux.

Comme quoi un pauvre Lazarusien ferait mieux de se taire.
Cordialement. Gilles

**ShaiLeTroll** · 25/07/2012, 16h17

les RTTI c'est ce qui gère les DFM en Delphi !
le mot clé published indique justement cela !
Pour énumerer le propriété Caption et Text des TLabel ou TEdit, cela se fait par les RTTI !

Et comme je le disais, c'est déjà censé exister sous la form du TLang
N'ayant pas essayé moi-même encore, j'ignore si celle fonctionne bien ou pas, cela m'étonne autant que toi que l'on doivent le faire manuellement !
As-tu pris 5 minutes pour tester la démo chez toi ?

l'intégration de FMX dans le RAD est assez récente,
Pour moi, c'était plutôt conçu à la base une lib graphique (VgScene) et non une lib applicative !

Difficile de comparer Lazarus qui existe depuis 10 ans et FMX qui n'existe que de puis 2 ans (ou 5 en version indep)

Pour les Anchors, on a je pense pareil, je pense surtout au séquence comme de TLabel et Edit comme dans Nouveau Message d'Outlook
La position du TEdit va plus ou moins à droite en fonction de la taille du Label selon le plus long d'une langue, là je ne vois pas ce que les Anchors peuvent faire pour remédier à cela !

FMX et internationalisation de projet

Composants FMX Delphi

Discussions similaires

Partager

Partager