Discussion :

[Papy214]

Hello tous,

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
 
function Confirm(Question: string; DefButton: TMsgDlgBtn; MsgDlgType: TMsgDlgType): Boolean;
var
  Dlg: FMX.Platform.IFMXDialogServiceSync;
begin
  if TPlatformServices.Current.SupportsPlatformService(IFMXDialogServiceSync, IInterface (Dlg)) then
    Result := Dlg.MessageDialogSync(
      Question,
      TMsgDlgType.mtConfirmation,
      [TMsgDlgBtn.mbYes, TMsgDlgBtn.mbNo],
      DefButton,
      0
    ) = mrYes
  else
    Result := False;
end;

L'application peut être mise en anglais avec DKLang.

Problème : Quand on utilise la méthode ci-dessus, le titre et les libellés des boutons sont en français si on est sur un Windows français.

Demande : Le client veut une traduction complète :-(

Question : Vais-je devoir me faire mon propre système de boite de dialogue ? Ou bien une méthode pas trop pourrie va-t-elle me permettre de faire plaisir au client à moindre frais ?

[SergioMaster]

Bonjour,

Très bonne question, tout ce que je sais c'est que ces "libellés" (ainsi que beaucoup d'autres) sont dans FMX.Const il doit donc être possible de les localiser (en plus c'est déjà des resourcestrings) d'un autre côté je me demande si c'est nécessaire (en VCL ce n'était pas le cas puisque c'était une histoire d'API).

[Papy214]

en VCL, j'avais trouvé une solution basée effectivement sur les resourcestring mais j'ai perdu le lien qui expliquait ça.
Et je ne sais pas si c'est valable en FMX.
Je vais essayer de retrouver la source et voir si ça peut s'adapter.

[SergioMaster]

Bonjour,

j'ai lu que l'on pouvait aussi redéfinir l'interface (aucune idée du comment ).
Je me bats avec une installation de DKLang sur mon nouveau poste mais j'ai été pollué par OneDrive sur ce dernier.
Sur le poste qui a "flambé" j'avais fait des tests que Gilles avait repris pour des messages https://www.developpez.net/forums/d1...duction-tlang/ mais on s'était contenté de showmessage (et donc du bouton universel OK) sans pousser vers les interfaces

[Papy214]

Peut-être que DKLang le permet ... Je n'ai pas fouillé de ce côté mais je vais retourner sur le site pour voir s'il y a des infos surle sujet .
Je ne l'utilise que de façon "standard".
J'ai d'ailleurs eu quelques soucis à l'utilisation avec certaines chaînes d'interface qui ne se traduisaient pas.
Il a fallu que je fasse une tradsuction manuelle pour certains onglet de TabControl par exemple.
Mais bon, c'est gratuit, je vais pas cracher dans la soupe.

[oneDev]

Il me semblait que le libellé de boutons (oui, non...) dépendait de la langue du système sur lequel il tournait.
Pour des utilisateurs anglophone, ils doivent déjà avoir leur système en anglais, les boites de dialogue devraient suivre.

J'avais déjà fait des tests de ce genre, mais je n'avait pas réussi à traduire ce genre de texte. Cela m'intéresse de savoir si vous trouvez une solution.

[Papy214]

Oui, c'est langue du système qui est utilisée mais le client nous dit certains utilisateurs préfèrent la version anglaise du logiciel même en étant su un Windows en langue française. :-(

En VCL, c'est facile : https://www.developpez.net/forums/d9...belle-boutons/

mais en FMX, même le TOpenDialog ne renvoie rien rien dans sa collection d'enfants. Donc, rien de modifiable par code

[SergioMaster]

Oui, c'est langue du système qui est utilisée mais le client nous dit certains utilisateurs préfèrent la version anglaise du logiciel même en étant su un Windows en langue française.

du coup cela devient compliqué ! J'ai fouillé dans les sources, au départ pour comprendre ce qui était entendu par "redéfinir l'interface" mais je reste dubitatif. Je me suis alors penché sur le source de
FMX.Dialogs.Win et cela devient encore plus obscur (du moins pour traduire) pour info , la "construction" du dialogue se fait à partir de la ligne 1912.
première chose "remarquable"

Code :

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

1
2
3
4
 if ADialogType <> TMsgDlgType.mtCustom then
    Params.lpszCaption := PChar(Translate(MsgCaptions[ADialogType]))
  else
    Params.lpszCaption := PChar(Application.Title);

