Gettext: È una buona idea che l'ID del messaggio sia il testo inglese?

https://stackoverflow.com/questions/216478

03-07-2019
|

Domanda

Ci stiamo preparando a tradurre il nostro sito Web PHP in varie lingue e il supporto gettext in PHP sembra la strada da percorrere.

Tutti i tutorial che vedo consigliano di utilizzare il testo inglese come ID messaggio, ad esempio

gettext (" Ciao a tutti! ")

Ma è davvero una buona idea? Diciamo che qualcuno nel marketing vuole cambiare il testo in " Ciao a tutti! & Quot ;. Quindi non devi aggiornare tutti i file della lingua perché quella stringa - che in realtà è l'ID del messaggio - è cambiata?

È meglio avere una sorta di ID generico, come " hello.message " ;, e un file di traduzioni in inglese?

Soluzione

Uso ID significativi come " welcome_back_1 " che sarebbe " bentornato,% 1 " ecc. Ho sempre l'inglese come mia "base" lingua quindi, nel peggiore dei casi, quando una lingua specifica non ha un ID messaggio, ripiego sull'inglese.

Non mi piace usare frasi inglesi effettive come ID messaggio perché se l'inglese cambia cambia anche l'ID. Questo potrebbe non influenzarti molto se usi alcuni strumenti automatici, ma mi dà fastidio. Non mi piace usare codici semplici (come msg3975) perché non significano nulla, quindi leggere il codice è più difficile a meno che non si sporchino commenti ovunque.

Altri suggerimenti

Wow, sono sorpreso che nessuno stia sostenendo di usare l'inglese come chiave. Ho usato questo stile in un paio di progetti software e IMHO ha funzionato abbastanza bene. La leggibilità del codice è ottima e se si modifica una stringa inglese diventa ovvio che il messaggio deve essere considerato per la nuova traduzione (il che è una buona cosa).

Nel caso in cui si corregga solo l'ortografia o si apportino altre modifiche che sicuramente non richiedono traduzione, è semplice aggiornare gli ID per quella stringa nei file di risorse.

Detto questo, sto attualmente valutando se portare avanti o meno questo modo di fare I18N a un nuovo progetto, quindi è bene sentire alcune riflessioni sul perché potrebbe non essere una buona idea.

Non sono assolutamente d'accordo con la risposta di Richard Harrisons sulla quale afferma che è "l'unico modo". Caro asker, non fidarti di una risposta che afferma che è l'unico modo, perché il "solo modo" non esiste.

Ecco un altro modo in cui IMHO ha alcuni vantaggi rispetto all'approccio di Richards:

Inizia con l'uso della proto-versione della stringa inglese come originale.
Non visualizzare queste proto-string ma crea comunque un file di traduzione per l'inglese
Copia le proto-string nella traduzione per iniziare

I vantaggi:

codice leggibile
il testo nel tuo codice è molto vicino se non identico a quello che visualizza la tua vista
se vuoi cambiare il testo inglese, non cambi la proto-stringa ma la traduzione
se vuoi tradurre la stessa cosa due volte, basta scrivere una proto-stringa leggermente diversa o semplicemente aggiungere 'versione per questo e quello' e hai ancora un codice perfettamente leggibile

Il motivo per cui gli ID sono inglese è che l'ID viene restituito se la traduzione non riesce per qualsiasi motivo: la traduzione per la lingua corrente e il token non sono disponibili o altri errori. Ciò ovviamente presuppone che lo sviluppatore stia scrivendo il testo originale in inglese, non una persona di documentazione.

Anche se il testo inglese cambia, probabilmente le altre traduzioni devono essere aggiornate?

In pratica usiamo anche ID puri piuttosto che testo in inglese, ma ciò significa che dobbiamo fare molto lavoro extra per impostare automaticamente l'inglese.

In una parola non farlo.

La stessa parola / frase in inglese può spesso avere più di un significato e ognuna significa una traduzione diversa.

Definisci ID mnemonici per le tue stringhe e tratta l'inglese come un'altra lingua.

Concorda con altri poster che i numeri ID nel codice sono un incubo per la leggibilità del codice.

Ex ingegnere della localizzazione

C'è molto da considerare e rispondere non è così semplice.

Uso dell'inglese semplice

Pro

Facile da scrivere e leggere il codice
Nella maggior parte dei casi, funziona anche senza eseguire le funzioni di traduzione nel codice

Contro

I programmatori coinvolti devono essere anche buoni copywriter :)
Devi scrivere testi precisi e corretti completamente in inglese, anche nel caso in cui la prima lingua che devi eseguire sia qualcos'altro (ovvero stiamo iniziando da un gran numero di progetti in lingua ceca e li stiamo localizzando in inglese in un secondo momento) .
In molti casi, è necessario utilizzare i contesti. Se non riesci a farlo dall'inizio, è un sacco di lavoro da aggiungere in seguito. Per spiegare: in inglese, una parola può avere molti significati diversi - e devi usare contesti per differenziarli - e non è sempre così facile (ordine = ordinamento o può essere un ordine di acquisto).
Può essere molto difficile correggere l'inglese più avanti nel processo. Le correzioni delle stringhe di origine portano molto spesso alla perdita di frasi già tradotte. È molto frustrante perdere la traduzione in 3 lingue diverse solo perché hai corretto l'inglese.

