Manuale cpp

[Maurizio Ulisse Dini]

Buongiorno a tutti e buon 25 aprile

nella documentazione OEF si cita un fantomatico manuale cpp. Dove lo trovo?

In effetti nella documentazione OEF la sintassi da usare per scrivere i file .cpp non è dichiarata se non sommariamente.

Nello specifico, al momento, non riesco a far funzionare l'istruzione condizionale #if.

Devo banalmente includere due file differenti a seconda della lingua ma non riesco a dichiarare la condizione.

lang=it è sempre falsa

lang==it invece è sempre vera

Grazie e buon weekend a tutti

Maurizio

[Gianluca Amato]

Ciao Maurizio,

CPP è l'abbreviazione di "C PreProcessor" che è uno dei componenti del linguaggio di programmazione "C". Ci sono molte guide online su CPP, ad esempio questa: https://beej.us/guide/bgc/html/split/the-c-preprocessor.html 

Il problema è che le guide fanno spesso riferimento anche al linguaggio C, mentre nel caso di WIMS solo i comandi del preprocessore, ovvero quelli che iniziano con #, hanno senso.

Nel tuo caso specifico, sei sicuro di dover/poter usare il preprocessore ? Perché OEF ha il comando \if che ti consente di controllare la lingua corrente.

--gianluca

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "CaffeWims" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a caffewims+...@googlegroups.com.
Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/caffewims/0c0245e9-c3b1-4648-a3a9-7a7e76d8c99dn%40googlegroups.com.

[Maurizio Ulisse Dini]

Ciao Gianluca! Grazie mille per la risposta.

Si, vero. Esiste il comando \if ma l'efficacia del suo utilizzo dipende dal significato che diamo al concetto di modulo multilingua.

I moduli multilingua, secondo me, dovrebbero essere composti da file che NON contengono i testi in tutte le lingue disponibili ma che al posto dei testi hanno variabili che fanno riferimento a vocaboli raccolti in file esterni.

Invece tutte le soluzioni per rendere multilingua i moduli wims che conosco adottano una soluzione scadente ovvero inseriscono i testi di tutte le lingue disponibili nel file oef o direttamente o in automatico tramite un .cpp

Il dato di fatto è che un esercizio dichiarato multilingua contiene cose così:

