Openapoc: Reemplace tinyfmt con fmt (https://github.com/fmtlib/fmt)

¿Se está trabajando en esto?

Tengo el puerto inicial funcionando localmente, pero no he tenido tiempo de pulirlo y probarlo correctamente (por ejemplo, todas las cadenas de traducción deben actualizarse, así que estaba usando esto como un buen punto para hacer que las cadenas se extraigan automáticamente del código con xgettext como objetivo de compilación, etc.)

También reveló una serie de políticas de traducción "malas", por ejemplo, unir fragmentos de texto traducidos en lugar de hacer la cadena incorrecta a la vez (por ejemplo, algo como "formato (tr ("% s,% s "), formato (tr (" % s cosa es% d de "), objeto, recuento), formato (tr (de"% d total "), número));

Lo que resultaría en cadenas completamente inútiles para los traductores:
"% s% s"
"% s es% d"
"de% d total"

cuando realmente debería traducirse como una sola llamada, por lo que la cadena extraída debería ser:
"% s cosa es% d de% d total" (o "{0} cosa está {1} de {2} total" en la forma fmtlib de hacer las cosas)

Por lo que puedo deducir, tiene que haber dos subsistemas de formato distintos:

1. Registro basado en {fmt} (dado que, en mi opinión, hay pocos beneficios en la traducción de mensajes de registro potencialmente cambiantes, y sería un poco afectado para el rendimiento enrutarlos a través de boost::locale .
2. boost::locale::format para cadenas de interfaz de usuario localizables (ya que tiene soporte para formas plurales).

Propondría implementarlos en pequeños pasos: primero cambie a {fmt} luego trate con cadenas localizables.

No estoy seguro de si boost :: locale realmente será tan útil para nosotros en el futuro; es excelente para aplicaciones estáticas con bases de datos de traducción estáticas, pero he tenido problemas para encontrar dónde puedo conectarme a su base de datos de mensajes para agregar nuevos mensajes desde mods.

Creo que solo es posible agregar una base de datos completamente nueva en un nuevo dominio de traducción, y luego nos metemos en problemas al tratar de averiguar con qué dominio deberíamos traducir una cadena, sin hacer algo como probar / todos / mod dominios en orden hasta que encontrar una coincidencia

Entonces, mi plan actual es tratar de separar cada una de las tareas, similar a lo que mencionó:

• Use {fmt} para todos los registros y cadenas internas (se usa en algunos lugares para construir ID, etc., algo que explícitamente no queremos traducir)
  - Esto implicará cambios significativos en la cadena del estilo% printf a {fmt}, pero lo ideal es que no afecte las traducciones.
• Conecte la generación de .pot automáticamente usando xgettext
  - Esto probablemente resaltará gran parte del trabajo de traducción "malo": algunas personas parecen haberse escapado con las cadenas extraídas de OG .exe como una fuente de mensajes de traducción "dorada", a pesar de que las cadenas de openapoc se construyeron de manera muy diferente en algunos lugares
• Verifique la fuente para ver si hay una construcción de cadena de traducción "mala" (como el ejemplo que mencioné anteriormente), o cadenas que no deberían traducirse (registros, cadenas de ID internas, etc.) o cadenas que deberían traducirse pero no lo están (IE solo directamente usando :: formato ())
  - Esto debería facilitarse con el paso anterior, ya que debería ser obvio en el .pot generado
• Convierta todas / traducidas / cadenas del estilo% printf a {fmt} / boost :: estilo local (creo que son funcionalmente iguales, ya que actualmente no tenemos ninguna anotación pleural o similar)
  - Esto invalidará prácticamente todo el trabajo de traducción actual, por lo que probablemente no valga la pena realizar actualizaciones de traducción entre etapas.

Tengo casi todas las etapas anteriores a nivel local en varios estados; probablemente tenga sentido para mí intentar ponerlas en un estado utilizable, y ahora tengo un poco de tiempo este fin de semana largo, supongo que será mi próxima tarea :)

Una vez que todo esté hecho, podemos comenzar a preocuparnos por cómo funcionarían los mods que agregan nuevas cadenas

Convierta todas / traducidas / cadenas del estilo% printf a {fmt} / boost :: estilo local (creo que son funcionalmente iguales, ya que actualmente no tenemos ninguna anotación pleural o similar)

En realidad, solo se ven similares: boost::locale presenta una indexación basada en 1 y una gramática de formato muy diferente. Si no fuera por las formas plurales, iría con {fmt} ya que encuentro que su soporte para el argumento con nombre es una buena ayuda para los traductores que agregan un contexto valioso, por ejemplo:

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

Aunque encuentro mucho más valioso el apoyo a las formas plurales.

Sí, recuerdo que la indexación me lanzó para empezar :)

TBH en el futuro, creo que el formato boost :: locale está listo, estoy seguro de que podemos solucionar los problemas del contexto del mod en el futuro.

O al menos entonces, cuando encontremos el "siguiente" problema, todas las cadenas traducidas estarán en un formato mucho más sano y no entremezcladas con texto formateado no traducido.

Además, honestamente, toda la clase UString debería ser un conjunto de ayudantes alrededor de un std :: basic_string- pero parece que no estará disponible de manera confiable hasta c ++ 20.

Estoy dispuesto a reemplazarlo todo con un std :: string (IE std :: basic_string), pero luego perderemos la seguridad de tipos para "utf8 conocido" frente a "matriz de bytes", pero no estoy seguro de que realmente estemos usando eso de todos modos. Tendríamos que tener cuidado con las interfaces, pero hoy no tenemos cuidado, solo llamamos a .cStr () /. Str () sin ninguna conversión real como un 'salir'

Actualmente, 'sucede' que funciona, ya que tiendo a probar en plataformas que ya usan utf8 en las API de su sistema, pero sospecho que actualmente se romperá si intentamos hacer algo hoy como abrir un nombre de archivo con una ruta no ascii en Windows