Cosa c'è di così buono in gettext per i file di lingua?

Question

Ovunque su SO quando si tratta di creare un'app multilingue in PHP tutti dicono che gettext è il modo migliore per farlo. Voglio solo sapere perché?

Come ciò che rende questo metodo di seguito, meno efficiente dell'uso di gettext?

<?PHP
//Have seperate language files for each language I add, this would be english file
function lang($phrase){
    static $lang = array(
        'NO_PHOTO' => 'No photo\'s available',
        'NEW_MEMBER' => 'This user is new'
    );
    return $lang[$phrase];
}
//Then in application where there is text from the site and not from users I would do something like this
echo lang('NO_PHOTO');  // No photo's available would show here
?>

Answer 1

Un aspetto positivo di gettext è che è una specie di standard di fatto: è usato da molte applicazioni, in molte lingue, il che significa che molte persone lavorano con esso.

Un'altra cosa positiva (forse una conseguenza, o una causa, o entrambi, in realtà) è che diversi strumenti, come Poedit per esempio, esiste per modificare i file gettext: non è necessario passare attraverso un codice sorgente (o qualunque cosa) di PHP. E questo è molto importante:

• significa che le persone non tecniche possono modificare i file di localizzazione di gettext
  • forse questo non ti sembra importante ora,
  • ma se stai lavorando su una grande applicazione open source, diventerà importante se ha successo e molte persone ne hanno bisogno nella loro lingua.
• significa che non rischiano di interrompere l'applicazione (pensa "errore di analisi" a causa di una mancata corrispondenza tra virgolette, ad esempio ;-))

Answer 2

Ci sono alcuni svantaggi nella tua " implementazione " ;.

• A differenza di gettext è implementato in php . ; -)
• Mantiene l'intera traduzione in memoria, non importa se la usi o no
• Il che è peggio, crea un'istanza dell'intera matrice di dati ogni volta che hai bisogno di una riga (ci vuole un po 'di tempo e un po' di memoria in PHP)
• Non è in grado di gestire forme plurali per molte lingue
• Il codice, usando questa traduzione è difficilmente leggibile
• Il codice, usando questa traduzione non ha un fallback incorporato da usare in caso di traduzione assente.

Fondamentalmente, la tua implementazione è ampiamente utilizzata in molti progetti che stanno morendo per rivendicare il loro supporto per l'internazionalizzazione e l'invenzione della ruota altamente innovativa, ma non si preoccupano un po 'del risultato e non conoscono il bene dal male.

Answer 3

È la stessa risposta che per tutte le domande che sembrano:

  

Cosa c'è di meglio con [altamente provato   e soluzione ampiamente usata]   che con [il mio cupo arrogante noob   implementazione]?

• È qui da molto tempo, che ci crediate o no, se lo sviluppatore esperto ci ha lavorato, lo ha usato e lodato, probabilmente è per una ragione.
• È uno standard, e quindi anche se la tua soluzione fosse migliore, il prezzo da pagare per romperla potrebbe non valerne la pena.
• Può fare 1000 in più rispetto all'implementazione perché è stato sviluppato tenendo conto di un ambito globale, mentre la tua idea mira solo a risolvere il tuo problema.

Non sto criticando, lo abbiamo fatto tutti, cercando di convincerci che siamo furbi e che altri sono programmatori eccessivi. Fa parte del modo di imparare. In realtà lo faccio continuamente, reinventando la ruota o esibendo con i miei amici / colleghi su un codice KISS che ho hackerato. Con il tempo, finisci per farlo sempre meno, e suppongo che smetti di farlo il giorno in cui ti meriti davvero di farlo :-)

Answer 4

Il vantaggio di gettext, rispetto ad altre soluzioni come la tua, le tabelle di stringhe Java o le risorse di Windows, è che rende il codice sorgente più leggibile.

Confronta questo:

printf(_("No photo available (error %d)."), err);

con questo:

printf(i18n(NO_PHOTO), err);
// or some variant of the same thing

Nel primo caso, puoi vedere il messaggio proprio lì nel codice e sai esattamente cosa fa. In quest'ultimo caso, vedi solo una costante simbolica e devi cercare gli identificatori di testo e formato esatti.