%%(display:none)
{{{
WikiUp
}}}
/%
[{TableOfContents }]\\
!!! Documenti scritti ma non ancora indicizzati\\
------------------------------------------------------------------------------------------
!! Tipizzazione delle schiere dei programmi\\
__TRASFERITO IN CONTENUTI TECNICI -> ISTRUZIONI OPERATIVE PROGRAMMATORE__

_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).

*********\\

!! Come fare pulizia\\
__TRASFERITO IN CONTENUTI TECNICI -> UTILITY MANUTENZIONE__
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_

--------------------------------------------------------------------------

!! Alcune considerazioni su come scrivere le costanti\\
__TRASFERITO IN CONTENUTI TECNICI -> ISTRUZIONI OPERATIVE PROGRAMMATORE__
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

-------------------------------------------------------------------
!! Multilingua in LoocUp\\
__TRASFERITO IN INTRODUZIONE -> COSA VIENE TRADOTTO IN SME.UP__
! Testi presenti nel client Looc.up\\
Al momento dell'avviamento di LOOC.up, insieme a tutti i parametri di setup, viene fornita una sezione contenente tutte le frasi utilizzate dal client. Tali frasi sono tutte e ed esclusivamente quelle contenute in un apposito membro del file di configurazione (SCP_CLO) di nome LANGUAGE.

Vedi Configurazioni di LOOC.up (OJ*FILE-SCP_CLO)\\
Vedi Traduzioni in lingua (MBSCP_CLO-LANGUAGE)\\

! Testi presenti negli SCRIPT\\
I programmi che elaborano gli SCRIPT trasformandoli in formato XML, conoscono le stringhe di testo. Se è attiva la gestione in lingua, tutte le costanti passano attraverso la funzione di traduzione nella lingua desiderata.

! Testi presenti nei servizi\\
Essendo i servizi dei particolari programmi, tutta la gestione delle costanti quali ad esempio le intestazioni delle colonne delle matrici, è quella dei normali programmi di SME.up a cui si rimanda.

! Come capire le lingue usando LOOC.up\\
La scheda del modulo A£LING contiene tutte le funzioni per analizzare il database delle frasi e delle traduzioni nelle varie lingue
Vedi Traduzioni (MBSCP_SCH-A£LING)\\

------------------------------------------------------------------------
!! Come tradurre le parti testuali di un'applicazione\\
__TRASFERITO IN CONTENUTI TECNICI -> ISTRUZIONI OPERATIVE PROGRAMMATORE__
'' (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\\

------- ---------- ------------ ------------------ --------- ------ ------------------ ------
!! Versione originale del documento\\

__This document is take out from online version at the address http://publib.boulder.ibm.com/infocenter/iseries/v5R3__

The following information provides some general tips to help simplify the translation of your textual material.

''Isolate textual data from running code''
	
To allow easier translation and to avoid translating the running code, you should separate all textual data from the running code. Only one set of running code is needed, but many translations of the textual data can be done.

''Provide expansion space''

The space needed to translate text from one language to another varies by language. To ensure that the translated version preserves the concept and keeps usability, allow sufficient presentation space for the textual data expansion. The following table shows recommended expansion space for user interfaces designed using U.S. English.

||__Number of characters in text __||__Additional space required__
|Up to 10  |  100 to 200%\\
|11 to 20  |  80 to 100%\\
|21 to 30  |  60 to 80%\\
|31 to 50  |  40 to 60%\\
|51 to 70  |  31 to 40%\\
\\

'' Variable placement of an object on the display''

Because the position of one display element often is influenced by the position and size of others, some of the elements on the translated version of a display may have to be relocated. The program must continue to respond properly, despite this relocation.

''Flexible order of variables''

In order to contain dynamic information, messages usually employ substitution variables. However, each spoken language has its own syntax (order of arrangement of parts of speech). When a message is translated into another language, the position and order of substitution variables may have to change to meet the syntax requirements in the translated language.

'' Complete textual data entities''

If the final form of the constant text relies on the composition of various parts, it may be untranslatable. This is because the translator might not know which form of the word to use or because there is no combination of parts that work for a different language.
For example, you should define column headings for display screens as complete entities. You should not combine words or parts of words to define column headings. Assume you are writing an application for scheduling jobs between Monday and Friday. You are creating your application in French. You decide to create column headings for reports and screen displays by combining the first part of the name of the day with the constant DI. Throughout the application, the column and report headings are assembled like this:

||__First Part of the Name of the Day:__||__ Combine With: __||__Result:__
|LUN          		  |        DI                   | LUNDI\\
|MAR                                              |        DI                   | MARDI\\
|MERCRE                          	  |        DI                   | MERCREDI\\
|JEU                           		  |        DI	               | JEUDI\\
|VENDRE                        	  |        DI	               | VENDREDI\\
\\

When you translate your application from French to German, you cannot combine two parts to create th
e names of the days: __MONTAG__, __DIENSTAG__, __MITTWOCH__, __DONNERSTAG__, and __FREITAG__.

''Treat commands, responses, and keywords like textual data''

Commands, responses, and keywords should be translated into the language normally spoken by the user. For example, an English application has been translated into German. If the response is still in English as Yes and No, the German users would feel unfamiliar and uncomfortable in using the program because the responses they are familiar with are Ja and Nein.

''Express all text as simply and clearly as possible''
# Use simple phrases and sentences and avoid compound phrases. Simple words allow easy translation.\\
# Make terminology consistent throughout the product.\\
If consistent terminology is not being adopted throughout the product, translators will waste time trying to determine the appropriate  word to be used in translation.\\
# Include notes to translators in your information for correct word use to prevent any misunderstandings.\\
# Avoid abbreviations.\\
Rules for abbreviations vary from language to language. Abbreviations of words can lead to misunderstandings by the translator and by the end user.\\
# Avoid slang, jargon, and humor.\\
Slang, jargon, and humor are specific for a particular language and cannot be easily translated into another language.\\
# Avoid negative questions.\\
Negative questions are often misunderstood by the user. When asking questions, ask them in a positive way.\\


-----------------------------------------------------------


!!! Strumenti per analizzare lo stato di avanzamento sulla traduzione di Sme.Up\\


------------------------------------------------------------------------
!! Statistiche traduzioni\\
__TRASFERITO IN CONTENUTI TECNICI -> UTILITY MANUTENZIONE__
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\\
__TRASFERITO IN CONTENUTI TECNICI -> UTILITY MANUTENZIONE__
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\\
__TRASFERITO IN CONTENUTI TECNICI -> UTILITY MANUTENZIONE__
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)\\
** __TRA / 1 - N  e TRA/ 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\\
* 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\\
** SMI è 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\\
* 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")\\

!!! Strumenti per tradurre facilmente Sme.Up\\
__TRASFERITO IN CONTENUTI TECNICI -> UTILITY MANUTENZIONE__
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\\
__TRASFERITO IN CONTENUTI TECNICI -> UTILITY MANUTENZIONE__
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).