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

18

Generalmente, su molte piattaforme, sto scrivendo le mie risorse di stringa in un file .resx o .xml, e poi le sto usando usando un approccio dipendente dalla piattaforma.

Cioè, su iOS, li ottengo tramite NSBundle.MainBundlee usando Context.Resourcessu Android.

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

In un progetto multipiattaforma, qualsiasi piattaforma può accedervi direttamente, senza integrazione.
Durante la costruzione non ci sono dubbi sul fatto che le risorse siano state costruite correttamente.
Il programmatore può utilizzare funzionalità come la gestione multilingua

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

[Modificare]

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

E supponiamo che il mio file sia totalmente simile a un file .resx / .xml, che assomigli a questo (non sono un professionista in xml, scusate!): Parametri Paramètres

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

Il file farebbe parte dell'applicazione così come si aggiunge qualsiasi file accessibile all'interno di un'app e il sistema per accedere alle risorse della stringa, codificato tramite PCL. Ciò aggiungerebbe un sovraccarico alle applicazioni?

cross-platform resources internationalization

— Léon Pelletier
fonte

possibile duplicato di internazionalizzazione: cosa pensare?

— moscerino

6

No, le mie preoccupazioni non riguardano l'internazionalizzazione e piuttosto l'architettura e multipiattaforma, scusate.

— Léon Pelletier,

1

Questa domanda può essere generalizzata a qualsiasi tipo di risorsa, davvero, anche con facilità di localizzazione / internazionalizzazione a parte. Quali sono i vantaggi di mantenere qualsiasi tipo di risorsa separata dal codice? Perché le immagini o i file audio di solito non sono codificati nella sorgente come stringhe binarie? (Gli URI dei dati esistono, ovviamente, ma sono generalmente poco pratici per file di grandi dimensioni). Altri hanno già fornito alcune risposte piuttosto valide, ma volevo solo sottolineare che le stringhe leggibili dall'utente non sono l'unico tipo di risorsa che trae vantaggio dall'esternalizzazione.

— JAB

38

Localizzazione e internazionalizzazione,

Mantenere le stringhe esterne consente loro di cambiare (leggi: tradotto) senza bisogno di ricompilare (solo una ricollega al massimo, e semplicemente cadere in una nuova cartella al massimo).

— maniaco del cricchetto
fonte

Questa ricollega contro la ricompilazione è una buona ragione, grazie.

— Léon Pelletier,

2

Ancora l'unica persona che ha capito la domanda.

— Léon Pelletier,

3

@ratchetfreak è una cattiva forma da accettare troppo presto (nel giro di poche ore sicuramente conta). Non dà il tempo ad altre risposte di fare bolle. Questo è semplice, preciso e preciso ... ma qualcuno potrebbe fornire una risposta migliore, più completa, più dettagliata domani (o il mese prossimo).

— WernerCD,

3

Extra: Potrebbe essere ok per un traduttore modificare un file XML, ma non lasciarli mai

— suonare

Ora la domanda è: "Questa risposta vale ancora per le lingue interpretate?". Chiedo perché non ci sarebbero ricollegamenti o ricompilazioni.

— Thomas Eding,

10

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

— Flo
fonte

2

Bene, non c'è alcuna differenza tra un file incluso nel progetto e un file di risorse. Il problema non c'è.

— Léon Pelletier,

Sto parlando di includere le risorse direttamente nel codice e quindi gestire tutto all'interno del programma, quindi è più PCL / Cross-platform friendly.

— Léon Pelletier,

2

se hai un file "di codice" con tutte le tue risorse di stringa (dizionario definiton o qualcosa del genere) e nient'altro in esso .. beh, in fondo è un file di risorse (ma uno per una singola piattaforma, come ad esempio Android non lo farà prendere qualsiasi codice obiettivo-c). Se contiene altro codice o se è suddiviso su più file, è più difficile ottenere una traduzione esterna. In una vista multipiattaforma, un formato di testo come xml ha il vantaggio di poter essere letto e utilizzato su qualsiasi linguaggio / piattaforma (ma potresti doverne fare un po 'di lavoro)

— Flo

7

Oltre all'internazionalizzazione / localizzazione, la separazione di stringhe di testo in questo modo consente anche a un correttore di bozze di inviare correzioni a ortografia / grammatica / punteggiatura a cui sono isolate 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 si accettano modifiche simultanee sia al codice che ai messaggi, tenerle separate semplifica l'unione delle patch, a condizione che le modifiche al codice non ridefiniscano i messaggi esistenti al momento del checkout del correttore di bozze messages.en_US.

Inoltre, a seconda della sua implementazione, potrebbe non essere nemmeno necessario ricollegare l'applicazione. Il codice può semplicemente prendere la riga 138 messages.${LOCALE}per un determinato messaggio, con il numero di riga determinato in fase di esecuzione.

— Monty Harder
fonte

0

Questo è solo il modo in cui la tua lingua / piattaforma ha deciso di implementare la localizzazione delle stringhe. Tutti gli approcci alla localizzazione richiedono una sorta di file di risorse esterne per ottenere le traduzioni. Il problema principale è come mantenere queste risorse.

Sembra che tu abbia bisogno di gestire manualmente questi file di risorse , il che può essere piuttosto un peso. Inoltre complica la condivisione di stringhe ripetute. E doverlo fare quando stai spedendo solo una lingua, è ancora più un peso.

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

— Rene Saarsoo
fonte