Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translate *Firefox Developer Edition* subpage for mozilla.org #56

Closed
kitsunenosaraT opened this issue Jul 25, 2017 · 15 comments
Closed

Comments

@kitsunenosaraT
Copy link
Member

kitsunenosaraT commented Jul 25, 2017

Questo progetto di 57 stringhe farà parte della pagina dei prodotti Mozilla sul sito mozilla.org, per presentare Firefox Developer Editor, la versione del browser con la volpe dedicato agli sviluppatori. Dunque sarà un contenuto ad alta visibilità.

Il progetto ha una scadenza per il 15 di agosto, quindi prima di prenderlo in carico valuta se sarai in grado di portarlo a termine entro i tempi stabiliti.

Informazioni sul progetto

URL https://www.mozilla.org/it/firefox/developer/
URL sito di test https://www-dev.allizom.org/it/firefox/developer/
Formato di file .lang
Strumenti Pontoon
Scadenza 15 agosto 2017

Istruzioni

Prima di iniziare:

Prendere in carico il progetto

EDIT Aggiornati URL sito e sito di test

@kitsunenosaraT
Copy link
Member Author

@eliogi se devo essere sincera, appena mi hanno proposto questa pagina per i volontari, ho subito pensato a te. Purtroppo c'è una scadenza, quindi se sei impegnato e non ti senti di sobbarcartela in questo momento dillo pure con franchezza. @gialloporpora si è offerto di occuparsene lui in caso tu non sia disponibile, e sicuramente ci saranno altre occasioni in futuro. 🦊 🌍

@valtermura
Copy link
Collaborator

valtermura commented Jul 25, 2017 via email

@eliogi
Copy link
Collaborator

eliogi commented Jul 25, 2017

Ciao a tutti :)
Beh che dire... mai successo prima che ci fossero tanti localizzatori "pronti" alla missione :) Ottimo direi! @kitsunenosaraT per me non ci sono problemi, ma comunque sono preso da altre cose di lavoro, visto che @valtermura è più libero, per me non ci sono problemi se la gestisce lui... poi nel caso serve una mano, io sono qui ;)

@kitsunenosaraT
Copy link
Member Author

@eliogi Grazie per aver risposto subito! Goditi una meritatissima pausa dalla traduzione e buon lavoro! 👍

@valtermura È un piacere risentirti 😁
Se vuoi, Firefox Developer è tutto tuo!
Visto che sarà passato un po' di tempo da quando hai letto la guida, ricapitolo brevemente:

  1. Segui il link al progetto, ti autentichi su Pontoon (ti sei già registrato, se non sbaglio).
  2. Per cercare i termini già tradotti puoi usare la barra di ricerca sotto il tab MACHINERY
  3. Quando hai terminato, scrivi un messaggio qui dando l'OK per il QA.

Per qualsiasi dubbio o problema tecnico, puoi sempre scrivere qui (così se salta fuori qualche spunto interessante, rimane per la guida).

Ti avviso di un’ultima cosa: da domani fino a venerdì notte sarò impossibilita ad accedere al computer, ma da sabato mattina torno a tua disposizione.

Buona traduzione! 🥂

@valtermura
Copy link
Collaborator

valtermura commented Jul 27, 2017 via email

@valtermura
Copy link
Collaborator

valtermura commented Jul 27, 2017 via email

@valtermura
Copy link
Collaborator

valtermura commented Jul 28, 2017 via email

@kitsunenosaraT
Copy link
Member Author

@valtermura Grazie mille 👍
Sono contenta che tu ti sia trovato a tuo agio con Pontoon, piace anche a me.
In questi giorni completo il QA, stay tuned.

Mi dispiace di essermi dovuta allontanare proprio in questi giorni e quindi non essere riuscita a rispondere alla tua domanda sull'uso delle persone in tempo utile, comunque siccome è un'ottima domanda provo a spiegare qui la nostra filosofia.

Allora, innanzitutto facciamo una distinzione tra materiale divulgativo/promozionale e documentazione tecnica.

