Newsgroup: it.comp.lang.visual-basic
Titolo: Creare software in lingue diverse

Secondo voi qual è il metodo migliore per creare un software che possa
essere
modificato facilmente per essere tradotto in altre lingue?
Avrei pensato a qualche file aggiuntivo al quale il programma va sempre a
leggere
ogni volta che scrive qualcosa. La cosa però non è banale, infatti anche
tutti i
controlli hanno le loro Caption, Text, ecc. ecc.
Qual è il metodo migliore?

 ha scritto

Molti ti proporranno di usare il file risorse, ma, come hai giustamente
sottolineato, non si tratta semplicemente di avere un archivio della stessa
parola/frase nelle varie lingue. Il problema non è quindi "come" archiviare
le informazioni, ma come reperirle.
Personalmente (che cerco di usare meno cose possibili) ho scartato i file
risorse e ho optato per questa soluzione, magari poco elegante, ma
abbastanza performante, pochissime risorse spese e facilmente manutenibile:
Ho creato un file di testo per ogni lingua (e magari uno per ogni form per
non farlo diventare gigantesco e quindi lento da scorrere) dove inserisco,
con una sintassi assolutamente inventata, le "chiavi" di ricerca, pari, ad
esempio, a Nome form, Nome controllo, Nome proprietà e valore relativo.
Nell'evento Load (beh, diciamo in un momento praticamente corrispondente a
tale evento) chiamo un'unica Sub che scorre i vari controlli della form, e,
secondo tipologia, ne ricerca l'eventuale chiave sul file della lingua
scelta e ne imposta le varie proprietà (per esempio la Caption, ma anche
altre cosine che possono risultare utili) secondo quanto trovato nel file di
testo e con le necessarie verifiche di errori.
Vantaggi (ovviamente ci si deve adeguare alla sintassi inventata e più o
meno "pratica"):
-L'utente (magari prevedendo da programma la gestione files "sosia"
alternativi e prioritari che non verranno sostituiti dai miei aggiornamenti)
può modificare come vuole col semplice WordPad.
-Estendendo il metodo a tutti i messaggi (lasciandoli quindi all'esterno e
non "secchi in programma") l'utente può integrare un messaggio esplicativo
aggiungendo le sue note.
-Io stesso, se mi accorgo che un messaggio o una parte di maschera non è
sufficientemente comprensibile, correggo/integro il solo file di testo e non
tocco minimamente il programma.
Non elenco gli svantaggi (giungeranno lunghi elenchi?!), non ne ho alcuno,
sinceramente.

 alcuno, sinceramente.
Lupo non è questione di svantaggi. Dico solamente che la tua stessa idea,
per come è stata formulata, è implementabile al meglio con dei semplici file
XML,
anziché file di testo con delle chiavi qua e là.
Saluti,
--
Antonio Cangiano
Webmaster di 
www.visualcsharp.it
free.it.comp.lang.csharp / free.it.comp.lang.vbnet /
free.it.comp.lang.aspnet
--

 XML, anziché file di testo con delle chiavi qua e là.
Sarà pur vero, non dico di no. Ma tu pensi già in termini di .NET,
dove la gestine dell'XML è praticamente nativa. Ma hai presente
cos'è gestire XML con VB ? E poi, per quello che serve, tanto
vale usare un file .INI.
[txtInputUtenteITALIANO]
DefaultText = ""
ToolTip = "Inserire qui i dati"
[txtInputUtenteENGLISH]
DefaultText = ""
ToolTip = "Insert your data here"
...e via dicendo.
Al Form Load, cicli fra i controlli e carichi le proprietà, usando come
nome della sezione Control.Name & LinguaScelta.
Oh, è solo un'idea buttata giù così, ma non vedo controindicazioni,
e non ti costringe a usare un parser XML.
Bye, G.
--
Le risposte alle tue domande sono sul Sito Comune
di questo NewsGroup: 
http://it-lang-vb.net/
... e nell'help in linea !

 XML, anziché file di testo con delle chiavi qua e là.
Antonio, hai certamente ragione, ma, mi cito, "Personalmente (che cerco di
usare meno cose possibili)...", chi ha detto che "niente è più necessario
del superfluo" secondo me dice una grande scemenza, in questo mondo, almeno.
Lo so, può essere un grave handicap, ma (scusate, lo dico piano piano),
Bill, negli anni, mi ha indirettamente, eppur vivamente, consigliato di
seguire questa logica. Quel che non è sufficientemente collaudato (diciamo
SP3/4), naaaaaa, resta dov'è.
Cito anche Paperino, in questo stesso topic: "Ma hai presente cos'è gestire
XML con VB ?".
La mia risposta è no, non ci ho mai provato perchè non ne ho mai avuto
necessità. Comunque, dopo questa inquietante domanda, penso che non leggerò
mai il manuale di XML che ho stampato, insieme a tanti altri, mai letti pure
loro. Fino a reale necessità.
Aggiungo anche che, per rendere il più semplice possibile la manutenzione
dei file menzionati, non solo ho escluso i file risorse, ma anche il
database.
Tempo fa, giusto per rendermi conto, ho fatto un mini-mini-"database" in VB
Embedded, su CE (palmare), in totale testo. Ci credi che prima o poi, da
pazzo scatenato quale sono e ben sapendo che l'idea non è affatto originale,
prima o poi farò il mio vero database in txt? Indexato? Sì. Client/Server?
No, ma grande come uno spillo perchè occupa solo l'indispensabile,
zippabile, manutenibile (insomma...), veloce come una scheggia, com'erano i
file random di "una volta" che, ovviamente, ripristinerò alla grande.
Scherzo, ma non troppo.

 Scherzo, ma non troppo.
Tu scherzaci... ma uno dei miei migliori (= più efficienti,
veloci, manutenibili e funzionanti) programmi, lavora su
un file random neanche indicizzato. Fino a 5-10000 elementi,
faccio abbastanza in fretta a scorrere sequenzialmente
tutti i record, per cercare qualcosa. Lavora su un disco in
rete, e naturalmente lo carico in memoria, ma salvo le
modifiche o gli aggiornamenti volta per volta, anche in locale.
Alla chiusura, faccio un sort.
Mai perso un record.
Mai avuto problemi di installazione, nè tanto meno
di compatibilità. Mi porto dietro la base di questo programma
(che ho riutilizzato in altri progs, fra l'altro) dai tempi del VB4,
e ho cambiato solo qualche riga, giusto per migliorare lo stile,
non la funzionalità.
E immagino che se dovessi ricompilarlo in .NET, mi darebbe
ben pochi problemi.
Ah, e naturalmente non ho mai dovuto combattere con
ado-dao-rdo-psi-pci-msi-pli-dc-dc-dc-dc-nunteregghepiù !
Bye, Rino G.

 ado-dao-rdo-psi-pci-msi-pli-dc-dc-dc-dc-nunteregghepiù !
Ecco.

 dove la gestine dell'XML è praticamente nativa. [cut]
LOL ^__^
Hai ragione sai... sto troppo proiettato in .NET... ^___^ E'  incredibile
come dia quasi per scontato che si parli di 
VB.NET
, quando in realtà sono
molti che non hanno ancora switchato ^_^



Vorrei buttare li una risposta non per dare un consiglio ma per sentire i
commenti dei piů esperti e vedere se ho detto una scemata.
Creare un DB dove per ogni colonna ci sono i nomi e le frasi nelle lingue
diverse e al momento del caricamento dei vari form interrogarlo facendo una
SELECT in base alla lingua e inserire i risultati.
Che ne dite? sarebbe di una lentezza mostruosa?
--
Claudio P.
ICQ: 39052657

 Che ne dite? sarebbe di una lentezza mostruosa?
No, quanto a velocità forse no. Lo vedo solo (inutilmente)
complesso. Direi che ne vale la pena solo se nello stesso
progetto usi già un DB, magari a quel punto ci metti poco
ad aprirne un momento un altro.
Personalmente, tendo ad usare solo lo stretto necessario.
Bye, G.

 Che ne dite? sarebbe di una lentezza mostruosa?
Forse no, ma io, come dicevo, ho preferito il TXT, anche e soprattutto per
le dimensioni e la manutenzione. Un file per ogni form, separatamente
aggiornabile e non necessariamente sostituibile per rispettare le
personalizzazioni fatte dall'utente. Pensa inoltre che, generalmente, un
campo di database contiene una cosa specifica. Quanti campi dovrai creare (e
consumare anche se non usati) per gestire, eventualmente e oltre al testo,
anche (sono esempi, neh!) colori, dimensioni, proprietà specifiche come
bordi, aspetti, etc.?
Secondo me non hai detto una scemata, assolutamente, ma penso che, in
termini di flessibilità, velocità, pesantezza, risorse, aggiornamento,
manutenzione, etc. vinca il TXT. ;-)

 complesso.