\if{\lang==it}{\text{saluti=buongiorno}

\if{\lang==en}{\text{saluti=goodmorning}

\if{\lang==fr}{\text{saluti=bonjour}

\if{\lang==es}{\text{saluti=buenas dias}

Le versioni più sofisticate che ho visto hanno un file da includere per ogni lingua. Ma comunque li includono tutti!

Ecco perché mi chiedevo come usare #if

Speravo fosse possibile leggere la variabile $lang a livello di preprocessore in modo da poter includere nel .oef solo i testi nella lingua locale.

In realtà io finora avevo seguito una strada differente e avevo risolto il problema dell'internazionalizzazione direttamente da .oef leggendo i testi (nella lingua selezionata tramite un comando \if) da file esterni.

L'esempio di prima l'ho infatti risolto così:

\text{lang=slib(oef/env lang)}
\text{file_text=generic_text.\lang}
\text{texts=wims(record 1 of \file_text)}
\text{saluti=row(1,\texts)}

Peccato che wims non gradisca avere una variabile come titolo dell'esercizio e quindi la mia soluzione, seppur elegante, è efficace solo al 99% perché comunque il file .oef deve contenere una riga \title{} per ogni lingua disponibile...

Oltre a questa ragione, nei moduli ci sono un sacco di altri file, oltre agli oef, che richiedono traduzione.

Ad esempio" filedesc" che contiene le descrizioni dei file contenuti nel modulo che, di solito, sono disponibili solo nella lingua dell'autore

Oppure "introhook" che contiene le configurazioni dei parametri da passare agli esercizi oef

E questi non possono essere modificati se non a livello più alto...

[Maurizio Ulisse Dini]

Ahimè... la notte non ha portato successi. Anzi.

Ho scoperto che "filedesc" non può contenere istruzioni ma può contenere solo un mero elenco di descrizioni.

Quindi non si può mettere la lingua come opzione.

Credo serva un intervento dei programmatori di wims per contemplare la possibilità di scrivere una serie di filedesc (filedesc.fr , filedesc.it , filedesc.en , eccetera) dalla quale wims estragga in automatico quello individuato dalla localizzazione (sei in italia? leggi il filedesc con estensione .it).

Inoltre non sono riuscito in alcun modo a usare l'istruzione condizionale per selezionare la  lingua.

O meglio. L'istruzione condizionale #if funziona. E' che non ho trovato il modo (e non so se ci sia) di leggere la variabile di sistema in fase di preprocessing per poterla mettere come condizione...

[marina....@unimib.it]

Provo a rispondere a un po' di domande, riassumendo anche cose già
dette nella discussione

Le informazioni sui file ccp sono nella Documentazione OEF, "Funzioni
avanzate", "Fichiers source prétraités"

https://openwims.matapp.unimib.it/wims/wims.cgi?lang=it&+module=help%2Foefdoc&+cmd=new&+special_parm=oefadv&+subject=oefadv

Un manuale è contenuto nel corso aperto "Aide au développement de
ressources"

https://openwims.matapp.unimib.it/wims/wims.cgi?lang=it&+module=home&+user=anonymous%2C9001%2Canonymous

In particolare ci interessa la parte sui "Moduli multilanguage"

Sezione "Thème 5 Utilisation de Modtool", "DocAide Modules d'exercices
OEF", "Module multilangage". Allego la versione stampabile pdf di
questa parte.

Il motivo per cui si è scelta questa modalità e non una come quella
suggerita da Maurizio (che dal punto di vista di programmazione sembra
molto più efficente) è che in questo modo si produce un file oef
editabile dai docenti (si è quindi voluto mantenere il principio che
il docente possa copiare l'esercizio nel suo corso e eventualmente
modificarlo per adattarlo ai suoi studenti). Se si utilizzano comandi
come "record", etc. l'esercizio non è più copiabile nel corso.

Mi sono anche accorta di un ulteriore bug (o feature di sicurezza) di
WIMS: tutti i comandi che leggono file di dati (quindi record, etc)
non funzionano nelle versioni stampabili dei test di autovalutazione

Esempio

https://openwims.matapp.unimib.it/wims/wims.cgi?lang=it&+module=adm%2Fsheet&+job=read&+sh=it%2FE1%2F1301%2Fsheet17

se clicchi su "versione stampabile" vengono a mancare tutte le figure.

Si è parlato (ma mai realizzato, quindi si può pensare di riproporre
il problema) di generare invece di un unico oef con tutti gli if

\if{\lang==it}{\text{saluti=buongiorno}}
\if{\lang==en}{\text{saluti=goodmorning}}
\if{\lang==fr}{\text{saluti=bonjour}}
\if{\lang==es}{\text{saluti=buenas dias}}

tanti oef, uno per ogni lingua (in modo che, stando al principio
sopra, il docente del corso quando importa un esercizio nel suo corso
si trovi solo con la lingua che gli interessa). Va però progettata
bene la cosa (e quindi è bene parlare e discutere le casistiche) per
capire la realizzabilità tecnica. Credo comunque che l'organizzazione
del "cpp" come descritto nel file che ho allegato possa funzionare
come base da cui sviluppare il resto.

Per quel che riguarda lo stato delle traduzioni (su cui molto c'è da
fare), tieni presente che io considero 4 livelli di utenti

(1) studenti
(2) docenti
(3) sviluppatori
(4) gestori di sito

Per le pagine accessibili da (1) tutte le traduzioni devono essere
"perfette" (chiare e corrispondenti a quello che succede).

Per le pagine accessibili da (2) ci sto provando, ma ci sono ancora
alcune cose che ho scelto di lasciare in inglese (o in Francese quando
proprio non c'è niente da fare).

Per le pagine di (3) e (4), sorry, per ora non mi pongo il problema...

In questo senso il file "filedesc" compete (3), e quindi non mi
preoccupo che sia in una sola lingua, mentre considererei più
importante lavorare su "observation" che compete (2).

Quindi c'è da lavorare e si può metter su un bel gruppo di sviluppo.

Alcune risposte a domande sparse di Maurizio

- il passaggio da cpp a oef in fase di preprocessing avviene senza che
sia definita la lingua (quindi la variabile lang non è definita in
nessuna delle varianti che hai cercato di usare)

- il file intro.phtml e introhook.phtml si possono rendere
multilingue: guarda un esempio di modulo multilingue ad esempio
https://openwims.matapp.unimib.it/wims/wims.cgi?module=U1/arithmetic/modarith.en

Mi pare che queste siano le cose principali, fammi sapere se ho
dimenticato qualcosa

Marina

[Maurizio Dini]

dimenticavo:

>> Quindi c'è da lavorare e si può metter su un bel gruppo di sviluppo

Sono disponibile!

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "CaffeWims" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a caffewims+...@googlegroups.com.

Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/caffewims/27119.4214.406330.853373%40gargle.gargle.HOWL.

--
NOTA:
- dal 29 gennaio 2024 e fino a nuovo avviso sarò temporanemente
  trasferita nell'ufficio U5-3041
- dal 22 settembre 2025 e fino a nuovo avviso sarò temporaneamente
  trasferita nell'ufficio DB1-3005

Marina Cazzola (marina....@unimib.it)    Ph. +39 02 64485710

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "CaffeWims" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a caffewims+...@googlegroups.com.

Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/caffewims/27119.4214.406330.853373%40gargle.gargle.HOWL.

[Maurizio Dini]

Scusate avevo risposto solo a Marina e non al gruppo

---------- Forwarded message ---------
Da: Maurizio Dini <mauriz...@gmail.com>
Date: lun 27 apr 2026 alle ore 12:13
Subject: Re: [CaffeWims] Manuale cpp
To: <marina....@unimib.it>

Intanto ti ringrazio per il tempo che mi stai dedicando, avendoti subissata di dubbi e questioni.

Inizio a replicare sul discorso multilanguage.

Grazie per il manuale. L'avevo già letto e la scelta di infilare tutte le traduzioni dentro al file .oef finale continua a farmi storcere il naso perché ritengo ci possano essere soluzioni facili da realizzare e che non compromettono la spendibilità degli esercizi da parte dei docenti utilizzatori.

A tal proposito io vedo 5 e non 4 livelli di utenti perché secondo me i docenti vanno divisi in due categorie:

2a) docenti fruitori (non modtool)

2b) docenti modtool

La mia esperienza è che di docenti di scuola che hanno voglia e capacità di gestire un account modtool ne trovi sì e no uno per scuola.

Il più grande ostacolo che ho incontrato alla diffusione di wims nelle scuole per le quali ho lavorato è proprio la necessità di fornire ai docenti "la pappa pronta". O gli esercizi sono già pronti all'uso e spendibili subito o i docenti piuttosto non usano wims.

Quindi non vedo come rilevante il problema della non copiabilità di un esercizio nel corso. Tanto a nessun docente io conosca verrebbe mai in mente di metterci mano per personalizzarlo. Anzi, sono del parere che sia meglio i docenti non mettano proprio mano agli oef pena una quantità spropositata di richieste di assistenza per esercizi oef perfettamente funzionanti che, manipolati dai docenti fruitori, poi non funzionano più.

Aggiungo un mio parere personale ovvero che se un esercizio necessita di ulteriore personalizzazione da parte di un docente fruitore significa che non è stato programmato bene.

La necessità di trovare altre soluzioni alla internazionalizzazione, secondo me, acquista un rilievo ancora maggiore se pensiamo che per mantenere il dubbio vantaggio di consentire a un docente fruitore di importare e modificare un oef nel suo corso, dall'altro lato rinunciamo ad una grossa fetta di esercizi di elevata qualità: gli esercizi migliori che ho trovato fanno uso intensivo di file esterni o addirittura non sono nemmeno oef. Il docente fruitore li cerca col motore, personalizza le opzioni disponibili nel pannello di controllo del modulo e li inserisce in un test senza metterci mano!

La soluzione che scommetto sia facile da realizzare consiste nel passare la variabile language al precompilatore.

Il precompilatore da qualche parte nel codice deve essere chiamato (immagino col comando gcc visto che siamo in ambiente linux).

Basterebbe recuperare la stringa della lingua (quella che in wims è memorizzata come $lang, per intenderci) e passarla al precompilatore in fase di chiamata (ad esempio col comando gcc -DLANG=xx) in modo che poi possa essere utilizzata in un file lang.inc ad esempio con le istruzioni:

#if LANG==xx

# include lang_xx.inc

#elif

eccetera

#endif

Ho cercato sul server dove sia la chiamata al precompilatore (che avviene ad ogni salvataggio di un file .cpp) ma non l'ho trovata altrimenti avrei subito provato a modificarla... se hai suggerimenti su come trovarla...

[marina....@unimib.it]

On 27 April 2026 12:18, Maurizio Dini writes:
>> Intanto ti ringrazio per il tempo che mi stai dedicando, avendoti subissata di
>> dubbi e questioni.
>> Inizio a replicare sul discorso multilanguage.
>> Grazie per il manuale. L'avevo già letto e la scelta di infilare tutte le
>> traduzioni dentro al file .oef finale continua a farmi storcere il naso perché
>> ritengo ci possano essere soluzioni facili da realizzare e che non
>> compromettono la spendibilità degli esercizi da parte dei docenti
>> utilizzatori.
>> A tal proposito io vedo 5 e non 4 livelli di utenti perché secondo me i
>> docenti vanno divisi in due categorie:
>> 2a) docenti fruitori (non modtool)
>> 2b) docenti modtool

bisogna mettersi d'accordo sui termini.

per me il tuo (2b) è esattamente (3)

Quello che forse non ti è chiaro è che un docente può modificare il
file oef senza passare da modtool (ed è giusto che il docente medio,
mia categoria (2) non abbia un account modtool).

Questo a volte è anche per questioni minime (un esercizio che viene
pensato per il corso di laurea in matematica viene invece utilizzato
per scienze della formazione primaria).

>> [...]

>> La necessità di trovare altre soluzioni alla internazionalizzazione, secondo
>> me, acquista un rilievo ancora maggiore se pensiamo che per mantenere il
>> dubbio vantaggio di consentire a un docente fruitore di importare e modificare
>> un oef nel suo corso, dall'altro lato rinunciamo ad una grossa fetta di
>> esercizi di elevata qualità: gli esercizi migliori che ho trovato fanno uso
>> intensivo di file esterni o addirittura non sono nemmeno oef. Il docente
>> fruitore li cerca col motore, personalizza le opzioni disponibili nel pannello
>> di controllo del modulo e li inserisce in un test senza metterci mano!

questi esercizi esistono già e sono multilanguage (vedi ad esempio
https://openwims.matapp.unimib.it/wims/wims.cgi?module=H4/stat/stat-3.nl
). Il discorso che si faceva era per la traduzione di moduli oef.

>> La soluzione che scommetto sia facile da realizzare consiste nel passare la
>> variabile language al precompilatore.

Il precompilatore creai i file oef e quindi i file "veri" di wims (che
sono i def) a partire dai file cpp+inc. Questa operazione avviene
senza che la lingua sia impostata (perché questo avviene quando il
modulo viene creato, _non quando il modulo viene eseguito_ da un
utente che ha una lingua).

Quello che tu vuoi fare potrebbe essere da un file

esercizio.cpp creo esercizio_it.oef, esercizio_fr.oef,
esercizio_en.oef

Questo si può fare, ma ti crea tre esercizi diversi nello stesso
modulo (ok, si può modificare il modo con cui WIMS gestisce i diversi
file in un modulo, ma questo richiede una modifica sostanziale al
sistema come è ora concepito).

nel file esercizio.cpp

target=esercizio_it esercizio_fr

#if defined TARGET_esercizio_it
# define lang_it
#endif

#if defined TARGET_esercizio_fr
# define lang_fr
#endif

#if defined lang_it
# include "lang_it.inc"
#endif

#if defined lang_fr
# include "lang_fr.inc"
#endif

(non escluso che si possa utilizzare una sintassi diversa tipo define
lang=it, ma così come ho scritto dovrebbe funzionare).

Questo ti produce due esercizi diversi esercizio_it.oef e
esercizio_fr.oef con le due lingue separate

Non sono sicura che sia un grande guadagno

>> Il precompilatore da qualche parte nel codice deve essere chiamato (immagino
>> col comando gcc visto che siamo in ambiente linux).
>> Basterebbe recuperare la stringa della lingua (quella che in wims è
>> memorizzata come $lang, per intenderci) e passarla al precompilatore in fase
>> di chiamata (ad esempio col comando gcc -DLANG=xx) in modo che poi possa
>> essere utilizzata in un file lang.inc ad esempio con le istruzioni:
>> #if LANG==xx
>> # include lang_xx.inc
>> #elif
>> eccetera
>> #endif
>> Ho cercato sul server dove sia la chiamata al precompilatore (che avviene ad
>> ogni salvataggio di un file .cpp) ma non l'ho trovata altrimenti avrei subito
>> provato a modificarla... se hai suggerimenti su come trovarla...

--

[Maurizio Dini]

=================

Il precompilatore crea i i file oef e quindi i file "veri" di wims (che

sono i def) a partire dai file cpp+inc. Questa operazione avviene
senza che la lingua sia impostata (perché questo avviene quando il
modulo viene creato, _non quando il modulo viene eseguito_ da un

utente che ha una lingua).

=================

Sono uno sciocco a non averci pensato. Hai perfettamente ragione...

===========================

Questo ti produce due esercizi diversi esercizio_it.oef e
esercizio_fr.oef con le due lingue separate
Non sono sicura che sia un grande guadagno

=============================

Hai ragione anche qui.

Grazie per avermi pazientemente spiegato queste cose!

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "CaffeWims" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a caffewims+...@googlegroups.com.

Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/caffewims/27119.35257.133949.559996%40gargle.gargle.HOWL.