Newsgroup: it.comp.lang.visual-basic
Titolo: come fare multi lingua?

Ciao a tutti.
Ho la necessità di scrivere un  programma multi lingua.
Pensavo di creare un file  "tipo INI" con le diverse traduzioni ed a 
secondo della selezione fatta dall'utente andare a pescare le parole 
dal file e sostituitle all'inerno del programma.
Cosa ne pensate ?
se eventualmente avete altre soluzioni, magari con qualche esempio di 
codice, ne sarei felice :D
Grazie

dal file e sostituitle all'inerno del programma.
Di soluzioni se ne possono adottare diverse, come fare un file di risorse con le
traduzioni.
Io uso un sistema come quello che hai pensato tu.
Metto le scritte in un file che leggo all'apertura del programma, le inserisco
in una matrice di stringhe, poi da programma chiamo la stringa con il numero.
Ovviamente la sequenza delle scritte deve essere la medesima in tutte le lingue.
Il vantaggio è che a volte le scritte mancanti le aggiungono direttamente gli
utenti modificando il file, altrimenti con l'islandese o il polacco sarebbe
stata molto dura.
--
ciao
  Stefano

Quoto, perň con una piccola modifica:
io invece di salvare una matrice di stringhe uso un approccio ad oggetti.
Creo un Tipo "applicazione" con vari sotto tipi "formMain" "Formcoso" 
"FormPincoPallino" e per ogni form creo altri sotto tipi "Label1, 
label2, button1, button2..."
Cosě quando voglio assegnare a label1 del FormMain un valore presente 
nel file INI, faccio:
label1.Text = Applicazione.FormMain.label1
Cosě invece di ricordare a memoria a che numero della matrice 
corrisponde una stringa, usi l'intellisense di VB6. :-)
bye

 numero.
Un sistema ancora più comodo, che non comporta nemmeno avere l'ordine 
corretto, e quindi la gestione di un indice costantemente da aggiornare, è 
mettere le varie frasi in una Collection (o un'hashtable in .Net) e usare 
sempre una funzione del tipo:
s = Translate("Questa è la mia stringa")
al posto di
s = "Questa è la mia stringa"
Translate() restituirà la stringa corrispondente tradotta o quella in 
intaliano se non esiste la traduzione.
Vantaggio: è un attimo per chiunque aggiungere la nuova frase in lingua se 
mancante.
Ciao 

Ciao. Io ho già fatto alcuni programmi multilingua, e i trucchi che si
possono adoperare sono diversi.
Caricare le stringhe in un array nel load è utile per poter cambiare la
lingua a run-time, senza dover chiudere e riaprire il programma: basta
inserire il caricamento dentro una funzione e richiamarla durante il load ma
anche quando la lingua selezionata è cambiata.
Si può sfruttare IntelliSense enumerando i codici delle stringhe, e
utilizzando delle costanti dal nome significativo si facilita di moltissimo
la programmazione, a patto però di progettare bene il tutto prima di
cominciare. Ad esempio io ho delle costanti tipo: frmMainLblNome,
frmMainLblCognome, frmMainMsgNoRec, eccetera.
Se puoi, cioè quando il tuo programma accede a un database .mdb, e perciò
hai già la necessità di distribuire ADO per farlo funzionare, ti consiglio
di implementare le stringhe multilingua in un altro file .mdb. Il file mdb è
molto più facile da usare per chi ti traduce le stringhe: crei una colonna
per l'ID della stringa, una colonna per l'italiano e poi una colonna per
ciascuna lingua aggiuntiva, poi nel file che dai al traduttore nascondi le
che non gli interessano. In questo modo lui lavora con una cella con la
stringa in italiano accanto a un'altra cella in cui lui deve scrivere la
traduzione. Se dovesse lavorare su un file di testo, per ogni stringa deve
scorrere il file in avanti o indietro per cercare la stringa corrispondente.
Naturalmente puoi usare sempre il file Access, ma poi devi distribuire MDAC
anche se il tuo programma non ne avrebbe la necessità.
Spero ti sia di aiuto. Ciao
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

Grazie a Tutti,
mi siete stati di grande aiuto.

mancante.
Si, la tua e quella di Nicola sono certamente soluzioni più eleganti, anche se
ad un elettronico come me viene subito da pensare al lavoro in più che deve fare
la CPU, una cosa che in tempi di .NET è veramente assurda.
Io uso la matrice di stringhe anche perchè in molti casi debbo visualizzare un
messaggio di allarme o di funzionamento che arriva via seriale, ed è una stringa
contenente il numero di evento e non la scritta, in maniera da renderlo
indipendente dalla lingua selezionata sul PC.
Inoltre la matrice la chiamo ancora GetStr() perchè ai tempi del QB o del VB3 la
capacità di memoria usabile era di soli 32K o 64K, impedendomi di tenere in
memoria tutto il file.
Quindi il file veniva aperto all'inizio, tenuto aperto e in una matrice di Long
come ScrAd&() si mettevano gli indirizzi delle scritte, poi con GetStr$() si
caricava  la stringa da scrivere.
es:
FUNCTION GetStr$ (Ns, ScrAd&())
  SEEK #4, ScrAd&(Ns) + 1         'PUNTA L'INDIRIZZO SCRITTA
  GetStr$ = INPUT$((ScrAd&(Ns + 1) - 4) - (ScrAd&(Ns)), #4)
END FUNCTION
Quindi passando poi a VB5 ho tenuto la stessa denominazione GetStr() che, data
la possibilità di caricare in memoria tutto il file, è diventata una matrice di
stringhe.
--
ciao
  Stefano

 ha scritto nel messaggio
news:mn.e29b7d617...@tiscalinetnospam.it...

Un testo fondamentale per questo argomento è il seguente:
http://www.i18nwithvb.com/
Leggendolo mi sono fatto l'idea che il compromesso probabilmente migliore in
termini di performance, deployment e manutenzione sia quella di una (o più)
DLL di sole risorse.
Non mi garbano granché i file INI per questo scopo poiché non sono
"sigillati": chiunque può modificarli con un banale editor.
Nemmeno l'uso di un DB lo vedo ottimale, visto che occorre distribuire MDAC
anche quando non è necessario per il resto dell'applicazione.
Qua c'è qualche riferimento:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q232625
Questo link mostra però come generare una DLL ActiveX con le risorse
stringa, mentre l'ideale sarebbe una DLL ordinaria, che può essere creata a
partire da un resource script (--> google) con il Resource Compiler (RC.EXE)
e il Linker di Visual Studio.
Bye
Raf

"sigillati": chiunque può modificarli con un banale editor.
Dipende dai casi, a volte può essere anche un vantaggio.
A me hanno trovato diversi errori e migliorato alcune traduzioni, tanto che ho
inserito la possibilità di editare il file di scritte in un menù, utile
soprattutto per le lingue orientali.
D'altronde il traduttore difficilmente è contemporaneamente un tecnico e di
lingua madre, quindi le espressioni sono spesso migliorabili.
Ho anche aggiunto in fondo al file la mia mail con la richiesta di mandarmi
'please' la versione aggiornata se fanno modifiche, cosa che fanno.
--
ciao
  Stefano