Quando usi gettext o un framework simile, le stringhe di traduzione includono ':' (come "Label:" ) per generare etichette per l'interfaccia utente o devo aggiungere ':' nel codice UI stesso?
Il colon può essere considerato un simbolo di punteggiatura. È una convenzione che fa parte del testo, proprio come un punto o un punto interrogativo.
Non lasceremmo fuori il punto interrogativo da "Sei sicuro di voler uscire?" e quindi scrivere il codice per aggiungere gli attributi della domanda in modo dipendente dalla lingua alla stringa tradotta. Fare ciò significa che il codice UI sta assumendo inutilmente le responsabilità di saper punteggiare frasi in varie lingue: una responsabilità che può essere gestita nella sostituzione del messaggio.
C'è una possibilità intermedia. È probabile che, proprio come tutte le etichette abbiano la caratteristica del colon in inglese, anche in altre lingue le etichette abbiano in comune qualche elemento lessicale. Quell'elemento, se presente, è probabilmente una sorta di prefisso o suffisso, o entrambi.
Potresti rappresentare le etichette senza l'ornamento e quindi avere una stringa traducibile aggiuntiva che fornisce uno schema per aggiungere l'ornamento dell'etichetta. Ad esempio, supponiamo che la formattazione di stile C sprintf sia disponibile nell'applicazione UI. La versione inglese della stringa di formato di generazione dell'etichetta sarebbe "%s:" , e potrebbe essere anche l'impostazione predefinita, poiché funziona in alcune altre lingue. I traduttori dell'interfaccia utente possono sostituire questo "%s:" con qualsiasi cosa ritengano utile. Una delle possibilità è che possano sostituirlo con "%s" (non fare nulla) e quindi specificare la rappresentazione completa e adornata di ciascuna etichetta nella tabella delle stringhe tradotta. Quindi questo approccio gestisce anche alcune strane possibilità in cui il marker lessicale che denota un'etichetta deve essere inserito nel mezzo.
Questo approccio non sembra utile, se tutto ciò che si ottiene è una leggera compressione nella rappresentazione delle stringhe dell'etichetta: la rimozione di un carattere del colon. Se devi scrivere 100 caratteri di codice extra per questo, devi rimuovere i due punti da 100 etichette solo per pareggiare: e questo non prende nemmeno in considerazione la giustificazione del tempo trascorso.
Ci deve essere qualche guadagno per questo: vale a dire che l'applicazione usa le stringhe per scopi diversi dalla semplice generazione di etichette, come la generazione di frasi che si riferiscono ai campi dell'interfaccia utente per nome. Supponi che una finestra di dialogo abbia un'etichetta "User ID:" per l'immissione di testo. Se si dispone di una logica generica che produce il messaggio "È stato immesso un ID utente non valido". combinando un testo boilerplate con il nome di un elemento dell'interfaccia utente, è necessario disporre della stringa "ID utente" senza stringhe e passarlo attraverso una funzione di creazione di etichette per generare "User ID:".
Per molte lingue, non esiste traduzione uno-a-uno di parole e frasi inglesi, ma più traduzioni sensibili al contesto.
Per semplificare la vita dei traduttori, dovresti fornire il più possibile il contesto per le stringhe. Ciò include due punti nelle etichette e informazioni contestuali in cui vengono utilizzate tali etichette.
Come regole di base, in un'interfaccia utente internazionalizzata dovresti
Ho finalmente deciso di utilizzare intere stringhe (stringhe con i due punti in questo caso) nei miei file i18n.
Il motivo è che in francese dovrebbe esserci uno spazio prima dei due punti. Quindi il modo migliore per codificare il francese consiste nel mettere i due punti (con spazi precedenti) nelle stringhe di traduzione.
No, non traduciamo in francese. Ma questo è un esempio per una regola generale di comportamento: Metti i due punti nelle stringhe di traduzione, non nel codice UI.
L'approccio ottimale consiste nell'incorporare i caratteri nella stringa per ogni locale, in quanto ciò in genere garantisce che il contesto sia corretto, presupponendo che tu abbia svolto le tue ricerche su ciò che il pubblico di destinazione si aspetta.
Ogni paese fornisce in genere una guida di stile, che detta tutti i luoghi "corretti" per la punteggiatura. Quindi, quando ho iniziato a capire come gestire le citazioni per lingue diverse per alcuni strumenti di progettazione web, ho prima esaminato tali guide di stile.
Tuttavia, mentre le pubblicazioni scritte tendevano a seguire le guide di stile, il mondo online è molto diverso! In genere, un gran numero di siti non europei e sudamericani non inglesi usa le citazioni in stile USA, al contrario dei "guillemets" («») delle loro guide di stile. Mostra solo quanto il dominio degli Stati Uniti sulla prima rete permea l'uso della lingua online in tutto il mondo.
Il MIT Notizie e giornali in lingua straniera: Home ha collegamenti a centinaia di siti online. Guardarli mi ha aiutato a trovare l'approccio migliore per il mio dilemma, che era quello di fornire al proprietario del sito la possibilità di selezionare uno dei 19 set più popolari di quotazioni - combinazioni di citazioni incorporate appropriate per il loro pubblico di destinazione.
Chrome tenta di utilizzare automaticamente la guida di stile di un Paese, ma fortunatamente può essere sovrascritta specificando una locale nell'attributo lang del tag q . Ciò evidenzia il problema con approcci automatici che non tengono conto del mondo reale, ma si affidano alla teoria per le loro implementazioni.
Per l'OP, cerca i siti di giornali online per vedere quali sono effettivamente utilizzati in vari paesi, in modo che tu possa vedere quale approccio fornirà risultati più coerenti.
Mentre alcune lingue hanno tradizionalmente usato un carattere diverso per il colon inglese, l'utilizzo online può essere indirizzato a un pubblico abituato a quel punto. Inoltre, diverse impostazioni locali possono avere un utilizzo diverso, che richiede l'utilizzo di stringhe di lingua specifiche per ogni locale completo, anziché solo per lingua.
Quando stavo facendo la mia internazionalizzazione qualche anno fa, ha funzionato in questo modo:
I messaggi nel codice sorgente sono stati scritti in inglese
I messaggi sono stati tradotti in fase di esecuzione applicando una traduzione (che è apparso nel sorgente come translate ("stringa") o più di solito / "stringa"). Ci si aspettava che fosse un dizionario precostruito di messaggi e traduzioni.
Durante la traduzione di un messaggio, lo spazio bianco a ciascuna estremità è stato ritagliato e la punteggiatura finale è stata rimossa, così come le eventuali maiuscole. Dopo aver tradotto ciò che era rimasto, questi sono stati rimessi.
Per fornire più contesto, a volte ho aggiunto un commento alla stringa, che faceva parte del processo di traduzione per trovare la corrispondenza migliore, ma il commento è stato poi scartato.
Quindi, con un messaggio come "Disk:", la stringa "disk" è stata tradotta in "disquette" e quindi ricomposta come "Disquette:". Ciò ha ridotto il numero di messaggi molto simili.
L'ho fatto solo per un piccolo numero di lingue dell'Europa occidentale; probabilmente ci sarebbero problemi con quelli più esotici. Comunque stavo usando un linguaggio di scripting per questo, quindi potevo usare qualche elaborazione per qualsiasi problema: quando dovevo tradurre "G" (abbreviazione di Green), appariva nella sorgente come left (/ "Green" ), tradotto in qualcosa come "vert" e ridotto a "V".
Tuttavia non ho familiarità con gli attuali framework e il modo in cui potrebbero funzionare; non forniscono linee guida per trattare questi tipi di problemi?
Può dipendere dal sistema di localizzazione che usi, ma avendo altre cose uguali, eviterei personalmente di aggiungere alcuna punteggiatura (a meno che entro una frase ovviamente, dove il suo uso è dettato dalla grammatica ), perché ritengo che facciano parte della presentazione , come la dimensione del carattere ecc. e non il contenuto . Quindi stiamo mescolando cose diverse con questo approccio.
Dopotutto, le stesse parole e frasi possono essere necessarie sia con la punteggiatura che senza. Per esempio. puoi avere "Enter subject:" didascalia accanto a una casella di testo, ma anche "Enter subject" come titolo di una finestra.
Ha senso che entrambi vengano tradotti separatamente?
Quando decidi che i due punti in realtà appaiono errati e ridondanti nell'interfaccia utente, dovrai ritrasformare tutte le versioni linguistiche. Che è un po 'sciocco.
PS. Le "regole di base" fornite da @bartc sono valide in entrambi i casi, indipendentemente dal fatto che vengano inclusi o meno segni di punteggiatura nelle stringhe tradotte.
PPS. @paulkayuk, inoltre, solleva un buon punto (nel suo commento) - che anche le specificità culturali dovrebbero essere prese in considerazione. Se hai cose come i punti interrogativi con mirroring in spagnolo, includile nella tua traduzione, naturalmente. La mia risposta presuppone una punteggiatura uniforme, indipendente dalla lingua, perché sembra essere un po 'discutibile.
Un file di linguaggio dell'applicazione non è solo una traduzione fittizia di parole. È un processo in cui traduci le parole e la loro presentazione "puntuale" nel contesto meaningfull corretto.
Hello? in spagnolo è ¿Hola? in arabo è مرحبا؟ . Come puoi vedere, non puoi semplicemente memorizzare Hello o Hola o مرحبا e poi nell'interfaccia utente fai solo un the_hello_text + "?" . Non produrrà l'output corretto. È ovvio che la punteggiatura deve essere curata nel file di lingua. Ciò significa che non è la preoccupazione della GUI di "aggiungere" un punto interrogativo o due punti alla fine di una stringa.
La punteggiatura e tutto deve essere all'interno del file di internazionalizzazione, pronto da inviare all'interfaccia utente.
L'unica cosa che l' UI dovrebbe preoccupare , è la presentazione corretta di questo testo pronto per essere otputato , come allineamento a destra se è un linguaggio RTL. Ma questa è un'altra storia e niente non ha a che fare con i file di lingua di internazionalizzazione di per sé.
Leggi altre domande sui tag internationalization