comme tu le constateras il y a là un Translate en suivant le fil du Translate on passe à FMX.Types. On peut y découvrir LoadLangFromFile et LoadLangFromStrings il faudrait peut-être fouiller dans cette direction mais 1- le fichier il faut en connaitre la structure (apparemment une simple value liste xxxx=yyyyyyy) mais ? LoadLangFromStrings me parait plus simple et facile à traduire via DKlang (à tenter) mais les boutons vont-ils être traduit ?


Pour ce qui est de "params". Bien il s'agit en fait d'unestructure Microsoft

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
typedef struct tagMSGBOXPARAMSW {
  UINT           cbSize;
  HWND           hwndOwner;
  HINSTANCE      hInstance;
  LPCWSTR        lpszText;
  LPCWSTR        lpszCaption;
  DWORD          dwStyle;
  LPCWSTR        lpszIcon;
  DWORD_PTR      dwContextHelpId;
  MSGBOXCALLBACK lpfnMsgBoxCallback;
  DWORD          dwLanguageId;
} MSGBOXPARAMSW, *PMSGBOXPARAMSW, *LPMSGBOXPARAMSW;

Seulement dwLanguageID n'est pas indiqué donc, à moins de pouvoir changer ça, cela restera la langue d'affichage de windows
Bref comme cela passe par des APIs la traduction me paraît mal partie, il manquerait à minima un paramètre à MessageDialogSync et je ne suis pas sûr que cela soit suffisant (sous windows il faudrait aussi que la langue soit installée ?)


[Edit] Test effectué
j'ai donc ajouté un fichier texte à mon projet (par précaution j'ai aussi testé en espagnol)

Oui=Yes
Non=No
Avertissement=Warning

et dans le onCreate de ma Forme

Code :

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

1
2
3
4
procedure TForm47.FormCreate(Sender: TObject);
begin
LoadLangFromFile('langue.txt');
end;

à ma grande surprise pour mon message d'avertissement asynchrone j'ai les boutons Yes et No mais Avertissement n'est pas traduit pourtant

Code :

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

1
2
3
4
procedure TForm47.Button1Click(Sender: TObject);
begin
ShowMessage(TranslateText('Avertissement'));
end;

fonctionne

Du coup j'en ai déduit que ma recherche initiale n'était pas suffisante , un debug en pas à pas m'a mené vers une autre unité : FMX.DialogHelper (du moins en ce qui concerne MessageDialogASync c'est par là que ça passe), trp bête car il y a juste une instruction à modifier ligne 312 LForm.Caption := MsgCaptions[ADialogType] en LForm.Caption := Translate(MsgCaptions[ADialogType])

Pour MessageDialogSync par contre c'est l'inverse le type se traduit correctement mais c'est bien ce que je craignais : pas les boutons

[Papy214]

Toi t'es trop fort !

C'est tout de dommage qu'il n'y ait pas un moyen de personnaliser les libellés avec de simples paramètres.

Au vu de tout ça, je finis par penser que la meilleure solution pour satisfaire le client va être de me faire mon propre système de boite de dialogue.
Je pourrais à la limite reprendre le code existant pour l'adapter à ma source mais légalement je ne suis pas sûr que ça passe.

