Newsgroup: it.comp.lang.visual-basic
Titolo: Ancora multi-language, ma di un software mono-lang.

Gentilmente, v-Vi sottopongo il mio problema: ho un applicativo che ho
sempre venduto a clienti italiani, e fin dall'inizio quindi non era
contemplato il multilanguage.
L'applicativo è parecchio complesso (almeno per i miei standard): 15.000
righe di codice infarcite di label, msgbox, textbox ecc.
Ora dovrei svilupparne una versione per l'estero (belgio).
Ho dunque 2 strade:
1. ricompilare una versione dell'EXE (duplicata dall'originale) con
tutti i testi sostituiti a mano nel codice e tradotti in inglese (il
cliente si potrebbe accontentare del solo inglese)
2. creare una release successiva del mio software con il supporto
multi-language.
La strada 1) sicuramente è la più rapida, ma anche la 2) mi tenta.
Certamente, poichè il tempo è denaro, non ho intenzione di impazzire con
raffinatezze di programmazione non richieste, ma se ci fosse un sistema
abbastanza rapido per implementare il multilanguage in un programma
sviluppato per un solo linguaggio, potrei affrontare i tempi di sviluppo
richiesti.
Quali strade mi si aprono?
INI FILE, come suggerito poco sopra da Yronium a Massimo, oppure MDB,
oppure file di risorse. Quale potrebbe essere nel mio caso, secondo voi,
la via più semplice? Tenete conto che non ho il problema di traduttori
esterni, quindi tutto il discorso pro mdb e contro il file di risorse
viene a morire.
grazie e ciao
Marco F.

 multi-language.
Ciao,
personalmente ti consiglio l'approccio al file di risorse (ti può essere 
utile anche per 'localizzare', in futuro, anche picture o altri contenuti 
binari).
Nell'area articoli di VB T&T (
www.visual-basic.it
) trovi un'articolo 
("Aggiungere il supporto multi-lingue ai progetti VB") a cura di Giorgio 
Brausi che ti potrà senz'altro esserti utile.
Ciao
-- 
Gianluca Cannalire
Microsoft MVP/MCP - Visual Basic
http://www.visual-basic.it
http://community.visual-basic.it/gianluca
 


Magari ti può essere utile questo mio post di 1 anno fa:
http://tinyurl.com/y66o69
Bye
Raf
-----------------------------------------------------
Funk: cooler than the other side of the pillow.

 voi, la via più semplice?
Io ho sviluppato un applicativo multilingua, ma a differenza di te ho avuto 
la fortuna di pensarci subito e l'ho progettato sin dall'inizio con una 
matrice di stringhe, che vengono lette all'avvio del programma.
Ho adottato la tecnica del file di lingua testuale, con righe "taggate", le 
cui stringhe sono precedute da un prefisso numerico a 3 cifre (che nel 
programma rappresenta l'indice della matrice di stringhe). In sostanza, un 
banalissimo TXT (rinominato poi con estensione a piacere) che contiene 
l'elenco di tutte le stringhe nazionalizzate presenti nel programma, nel 
formato:
000 - labela
001 - labelb
002 - ecc...
Anche se capisco che questo sistema da una parte si presta a facili 
manipolazioni da parte dell'utente (ma mi sono detto "e chissenefrega... se 
lo modifica peggio per lui...") da un'altra parte devo dire che è stata una 
benedizione, oserei dire una scelta vincente, perché nel giro di pochi mesi 
ho ricevuto tutte le traduzioni nelle lingue principali (inglese francese 
spagnolo portoghese olandese tedesco svedese norvegese ceco croato 
finlandese...) da altrettanti utenti entusiasti del mio applicativo a tal 
punto da farmi il favore di tradurlo nella loro lingua!!! :-)
Ovviamente le lingue ricevute finiscono "online" sul sito, in modo che anche 
i nuovi utenti possano usufruirne... e questo a tutto vantaggio della 
visibilità e dell'immagine del programma stesso.
La scelta sta a te... vedi tu cosa è meglio.
Dipende ovviamente dal tipo di utilizzo che prevedi, e dalla varietà degli 
utenti (sparsi nel mondo) che pensi di dover avere.
Un unico appunto, per finire, ma che purtroppo NON E' UN DETTAGLIO:
L'interfaccia ne risentirà, e non poco... ogni nuova lingua che riceverai 
dovrà essere testata, prima della distribuzione, perché *sicuramente* 
qualche campo andrà fuori dai margini, e quindi sarà necessaria una 
variazione della GUI (e conseguente ricompilazione e rilascio di una nuova 
release).
L'olandese mi ha dato molti grattacapi, in questo senso...
Un'altra cosa: qualora nel tuo programma tu utilizzassi degli oggetti che 
non prevedono l'utilizzo di caratteri unicode, ricordati che anche quello 
sarà un problema: infatti finché rimarrai nel set europeo (latin1) non 
succederà nulla, ma appena dovrai implementare una lingua appartenente ad un 
codepage diverso dal nostro (per esempio il ceco, o l'ebraico, o il cinese) 
allora sono dolori... dovrai prevedere anche la configurazione del codepage 
per tutti gli oggetti in questione.
Ma questo è un problema che incontrerai solo con le lingue dell'est europa o 
con quelle orientali. Finché rimarrai in latin1 (west-europe, nord e sud 
america e australia) non avrai nessun problema di codepage.
Ciao, e buon lavoro! ;-)
B.

 Brausi che ti potrà senz'altro esserti utile.
Non solo l'articolo, ma anche una addin che sembra miracolosa.
A breve la provo
Grazie.

 
http://tinyurl.com/y66o69
Il link al support microsoft puntato dal tuo post non è più valido.
Grazie lo stesso
ciao

Ciao
l'idea mi piace, mi sembra semplice, facile da modificare, e soprattutto
da implementare...
Se non riesco a far funzionare il sistema di Brausi, credo che questa
sarà la mia strada
ciao e grazie


Hai ragione... comunque l'ho ritrovato cercando in base all'ID 232625:
http://support.microsoft.com/kb/232625/en-us