Uso dei tasti

Pro

È possibile utilizzare le funzioni della piattaforma di localizzazione anche per la lingua inglese. Cioè stiamo usando la deliziosa piattaforma Crowdin. Esistono molti strumenti utili - o piuttosto un flusso di lavoro completo - per la gestione delle traduzioni: voto per traduzioni diverse, cronologia delle traduzioni, glossari (che aiuta a mantenere coerente la traduzione / lingua), correzione, approvazione, ecc. L'uso delle chiavi rende questo processo molto più liscio.
È molto più facile inviare testi in inglese per la correzione di bozze ecc. Di solito, non è una buona idea lasciare che i copywriter modifichino direttamente il tuo codice :)

Contro

Installazione del progetto più complicata.
Più difficile da usare% d,% s ecc.

Non hai già risposto alla tua domanda? :)

Chiaramente, se intendete supportare i18n della vostra applicazione, dovreste trattare tutte le implementazioni linguistiche allo stesso modo. Se qualcuno decide che una stringa deve essere modificata, si apporta una modifica simile in tutti i file della lingua. I metadati con il check-in dovrebbero raggruppare tutti i file della lingua insieme nella stessa modifica. Se il tuo " default " la lingua è gestita in modo diverso, il che rende più difficile la manutenzione.

Alla fine della giornata, un traduttore dovrebbe essere in grado di sedersi e cambiare i testi per ogni lingua (in modo che corrispondano nel significato) senza dover coinvolgere il programmatore che ha già fatto il suo lavoro.

Questo mi fa sentire come la risposta corretta è usare una versione modificata di gettext dove metti stringhe come questa

_(id, backup_text, context)

_('ABOUT_ME', 'About Me', 'HOMEPAGE')

contesto facoltativo

perché in questo modo? perché devi identificare il testo nel sistema usando un ID univoco non in inglese che potrebbe essere ripetuto altrove.

Dovresti anche mantenere il backup, l'id e il contesto nello stesso posto nel tuo codice per ridurre le discrepanze.

Anche l'id deve essere leggibile, il che comporta il problema dei sinonimi e dell'uso duplicato (anche come ID), potremmo prefissare gli ID come questo " HOMEPAGE_ABOUT_ME " o " MAIL_LETTER " ;, ma

le persone dimenticano di farlo all'inizio e cambiarlo in seguito è un problema
è più flessibile per il sistema essere in grado di raggruppare sia per id che per contesto

ecco perché alla fine ho aggiunto anche la variabile di contesto

il testo di backup può essere praticamente qualsiasi cosa, potrebbe anche essere " [Impossibile caricare il testo ABOUT_ME @ HOMEPAGE, si prega di contattare esempio@esempio.com] "

Non funzionerà con gli attuali programmi di editing di gettext come " poedit " ;, ma penso che puoi definire nomi di variabili personalizzati per traduzioni come solo " t () " senza il carattere di sottolineatura all'inizio.

So che gettext supporta anche i contesti, ma non è molto ben documentato o ampiamente utilizzato.

P.S. Non sono sicuro del miglior ordine variabile per applicare un codice valido ed estensibile, quindi i suggerimenti sono ben accetti.

Andrei fino al punto di dire che non vuoi mai (per la maggior parte dei valori di mai) usare il testo libero come chiave per qualsiasi cosa. Immagina se SO ha usato il titolo della query come chiave di questa pagina, ad esempio. Se qualcuno lo collega e quindi il titolo viene modificato, il collegamento non è più valido.

Il tuo problema è simile, tranne che tu saresti anche responsabile dell'aggiornamento di tutti i link ...

Come menziona Douglas Leeder, quello che probabilmente vuoi fare è usare l'inglese come lingua predefinita (backup), sebbene un'interfaccia che utilizza l'inglese e un'altra lingua mescolata sia altamente confusa (ma anche leggermente divertente).

Oltre alle considerazioni precedenti, ci sono molti casi in cui vorresti la chiave " " (msgstr) essere diverso dal testo sorgente (inglese). Ad esempio, nella vista HTML, potrei voler dire [yyyy] dove la destinazione e l'etichetta di quel tag di ancoraggio dipendono dalle impostazioni locali dell'utente. Per esempio. potrebbe essere un collegamento a un social network, e negli Stati Uniti sarebbe Facebook, ma in Cina sarebbe Weibo. Quindi i messaggi potrebbero essere qualcosa di simile a socialSiteUrl e socialSiteLabel.

Uso un mix.

Per le stringhe di base che non credo avranno conflitti / cambiamenti / strani significati, farò in modo che la chiave sia la stessa dell'inglese.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow