Traduzione giochi Legend, (già: "problemi del traduttore" Consigli per chiunque voglia Opzioni

[katoble]

Ho deciso di cominciare la dura vita del traduttore perchè alcuni giochi meritano di essere goduti a pieno in italiano e perchè spesso non sono facilmente reperibili in tale lingua.
Per cominciare ho letto parte della guida di Marco, alias CavaliereOmbra, per farmi un'idea su ciò che mi aspettava.
Decidendo di continuare, siccome avevo sul pc la versione inglese di Might and magic 8 ho provato ad iniziare da questo gioco.
Mi sono quindi imbattuto nella prima difficoltà tecnica: non riesco a trovare i file di testo.
Ho provato con dragon unpacker a vedere se c'erano archivi compressi ma non ho trovato niente di importante; allora sono passato all'editor esadecimale e codificando tramite ascii. Qualche parola in inglese mi veniva fuori ma per il resto non ho trovato nè dialoghi nè nomi di armi,quest o altro che potessi poi tradurre.

Chiedo quindi illuminazioni su cosa posso fare. E' possibile che un file abbia 2 codici (ascii ed un altro) ?

[Syxtem]

Ti dirò... mi ha intrigato un po' questo caso e mi sono messo a dare un'occhiata pure io.
Innanzitutto ti dico che sono d'accordo sul fatto che il decompressore non effettui il dump di tutti i dati, ma non credo riguardi i vocaboli che dici te. Mi riferisco soprattutto ai flag dei segmenti, che nel dump non vengono riportati.
Cmq mi son messo a guardare qualcosa. Ora come ora sto valutando se è più conveniente scrivere il compressore direttamente in c o in java, come invece preferirei (purtroppo in java non esistono i tipi numerici unsigned ^^' ).

ho visto delle cose tipo <%s%sn't think%s [...]> .

Probabilmente questa frase va bene così, non mancano cose che il decompressore non ha estratto. In C esistono diverse funzioni che sfruttano queste cose. La più classica ad esempio è la printf (per stampare a video) che fa uso di questi marcatori per inserire il contenuto di variabili nel testo da mostrare.
Mentre in Pascal (e quindi forse anche in Delphi, anche se mi sembrava che lì le cose le avessero potenziate un po'), se non ricordo male, si aveva una struttura del tipo:

CODICE

writeln('Stringa1 =',var1,' e Stringa2 =',var2)

in C la cosa diventa:

CODICE

printf("Stringa1 = %s e Stringa2 = %s",var1,var2)

Poi a seconda del tipo di dato, si deve usare un certo tipo di "marcatore", per indicare al compilare come deve rappresentare il contenuto della variabile (ad esempio come numero o come carattere).
Magari puoi dare un'occhiata qui: http://www.cplusplus.com/reference/clibrar...dio/printf.html
Guardi gli esempi e capisci subito.

Per questo dico che secondo me ci vanno. Molto probabilmente quella stringa viene data in pasto all'eseguibile così com'è e tramite funzioni di questo tipo poi si decide che valore sostituire a quei marcatori. Probabilmente si tratta di testo non costante che può variare nel gioco (io non ne ho idea visto che non l'ho mai giocato... anzi, non ho la più pallida idea di che gioco sia. Ho capito solamente che è un'avventura testuale), nel caso in cui il giocatore possa ad esempio scrivere il nome del proprio personaggio... oppure nelle frasi che si riferiscono a certi oggetti che il personaggio tiene nell'inventario e devono tenere conto se il giocatore ne possiede più di uno per coniugare la frase al singolare o plurale.... etc etc... I casi possono essere tanti.
Cmq ci tengo a sottolineare che a mio avviso è un po' improponibile tradurre un'avventura testuale inglese in questo modo proprio perchè, come qualcuno ha già fatto notare, il parser ragionerà in inglese su frasi in italiano e perciò secondo me ne verrà una schifezza. Già temo per tutte le coniugazioni dei verbi fatte ad cazzum e gli articoli completamente sballati.
Forse converrebbe di più rifare il gioco, con un linguaggio come Inform o simili (che ha già le librerie per avere un parser in italiano). Strada che hanno adottato molti per tradurre vecchi giochi col progetto "From Hell". Magari chiedete a RGrassi per queste cose, che lui ne capisce più di me.

Ad ogni modo come funziona il decompressore più o meno l'ho capito. Non ho avuto molto tempo invece per farmi un'idea precisa di come sono organizzate le informazioni correttamente dentro il file.
Da notare che non si tratta di una codifica Huffman "classica" in quanto il compressore si crea, inoltre, anche un dizionario con alcuni vocaboli che, in virtù di questo, possono essere letti in chiaro a partire dell'offset 0x412E del file SHANSTR.DAT
In questo caso invece di risalire tramite i bit alla singola lettera, si arriva direttamente a tutta la parola. Ora non so in base a cosa siano state scelte queste parole per entrare nel dizionario. Probabilmente in base alla loro frequenza. In questo caso si avrebbe probabilmente un tot di parole scelte per essere inserite nel dizionario. Per questo farebbe comodo un confronto con un altro file, in modo da determinare se questo numero è fisso o variabile (ad esempio potrebbe essere "metti nel dizionario tutte le parole con frequenza >= X).
L'unica cosa che finora sembra chiara è che, per calcolare la frequenza di queste parole, vengano considerate come parole le stringhe separate da spazi (pare solo da spazi a vedere il file... non ci sono parole nel dizionario che terminano con simboli diversi da spazi o lettere). Cioè, nel caso ci siano 2 frasi così:

CODICE

I am tall
I am young

le frequenze calcolate dovrebbero essere:

CODICE

"I "=2
"am "=2
"tall"=1
"young"=1

e non ad esempio "I am "=2
Inoltre beh... dettagli tecnici... i nodi sono identificati da due byte (short) [b1][b2]:
Nodo interno: bit più significativo = 1
Nodo foglia: bit più significativo = 0 (quindi vengono ribaltati tutti i bit, facendo quello xor con 0xFFFF)
Se è una foglia inoltre si controlla se si tratta di un carattere "normale" o se si punta ad una parola del dizionario. In questo caso si guarda il singolo byte (quello meno significativo dei 2) e la regola è:
Carattere: bit più significativo = 0
Parola del dizionario: bit più significativo = 1
Questo è lecito in quanto la codifica adottata è l'ASCII a 7bit.
Nel caso si abbia a che fare con una parola del dizionario, questo byte non rappresenta un carattere, ma bensì un indice (che viene perciò normalizzato, riportando a 0 il bit più significativo) che viene utilizzato per navigare tra il vettore di parole del dizionario.

PS: Ah... ho notato adesso che le parole contenute nel dizionario sono per l'appunto 128 (0-127)... questo fa intuire che la strada giusta sia l'ipotesi per la quale vengano scelte le 128 parole più frequenti

[Alpobemp]

ho visto delle cose tipo <%s%sn't think%s [...]> .

Probabilmente questa frase va bene così, non mancano cose che il decompressore non ha estratto. In C esistono diverse funzioni che sfruttano queste cose. La più classica ad esempio è la printf (per stampare a video) che fa uso di questi marcatori per inserire il contenuto di variabili nel testo da mostrare.

Guarda, questo è pacifico, tant'è vero che io stesso parlavo già di "variabili", nel senso che cose di questo genere sono comunissime nei parser delle avventure testuali (nell'AGI e anche nello SCI della Sierra) ; la mia paura e le mie perplessità erano esattamente quelle che esprimi tu, ma potrebbero esserci delle scappatoie possibili, provando a "piegare" le traduzioni verso espressioni più generalistiche, magari omettendo l'uso delle variabili nelle frasi tradotte, ove fosse possibile. Il problema è vedere se ciò non possa mandare in abend il motore del gioco, ma a questo punto ritorniamo da capo a dodici, nel senso che per fare questo esperiemento dobbiamo essere in grado di potere reinserire le frasi tradotte nei file di gioco e per far ciò ci serve un compressore compatibile.

Comunque per una settimana circa non potrò frequentare, dunque ... buon lavoro!

Ciao,
Alberto

Messaggio modificato da Alpobemp il 11 Mar 2009, 23:04