Perché le risorse stringa sono generalmente mantenute esterne al codice e non all'interno del codice?

Naviga le tue risposte
17

Generalmente, su molte piattaforme, sto scrivendo le mie risorse di stringa su un file .resx o .xml, e quindi le sto utilizzando con un approccio basato sulla piattaforma.

Ovvero, su iOS, le sto ottenendo tramite NSBundle.MainBundle e utilizzando Context.Resources su Android.

Quali sono i vantaggi di questo approccio e perché non averlo direttamente accessibile nel codice, quindi, ad esempio:

  1. In un progetto multipiattaforma, qualsiasi piattaforma può accedervi direttamente, senza integrazione.

  2. Non ci sono dubbi durante la costruzione se le risorse sono state create correttamente.

  3. Il coder può utilizzare funzionalità come la gestione multilingue

Per farla breve: qual è il motivo per cui le risorse stringa sono strutturate in questo modo?

[Modifica]

Diciamo che il mio file fa parte di un progetto "core" condiviso tra altri progetti. (Pensa a un PCL, struttura di file di progetto multipiattaforma.)

Supponiamo che il mio file sia del tutto simile a un file .resx / .xml, simile a questo (non sono un professionista in xml, scusa!):   parametri   Paramètres

Quindi, questo è fondamentalmente un xml personalizzato, in cui si punta alla chiave / lingua per ottenere la stringa corretta.

Il file sarebbe parte dell'applicazione proprio come si aggiunge qualsiasi file accessibile all'interno di un'app e il sistema per accedere alle risorse stringa, codificato tramite PCL. Questo aggiungerebbe un sovraccarico alle applicazioni?

    
posta Léon Pelletier 10.03.2014 - 13:35
fonte

4 risposte

38

Localizzazione e internazionalizzazione,

Mantenere le stringhe esterne consente loro di cambiare (leggi: tradotto) senza la necessità di ricompilare (solo una ricollegatura al massimo, e semplicemente rilasciare una nuova cartella al meglio).

    
risposta data 10.03.2014 - 13:39
fonte
10

Se si dispone di un file che contiene solo le risorse stringa, è possibile assegnare il file di risorse a un'agenzia di traduzione o qualcosa del genere e ottenere una traduzione. Immagino che tu possa immaginare quanto possa essere difficile se dovessi dare un sacco di file di codice a un laico per fare una traduzione (oltre a non voler dare il tuo codice a chiunque).

    
risposta data 10.03.2014 - 13:52
fonte
7

Oltre all'internazionalizzazione / localizzazione, separare le stringhe di testo in questo modo consente anche a un correttore di bozze di inviare correzioni di ortografia / grammatica / punteggiatura isolate a, messages.${LOCALE} , senza dover toccare un vero file di codice sorgente. Potresti avere un blackout sulle modifiche al codice ma accettare tali correzioni di testo. Se accetti modifiche simultanee sia al codice che ai messaggi, tenerli separati semplifica l'unione delle patch, a condizione che le modifiche al codice non ridefiniscano i messaggi esistenti quando il proofreader ha estratto messages.en_US .

Inoltre, a seconda di come è implementato, potrebbe non essere nemmeno necessario ricollegare l'applicazione. Il codice può semplicemente prendere la linea 138 da messages.${LOCALE} per un particolare messaggio, con il numero di linea determinato in fase di esecuzione.

    
risposta data 10.03.2014 - 18:50
fonte
0

Questo è il modo in cui la tua lingua / piattaforma ha deciso di implementare la localizzazione delle stringhe. Tutti gli approcci alla localizzazione necessitano di qualche tipo di file di risorse esterne per ottenere le traduzioni. Il principale punto dolente è come mantieni queste risorse.

Sembra che tu debba mantenere questi file di risorse manualmente , il che può essere un grosso problema. Inoltre, complica la condivisione di stringhe ripetute. E doverlo fare quando al momento stai inviando solo una lingua, è ancora più difficile.

Un'alternativa comune è l'approccio GNU Gettext che consiste semplicemente nel contrassegnare le stringhe traducibili nel codice sorgente e nell'estrare automaticamente queste stringhe in file PO standard che funzionano bene su piattaforme e linguaggi incrociati. Dal punto di vista dello sviluppatore, batte la manutenzione manuale dei file di risorse XML ogni giorno.

    
risposta data 14.03.2014 - 15:08
fonte

Leggi altre domande sui tag

Dovremmo provare a rivedere tutto il nostro codice? Le frasi dovrebbero essere nel metodo interno o esterno?