Entraría en el contenedor, instalaría vim y repararía la configuración regional.
Podrías guardar la configuración regional hebrea rota y copiar la inglesa encima…
root@carrie-app:/var/www# for i in `find . -name *.he.yml` ; do cp ${i/he.yml/en.yml} $i ; done
Linda idea, pero no funcionó en la práctica. Cuando volví a cambiar mi configuración regional a HE, recibo el error. Supongo que volveré a iterar sobre los usuarios para configurarlos todos en inglés por ahora.
¿Reiniciaste discourse después de modificar las locales?
Sí. No hice mucho.

Después de mostrar mis antiguas habilidades de Ruby, simplemente cambié a todos a inglés por ahora. Abriré un ticket sobre la configuración regional hebrea a continuación.
gracias @JammyDodger por la transferencia a Bug, ¿es todo lo que se necesita para abrir un informe de error, o debería abrir uno oficial en algún rastreador de errores?
Si se copia una configuración regional en inglés, se produce un error durante la fusión (parece que las entradas no traducidas se eliminan y, si no queda nada, se produce un error).
Sin embargo, eliminar config/locales/client.he.yml permite iniciar sesión en mi sitio de prueba.
Porque recurre completamente a EN. Creo que ese es el comportamiento esperado.
En la configuración regional hebrea config/locales/client.he.yml
posts_likes_MF: |
{ count, plural,
one {תגובה, }
two {שתי תגובות, }
many {# תגובות, }
other {# תגובות, }
}{ ratio, select,
low { יחס גבוה בין פוסטים ללייקים, }
med { יחס גבוה מאוד בין פוסטים ללייקים, }
high { יחס גבוה במיוחד בין פוסטים ללייקים, }
other {}
} קפיצה לפוסט הראשון או האחרון…
la línea
many {# תגובות, }
debe eliminarse.
many no está permitido en hebreo (ver Language Plural Rules)
El problema se puede resolver a través de la interfaz de usuario. Para lograr esto, el valor corregido debe ingresarse en /admin/customize/site_texts/js.posts_likes_MF para el idioma hebreo:
{ count, plural,
one {תגובה, }
two {שתי תגובות, }
other {# תגובות, }
}{ ratio, select,
low { יחס גבוה בין פוסטים ללייקים, }
med { יחס גבוה מאוד בין פוסטים ללייקים, }
high { יחס גבוה במיוחד בין פוסטים ללייקים, }
other {}
} קפיצה לפוסט הראשון או האחרון…
Me parece un poco extraño que todo el sitio pueda quedar inutilizable al ingresar datos incorrectos en una personalización de texto.
Registrarlo aquí es el lugar para los informes de errores. ![]()
Entraré con git para ver quién tiene la culpa de esa línea, ¿pensé que la única parte permitida para confirmar cambios en esos es crowdin?
Además, si ese es el caso, ¿por qué reiniciar el unicorn después de copiar el inglés sobre el hebreo no solucionaría esto?
Realmente debería haber una distinción entre no permitido y no compatible.
Curiosamente, en el código de Discourse, ni siquiera el “plural two” es compatible con ninguno de los códigos de idioma, que SÍ se comparte con el árabe. Creo que aquí es donde se necesita solucionar el problema. Haré una PR para eso, pero definitivamente es necesario solucionar el fallo forzado en el campo many “superfluo”, ya que parece que Crowdin no se ajusta a este archivo plurals.rb.
Creo que es más complicado.
Las traducciones del front-end son interpretadas por el módulo de nodo @messageformat/core usando messageformat-wrapper.
El problema es que las reglas de plural se definen en dos lugares. El otro se cambió recientemente para usar una biblioteca (DEV: Upgrade the MessageFormat library (JS) · discourse/discourse@301713e · GitHub).
Sin embargo, los plurales definidos en la biblioteca no siempre son los mismos que los que Discourse usaba antes, y los de plurals.rb no se cambiaron. Inconsistency in plural definition
Pero eso no explica por qué Crowdin creó una versión separada para muchos.
Agregué las reglas de campo necesarias para la traducción, pero esa no es una solución para este error, solo una compatibilidad para la salida de Crowdin.
Creo que la regla al final de la línea también necesita un ajuste.
Por el momento, esto todavía solo menciona “one” y “other”.
rule: lambda { |n| n == 1 ? :one : :other }
Sí, la he liado. La arreglé con amend y no me di cuenta de que la había subido sin --force. Ya está corregido.
Gracias a todos, sigamos rastreando el problema más amplio en este tema: