Table of Contents
- Documenti scritti ma non ancora indicizzati
- Tipizzazione delle schiere dei programmi
- Come fare pulizia
- Alcune considerazioni su come scrivere le costanti
- Multilingua in LoocUp
- Testi presenti nel client Looc.up
- Testi presenti negli SCRIPT
- Testi presenti nei servizi
- Come capire le lingue usando LOOC.up
- Come tradurre le parti testuali di un'applicazione
- Versione originale del documento
- Strumenti per analizzare lo stato di avanzamento sulla traduzione di Sme.Up
- Statistiche traduzioni
- Analisi utilizzi
- Utility del programma A£02
- Strumenti per tradurre facilmente Sme.Up
- Come ottenere un aiuto nella traduzione degli oggetti Sme.Up
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.
eliminare le frasi visualizzate con opzione '4'
- Spostare le frasi SENZA ALCUN UTILIZZO ma TRADOTTE, nel cestino delle frasi.
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.
(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
Descrizione..........
Stato................
L(PUN)
- GESTIONE ARTICOLI ** )
- GESTIONE ARTICOLI ** )
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.
- Include notes to translators in your information for correct word use to prevent any misunderstandings.
- Avoid abbreviations.
- Avoid slang, jargon, and humor.
- Avoid negative questions.
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
- 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
- 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
- NUT Non utilizzate e non tradotte permette di eliminare dal lavoro di traduzione tutte le frasi che non vengono più utilizzate
- 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")
- COS Permette di scandagliare i nuovi programmi,file schede etc al fine di aggiornare i file che gestiscono le traduzioni
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).