Django i18n: c'è un'alternativa gettext?

Question

Sto cercando un modo per tradurre il mio progetto Django. Il meccanismo incorporato fornito con Django è ottimo, ma ha diversi punti deboli che mi hanno spinto a cercare un'alternativa.

Il proprietario del progetto deve essere in grado di modificare ogni traduzione compreso l'inglese (traduzione originale). Con gettext è possibile modificare le traduzioni con strumenti come Pootle, ma le stringhe originali rimangono codificate all'interno di sorgenti o modelli di file. Non è possibile che il proprietario del prodotto possa cambiarli.

Possibile soluzione è quella di rendere gettext tradurre alcuni identificatori univoci, e solo li tradurre in tutte le lingue tra cui inglese, in questo modo:

_('form_sumbit_button') 

Ma questo rende strumenti come Pootle quasi impossibile da utilizzare per i traduttori.

Domanda: esistono strumenti per la traduzione del progetto Django che potrebbero soddisfare le mie esigenze?

Answer 1

Potrebbe essere possibile utilizzare Pootle con l'approccio _ ("message_id"), a seconda di quanto è facile personalizzare Pootle (non conosco gli interni, quindi non posso dirlo, ma IIUC utilizza Django dove le modifiche ai modelli sono in genere semplici).

Ad esempio, le schermate di traduzione di Pootle hanno sezioni "Originale" e "Traduzione"; potresti adattare i modelli per mostrare, sotto la sezione "Originale", una sezione "Riferimenti" che mostra alcune traduzioni canoniche usando una lingua di riferimento specifica (ad esempio inglese).

Oppure potresti essere in grado di utilizzare la funzionalità alternative source language di Pootle, senza dover personalizzare Pootle. È possibile memorizzare le versioni canoniche delle traduzioni utilizzando un codice lingua inutilizzato (o uno inventato).

Answer 2

Se si utilizzano alcuni ID messaggio, potrebbero essere incomprensibili ("messaggio_2215") o si sarebbe costretti a sincronizzare gli ID messaggio con i messaggi effettivi ("Premere qualsiasi tasto" = "please_press_any_key" => " Qualsiasi chiave per continuare "=" any_key_to_continue "). In ogni caso, le stringhe reali sono migliori per i programmatori e per gli strumenti.

Tuttavia, se si impiegano un proof-reader separato per le stringhe, è possibile effettuare le seguenti operazioni:

1. Crea un file di inglese "traduzione" (sì, questo funziona)
2. Si compia la tua Proof il lettore "traduce" dall'inglese all'inglese utilizzando Pootle o qualsiasi altro strumento
3. Assicurati che i tuoi programmatori non traducano quel file di traduzione aggiornando le stringhe nel codice.
4. (facoltativo) Creare un modo per distribuire le traduzioni indipendentemente dal codice principale in modo da poter correggere un errore di battitura rapidamente.

Answer 3

ho avuto il tuo stesso problema e non ho fondato qualsiasi soluzione di terze parti così ho scritto questa libreria: https://github.com/fabiocaccamo/django-kway

speranza che qualcuno wil ha ritenuto utile.

Answer 4

L'utilizzo degli identificatori è sicuramente possibile con Gettext e ci sono strumenti che supportano questo. Tuttavia potrebbe essere insolito per alcuni traduttori poiché sono utilizzati per scaricare solo file .po per la traduzione offline, cosa non funziona con le traduzioni monolingue.

Per esempio Weblate supporta i file bene monolingue Gettext (io sono autore di questo strumento): https://docs.weblate.org/en/latest/formats.html#monolingual-gettext