%%(display:none)
{{{
WikiUp
}}}
/%
[{TableOfContents }]\\
!!! Contenuti tecnici\\
!! Correzione errori\\

! Azioni su sorgenti\\

In prima battuta è possibile verificare l'impostazione corretta dei sorgenti sfruttando le utility previste per il trattamento dei sorgenti. Per fare questo dal menù A£ standard lanciare l'azione "Trattamento Sorgenti" (B£UT10) impostare File/Libreria ed eventualmente Membri/Tipi membri interessati, premere F17 per passare alla schermata "Altre funzioni" e lanciare le funzioni presenti su "Elaborazione costanti".

! Analisi errori-anomalie\\
E' possibile verificare le possibili anomalie legate alle traduzioni utilizzando un'utility __A£UT72__ . Tale utility è raggiungibile tramite  il menù delle lingue GO-A£02- voce utility funzione-metodo PGM-CRE:
- indicando l'applicazione (per es. C5) e la libreria (per es. SMEDEV) si ottiene una stampa con tutte le possibili anomalie.

Per verificare l'anomalia in un __singolo sorgente__ si usa l'utility __"e nomeprogramma"__ ( Per esempio __"e B£SER_06"__) e una volta entrati si richiama l'opzione __12__ che mostra le schiere ed eventuali stringhe che al momento non sono traducibili.

Per verificare tale utility è presente un esempio in __SMEDEV-A£SRC- A£UT72_ES __che permette di analizzare come devono essere gestite le stringhe.


! Estrazione specifiche di Output - O - in schiere\\
Per la corretta estrazione delle specifiche "O" sarebbe buona norma portare tutto ciò che viene "stampato" in fondo nelle schiere. Purtroppo in molti programmi questo non è stato fatto. Per fare in modo di allineare anche tali programmi e permetterne la traduzione corretta è possibile utilizzare un utility specifica chiamata __A£UT72__ e raggiungibile anche tramite il menù delle lingue GO-A£02- voce utility funzione-metodo PGM-CRE.
Di seguito elenchiamo i possibili passaggi per una corretta esecuzione:
# GO - A£02 - voce __utility__ -  funzione-metodo __PGM-CRE__\\
# Tale utility genera nella libreria __SMEUP_RPL__-file __A__ le parti  da sostituire nel nuovo sorgente.\\
# Andando nel file generato in SMEUP_RPL prendere le righe elencate e sostituirle nel file originale contenetente le specifiche 'O'\\
# Verificare con una compilazione che le modifiche effuate siano corrette\\
# Estrarre le costanti con il  programma A£LINB (da menù GO-A£02-voce 02 Estrazione costanti)\\
# Entrare nel programma di gestione delle lingue in LoocUp (par. ) o in emulazione  tramite il programma __"e"__ (si veda il paragrafo precedente), cercare le nuove stringhe generate e tradurle\\
# Entrare in un ambiente/utente in lingua e verificare la corretta traduzione\\

Per verificare tale utility è presente un esempio in __SMEDEV-A£SRC- A£UT72_ES__ che permette di analizzare come devono essere gestite le stringhe.


!! Istruzioni operative per il programmatore\\
In questa sezione cercheremo di indicare alcuni comportamenti attraverso i quali un programmatore possa collaborare affinchè le traduzioni dell'applicativo Sme.Up mantengano sempre un buon livello. Le indicazioni sottostanti, inoltre, sono da considerarsi come schema per un miglioramento generale della qualità linguistica ed espressiva di Sme.Up.
Sommario della sezione:
- Regole di buona scrittura delle frasi in italiano\\
- Come tradurre le parti testuali di un'applicazione\\
- Regole per l'individuazione delle costanti\\
- Caratteri speciali (** % spazi bianchi ecc)\\
- Tipizzazione delle schiere dei programmi\\
- Traduzione del programma creato tramite LoocUp o tramite le Utility 5250.\\
\\

! Regole di buona scrittura delle frasi in italiano\\

**********\\