Complesso intendi a livello di codice? cioè la creazione si due oggetti il
loro settaggio l'utilizzazione e la loro distruzione?
Grazie per le risposte


 bordi, aspetti, etc.?
Non dovrei assolutamente creare niente per gestire bordi, colori e altro
perchè quello è tutto uguale indipendentemente dalla lingua scelta.
Un DataBase con un'unica tabella o una tabella per ogni form per velocizzare
e rendere più ordinato


 Secondo voi qual č il metodo migliore per creare un software che possa
Per l'appunto č un problema che sto affrontando per un sw....
Io lo risolvo con
File risorse
es.
100
300 Italia
400
700 Inglese etc etc
basta fare un funzione (linguascelta+codice messagio)...con
linguascelta=100,400,... etc etc
Questo per le cazzatine ...label caption form, icone localizzate, etc etc...
Le cose piů sostanziose....e ancora NON definitive...ma chissenefrega....il
vecchio caro file INI ...se devi modificare qualcosa...la fai al volo col
notepad.
Se sei "moderno" come ti hanno detto file XML(ma io uso DAO su sto
prog....quindi!)
ciauz!


Prova a vedere questo sito:
http://www.beta-sigma.com/
ciao
		maxx
P.S. La versione Lite e' free!
-- 
NOSPAM: Rimuovere i trattini dallo username!

 o una tabella per ogni form per velocizzare e rendere più ordinato
Quest'ultima ipotesi è da escludersi. Prova a vedere le prestazioni di un db
Access (con SQL Server non ho provato) che contenga 20 tabelle contro uno
che ne contiene 200. Anche vuote.
Io, visto che la lingua non cambia da form a form, ma, semmai, da cliente a
cliente, anzi, proprio per rispettare anche le multinazionali anche nel
settore impiegatizio, da operatore a operatore, se proprio devo, un database
per ogni lingua, non un database per tutte le lingue. Quello carico e vale
pert l'intera sessione di lavoro. Inutile avere in linea dati per l'inglese
se l'operatore preferisce il francese.
Non scordare anche il fatto degli aggiornamenti (argomento toccato, ma non
approfondito, troppo spesso quello che fa saltare i budget e le previsioni
per le complicazioni che può creare).
Se inserisci una nuova label (oppure decidi di cambiare la caption a una
label esistente) che fai? Reinstalli l'intero database? E (sempre che tu
voglia dare, non imporre, questa possibilità) le eventuali personalizzazioni
dell'utente? Che fai? Le copri e lui se le deve rifare per 1000 controlli
e/o messaggi? Oppure non è il caso di fornire il tuo file (TXT o database
che sia) "standard" che è _comunque_ subordinato all'esistenza di un file (e
chiave relativa all'oggetto interessato) "gemello" e prioritario sul quale
l'utente può agire come vuole. Una procedura per le modifiche e le aggiunte
gliela vuoi fare? Se sì, devi. WordPad c'è già e va bene per qualsiasi file
di testo, senza alcun adattamento.

 loro settaggio l'utilizzazione e la loro distruzione?
In questo senso, in termini di numero di istruzioni, hai ragione. Come detto
sopra ho però qualche dubbio sulle prestazioni. Certamente penalizzante per
il "peso" dell'oggetto e dei "sotto-oggetti". Penso comunque che Paperino si
riferisse, come aveva specificato, al fatto di dover gestire a "quell'unico
db".

 modificato facilmente per essere tradotto in altre lingue?
allora prendo l'esempio ( IMHO semplice e intuibile )
1: crare dei file di linguaggio .LNG che sono usati pari a dei .INI
eccone la struttura :
[Actions]
0=Pausa
1=Sempre in Primo Piano
2=Nascondi Menu
3=Mostra StatusBar
....
[Mouse]
0=Ridimensiona
1=Aspect Ratio
...
[Data]
frmMain=DVB Viewer
frmMain.TbButton1.Caption=Mostra StatusBar
...
adesso capirai che per avere questo file devi AVERE BEN IN MENTE tutti gli
oggetti di cui vuoi gestirne la lingua
nel programma, da cui ho preso l'esempio, hanno creato anche un EXE che
chiamano translator che carica quello prima del "=" come numero ( non
considerando i "[") e quello a destra come valore , il tutto lo carica in
una tabella di una sola colonna con titolo row = numero e titolo col =
"testo"
a questo punto agendo sui campi puoi modificarli e salvarti un file LNG che
andrai a gestire nel prg principale.
nel principale non fai nient'altro che caricare il file LNG e assegnare a
ogni riga ( numero del controllo ) un valore