Openapoc: Remplacez tinyfmt par fmt (https://github.com/fmtlib/fmt)

Est-ce qu'on y travaille ?

J'ai le port initial qui fonctionne localement, mais je n'ai pas eu le temps de le peaufiner et de le tester correctement (par exemple, toutes les chaînes de traduction doivent être mises à jour, j'utilisais donc cela comme un bon point pour extraire les chaînes automatiquement du code avec xgettext comme cible de construction, etc.)

Il a également révélé un certain nombre de "mauvaises" politiques de traduction - par exemple, assembler des fragments de texte traduits au lieu de faire la mauvaise chaîne à la fois (par exemple, quelque chose comme "format(tr("%s, %s"), format(tr(" %s chose est %d sur "), objet, nombre), format(tr(sur "%d total"), nombre));

Ce qui se traduirait par des chaînes complètement inutiles pour les traducteurs :
"%s %s"
"%s chose est %d "
"sur %d total"

alors qu'il doit vraiment être traduit en un seul appel, la chaîne extraite doit donc être :
"%s chose est %d sur %d total" (ou "{0} chose est {1} sur {2} total" dans la manière fmtlib de faire les choses)

D'après ce que je peux comprendre, il doit y avoir deux sous-systèmes de formatage distincts :

1. Journalisation basée sur {fmt} (puisque IMO, il y a peu d'avantages à traduire des messages de journal potentiellement en constante évolution, et serait un peu affecté par les performances de routage via boost::locale .
2. boost::locale::format pour les chaînes d'interface utilisateur localisables (puisqu'il prend en charge les formes plurielles).

Je proposerais de les implémenter par petites étapes : d'abord passer à {fmt} puis traiter les chaînes localisables.

Je ne sais pas si boost::locale va vraiment nous être utile à l'avenir - c'est génial pour les applications statiques avec des bases de données de traduction statiques, mais j'ai eu du mal à trouver où je peux me connecter à sa base de données de messages pour ajouter de nouveaux messages à partir de mods.

Je pense qu'il n'est possible d'ajouter une toute nouvelle base de données que dans un nouveau domaine de traduction, puis nous nous heurtons à des problèmes en essayant de déterminer avec quel domaine nous devons traduire une chaîne, sans faire quelque chose comme essayer /tous/ les domaines mod dans l'ordre jusqu'à ce que nous trouver une correspondance

Mon plan actuel est donc d'essayer de séparer chacune des tâches - similaire à ce que vous avez mentionné :

• Utilisez {fmt} pour tous les journaux et chaînes internes (il est utilisé à certains endroits pour construire des identifiants, etc. - quelque chose que nous ne voulons explicitement pas traduire)
  -- Cela impliquera des changements de chaîne importants du style %printf à {fmt}, mais idéalement n'affectera pas les traductions
• Câblez automatiquement la génération .pot à l'aide de xgettext
  - Cela mettra probablement en évidence une grande partie du "mauvais" travail de traduction - certaines personnes semblent s'être enfuies avec les chaînes extraites OG .exe comme source de message de traduction "doré", malgré le fait que les chaînes d'openapoc soient construites très différemment à certains endroits
• Vérifiez la source pour la construction de chaînes de traduction "mauvaise" (comme dans l'exemple que j'ai mentionné ci-dessus), ou des chaînes qui ne devraient pas être traduites (journaux, chaînes d'ID internes, etc.) ou des chaînes qui devraient être traduites mais ne le sont pas (IE juste directement en utilisant ::format())
  -- Cela devrait être facilité par l'étape précédente, car cela devrait être évident dans le .pot généré
• Convertissez toutes les chaînes /translated/ du style %printf en style {fmt}/boost::locale (je pense qu'elles sont fonctionnellement identiques car nous n'avons actuellement aucune annotation pleurale ou similaire)
  -- Cela invalidera à peu près tous les travaux de traduction en cours - donc cela ne vaut probablement pas la peine de faire des mises à jour de traduction entre les étapes

J'ai à peu près toutes les étapes ci-dessus localement dans divers états - il est probablement logique pour moi d'essayer de les mettre dans un état utilisable, et maintenant j'ai un peu de temps ce long week-end, je suppose que ce sera ma prochaine tâche :)

Une fois tout cela fait, nous pouvons alors commencer à nous soucier du fonctionnement des mods qui ajoutent de nouvelles chaînes

Convertissez toutes les chaînes /translated/ du style %printf en style {fmt}/boost::locale (je pense qu'elles sont fonctionnellement identiques car nous n'avons actuellement aucune annotation pleurale ou similaire)

En fait, ils ne se ressemblent que -- boost::locale propose une indexation basée sur 1 et une grammaire de formatage très différente. Sinon pour les formes plurielles, j'irais avec {fmt} car je trouve que son support pour l'argument nommé est une bonne aide pour les traducteurs ajoutant un contexte précieux, par exemple :

Delay = {seconds}
Range = {meters:2.1}m.

Bien que je trouve le support pour les formes plurielles beaucoup plus précieux.

Ouais, je me souviens de l'indexation me lançant pour commencer :)

TBH à l'avenir Je pense que le format boost::locale est bon, je suis sûr que nous pouvons résoudre les problèmes de contexte de mod à l'avenir.

Ou du moins, lorsque nous trouverons le "prochain" problème, toutes les chaînes traduites seront dans un format beaucoup plus sain et ne seront pas mêlées à du texte formaté non traduit.

De plus, honnêtement, toute la classe USstring devrait être un ensemble d'assistants autour d'un std::basic_string- mais il semble que ce ne sera pas fiable avant c++20.

Je suis tenté de tout remplacer par un std::string (IE std::basic_string), mais alors nous perdrons la sécurité de type pour "connu utf8" vs "tableau d'octets" - mais je ne suis pas sûr que nous l'utilisions vraiment de toute façon. Nous devrions juste faire attention aux interfaces, mais nous ne faisons pas attention aujourd'hui, en appelant simplement .cStr()/.str() sans aucune conversion réelle en tant que "sortir"

L'informatique "se trouve" actuellement à fonctionner car j'ai tendance à tester sur des plates-formes qui utilisent déjà utf8 dans leurs API système - mais je soupçonne que cela se brisera actuellement si nous essayons de faire quelque chose aujourd'hui, comme ouvrir un nom de fichier avec un chemin non-ascii sur Windows