Nel materiale divulgativo/promozionale (pagine web che presentano le nuove funzioni, pubblicizzazione di eventi e iniziative, descrizioni per le app su Google Play ecc.) si deve usare un tono fresco e accattivante per attirare e mantenere l'attenzione dell'utente, per cui usiamo la seconda persona singolare in modo da favorire un coinvolgimento del lettore.

Per la documentazione tecnica (elementi dell'interfaccia, articoli di supporto, note di versione) usiamo invece il buon vecchio stile italiano impersonale.
Attenzione a questa distinzione:
quando l'istruzione è rivolta all'utente usare la forma impersonale.
es. Digitare un indirizzo email valido
quando l'utente impartisce un comando al programma usare la seconda persona imperativa.
es. Elimina tutti i messaggi.
In pratica si può razionalizzare dicendo che è scortese impartire un ordine all'utente, dunque si usa la formula impersonale, mentre il programma è un'entità inanimata si può tranquillamente usare la forma imperativa senza offendere i suoi sentimenti… almeno è quello che penso io per ricordarmi la distinzione 😅

Allora mi faccio sentire qui appena ho finito il QA!

@kitsunenosaraT
Copy link
Member Author

Rieccomi!
Complimenti @valtermura come c'era da aspettarsi hai fatto un ottimo lavoro, puntuale, chiaro e consono😀
Io ho messo qualche alternativa, ti chiedo, quando hai tempo di riguardarle qui:
https://pontoon.mozilla.org/it/mozillaorg/firefox/products/developer.lang/?status=suggested&string=168777
Se ti vanno bene, basta che le lasci così e poi torni qui a darmi l'OK per accettarle.

Se non ti convincono e vorresti cambiare qualcosa, inserisci un nuovo suggerimento come controproposta.

Di seguito elenco alcuni cambiamenti che ho segnato con relative spiegazioni, in modo da illustrarti le motivazioni dei miei cambiamenti.

Make our devtools yours thanks to open-source code and customization.

Personalizza per le tue esigenze i nostri strumenti di sviluppo grazie al codice open source.

Grazie al codice open source adatta alle tue esigenze gli strumenti di sviluppo integrati.

Questa è per non ripetere "personalizza" come prima parola nell'header e nella descrizione. Inoltre meglio evitare i possessivi quando possibile, vedi nostri strumenti.

Ship responsive and compatible sites that work for everyone, everywhere.

Crea siti compatibili e flessibili, funzionanti per tutti, ovunque.

Crea siti compatibili e flessibili, che funzionano per tutti dappertutto.

Qui ho "svolto" la frase dandole un tono più colloquiale.

Master CSS Grid with the only grid inspector
and layout tools on the Web.

Diventa esperto della CSS Grid solo con l'ispettore di griglia
e gli strumenti per layout sul Web.

Gestisci con facilità le griglie CSS grazie all’esclusivo strumento di analisi griglia
e tanti altri strumenti per layout.

Qui la frase era un po' incasinata pure in inglese. Ho intrepretato "only" come "il solo strumento di ispezione griglie CSS sul Web". Vi suona giusto?

Try CSS Grid now

Prova la CSS Grid ora

Prova subito CSS Grid

Questo vale anche per qualche stringa successiva (es. il Debugger). Quando un nome straniero è utilizzato come nome proprio, evitiamo l’articolo.

Debug Firefox and framework apps
built on React and Ember
with the “go anywhere” debugger

Esegui il debug di Firefox e delle app per il framework
che si basano su React ed Ember
con il debugger “go anywhere”

Esegui il debug di Firefox e delle app per il framework
sviluppante con React ed Ember
con il debugger “go anywhere”

Qui penso che built on significhi proprio che prima sviluppi le app con gli strumenti integrati React e Ember, poi le analizzi con il debugger, tutto senza uscire da Firefox. Quel "go anywhere" mi lascia un po' perplessa… Go è un linguaggio se non sbaglio… Si tratta di un gioco di parole? Del nome della tipologia di debugger?

Track CSS, JavaScript, security and network issues.

Traccia i problemi di CSS, JavaScript, sicurezza e rete.

Individua le falle di sicurezza e rete in CSS e JavaScript.

Nonostante l'inglese, penso che il senso sia le falle di sicurezza e rete nel codice… vi torna?

In ultimo ti chiedo in futuro di usare apostrofi e virgolette curvi se possibile. È una misura per evitare che la punteggiatura venga interpretata come codice HTML, che fa uso di apostrofo e virgolette dritte. Altrimenti, se sulla tua tastiera la combinazione dei tasti è troppo incasinata, posso aggiustarli io successivamente, nessun problema.

@valtermura
Copy link
Collaborator

valtermura commented Jul 31, 2017 via email

@gialloporpora
Copy link
Collaborator

gialloporpora commented Jul 31, 2017 via email

@kitsunenosaraT
Copy link
Member Author

@gialloporpora grazie per essere intervenuto.
Una cosa: ho de-accettato le stringhe verdi a cui hai messo un suggerimento, così che tornino visibili nel filtro suggested. Propongo anche qui di fare così quando vogliamo proporre un'alternativa a una stringa già accettata.

CSS Grids: personalmente lo tradurrei. Come ha scritto gialloporpora non è il nome proprio di un nuovo software o di un nuovo linguaggio, ma semplicemente una modalità diversa di impostare i fogli di stile.

Web Audio API: io terrei questo riferimento. Per quanto riguarda come metterlo, seguirei questo ragionamento:

Web Audio API
nome "proprio" dell'API tipo di file

Dunque, ricostruendo l'ordine naturale italiano:
L’API Web Audio

@gialloporpora
Copy link
Collaborator

gialloporpora commented Jul 31, 2017 via email

@valtermura
Copy link
Collaborator

valtermura commented Jul 31, 2017 via email

@kitsunenosaraT
Copy link
Member Author

@valtermura

Personalmente, nelle mie esperienze, tendo a tradurre il più possibile in italiano, un piccolo tentativo che adottiamo anche in KDE per contrastare il predominio dell'inglese.

Questo stile in linea di massima lo condividiamo anche a Mozilla. Saper esprimere un concetto nella propria lingua porta a interiorizzarlo più facilmente, mentre l'utilizzo a sproposito della lingua inglese fa sembrare anche i concetti più basilari come chissà cosa. 👍

Nella mia ignoranza ho dunque considerato Web Audio come un riferimento non a un programma specifico ma a un'area specifica, dunque ho tradotto 'API audio web'.

Tecnicamente questo ragionamento fila benissimo. Anche noi, quando abbiamo iniziato a parlare di API, abbiamo valutato se adottare questo sistema, ma poi lo abbiamo escluso. Ecco il motivo:

Per Web Audio API intendiamo un'interfaccia di programmazione open source specifica, che si può usare per gestire l'audio. Non ci sono 3 o 4 API del tipo web audio con nomi diversi, c'è solo quella, identificata appunto con il nominativo Web Audio.

Tieni conto che l'utente comune non sentirà mai parlare di API, che interessano invece gli sviluppatori.
Adesso, siccome il nome è decisamente descrittivo, non ci sarebbero problemi a tradurlo in modo perfettamente univoco come hai fatto tu. Però se traduciamo quel nome, per coerenza dobbiamo anche tradurre i nomi di tutte le altre API, alcune delle quali non hanno traducenti così immediati.
Dunque, al fine di non causare confusione negli sviluppatori, per cui potrebbe non risultare immediato riconoscere l'API a cui ci stiamo riferendo nella versione italiana, abbiamo deciso di trattare la denominazione dell'API come un nome proprio.

Mi piacerebbe sentire se a KDE vi sono capitati simili dilemmi e come avete deciso di risolverli.

Intanto, visto che abbiamo appianato la maggior parte dei dubbi, procedo ad accettare le stringhe.
In questo modo potremmo vederle al loro posto sul sito di test e ci salteranno all'occhio problemi che sfuggono leggendo semplicemente le stringhe.

Ricordo anche ai nuovi che una stringa può essere modificata più e più volte in qualsiasi momento, quindi anche le stringhe già accettate sono soggette a suggerimenti e miglioramenti.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants