Entrerei nel container, installerei vim e riparerei la locale.
Potresti salvare la locale ebraica corrotta e copiarci sopra quella inglese…
root@carrie-app:/var/www# for i in `find . -name *.he.yml` ; do cp ${i/he.yml/en.yml} $i ; done
Idea carina, ma non ha funzionato in pratica. quando ho reimpostato la mia locale su HE, ricevo l’errore. Suppongo che tornerò a scorrere gli utenti per impostarli tutti in inglese per ora.
Hai riavviato discourse dopo aver modificato le impostazioni locali?
sì. non ho fatto molto.

dopo aver messo in mostra le mie vecchie abilità in ruby ho semplicemente impostato l’inglese per tutti per ora. aprirò un ticket sulla localizzazione ebraica in seguito.
grazie @JammyDodger per lo spostamento in Bug, basta questo per aprire un bug report, o dovrei aprirne uno ufficiale in qualche bug tracker?
Se una locale en viene copiata, si verifica un errore durante il merge (sembra che le voci non tradotte vengano rimosse e se non rimane nulla, allora si verifica un errore).
Tuttavia, la rimozione di config/locales/client.he.yml consente l’accesso al mio sito di test.
Poiché si basa interamente sull’inglese. Penso che questo sia il comportamento previsto.
Nella localizzazione ebraica config/locales/client.he.yml
posts_likes_MF: |
{ count, plural,
one {תגובה, }
two {שתי תגובות, }
many {# תגובות, }
other {# תגובות, }
}{ ratio, select,
low { יחס גבוה בין פוסטים ללייקים, }
med { יחס גבוה מאוד בין פוסטים ללייקים, }
high { יחס גבוה במיוחד בין פוסטים ללייקים, }
other {}
} קפיצה לפוסט הראשון או האחרון…
la riga
many {# תגובות, }
deve essere eliminata.
many non è consentito in ebraico (vedi Language Plural Rules)
Il problema può essere risolto tramite l’interfaccia utente. Per fare ciò, il valore corretto deve essere inserito in /admin/customize/site_texts/js.posts_likes_MF per la lingua ebraica:
{ count, plural,
one {תגובה, }
two {שתי תגובות, }
other {# תגובות, }
}{ ratio, select,
low { יחס גבוה בין פוסטים ללייקים, }
med { יחס גבוה מאוד בין פוסטים ללייקים, }
high { יחס גבוה במיוחד בין פוסטים ללייקים, }
other {}
} קפיצה לפוסט הראשון או האחרון…
Sembra un po’ strano che l’intero sito possa diventare inutilizzabile inserendo dati errati in una personalizzazione del testo.
Registrarlo qui è il posto giusto per i bug report. ![]()
Entrerò con git per vedere chi è da biasimare per quella riga, pensavo che l’unica festa autorizzata a fare commit a quelle fosse crowdin?
Inoltre, se è così, perché riavviare l’unicorno dopo aver copiato l’inglese sull’ebraico non risolverebbe questo problema?
Dovrebbe esserci davvero una distinzione tra non consentito e non supportato.
Stranamente, nel codice di Discourse, anche il “plurale due” non è supportato per nessuno dei due codici linguistici, che è condiviso con l’arabo. Penso che sia qui che il problema debba essere risolto. Farò una PR per questo, ma c’è sicuramente la necessità di correggere il fallimento forzato sul campo many “superfluo”, poiché sembra che Crowdin non sia conforme a questo file plurals.rb.
Penso che sia più complicato.
Le traduzioni front-end sono interpretate dal modulo node @messageformat/core utilizzando messageformat-wrapper.
Il problema è che le regole plurali sono definite in due posti. L’altro è stato recentemente modificato per utilizzare una libreria (DEV: Upgrade the MessageFormat library (JS) · discourse/discourse@301713e · GitHub).
Tuttavia, i plurali definiti nella libreria non sono sempre gli stessi di quelli che Discourse utilizzava in precedenza, e quelli in plurals.rb non sono stati modificati. Inconsistency in plural definition
Ma ciò non spiega perché Crowdin abbia creato una versione separata per molti
Ho aggiunto le regole di campo necessarie per la traduzione, ma non è una soluzione per questo bug, solo una compatibilità per l’output di Crowdin.
Penso che anche la regola alla fine della riga necessiti di un aggiustamento.
Al momento, questo menziona ancora solo “one” e “other”.
rule: lambda { |n| n == 1 ? :one : :other }
sì, ho sbagliato. L’ho corretto con amend e mi è sfuggito di averlo eseguito senza --force. ora è corretto.
Grazie a tutti, continuiamo a monitorare il problema più ampio in questo argomento: