Je dois préparer la demande de localisation de Delphi 2007. Maintenant, environ 80% de ce qui doit être traduit est en réalité une bibliothèque de temps d'exécution Delphi. Je ne peux pas imaginer que cette matière doit être re-traduite encore et encore, par chaque développeur qui localise son logiciel.
Alors, je cherche où je peux obtenir une "mémoire de traduction" / "glossaire" pour Delphi 2007 EUD-TIME, GRATUITEMENT ou pour de l'argent. Je suis particulièrement intéressé par le chinois traditionnel.
4 Réponses :
Delphi lui-même n'est pas traduit en chinois ... Mais je suis d'accord, certaines entreprises / traducteurs ont certainement l'ont déjà fait.
Pour information, dans les langues existantes Delphes (français, allemand et japonais), il existe des fichiers spécifiques Avec traductions dans Sources Subfolders, par exemple: ... \ rad Studio \ 8.0 \ Source \ VCL \ fr, ... \ rad Studio \ 9.0 \ Source \ RTL \ Common \ De, ...
Par exemple, le début des vCl.Consts.pas :
Oui, malheureusement, comme vous l'avez dit, il n'est que français / allemand / japonais ... donc ce n'est donc pas vraiment un référentiel, et plutôt limité en termes de nombre de langues.
Et cela devient difficile lorsque vous avez affaire à des composants de DB qui utilisent cette chaîne de ressources et vous attendez à un texte anglais au lieu d'un ...
@haimg: Je suis d'accord; BTW, c'est un bon endroit pour rechercher toutes les cordes dont vous avez besoin pour traduire.
@RBA: Habituellement, il y a des étiquettes dans le code pour dire explicitement à ne pas traduire ce genre de chaînes ... N'hésitez pas à signaler les problèmes que vous avez trouvés dans QC
Je crois que par Repository de traduction OP signifiait littéralement le référentiel de traduction tel que présenté sous Voir - >> Gestionnaire de traduction -> référentiel (ou outil autonome ETM), où les messages à localiser sont Messages RTL. Ainsi, au moment du processus de démarrage de la localisation (créer une DLL de ressources) ~ 80% des messages à localiser viennent de RTL, pas d'application sous la localisation elle-même et OP recherche une réutilisation du travail effectué précédemment. @haimg, corrigez-moi s'il vous plaît si je suis mal impression.
@ Downvoter-pas-dans-la-lumière: vous êtes correct. En fait, tout format de référentiel fonctionnera pour moi. TMX, XML natif de Delphi, peu importe.
@haimg, j'ai eu votre question à ce moment-là. J'avais des égratignures similaires lorsque je créais ru-ru DLL de ressource pour mon logiciel plutôt minuscule et que le volume de travail avec Delphi Standard Tool semblait être beaucoup plus grand que possible. Malheureusement, je n'ai trouvé aucune traduction prémache et je dois le faire moi-même, que votre chance sera meilleure et que vous trouverez une partie du référentiel souhaitée, car je suis sûr que ce type de travail a été fait précédemment. Quoi qu'il en soit, je vous suggère de reformuler une question un peu, car aller à travers ressources unité par unité comme dans les réponses n'est pas Delphi Way to Go
De ma connaissance, cela n'existe pas ... soit payé gratuitement. Vous n'avez que les versions françaises / allemandes / japonaises de l'unité VCL.CONSTS. Pour tout ce que vous devez être traduit, vous devez le faire par vous-même.
Regardez le GNU GetText pour Delphi et C ++ Builder .
Cet outil est capable de traduire tous les afaik Il y a plusieurs Traductions pré-fabriquées Disponible, pour plusieurs langues (plus que le français officiel / Versions allemandes / japonaises / anglaises).
mise à jour: J'ai utilisé des idées de gettext pour Les caractéristiques I18N de notre cadre Mormot , pour la partie UI. Cela utilisera des fichiers texte clairs pour la traduction, au lieu de .po ou d'autres systèmes propriétaires, et plus spécifique Delphi (E.G. Le contenu DFM est analysé). Ceci est dédié à notre cadre (par exemple, il utilise ses classes RTTI), mais cela peut être un bon démarrage si vous souhaitez écrire votre propre unité, avec certaines améliorations par rapport à GetText ou à la Delphi IDE. Resourtring définis dans l'EXE dans n'importe quelle langue, à la volée. Il est donc capable de traduire le Resourtring utilisé par le Delphi RTL, dans n'importe quelle langue.
GNU GetText est assez invasif pour ne pas être un aussi bon choix. Étant donné que Delphi propre outil de localisation s'est amélioré (mais il a toujours des problèmes dans la D2007), il est imho une solution assez meilleure, en particulier lorsqu'il s'agit de la localisation, car elle a une aperçu et peut localiser non seulement des cordes, vous pourriez avoir besoin d'adapter graphique. éléments aux clients cibles, en particulier lorsqu'ils sont dans des pays avec une culture et des traditions très différentes.
Même si vous ne souhaitez pas utiliser GNU GetText pour Delphi, vous pouvez toujours utiliser ses traductions pré-fabriquées Delphi RTL. Oh, et assurez-vous de prendre les traductions allemandes du référentiel DxgetText SVN, car je les ai considérablement améliorés ces derniers mois.
@Mad hatter c'est une question de goût. Comment appelez-vous «invasif»? Que toutes les ressources sont traduites? C'est une fonctionnalité, imho. Je n'aime vraiment pas vraiment les outils de localisation Delphi, pour deux raisons principales: que vous avez besoin de l'IDE pour mettre à jour une traduction et utilisera des bibliothèques.
C'est "invasif" car il nécessite des changements de code. Vous devez coder pour GetTText. Les outils de localisation Delphi ne le font pas. Vous n'avez pas besoin de l'ensemble de l'IDE pour mettre à jour une traduction, juste l'exécutable ETE. Il utilise des dlls, true, mais c'est ainsi que fonctionne toute la localisation de Windows. Les fenêtres elles-mêmes et au bureau, par exemple, sont localisées de la même manière. Il est simple de déployer (et de mettre à jour), vous ne pouvez déployer que les localisations dont vous avez besoin et ne peuvent traduire toute ressource, y compris des images, des vidéos, des sons, etc.
Évidemment, les traductions préalables que vous avez mentionnées ne sont même pas proches d'être complètes, mais c'est la chose la plus proche de ce que je cherchais dans les réponses, donc je le marquais comme accepté. P.s. Merci pour GetText pour Delphi Pointer!
@Mad hatter quel changement de code nécessite-t-il? Toutes les ressources sont traduites à la volée, ainsi que toutes les formes. Quelque code d'initialisation, et c'est tout. À propos du déploiement, il est basé sur des fichiers externes. Je pense que vous n'avez pas regardé la mise en œuvre exacte de cette bibliothèque. Il y a beaucoup plus que _ ("Texte anglais") dedans.
1) ajouter translatecomponent (auto); à chaque formulaire
1) ajouter translatecomponent (auto); à chaque formulaire 2) Ajouter "Ignores typiques" 3) Construire une structure de répertoires complexes 4) Il "fonctionne mieux" si vous utilisez la syntaxe _ () 5), il peut échouer avec certains Contrôles, nécessitant des appels à traduireProperties (). Quoi qu'il en soit, comme toutes ces bibliothèques de traduction, il ne vous permet pas de régler la taille des commandes pour refléter les chaînes traduites. GetText est une bibliothèque bon marché qui fonctionne dans une applica simple
Il y a longtemps, IIRC C'était Delphi 5, Borland a publié un Répartition de la traduction Fichier pour son propre outil de localisation prenant en charge certaines langues (mais pas chinois, cependant). Il fonctionne toujours et peut être utilisé comme base pour ajouter plus de traductions, c'était une bonne idée, mais autant de bonnes idées à Delphi, il a été rapidement oublié. IMHO, je ne perdrais pas de temps à livrer des versions IDE localisées, j'utiliserais ces ressources pour fournir un "référentiel de traduction" pour le RTL / VCL, qui serait beaucoup plus utile.
Delphi Xe2 a toujours le référentiel, bien qu'avec seulement 3 langues (allemand / français / japonais), il n'était donc pas "rapidement oublié". Hélas, 3 langues seulement :-(
Ah, bon de savoir qu'ils ont ajouté les traductions réelles du référentiel maintenant. Je suppose que parce que ce sont les langues Delphi lui-même est localisée. C'est dommage qu'aucun développeur Delphi d'autres pays a rempli l'écart. Les contributions de la communauté malheureusement à Delphes sont beaucoup moins nombreuses qu'avec d'autres langues.
Je suis surpris que vous ayez besoin de traduire le texte de Delphi Runtime. Quelle partie de l'exécution montre du texte à vos utilisateurs.
@David: Je suppose que je devinerais des messages d'exception comme "'A' 'n'est pas une valeur entière valide.".
@Andreas Il n'y a guère de ceux-ci et vous ne les montrez sûrement pas à l'utilisateur. Ne peut pas vraiment être 80%.
@David, par exemple, le
constes unité.Si c'est ce que les suspects andreas, je suis sûr qu'il existe une DLL de ressources pour toutes les langues ordinaires. Mais D2007 est ANSI. Mieux avec Delphes modernes.
Il y a tous les messages d'erreur (des centaines d'entre eux), tous les boîtes de dialogue / composants communs, noms de boutons communs, noms de jour de la semaine, etc., plusieurs centaines de cordes. Je détesterais payer pour une traduction personnalisée de ceci, quand je sais, bien sûr, cela était déjà traduit, de nombreuses fois encore et encore.
@David Delphi 2007 ou Delphi 2009 n'a pas beaucoup d'importance, car la plupart des chaînes RTL / VCL sont identiques. Et si Delphi lui-même est ANSI ou Unicode n'est pas pertinent pour ma question. J'ai été incapable de trouver une telle DLL de ressources pour le chinois par exemple.
Les boîtes de dialogue communes sont localisées par Windows. Les noms de boutons sont choisis par vous. Les messages d'erreur ne doivent pas être vus par l'utilisateur. Mais je prends votre point que ce genre de choses doit être traduite déjà. Tout est mis en œuvre avec
Resourctring Donc c'est prêt pour cela. Quelque chose me dit que la version d'entreprise pourrait avoir les traductions disponibles. Je suis très intéressé par la question et j'espère que quelqu'un sait quelque chose !!Au moins dans Delphi Xe2, les traductions expédiées ne sont que l'allemand, le français et le japonais - les langues Delphi est disponible. Même DxgetText n'a pas de traductions chinoises du Delphi RTL.
BTW, le taux de 80% ne signifie pas que 80% des chaînes d'exécution doivent être traduites (car la plupart d'entre elles ne seront jamais présentées à l'utilisateur). Il indique que 80% des traductions globales sont des chaînes d'exécution.