! Come tradurre le parti testuali di un'applicazione\\
'' (Questo documento è un breve estratto della documentazione presente presso il link http://publib.boulder.ibm.com/infocenter/iseries/v5R3)''

Le informazioni qui presenti forniscono alcuni suggerimenti di carattere generale che possano essere di aiuto nella traduzione successiva in lingue differenti da quelle di partenza


''Isolate le informazioni testuali e i messaggi dal codice sorgente dell'applicazione ''
	
Per permettere una traduzione in modo semplice e per evitare di tradurre il codice sorgente è buona norma separare le informazioni testuali da quelle che invece servono solamente all'esecuzione del programma. E' necessario prestare attenzione nei vari punti dove vengono usate informazioni testuali.

''Prevedere uno spazio extra di espansione''

Lo spazio necessario per scrivere una frase o una parola in diverse lingue varia a seconda della struttura delle proposizioni e delle parole presenti nella lingua in cui viene tradotto il testo. Per essere sicuri di aver tradotto senza alterare contenuti e fruibilità è necessario mantenere uno spazio extra per un'eventuale espansione delle informazioni contenute. La tabella seguente consiglia la quantità di spazio aggiuntivo nel caso sia stata usata la lingua inglese-americana per creare l'interfaccia utente dell'applicazione:


||__Numero di caratteri nel testo __||__Spazio addizionale richiesto__
|fino a 10  |  da 100 a 200%\\
|da 11 a 20  |  da 80 a 100%\\
|da 21 a 30  |  da 60 a 80%\\
|da 31 a 50  |  da 40 a 60%\\
|da 51 a 70  |  da 31 a 40%\\
\\

'' Posizione delle variabili di un oggetto sullo schermo ''


Poichè la posizione di un elemento sullo schermo spesso è influenzata dalla posizione e dalla dimensione di altri elementi vicini,  bisognerrebbe ricollocare alcuni di essi nel momento in cui vengono tradotti. Il programma deve essere abbastanza flessibile da non essere influenzato dalla ridisposizione dell'oggetto.

''Mantenere un ordine delle variabili relativamente alla struttura sintattica''

Affinchè sia possibile mantenere informazioni dinamiche i messaggi sfruttano la possibilità di usare variabili sostituibili a runtime. Nonostante questo ogni lingua ha la sua sintassi, la sua modalità di costruire proposizioni. Quando un messaggio deve essere tradotto in un'altra lingua la posizione delle variabili dovrebbe seguire anche la differente struttura sintattica della frase.


'' Aggregazione di dati testuali provenienti da più parti''

Se la forma finale di un testo costante dipende dalla composizione di varie parti, questo potrebbe essere non traducibile. Questo avviene perchè non è sempre facile sapere quale forma usare nella traduzione oppure nel caso in cui uno stesso concetto richieda un insieme di strutture verbali e sintattiche differenti.
Per esempio, se per caso vengono stabilite le intestazioni delle colonne per definire più parti di una parola, in seguito non sempre è possibile portare questa parametrizzazione in altre lingue. Facciamo un esempio pratico: nel caso dei giorni della settimana è possibile separare un prefisso e un suffisso. Vediamo il caso della lingua francese per i giorni da lunedì a venerdì:

||__Prima parte del nome del giorno:__||__Combinata con: __||__Risultato:__
|LUN          		  |        DI                   | LUNDI\\
|MAR                                              |        DI                   | MARDI\\
|MERCRE                          	  |        DI                   | MERCREDI\\
|JEU                           		  |        DI	               | JEUDI\\
|VENDRE                        	  |        DI	               | VENDREDI\\
\\

Quando pero' si va atradurre l'applicazione dal Francese al Tedesco, non è possibile combinare le 2 parti per creare il nome del giorno perchè i giorni in tedesco sono:
__MONTAG__, __DIENSTAG__, __MITTWOCH__, __DONNERSTAG__, and __FREITAG__.


''Come comportarsi con comandi, risposte e parole chiave contenenti dati di tipo testuale''

I comandi, le risposte e le parole chiave usati devono essere tradotti nella lingua normalmente parlata dagli utenti.

''Esprimere tutti i testi nel modo più semplice e chiaro possibile.''
# Usare frasi e periodi semplici ed evitare di comporre frasi in modo complesso. L'uso di parole semplici facilita la traduzione.\\
# Mantenere l'uso dei termini coerente attraverso tutto il prodotto. Se la terminologia usata non è coerente lungo tutto il prodotto, coloro che traducono perdono ogni volta tempo ad adattare il linguaggio al diverso contesto che si presenta\\
# includere alcune note su come tradurre per i traduttori del prodotto per prevenire  incomprensioni\\
# evitare dove possibile le abbreviazioni. Le regole adottate nelle abbreviazioni variano da un linguaggio ad un altro. Le abbreviazioni possono portare ad incomprensioni sia a coloro che traducono che agli utenti del prodotto finale\\
# evitare frasi gergali, tipiche di una data regione o provincia o correlati a forme di umorismo. Queste forme sono specifiche di un linguaggio particolare e molto spesso sono difficili da tradurre in lingue differenti\\
# evitare domande in forma negativa. Le domande in forma negativa traggono in confusione l'utente poco attento. Quando si pone una domanda è sempre meglio porla in forma positiva\\

! considerazioni su come scrivere le costanti\\

Il programmatore (in particolare chi scrive programmi standard) deve prestare molta attenzione
a come scrive le __costanti__. Questo perché, aggiungere costanti nuove (non usate in altri
programmi o DSPF o PRTF) significa, poi, un corrispondente lavoro di traduzione nelle varie lingue.
Per limitare il proliferare di queste frasi occorre stabilire degli standard, delle direttive di
sviluppo a cui TUTTI devono attenersi.
Per quanto riguarda le costanti in schiere di programmi esiste un utile tool richiamabile
con il comando AT (analisi traduzioni) sulla sorgente stessa. Questo tool analizza le
costanti nella sorgente e segnala quali sono nuove, quali sono simili ad altre costanti (magari
differenti solo per maiuscolo/minuscolo), e quali sono costanti già usate in altri oggetti
di Smeup. _h_Si consiglia, ove possibile, di utilizzare le costanti già "conosciute" e ridurre
al minimo il numero di frasi nuove.

In ogni caso è buona norma attenersi a queste direttive (valide anche per la scrittura
delle costanti nei DSPF e PRTF ):
# Scrivere la frase senza caratteri speciali (es. "&|*@ç°#.? ....ecc...)\\
# Allineare sempre la frase a sinistra\\
# Evitare effetti puramente estetici quali l'allineamento con i punti, i doppi asterischi\\
nei titoli ecc...  (es.      Articolo.............\\
Descrizione..........\\
Stato................\\
L(PUN)\\
## GESTIONE ARTICOLI ** )\\
L'ultima costante deve essere costruita concatenando (EVAL o CAT ...) la costante con gli ** .
- Scrivere tutta la frase in minuscolo, con eccezione del primo carattere.
- Evitare di scrivere le intestazioni (es della __£G18__) su un'unica riga, ma suddividerla in __N__ parole.
Non sono accettabili frasi del tipo:
Codice         Descrizione          Stato Livello     UM     Peso

! Caratteri speciali (** % spazi bianchi ecc)\\

*********\\

! Tipizzazione delle schiere dei programmi\\

_h_La traduzione delle schiere nei programmi avviene dinamicamente quando il programma viene eseguito. La sostituzione vera e propria della costante con la sua traduzione avviene con la chiamata della /copy £LIN, tipicamente nella £INIZI di ogni programma.

NB Vengono tradotte solamente le costanti presenti in schiera._n_

Nello standard di programmazione Smeup esistono diverse tipologie di schiere che per loro natura devono essere tradotte in modo differente. Si prenda ad esempio la seguente schiera ( £11A) che viene utilizzata nella /COPY £G11:

||__Descrizione__			||__TpParametro__  	||__ Lung.DOVAuD__
|Articolo			| ARART		|	15\\
|Cliente			| CNCLI    	|  	15\\
|Visualizza configurazione  	| V2SI/NO 	|	1\\
\\

ovviamente non deve essere tradotta per intero, ma solamente la prima parte (i primi 30 caratteri).
Per fare questo è necessario "tipizzare" la schiera, ossia descriverne il tipo, in fase di dichiarazione della schiera stessa. Per tipizzarla, sulla specifica di dichiarazione della schiera oltre al nome e alla dimensione, diremo che è una schiera di tipo £11A (che finirà cioè nella schiera £11A della /copy £G11), in questo modo:

||D||X11A||S||	70||DIM(10)||CTDATA  PERRCD(1)||_£G11_A
\\


Il tipo schiera (nell'es. _£G11_A) viene scritto nel campo "comments" della sorgente RPGLE preceduto
dal carattere di underscore. Tutti i tipi schiera disponibili in Smeup sono oggetti __V2__ di tipo
__A£TSK__, consultabili tramite l'interfaccia £DEC.

Nello standard di programmazione Smeup la tipizzazione delle schiere è un passo obbligatorio, se
anche una sola schiera non è tipizzata il programma non si compila (con l'opzione CO).

***********\\

!! Utility di manutenzione\\

In questa sezione vengono descritte delle utiliy per la corretta manutenzione del modulo Multilingua in Sme.up.
Sommario della sezione:
- Statistiche traduzioni\\
- Analisi utilizzi\\
- Utility del programma A£02\\
- Come fare pulizia\\
******\\

! Statistiche traduzioni\\

Ad oggi sono disponibili vari tool che permettono di avere un' analisi dettagliata dello stato di traduzione dell'applicativo.
In Looc.Up partendo dalla __scheda del multilingua__ (''A£LING'') il tab __Statistiche__ permette di avere molte informazioni sullo stato delle traduzioni. Questo deve essere uno dei punti di partenza per capire dove è più necessario intervenire nella traduzione del programma.
In particolare il tab fornisce le seguenti tipologie di informazioni:

#  Dei diagrammi  a barra per vedere graficamente le statistiche\\
#  Alcuni diagrammi di riepilogo da cui è possibile trarre alcune considerazioni di carattere generale\\
#  il tag __Avanzamento per lingua__ (molto importante) che permette di vedere nel dettaglio come le singole frasi/parole sono già tradotte nelle varie lingue\\
#  Un'analisi delle statistiche sugli __utilizzi__ delle frasi partendo dall'iniziale o analizzando le parole/frasi non tradotte o ragionando in termini generali. Queste informazioni sono raggiungibili sempre nel tag __Avanzamento per lingua-Totale generali__\\
******\\
! Analisi utilizzi\\

Un ulteriore strumento a disposizione per avere sott'occhio tutte le traduzioni effettuate relativamente ad ogni singlo oggetto di Sme.Up è disponibile tramite il tab __Analisi utilizzi__. In questo tab per ogni applicazione è possibile vedere per ogni tipologia di oggetto (tra cui OJ*DSPF, OJ*MSGF, OG*PGM, REF-, RET-, ST)  l'analisi degli utilizzi delle parole e delle frasi.
******\\
! Utility del programma A£02\\

Infine un tool più complesso che fornisce una serie di strumenti per effettuare un'analisi è fornito dal programma AS400 __A£02__. (Chiamato tramite  __go A£02__ )
Questo programma oltre a fornire uno strumento per tradurre le frasi (aspetto che verrà trattato di seguito nel paragrafo in __Strumenti per tradurre facilmente Sme.Up__), fornisce alcune __utility__ . Per accedere alle utility è necessario selezionare l'opzione __04__ del programma.
* TRA funzione sul file delle frasi tradotte (solo frasi)\\
** 1 - N  e N - 1 (una origine - n traduzioni o n origini -una traduzione) : per vedere se ci sono delle frasi che hanno relazioni 1 a molti o molti a uno con le corrispettive traduzioni). Queste informazioni mi possono servire per uniformare dove possibile le traduzioni\\
**  __TRA.ERR__(errore nel database delle traduzioni) :per vedere se ci sono delle frasi che si riferiscono  a oggetti non più esistenti\\
** __TRA.ALL __: funzione che permette di visualizzare tutti i risultati delle funzioni sopra citate\\
** NMI Normalizza minuscolo dopo il primo carattere\\
** UGU Non tradotte UGUALI a già tradotte\\
** T_D Tradurrebbe in modo diverso\\
** NOR Stampa controllo normalizzazioni\\
* FRA fuzione sul file delle frasi in lingua\\
** NUT Non utilizzate e non tradotte permette di eliminare dal lavoro di traduzione tutte le frasi che non vengono più utilizzate\\
** TNU Già tradotte ma non più utilizzate: potrebbe essere utile mantenere quanto tradotto in passato in modo da non perdere il lavoro fatto\\
** TNUELI Ritorna quelle frasi tradotte, non utilizzate ma che possono essere eliminate perchè presentano delle somiglianze con quanto già tradotto in altri punti\\
** SIM è una funzione che permette di identificare delle somiglianze di frasi non tradotte con quanto già tradotto in precedenza\\
** ABB andando a vedere la tabella A£A ottengo informazioni su abbreviazioni considerate non conformi agli standard\\
** BLN  fuzione che permette di idenntificare le frasi con troppo spazi bianchi\\
** CAR Con caratteri speciali\\
** EUO Elimina utilizzi oggetto\\
** USO Utilizzi senza oggetto\\
* PAR lavoro sulle singole parole (__Sezione di utility importanti__)\\
** COS Permette di scandagliare i nuovi programmi,file schede etc  al fine di aggiornare i file che gestiscono le traduzioni\\
** ACR Stampa in un file di spool tutti gli acronimi derivati da alcune radici ( per esempio da "ALF" a    "alf.,alfab")\\
** COM Completamento attributi parole\\
* SRC Funzioni sui sorgenti\\
** SOS Parole da sostituire (solo stampa)\\
* CES (Funzioni sul cestino)\\
** GES Gestione delle frasi cestinate\\
** RIP Ripristina traduzioni dal cestino\\
* BLD (Build)\\
** SYS SYSTRAN Dictionary\\
** T-M Import  per TRADOS / Multiterm\\
** T-W Import per TRADOS / WorkBench\\
* PRO Funzioni sulle proposte\\
** APPEND Invia proposte al laboratorio\\
** PUT Invio al laboratorio (file provvisorio)\\
** GET Ripresa da ambiente esterno (file provvisorio)\\
* PGM Analisi dei programmi con anomalie\\
** ALL Tutti i tipi di anomalia\\
** CRE Crea membro di lavoro\\
** CRT Crea tutti i membri di lavoro\\
******\\

! Strumenti per tradurre facilmente Sme.Up\\
La traduzione di Sme.Up presenta due aspetti principali:
# suddivisione del lavoro di traduzione tra diversi operatori.\\
# quali sono i punti da cui è possibile partire nella traduzione\\

! Come ottenere un aiuto nella traduzione degli oggetti Sme.Up\\

La versione in lingua di Smeup si ottiene generando gli oggetti che lo compongono nell'opportuna lingua di destinazione.

Per gli oggetti quali display file (*DSPF) e printer file (*PRTF) il procedimento di generazione dell'oggetto in lingua consiste nel riscrivere il sorgente sostituendo le costanti in italiano con le corrispondenti traduzioni. Questi oggetti "in lingua" vengono poi __compilati__ e messi nella libreria __SMELIN_xx__ dove xx è il prefisso della lingua di destinazione (__tabella V§L__).

Questa operazione può essere eseguita __manualmente__ (es. nel caso di particolari pgm personalizzati dal cliente) __o__ essere __automatizzata__ mediante il __ tool di estrazione e generazione automatica__ dell'oggetto in lingua (vedere la documentazione apposita).
Oltre ai DSPF e PRTF bisogna tradurre __anche__ tutte le __costanti__ presenti nei sorgenti dei programmi.

Questa traduzione avviene in __automatico__, in fase di esecuzione del pgm stesso, __se__ è __impostata__ una __lingua__ in __tabella B£2 __(campo ££B£2I). Vengono tradotte tutte e sole le costanti presenti nelle schiere a tempo di compilazione (CTDATA, per capirsi), quindi, quando si scrivono dei programmi, è __NECESSARIO mettere in schiera le costanti__ che devono essere tradotte.

Per una corretta traduzione di queste costanti occorre __tipizzare__ opportunamente tali schiere (leggere la documentazione relativa alla tipizzazione delle schiere nei programmi).

******\\

! Come fare pulizia\\

Di tanto in tanto è bene fare un po' di pulizia negli archivi interessati dalla gestione del
multilingua.
Esistono delle utility che guidano l'utente in una pulizia "mirata".

Come si accede alle utility:
Dal menu del multilingua, tramite opzione__ '4'__.

''Manutenzioni consigliate:''

# Eliminare DEFINITIVAMENTE tutte le frasi SENZA ALCUN UTILIZZO e NON TRADOTTE in nessuna lingua.\\
Impostare funzione=FRA metodo=NUT, non impostare nessuna parzializzazione, premere F06,\\
eliminare le frasi visualizzate con opzione '4'\\
# Spostare le frasi SENZA ALCUN UTILIZZO ma TRADOTTE, nel cestino delle frasi.\\
Queste frasi, anche se non più usate, rappresentano un patrimonio in quanto qualcuno le ha già\\
tradotte in qualche lingua. Spostarle nel cestino permette di poterle ripristinare in qualsiasi\\
momento, qualora si ripresenti la stessa frase da tradurre.\\
Impostare funzione=FRA metodo=TNU, non impostare nessuna parzializzazione, premere F06,\\
e cestinarle con opzione 'S'.\\
# E' possibile avere nell'archivio delle costanti la stessa frase ma con lunghezze diverse.\\
Impostando funzione=TRA metodo=UGU verrano mostrate tutte le frasi non tradotte che sono uguali\\
(tranne che per la lunghezza) a frasi già tradotte. Con l'opzione 'IT' si inserisce automaticamente\\
la traduzione.\\
''Il cestino''

Impostando Funzione=CES e Metodo= RIP un apposito programma leggerà tutte le frasi cestinate e
verificherà quali traduzioni possono essere importate negli archivi delle lingue.
Queste frasi vengono presentate all'utente che le può importare usando l'apposita
opzione di ripristino (RI).
Con Funzione=CES e Metodo= GEF si accede alla manutenzione di tutte le frasi cestinate, in
particolare è possibile eliminarle definitivamente o importare le traduzioni negli archivi
delle lingue.


N.B. _i_L'importazione delle traduzioni è consentita solo se esiste la corrispondente frase in italiano
non tradotta negli archivi delle lingue._n_

!! Rilascio nuova versione in presenza di traduzioni personalizzate\\
Nel caso siano presenti delle traduzioni personalizzate (derivanti da correzioni di traduzioni standard o traduzioni aggiunte), ci sono dei piccoli problemi da affrontare in caso di rilascio. Nel seguente documento sono analizzate tali problematiche e le possibili soluzioni:

!!! Contenuti tecnici\\
Nel caso siano presenti delle traduzioni personalizzate (derivanti da correzioni di traduzioni standard o traduzioni aggiunte), ci sono dei piccoli problemi da affrontare in caso di rilascio.
Vediamo nello specifico queli sono tali problematiche e queli sono le possibili soluzioni:

!! Meccanismo semplificato di traduzione\\

A£LINT0F contiene le traduzioni
A£LIND0F le frasi in italiano

La frase in italiano e quella in lingua sono "collegate" da una chiave (AT£KEY nell'A£LINT0F e AD£KEY nell'A£LIND0F). Es:
A£LIND0F:
||001||lavoro
|002|cane\\
\\
A£LINT0F:
||001||EN||work
|002|EN|dog\\
|001|ES|trabajo\\
|002|ES|perro\\
\\

Tutte le notti, in laboratorio vengono aggiunti record all'A£LIND0F con le nuove parole/frasi estratte.

Una volta a settimana (e comunque al rilascio o su richiesta manuale) viene fatta pulizia in questi file (sopratutto per cancellare frasi inutilizzate e non tradotte).
Tra un rilascio (anche all'interno della stessa release) non è quindi detto che le chiavi rimangano fisse. Quindi i nuovi file al rilascio potrebbero avere:
A£LIND0F:
||001||automobile
|005|lavoro\\
|008|cane\\
\\
A£LINT0F:
||001||EN||car
|005|EN|work\\
|008|EN|dog\\
|001|ES|coche\\
|005|ES|trabajo\\
|008|ES|perro\\
\\

!! possibili problemi\\
Quindi normalmente al rilascio di una nuova SMEDEV (anche all'interno della stessa release) si sostiutiscono anche gli A£LINT0F e A£LIND0F e non c'è nessun problema.
Il problema nasce se vengono fatte delle traduzioni personaliizate presso il cliente. A questo punto non è più possibile sostituire i file perché si prederebbero le traduzioni personalizzate.

In pratica la situazione potrebbe essere:

A£LIND0F:
||001||lavoro
|002|cane\\
|100|cliente\\
\\
A£LINT0F:
||001||EN||job
|002|EN|dog\\
|001|ES|trabajo\\
|002|ES|perro\\
|100|EN|customer\\
\\

(è stata aggiunta la parola da tradurre "cliente", ad esempio estratta da un DSPF personalizzato e la relativa traduzione in inglese; inoltre è stata modificata la traduzione inglese di lavoro).

!! Possibile workaround (non definitivo)\\
! Fusione file vecchi e nuovi\\
E' quindi necessario scrivere un progrmma che "completi" i file (A£LINT0F e A£LIND0F) installati presso il cliente.
Il programma deve leggere il nuovo A£LIND0F, controllare record per record se la frase/parola da tradurre è già presente nel vecchio. Se è già presente non fa niente (si da per scontato che le traduzioni presenti presso il cliente siano corrette) e passa al successivo. Altrimenti se c'è una nuova parola nel nuovo file deve creare una nuova chiave e aggiungere i relativi record ai file A£LINT0F e A£LIND0F "vecchi" (si copiano i record dai nuovi file nei nuovi sostituendo la chiave originale con quella appena creata).
Continuanado il nostro esempio, arriveremo alla situazione:

A£LIND0F:
||001||lavoro
|002|cane\\
|100|cliente\\
|X00|automobile\\
\\
A£LINT0F:
||001||EN||job
|002|EN|dog\\
|001|ES|trabajo\\
|002|ES|perro\\
|100|EN|customer\\
|X00|EN|car\\
|X00|ES|coche\\
\\

In questo modo si dovrebbero salvare traduzioni nuove, vecchie e personalizzate.

Per la creazione della nuova chiave, per essere sicuri di non andare ad interferire con una chiave esistente, consigliamo di comporla nel seguente modo: 'XX'+ un numeratore progressivo.

! qualche complicazione\\
A tutto quello detto fino ad ora si aggiungono alcune piccole complicazioni.
Una di queste è la presenza del file A£LINU0F (utilizzi, con campo AU£KEY come chiave).
Quando si trova una nuova traduzione nei nuovi file, oltre ad andare ad aggiungere un record nei file A£LINT0F e A£LIND0F vecchi (copiandoli a meno della chiave da quelli nuovi), è necessario copiare (sempre a meno della chiave) anche il corrispondente record del file A£LINU0F.
Altra complicazione è data dalla lunghezza delle parole da tradurre. Nel file A£LIND0F, oltre alla parola in italiano da tradurre, è memorizzata anche la sua lunghezza. Quindi quando si controlla la presenza di nuove parole nei nuovi file, è necessario tenere conto anche di questa informazione.
Ad esempio nel nuovo A£LIND0F potrebbe essere presente la parola "Lavoro" con lunghezze 6 e 10. Se nei vecchi file è presente solo "lavoro" con lunghezza 6, è necessari aggiungere il record relativo alla parola lavoro di lunghezza 10.


In questo modo sono stati creati dei file A£LINT0F, A£LIND0F e A£LINU0F come fusione dei vecchi con i nuovi.

! Ricreazione oggetti\\
A questo punto bisogna ricostruire la libreria con gli oggetti (display file, file messaggi ecc.) tradotti, perché la librerie con tali file in lingua deve essere allineata alla SMEDEV, altrimenti si incappa in vari errori (tipicamente errori di livello).
Per fare questo è necessario andare nel menù dell'applicazione A£, fino alla voce "Estrazione e generazione".
Si apre il programma A£LINB, che va eseguito con le funzioni/metodo GEN/MSG, GEN/DSP, GEN/PRT usando la modalità di selezione "2". Queste 3 "esecuzioni" vanno fatte per le librerie SMEDEV, SMESRC e tutte le personalizzate (che contengono sorgenti di pgm, dspf o prtf). Ovviamente per tutte le lingue di interesse.