Cela aurait au moins l'avantage de m'affranchir des problèmes de boite de dial qui ne s'affichent pas parfois en premier plan et qui laissent penser que l'appli est plantée (si si, ça m'est déjà arrivé). En VCL il n'y avait pas de problème mais en FMX, ça se peut. Comme le système modal qui ne fonctionne pas toujours comme ça devrait. Dans plusieurs cas, et quel que soit le paramétrage, le dial s'affiche et le code continue à s'exécuter alors que ce n'est pas du tout le comportement attendu.

Je vais prendre le temps d'aller fouiller dans ces unités pour voir si je peux faire quelque chose en partant de tes recherches.

Encore merci ....

ps: au fait, j'ai toujours en tête ce dont on a parlé mais j'ai eu quelques soucis de santé et autre chose à penser :-(

[SergioMaster]

Fort, peut-être mais frustrè ! dans le cas des messages Asynchrone c'est vraiment trop bête d'avoir oublié le Translate, dans le cas des messages Synchrone (bon, je n'ai pas fouillé la partie Mac) pour la partie windows c'est dommage de ne pas avoir pensé à la localisation (surtout qu'il y a le paramètre)

Se faire une unité oui c'est la solution la plus aisée mais franchement on est à un poil de grenouille avec les messages asynchrones (tellement que j'irais presque le mettre sur le portail qualité !)
[Edit] j'ai copié FMX.Helpers dans le répertoire de mon projet, modifié comme j'avais indiqué avec le translate, indiqué que cette unité faisait partie du projet et cela fonctionne nickel du moins pour windows, pour android je ne sais pas trop où mettre le fichier langue.txt pour le déploiement

d'un autre côté il risque d'y avoir des pertubations avec TLang qui utilise LoadLangFromFile lui aussi, pour DKLang la propriété AutoTranslate n'est pas faite pour les chiens mais on se retrouve avec deux fichiers de "traductions" à chaque fois pas simple !

[Papy214]

Ce serait peut-être effectivement à signaler comme demande pour une prochaine version si c'est pas grand-chose.
Mais il y a des demandes même simples qui ont traîné des années comme ça

[SergioMaster]

Il y a déjà plein de RSP sur le sujet, une donne même une solution (qui devrait même être pas mal assez en phase DKLang)

J'ai donc essayé

Code :

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

1
2
3
4
5
6
7
8
9
10
11
procedure TForm47.FormCreate(Sender: TObject);
//var Flang : String;
begin
//Flang:='langue.txt';
{$IFDEF ANDROID}
//  FLang:=TPath.Combine(Tpath.GetDocumentsPath,Flang);
{$ENDIF}
PString(@ButtonCaptions[TMsgDlgBtn.mbYes])^ := 'Si';
PString(@ButtonCaptions[TMsgDlgBtn.mbNo])^ := 'No';
// PString(@MsgTitles[TMsgDlgType.mtWarning])^ := 'Cuidado';
end;

cela fonctionne bien pour les messages Asynchrone (testé aussi sur Android) mais pas pour les synchrones(windows) .
[Windows]Je n'ai pas trouvé comment changer les titres (la ligne MsgTitles ne fait rien) et je n'ai pas su atteindre MsgCaptions

[Papy214]

Effectivement, ça fonctionne avec IFMXDialogServiceASync mais pas IFMXDialogServiceSync
Dommage que ça ne soit pas l'inverse, ça maurait mieux arrangé

Pour le caption, à la limite c'était pas grave puisque ça prendrait le nom de l'application.

Je pensais contourner le problème asynchrone comme ça:

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
 
  PString(@ButtonCaptions[TMsgDlgBtn.mbYes])^ := 'Si';
  PString(@ButtonCaptions[TMsgDlgBtn.mbNo])^  := 'No';
  PString(@ButtonCaptions[TMsgDlgBtn.mbOK])^ := 'D''accord';
 
  Evt := TEvent.Create(nil, True, False, 'azerty', True);
  if TPlatformServices.Current.SupportsPlatformService(IFMXDialogServiceASync, DialogSvcA) then
    DialogSvcA.MessageDialogAsync(
      'Bonjour',
      TMsgDlgType.mtCustom,
      [TMsgDlgBtn.mbOK, TMsgDlgBtn.mbNo],
      TMsgDlgBtn.mbYes, 0,
      procedure(const AResult: TModalResult)
      begin
        Evt.SetEvent;
      end
    );
  Evt.WaitFor(INFINITE);
  Evt.ResetEvent;
  Evt.Free;

Mais l'interface reste bloquée après l'affichage du message.
Si dans le TEvent.Create je mets le dernier paramètre à false, je n'ai pas l'affichage des éléments sur la fenêtre de dial.

[SergioMaster]

Bonjour,

c'est vrai que l'asynchrone pour windows ça le fait pas vraiment ! Je m'étais plus penché sur cette partie car voulant tester Android, dans ce cas il est plus compréhensible qu'Embarcadero ne se soit pas embarrassé de traduire le titre puisque le titre n'apparaît pas (bien que, partant du principe que dans le futur cela aurait pu apparaitre ...)

Pour ce qui est de la méthode synchrone là encore c'est compréhensible, puisque la méthode utilise l'API il y a peu de raison logique que l'utilisateur veuille une langue différente que celle de son OS (gros pas de bol tu es tombé sur le client "tordu" qui utilise un environnement/os en français mais veut son application dans une autre langue !) Tout comme pour mes tests concernant l'asynchrone il est tout à fait possible de copier l'unité FMX.Dialogs.Win dans le répertoire des sources de l'application et modifier (ou ajouter) des fonctions qui prendrait en compte un paramètre langue mais je pense que c'est investir presque autant de temps que de se faire sa propre forme modale (quitte à pomper un peu dans les sources de FMX.Helpers pour voir comment sont gérer les boutons et le texte du message pour la taille de la fenêtre)

[Papy214]

Je vais essayer de convaincre le client d'oublier ça.
En expliquant que ça va leur coûter 1 jour de dev juste pour ça, il va peut-être "entendre raison"