Translating MDN – How to properly tag pages

[kitsunenosaraT]

Questo issue è dedicato alla traduzione e revisione di un articolo di MDN.

Informazioni sul progetto

URL: https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Tag

URL traduzione: https://developer.mozilla.org/it/docs/MDN/Contribute/Howto/Tag

Formato di file: markup wiki (testo con tag)

Strumenti: a scelta tra interfaccia di traduzione MDN (online) / editor di testo semplice (offline) / OmegaT (offline)

Istruzioni

Prima di iniziare

• Crea un account GitHub (se non lo hai già): ti servirà sia per scrivere in questo issue, sia per accedere a MDN

  • (Facoltativo) Installa il componente aggiuntivo MozIta L10n Addons per accedere più facilmente ai caratteri speciali come ’ “ ” È ecc.

• Leggi "Come tradurre le pagine di MDN"

• Leggi i capitoli della guida. Se lo desideri, lascia un feedback nel relativo issue:

  • Capitolo 1 – Buone norme di traduzione tecnica Feedback: issue (IT) Capitolo 1 – Buone norme di traduzione v.3 #225
  • Capitolo 2 – Linee guida di Mozilla Italia Feedback: issue (IT) Capitolo 2 – Linee guida di Mozilla Italia v.2 #138
  • Capitolo 3 – Flusso di lavoro Feedback: issue (IT) Capitolo 3 – Flusso di lavoro #24
  • Capitolo 4 – Tipi di file Feedback: issue (IT) Capitolo 4 – Tipi di file #31
  • Capitolo 5 – Risorse esterne Feedback: issue (IT) Capitolo 5 – Risorse esterne #36

Prendere in carico il progetto

• Scrivi nello issue Traduzione articoli MDN (Indice) #217 l'URL dell'articolo che vuoi tradurre. Verrà aperto uno issue dedicato.
• Accedi a MDN con il tuo account GitHub
• Attieniti alle istruzioni per MDN del capitolo 3 e ai suggerimenti del resto della guida, in particolare i consigli pratici del capitolo 2
• Quando hai terminato, aggiungi a questo issue il label richiesta revisione tecnica e avvisa con un messaggio nella sezione commenti.
  • Se sei il revisore tecnico, quando hai terminato, elimina il label richiesta revisione tecnica e applica quello richiesta revisione stilistica.
  • Se sei il revisore stilistico, quando hai terminato, elimina il label richiesta revisione stilistica.
• Per qualsiasi problema o domanda scrivi pure in questo issue
• …e buona traduzione! 🎊

Link Utili

• Motori di ricerca per la terminologia
  • Pontoon: tutti i progetti -- Per gli elementi UI, le funzioni e altra terminologia dei prodotti Mozilla.
  • Transvision -- Motore di ricerca esterno per i software e i siti Mozilla, complementare a Pontoon.
  • Microsoft Language Portal -- Per gli elementi UI, le funzioni e altra terminologia dei prodotti Microsoft.

❗️ N.B. Per segnalare la traduzione di un nuovo articolo utilizzare lo issue indice #217.

[danielebarell]

Ciao Sara.
Il problema affrontato nell'articolo impatta direttamente sulle localizzazioni di cui mi sto occupando.
Cerco di seguirti con attenzione su questo issue.

[kitsunenosaraT]

L'articolo How to properly tag pages (Usare correttamente i tag) è pronto per:

• revisione tecnica: questa pagina verte molto sulle API, sulle specifiche, sui processi di standardizzazione, quindi vorrei assicurarmi di aver utilizzato la terminologia giusta;
• revisione editoriale: serve qualcuno che ricontrolli se ci sono errori di ortografia o simili (va bene chiunque voglia cimentarsi, anche senza particolari conoscenze tecniche).

[danielebarell]

Ciao Sara.
Sulla [ revisione editoriale ] provo io domani.
In pratica dovrei avere lo stesso ruolo che giochi tu sulle mie traduzioni, vero?

Invece su [ revisione tecnica ] posso esporti qualche dubbio se la terminologia mi suona strana, ma sarebbe meglio trovare qualcuno più coinvolto sullo sviluppo in Mozilla.

A presto.

[kitsunenosaraT]

@danielebarell

Sulla [ revisione editoriale ] provo io domani.
In pratica dovrei avere lo stesso ruolo che giochi tu sulle mie traduzioni, vero?

Esatto: controlli grammatica e punteggiatura, formattazione, scorrevolezza della frase, link e tutto il resto.

Invece su [ revisione tecnica ] posso esporti qualche dubbio se la terminologia mi suona strana, ma sarebbe meglio trovare qualcuno più coinvolto sullo sviluppo in Mozilla.

Se mentre fai la revisione hai tempo, segnala pure i tuoi dubbi di natura tecnica. Magari trovi qualcosa che gli atri non vedono.

Grazie per il tuo aiuto!

[danielebarell]

QA fino a "Identificazione API" esclusa. Domani spero di terminare.

A presto.

[kitsunenosaraT]

Grazie @danielebarell
Poi guardo con più calma quando avrai terminato!
Per adesso vorrei avvisarti di una cosa:
non so che combinazioni di tasti premi per immettere il carattere dello spazio, ma stai seminando   ovunque 😅
(si vede bene se visualizzi l'articolo come testo sorgente)

[danielebarell]

@kitsunenosaraT
Ciao Sara,
ho fatto la revisione stilistica.
Ci ho messo attenzione ma essendo la prima volta può essere che non sia venuta al meglio.

Al di fuori della questione stilistica ho riscontrato un problema quando

"[...]Is it non-standard?[...]"

è stato tradotto Non ancora standard
come spiegato bene più avanti esistono software proprietari che fanno uso di API che non sono allo studio come standard e neppure lo saranno mai. Quindi per me l'avverbio "ancora" dà un senso scorretto alla frase.

Link e non-breaking-space non sono riuscito a rivederli per ora.

A presto

[kitsunenosaraT]

@danielebarell

Grazie e mille, grandioso 🎉
Spero di riuscire a guardare le tue correzioni nel weekend.

Su "non-standard", in effetti hai ragione.
Ti risponderò più dettagliatamente dopo aver revisionato attentamente le modifiche.

[kitsunenosaraT]

Ecco la prima parte delle mie osservazioni, fino ad "Argomento" escluso.

<span class="seoSummary">Questa pagina spiega come ottimizzare l'uso dei tag per permettere ai lettori di trovare informazioni pertinenti e ai gestori di MDN di mantenere i contenuti organizzati.</span></p>

<span class="seoSummary">Questa pagina spiega come ottimizzare l'uso dei tag per facilitare i lettori nella ricerca e agevolare i gestori nell'organizzazione e mantenimento dei contenuti.</span></p>

OK

---

<p>È importante utilizzare i tag secondo queste regole, o gli strumenti automatizzati non saranno in grado di generare automaticamente liste di contenuti, landing page e link di rimando tra i vari articoli.</p>

<p>È importante utilizzare i tag secondo queste regole altrimenti gli automatismi non saranno in grado di generare&nbsp;liste di contenuti, landing page e link incrociati&nbsp;tra i vari articoli.</p>

Ottimo, però tolgo i vari  

<p>È importante utilizzare i tag secondo queste regole, altrimenti gli automatismi non saranno in grado di generare liste di contenuti, landing page e link incrociati tra i vari articoli.</p>

---

<h2 id="How_MDN_uses_tags">Uso dei tag in MDN</h2>
<h2 id="Uso_dei_tag_in_MDN">Uso dei tag in MDN</h2>

... E seguenti: hai ragione, anche l'id va localizzato.

---

Si tratta di una categoria di tag fondamentali, che i lettori possono utilizzare per filtrare i contenuti di ricerca.</dd>
Si tratta di una categoria di tag fondamentali, che i lettori possono utilizzare per filtrare le ricerche.</dd>

OK

---

<dd>Qual è l'argomento dell'articolo? Parla di API? Di DOM? Di grafica? Come i tag precedenti, anche questi hanno il ruolo fondamentale di filtrare i risultati di ricerca.</dd>

<dd>Qual è l'argomento dell'articolo? Parla di API? Oppure di DOM? O di grafica? Questi tag, al pari dei precedenti, hanno un&nbsp;ruolo fondamentale nel&nbsp;filtrare i risultati di ricerca.</dd>

OK, tolgo solo i nbsp.

<dd>Qual è l'argomento dell'articolo? Parla di API? Oppure di DOM? O di grafica? Questi tag, al pari dei precedenti, hanno un ruolo fondamentale nel filtrare i risultati di ricerca.</dd>

---

<dd>Ogni pagina di consultazione di un'API deve avere un tag che identifichi il componente specifico documentato (l'interfaccia di cui è parte e, dove applicabile, la proprietà o metodo che tratta).</dd>

<dd>Ogni pagina di consultazione di un'API deve identificare lo specifico componente documentato (ovvero l'interfaccia di cui fa parte e, dove applicabile, quale&nbsp;proprietà o metodo viene trattato).</dd>

Penso che ciò che sta cercando di dire è (come spiega dopo) che le sezioni delle varie API sono composte da più pagine, ciascuna che tratta una proprietà o un metodo. Quindi, ciascuna di queste pagine deve avere un tag "generico" col nome dell'API di cui parla + un tag per l'argomento specifico di quella pagina (interfaccia, proprietà o metodo). Provo ad esprimermi diversamente:

<dd>Ogni pagina di consultazione di un'API deve essere associata a un tag che identifichi lo specifico componente trattato (ovvero l'interfaccia di cui fa parte e, dove applicabile, la proprietà o metodo).</dd>

---

<dd>Qual è lo stato dell'arte della tecnologia trattata? Non è ancora standardizzata? È obsoleta o deprecata? Oppure sperimentale?</dd>

<dd>Qual è lo stato dell'arte della tecnologia trattata? Non è riconosciuta come standard? È obsoleta o deprecata? Oppure sperimentale?</dd>

Ottimo! Ero abbastanza incerta sulla questione degli standard/non-standard.

---

<dd>Applicabile a tutorial e guide: quanto è avanzata la materia di cui tratta l'articolo?</dd>
<dd>Applicabile a tutorial e guide: quanto è impegnativo&nbsp;l'articolo?</dd>

Non saprei... per questa categoria più che l'impegno è determinante il livello di conoscenza dell'argomento richiesto (un articolo può trattare un argomento semplice in modo impegnativo).
Controproposta:

<dd>Applicabile a tutorial e guide: l'argomento richiede conoscenze approfondite?</dd>

---

<dd>La comunità dei creatori di contenuti usa questi tag per tenere traccia di quali pagine hanno bisogno di quali interventi.</dd>

<dd>Chi scrive e gestisce i contenuti usa questi tag per tenere traccia del tipo di interventi da effettuare sulle pagine.</dd>

Ottimo!

---

<h2 id="Tag_type_guide">Guida ai tipi di tag</h2>

<h2 id="Guida_ai_tipi_di_tag">Guida ai tipi di tag</h2>

Ok.

---

<p>Segue una breve guida ai tipi di tag utilizzati su MDN e i valori ad essi associati.</p>

<p>Segue una breve guida ai tipi di tag utilizzati su MDN e i loro significati.</p>

OK

---

<h3 id="Document_category">Categoria documento</h3>

<h3 id="Categoria_documento">Categoria documento</h3>

Ok

---

<p>I tag di categoria, associati a un articolo, facilitano la generazione automatica di landing page, indici e altri elementi. Inoltre, nel nuovo sistema di ricerca, questi termini potranno essere usati anche dagli utenti per trovare materiali di consultazione e guide pertinenti.</p>

<p>I tag di categoria, associati a un articolo, facilitano la generazione automatica di landing page, indici e via dicendo. Inoltre, nel nuovo sistema di ricerca, questi termini possono essere usati anche dagli utenti per trovare materiali di consultazione e guide pertinenti.</p>

OK

---

Come regola generale, ciascuna area dedicata a una tecnologia dovrebbe possedere un unico tag "Intro".</dd>

Come regola generale, ciascuna area tecnologica dovrebbe disporre di un unico tag "Intro".</dd>

OK.

---

<dd>Indica che la pagina in questione è una landing page, la pagina iniziale di un dato argomento.</dd>

<dd>"Approccio". Indica che la pagina in questione è una landing page, la pagina iniziale di un dato argomento.</dd>

In questo caso non ho tradotto il tag "landing" perchè non è traducibile letteralmente, è solo l'abbreviazione di "landing page", che abbiamo lasciato in inglese.
"Approccio" ha un suo senso, visto che la landing page è la pagina introduttiva, ma è più un'interpretazione che una traduzione del tag.
Ho visto tradurre "landing page" come "pagina di destinazione", ma "landing page" mi sembra più usato. Personalmente non tradurrei il tag in questo caso, ma vorrei sentire anche se hai altre proposte.

---

<dd>"Guida". L'articolo è una pagina contenente una guida o una procedura guidata.</dd>
<dd>"Guida". L'articolo consiste in&nbsp;una pagina contenente una guida o una procedura guidata.</dd>

Tolgo solo il nbsp.

<dd>"Guida". L'articolo consiste in una pagina contenente una guida o una procedura guidata.</dd>

---

<dd>"Esempio". L'articolo è una pagina di codice esempio, oppure contiene campioni di codice (ovvero frammenti di codice che possono essere riutilizzati, non semplici esempi di sintassi da una riga).</dd>

<dd>"Esempio". L'articolo contiene un&nbsp;codice di esempio, oppure contiene campioni di codice (ovvero&nbsp;non semplici esempi di sintassi da una riga bensì&nbsp;frammenti di codice che possono essere riutilizzati).</dd>
Grazie di aver fatto chiarezza, però vorrei evitare la ripetizione di "contiene". Inoltre faccio un po' di pulizia di nbps.

<dd>"Esempio". L'articolo contiene un codice di esempio, oppure campioni di codice (ovvero non semplici esempi di sintassi da una riga, bensì frammenti di codice che possono essere riutilizzati).</dd>

[kitsunenosaraT]

@danielebarell seconda parte del contro-QA (scusa, nella prima, qui sopra, ho dimenticato la menzione)

<h3 id="Topic">Argomento</h3>

<h3 id="Argomento">Argomento</h3>

Ok

---

<p>Pur trattandosi di una categoria abbastanza elastica, che cresce mano a mano che vengono identificati nuovi argomenti, cerchiamo di limitare i tag ai nomi di API o tecnologie.

<p>Pur trattandosi di una categoria che può espandersi&nbsp;mano a mano che vengono identificati nuovi argomenti, cerchiamo di limitare i tag ai nomi di API o tecnologie.

tolgo solo il nbsp

<p>Pur trattandosi di una categoria che può espandersi mano a mano che vengono identificati nuovi argomenti, cerchiamo di limitare i tag ai nomi di API o tecnologie.

---

<li><code>{{Tag("Document")}}</code></li>

<li><code>{{Tag("Document")}}</code>, "documento"</li>

OK

---

<li><code>{{Tag("Graphics")}}</code></li>

<li><code>{{Tag("Graphics")}}</code>, "grafica"</li>

ok

---

<li><code>{{Tag("Tools")}}</code></li>

<li><code>{{Tag("Tools")}}</code>, "strumenti"</li>

---

<li><code>{{Tag("Element")}}</code></li>

<li><code>{{Tag("Element")}}</code>, "elemento"</li>

---

<li><code>{{Tag("Extensions")}}</code> e <code>{{Tag("WebExtensions")}}</code> per la documentazione su WebExtension.</li>

<li><code>{{Tag("Extensions")}}</code>,"estensioni" e <code>{{Tag("WebExtensions")}}</code>, "estensioni-Web"&nbsp;per la documentazione su WebExtension.</li>

A parte il nbsp da togliere, ho un dubbio su WebExtestension. Forse dirò una scemenza, ma non è una sorta di nome proprio al pari di JavaScript ecc.? Ha senso mettere "estensioni-Web"? Da segnalare a @Mte90 o @Sav22999 per la revisione tecnica.

---

<p>In linea generale, i tag di argomento sono nomi di un'interfaccia associati a diverse pagine rilevanti (per esempio, <a href="it/docs/Web/API/Node">Node</a> è associato a diverse pagine perché possiede più proprietà e metodi), o nomi di un tipo di tecnologia più ampia.

<p>In linea generale, i tag di argomento sono nomi di un'interfaccia associati a diverse pagine rilevanti (per esempio, <a href="it/docs/Web/API/Node">Node</a> è associato a diverse pagine perché possiede molteplici proprietà e metodi), o nomi che indicano un complesso di&nbsp;tecnologie.

A parte il nbsp, non sono sicura che parli di un "complesso di tecnologie", ma piuttosto dei tag delle varie tecnologie base come HTML, JavaScript, CSS ecc., opposta ai nomi più specifici come l'interfaccia ecc.
Controporposta:

<p>In linea generale, i tag di argomento sono nomi di un'interfaccia associati a diverse pagine rilevanti (per esempio, <a href="it/docs/Web/API/Node">Node</a> è associato a diverse pagine perché possiede molteplici proprietà e metodi), o nomi che indicano una categoria tecnologica.

---

Ad esempio, una pagina che parla di WebGL potrebbe essere associata ai tag <code>Graphics</code> e <code>WebGL</code>, una pagina che tratta dell'elemento {{HTMLElement("canvas")}}

Ad esempio, una pagina che parla di WebGL potrebbe essere associata ai tag <code>Graphics</code> e <code>WebGL</code> mentre&nbsp;una pagina che tratta dell'elemento {{HTMLElement("canvas")}}

Tolgo solo il nbsp e aggiungo una virgola:

Ad esempio, una pagina che parla di WebGL potrebbe essere associata ai tag <code>Graphics</code> e <code>WebGL</code>, mentre una pagina che tratta dell'elemento {{HTMLElement("canvas")}}

---

<h4 id="Mozilla-specific_content">Contenuti Mozilla</h4>

<h4 id="Contenuti_Mozilla">Contenuti Mozilla</h4>

---

<p>I seguenti tag sono associati unicamente ai contenuti specifici di Mozilla:</p>

<p>I seguenti tag sono associati esclusivamente a&nbsp;contenuti specifici di Mozilla:</p>

Ok, tolgo nbsp

<p>I seguenti tag sono associati esclusivamente a contenuti specifici di Mozilla:</p>

---

<h3 id="API_identification">Identificazione API</h3>

<h3 id="Identificazione_API">Identificazione API</h3>

Ok

---

<p>All'interno del materiale di consultazione di ogni API, ciascun articolo dovrebbe essere associato a un tag che identifichi specificatamente la parte dell'API trattata:</p>

<p>All'interno del materiale di consultazione delle API, ciascun articolo dovrebbe essere associato a un tag che identifichi la specifica parte dell'API trattata:</p>

Ottimo!

---

<h3 id="Technology_status">Stato tecnologia</h3>

<h3 id="Stato_tecnologia">Stato tecnologia</h3>

Ok

---

Il tag non spiega in dettaglio la natura e i progressi della specifica nel processo di specificazione

Il tag non spiega in dettaglio il tipo e i progressi della tecnologia nel processo di specificazione

Ok

---

<p>Di seguito, i possibili valori di questa categoria di tag:</p>

<p>Di seguito, i possibili valori per questa categoria di tag:</p>

Ok

---

<dd>"Deprecata". La tecnologia o API trattata nella pagina è una specifica "deprecata", dunque cadrà probabilmente in disuso, ma per il momento è ancora disponibile nelle versioni più recenti dei browser.</dd>

<dd>"Deprecata". Quando la tecnologia o API trattata nella pagina è segnalata come "deprecata" è probabile che cada in disuso anche se per il momento è ancora disponibile nelle versioni più recenti dei browser.</dd>

Ottimo, però necessita di una virgola dopo "deprecata":

<dd>"Deprecata". Quando la tecnologia o API trattata nella pagina è segnalata come "deprecata", è probabile che cada in disuso, anche se per il momento è ancora disponibile nelle versioni più recenti dei browser.</dd>

---

È inoltre suscettibile alle modifiche nel motore del browser che la implementa (di solito si tratta di un singolo browser).

Inoltre dipende dalle modifiche nel motore del browser che la implementa (di solito si tratta di un singolo browser).

Forse nessuna delle due rende bene il discorso, cioè che se il motore del browser viene aggiornato, quella tecnologia ptrebbe diventare inutile oppure cambiare anch'essa.
Controproposta:

È inoltre soggetta alle modifiche nel motore del browser che la implementa (di solito si tratta di un singolo browser).

---

<h3 id="Skill_level">Livello di competenza</h3>

<h3 id="Livello_di_competenza">Livello di competenza</h3>

Ok

---

Aiutano l'utente a scegliere un tutorial in base al proprio livello di familiarità con una data tecnologia.

Aiutano l'utente a scegliere un tutorial in base alla propria conoscenza di una data tecnologia.

Ok.

---

<dd>"Avanzato". Articoli che esplorano le possibilità della tecnologia trattata e mettono alla prova le competenze dell'utente.</dd>

<dd>"Avanzato". Articoli che approfondiscono le possibilità della tecnologia trattata e mettono alla prova le competenze dell'utente.</dd>

Ottimo!

---

<h3 id="Document_metadata">Metadati del documento</h3>

<h3 id="Metadati_del_documento">Metadati del documento</h3>

Ok

---

Per evitare conflitti di contenuti, prima di eseguire qualsiasi modifica, è buona norma contattare gli ultimi collaboratori che hanno lavorato all'articolo.</dd>

Prima di eseguire qualsiasi modifica è buona norma contattare i collaboratori che hanno lavorato all'ultima bozza dell'articolo al fine di evitare possibili conflitti di contenuto.</dd>

Ok, ma aggiungerei un paio di virgole per migliorare la leggibilità:

Prima di eseguire qualsiasi modifica, è buona norma contattare i collaboratori che hanno lavorato all'ultima bozza dell'articolo, al fine di evitare possibili conflitti di contenuto.</dd>

---

Il codice di markup che costituisce la formattazione dell'articolo deve essere ottimizzato (solitamente perché l'articolo contiene solo o quasi tag di tipo {{HTMLElement("p")}}).</dd>

Il codice di markup che costituisce la formattazione dell'articolo deve essere ottimizzato (solitamente perché l'articolo è formattato solo o quasi da tag generici tipo {{HTMLElement("p")}}).</dd>

Ottimo!

---

<h2 id="Putting_it_all_together">Combinare i vari tag</h2>

<h2 id="Combinare_i_vari_tag">Combinare i vari tag</h2>

Ok

---

<p>Abbiamo visto che a ogni pagina vanno assegnati più tag di categoria diversa, per esempio:</p>

<p>Abbiamo visto che a ogni pagina vanno assegnati più tag di diverse categorie, per esempio:</p>

Ok

---

<dt>Per un tutorial per principianti su WebGL</dt> <dd>{{Tag("WebGL")}}, {{Tag("Graphics")}}, {{Tag("Guide")}}, {{Tag("Beginner")}}</dd> <dt>Per la pagina di consultazione dell'elemento {{HTMLElement("canvas")}}</dt> <dd>{{Tag("Canvas")}}, {{Tag("HTML")}}, {{Tag("Element")}}, {{Tag("Graphics")}}, {{Tag("Reference")}}</dd> <dt>Per una landing page sugli strumenti di sviluppo di Firefox</dt> <dd>{{Tag("Tools")}}, {{Tag("Firefox")}}, {{Tag("Landing")}}</dd>

<dt>Un tutorial per principianti su WebGL</dt> <dd>comprende i tag {{Tag("WebGL")}}, {{Tag("Graphics")}}, {{Tag("Guide")}}, {{Tag("Beginner")}}</dd> <dt>La pagina di consultazione dell'elemento {{HTMLElement("canvas")}}</dt> <dd>comprende i {{Tag("Canvas")}}, {{Tag("HTML")}}, {{Tag("Element")}}, {{Tag("Graphics")}}, {{Tag("Reference")}}</dd> <dt>Una landing page sugli strumenti di sviluppo di Firefox</dt> <dd>comprende i tag {{Tag("Tools")}}, {{Tag("Firefox")}}, {{Tag("Landing")}}</dd>

Ottimo!

---

<h2 id="Tagging_and_search_filters">Tag e filtri di ricerca</h2>

<h2 id="Tag_e_filtri_di_ricerca">Tag e filtri di ricerca</h2>

Ok

---

<dd>Di norma, ogni articolo dovrebbe essere associato <em>almeno</em> a un tag di "{{anch("Categoria documento")}}" e a un tag di "{{anch("Argomento")}}".

<dd>Di norma, ogni articolo dovrebbe essere associato<em>almeno</em> a un tag per la {{anch("Categoria documento", "categoria")}} e a un tag per l'{{anch("Argomento", "argomento")}} del documento.

Manca uno spazio tra "associato" e "almeno".

<dd>Di norma, ogni articolo dovrebbe essere associato <em>almeno</em> a un tag per la {{anch("Categoria documento", "categoria")}} e a un tag per l'{{anch("Argomento", "argomento")}} del documento.

---

Puoi aggiungere altri tag appropriati, ma anche solo assicurandoti che ogni pagina abbia i tag strettamente necessari darai un contributo enorme.</dd>

È possibile aggiungere altri tag appropriati, ma anche assicurarsi semplicemente che ogni pagina abbia i tag strettamente necessari costituisce un enorme contributo.</dd>

La semplificherei ulteriormente:

È possibile aggiungere altri tag appropriati, ma assicurarsi che ogni pagina abbia i tag strettamente necessari costituisce già di per sé un enorme contributo.</dd>

---

<dd>Se trovi un documento che non segue gli standard di questa pagina, correggilo.<br>

<dd><span lang="IT" style="font-family:&quot;Calibri Light&quot;,sans-serif; font-size:16.0pt; line-height:107%">Se viene trovato un documento che non segue gli standard di questa pagina occorre correggerlo.<br />

Non so se si tratti di un copia-incolla finito male, ma qui hai introdotto un altro carattere. Per questi tipi di file è consigliabile lavorare su un editor di testo semplice, tipo il Blocco Note, in modo da non introdurre formattazione esterna.

Inoltre, questo mi sembra uno di quei casi in cui volgere la frase all'impersonale renda tutto meno leggibile e diretto, per questo avevo optato per la seconda persona. Comunque propongo:

<dd>Quando si trova un documento che non segue gli standard di questa pagina, è opportuno correggerlo.<br />

---

Attenzione: potresti trovare alcuni tag localizzati in altre lingue su pagine in lingua inglese (es. <code>Référence</code>).

Attenzione: è possibile trovare alcuni tag localizzati in altre lingue su pagine in lingua inglese </span> (es. <code>Référence</code>).

Vedi sopra per il discorso indiretto. (Quello </span> lo tolgo, visto che era il tag di chiusura di quella formattazione indesiderata della stringa prima.)

Attenzione: su alcune pagine in lingua inglese è possibile talvolta imbattersi in tag localizzati in altre lingue (es. Référence).`

---

Rimuovi i tag non corretti e aggiungi quelli appropriati, se mancano.

I tag non corretti vanno rimossi e quelli appropriati vanno aggiunti, se mancanti.

Ok

---

Correggi anche i tag che contengono errori di battitura, come ad esempio "Javascript" (il tag sarà comunque funzionale, visto che non differenzia maiuscole e minuscole, ma anche la forma va curata.)</dd>

Inoltre i tag che contengono errori di battitura vanno corretti, come ad esempio "Javascript" (il tag funziona comunque, poichè il sistema non coglie la differenza tra maiuscole e minuscole, ma anche la forma va curata.)</dd>

Aggiungerei una virgola dopo "Inoltre". Poi cercherei di rendere un po' più fluida la frase:

Inoltre, vanno corretti anche i tag che contengono errori di battitura, come ad esempio "Javascript" (il tag funziona comunque, poichè il sistema non coglie la differenza tra maiuscole e minuscole, ma anche la forma va curata.)</dd>

---

<dd>Se un articolo è già associato ad alcuni tag, ma non a tutti quelli necessari, aggiungili tu.

<dd>Occorre aggiungere tutti i tag necessari all'articolo anche quando questo articolo ne è già provvisto ma solo di alcuni tra quelli necessari.

Qui, la semplificherei:

<dd>Un articolo potrebbe già essere associato ad alcuni tag, ma non a tutti quelli necessari. In questo caso, occorre aggiungere i tag mancanti.

---

Per esempio, se una pagina di consultazione in JavaScript presenta soltanto il tag "JavaScript" (peraltro corretto), sei incoraggiato ad aggiungere i tag "Reference" o {{anch("Categoria documento", "di un'altra categoria")}}.</dd>

Per esempio, se una pagina di consultazione in JavaScript presenta soltanto il tag "JavaScript" (peraltro corretto), i collaboratori sono incoraggiati ad aggiungere i tag "Reference" o di un'altra {{anch("Categoria documento", "categoria")}}.</dd>

Ok.

---

<dd>Si tratta del problema più fastidioso di tutti: alcuni parassiti del Web hanno infettato anche MDN, seminando tra le pagine tag tipo "Free warez!"

<dd>Si tratta del problema più fastidioso di tutti: alcuni malevoli frequentatori del Web hanno&nbsp; attaccato anche MDN, infestando le pagine con tag tipo "Free warez!"

Tolgo solo il nbsp

<dd>Si tratta del problema più fastidioso di tutti: alcuni malevoli frequentatori del Web hanno attaccato anche MDN, infestando le pagine con tag tipo "Free warez!"

---

<p>Se noti uno (o più) di questi tag, <a href="/it/docs/Project:Getting_started">accedi a MDN</a> e premi MODIFICA nell'angolo in alto a destra della finestra. Una volta che l'editor si sarà caricato, scorri fino al riquadro dei tag, che si trova in fondo alla pagina.

<p>Se uno (o più) di questi tag vengono notati, <a href="/it/docs/Project:Getting_started">accedere a MDN</a> e premere MODIFICA nell'angolo in alto a destra della finestra. Una volta che l'editor si sarà caricato, scorrere fino al riquadro dei tag, che si trova in fondo alla pagina.

Per renderla più fluida:
<p>Quando si nota uno (o più) di questi tag, <a href="/it/docs/Project:Getting_started">accedere a MDN</a> e premere MODIFICA nell'angolo in alto a destra della finestra. Una volta che l'editor si sarà caricato, scorrere fino al riquadro dei tag, che si trova in fondo alla pagina.

E questo è tutto!

Ci sono un paio di correzioni che ho leggermente modificato (per cui ti chiedo se ti vanno bene), ma la tua revisione meticolosa mi ha aiutato a migliorare l'articolo. Grazie e mille! 🙇

[danielebarell]

Penso che ciò che sta cercando di dire è (come spiega dopo) che le sezioni delle varie API sono composte da più pagine, ciascuna che tratta una proprietà o un metodo. Quindi, ciascuna di queste pagine deve avere un tag "generico" col nome dell'API di cui parla + un tag per l'argomento specifico di quella pagina (interfaccia, proprietà o metodo). Provo ad esprimermi diversamente:

Ogni pagina di consultazione di un'API deve essere associata a un tag che identifichi lo specifico componente trattato (ovvero l'interfaccia di cui fa parte e, dove applicabile, la proprietà o metodo).

Benissimo per me.

Applicabile a tutorial e guide: quanto è avanzata la materia di cui tratta l'articolo?

Applicabile a tutorial e guide: quanto è impegnativo l'articolo?

Non saprei... per questa categoria più che l'impegno è determinante il livello di conoscenza dell'argomento richiesto (un articolo può trattare un argomento semplice in modo impegnativo).

Vero. Più precisa la traduzione originale.

< h2 id="Tag_type_guide" >Guida ai tipi di tag
< h2 id="Guida_ai_tipi_di_tag" >Guida ai tipi di tag
[...]

Aspe.
Non ho fatto io questa revisione. Nessuna revisione che concerne la traduzione in sè dei tag è di mia iniziativa.
Che è sta magia?

Indica che la pagina in questione è una landing page, la pagina iniziale di un dato argomento.

"Approccio". Indica che la pagina in questione è una landing page, la pagina iniziale di un dato argomento.

In questo caso non ho tradotto il tag "landing" perchè non è traducibile letteralmente, è solo l'abbreviazione di "landing page", che abbiamo lasciato in inglese.
"Approccio" ha un suo senso, visto che la landing page è la pagina introduttiva, ma è più un'interpretazione che una traduzione del tag.

Ho visto tradurre "landing page" come "pagina di destinazione", ma "landing page" mi sembra più usato. Personalmente non tradurrei il tag in questo caso, ma vorrei sentire anche se hai altre proposte.

Si assolutamente. Per me togli "Approccio" e lascia "Landing Page". Ti ho proposto questo traducente solo perchè mi pareva che occorresse qualcosa, perchè in questa parte dell'articolo partivi sempre con un equivalente italiano.
Nella guida di riferiferimento specifichi giustamente che di alcuni termini è meglio non forzare la traduzione.

[kitsunenosaraT]

< h2 id="Tag_type_guide" >Guida ai tipi di tag
< h2 id="Guida_ai_tipi_di_tag" >Guida ai tipi di tag
[...]

Aspe.
Non ho fatto io questa revisione. Nessuna revisione che concerne la traduzione in sè dei tag è di mia iniziativa.
Che è sta magia?

Allora deve essersi aggiornato automaticamente, bene 😁
All'inizio non capivo a cosa serviva quell'id dopo l'header, penso che serva per generare l'indice dei contenuti in italiano.

[danielebarell]

< li >{{Tag("Extensions")}} e {{Tag("WebExtensions")}} per la documentazione su WebExtension.</ li >
< li >{{Tag("Extensions")}},"estensioni" e {{Tag("WebExtensions")}}, "estensioni-Web" per la documentazione su WebExtension.< /li >
A parte il nbsp da togliere, ho un dubbio su WebExtestension. Forse dirò una scemenza, ma non è una sorta di nome proprio al pari di JavaScript ecc.? Ha senso mettere "estensioni-Web"? Da segnalare a @Mte90 o @Sav22999 per la revisione tecnica.

Chiediamo a Daniele o Saverio
@Mte90 o @Sav22999

In linea generale, i tag di argomento sono nomi di un'interfaccia associati a diverse pagine rilevanti (per esempio, Node è associato a diverse pagine perché possiede più proprietà e metodi), o nomi di un tipo di tecnologia più ampia.
In linea generale, i tag di argomento sono nomi di un'interfaccia associati a diverse pagine rilevanti (per esempio, Node è associato a diverse pagine perché possiede molteplici proprietà e metodi), o nomi che indicano un complesso di tecnologie.

A parte il nbsp, non sono sicura che parli di un "complesso di tecnologie", ma piuttosto dei tag delle varie tecnologie base come HTML, JavaScript, CSS ecc., opposta ai nomi più specifici come l'interfaccia ecc.

Quando ti ho dato l'alternativa, ho pensato a WebComponents, Ajax ecc. e ho fatto ricadere Node in questa categoria, ovvero in un insieme di linguaggi standard (JavaScript, CSS, HTML) integrati e finalizzati a un determinato risultato.
In dettaglio Node è uno strumento, le altre che ho citato sono tecniche.
Sara, posto che il quadro che ti ho fatto sia corretto, sta a te scegliere quale sia la traduzione che meglio qualifica la questione.

[...]
Tolgo solo il nbsp e aggiungo una virgola:
Ad esempio, una pagina che parla di WebGL potrebbe essere associata ai tag Graphics e WebGL, mentre una pagina che tratta dell'elemento {{HTMLElement("canvas")}}

OK!

[...]
Ottimo, però necessita di una virgola dopo "deprecata":
< dd >"Deprecata". Quando la tecnologia o API trattata nella pagina è segnalata come "deprecata", è probabile che cada in disuso, anche se per il momento è ancora disponibile nelle versioni più recenti dei browser.

OK!

[...]
Forse nessuna delle due rende bene il discorso, cioè che se il motore del browser viene aggiornato, quella tecnologia ptrebbe diventare inutile oppure cambiare anch'essa.
Controproposta:
È inoltre soggetta alle modifiche nel motore del browser che la implementa (di solito si tratta di un singolo browser).

Bene, brava!

[...]
Ok, ma aggiungerei un paio di virgole per migliorare la leggibilità:
Prima di eseguire qualsiasi modifica, è buona norma contattare i collaboratori che hanno lavorato all'ultima bozza dell'articolo, al fine di evitare possibili conflitti di contenuto.

Certo, io con la punteggiatura sono assai maldestro. :D

[...]
Manca uno spazio tra "associato" e "almeno".
< dd> Di norma, ogni articolo dovrebbe essere associato < em >almeno</ em > a un tag per la {{anch("Categoria documento", "categoria")}} e a un tag per l'{{anch("Argomento", "argomento")}} del documento.

Ok!

[...]
La semplificherei ulteriormente:
È possibile aggiungere altri tag appropriati, ma assicurarsi che ogni pagina abbia i tag strettamente necessari costituisce già di per sé un enorme contributo.

Sì. Coprire il significato della frase con meno parole possibili è sempre un'ottima cosa secondo me. :)

Non so se si tratti di un copia-incolla finito male, ma qui hai introdotto un altro carattere. Per questi tipi di file è consigliabile lavorare su un editor di testo semplice, tipo il Blocco Note, in modo da non introdurre formattazione esterna.

Immaginavo. Cambierò modo di elaborare i testi.

Inoltre, questo mi sembra uno di quei casi in cui volgere la frase all'impersonale renda tutto meno leggibile e diretto, per questo avevo optato per la seconda persona. Comunque propongo:
< dd >Quando si trova un documento che non segue gli standard di questa pagina, è opportuno correggerlo.< br />

Sì, da qui in poi ti ho dato una versione baata sulle regole che avevamo discusso alcune settimane fa.
Che mi pare fossero:
1- uso impersonale
2- uso prima plurale ("quando troviamo un documento ...")
3- uso prima singolare ("quando trovi un documento ....")
evitare sempre la divisione tra autori e lettori ("noi abbiamo scritto ... affinchè voi leggiate")

Certamente l'impersonale è anche il meno diretto.

[...]
Aggiungerei una virgola dopo "Inoltre". Poi cercherei di rendere un po' più fluida la frase:
Inoltre, vanno corretti anche i tag che contengono errori di battitura, come ad esempio "Javascript" (il tag funziona comunque, poichè il sistema non coglie la differenza tra maiuscole e minuscole, ma anche la forma va curata.)

Bene.

[...]
Qui, la semplificherei:
< dd >Un articolo potrebbe già essere associato ad alcuni tag, ma non a tutti quelli necessari. In questo caso, occorre aggiungere i tag mancanti.

Benissimo.

Per renderla più fluida:

Quando si nota uno (o più) di questi tag, accedere a MDN e premere MODIFICA nell'angolo in alto a destra della finestra. Una volta che l'editor si sarà caricato, scorrere fino al riquadro dei tag, che si trova in fondo alla pagina.

Ottimo.

E questo è tutto!
Ci sono un paio di correzioni che ho leggermente modificato (per cui ti chiedo se ti vanno bene), ma la tua revisione meticolosa mi ha aiutato a migliorare l'articolo. Grazie e mille! 🙇

Bel lavoro!
Grazie a te.
🙇

[danielebarell]

Allora deve essersi aggiornato automaticamente, bene 😁
All'inizio non capivo a cosa serviva quell'id dopo l'header, penso che serva per generare l'indice dei contenuti in italiano.

Ah.
Che thriller!
;D

[Mte90]

WebExtensions è il nome del progetto e anche lo standard quindi non si traduce.

[kitsunenosaraT]

@danielebarell

Quando ti ho dato l'alternativa, ho pensato a WebComponents, Ajax ecc. e ho fatto ricadere Node in questa categoria, ovvero in un insieme di linguaggi standard (JavaScript, CSS, HTML) integrati e finalizzati a un determinato risultato.
In dettaglio Node è uno strumento, le altre che ho citato sono tecniche.
Sara, posto che il quadro che ti ho fatto sia corretto, sta a te scegliere quale sia la traduzione che meglio qualifica la questione.

Ragioniamo sul contesto della frase. Noi sappiamo quali sono i tag da cui pescare, perché vengono citati poco prima:

HTML, CSS, JavaScript , Document, DOM, API, Method, Property, Graphics, SVG, WebGL, Tools, Web, Element, Extensions e WebExtensions.

Definiresti ciascuno di questi termini qui sopra (a parte quelli classificabili come proprietà/metodi) "un complesso di tecnologie"? Se sì, lo lascio 😁 .

Sì, da qui in poi ti ho dato una versione baata sulle regole che avevamo discusso alcune settimane fa.
Che mi pare fossero:
1- uso impersonale
2- uso prima plurale ("quando troviamo un documento ...")
3- uso prima singolare ("quando trovi un documento ....")
evitare sempre la divisione tra autori e lettori ("noi abbiamo scritto ... affinchè voi leggiate")

Confermo le linee guida che hai scritto. Infatti, in genere è preferibile l'uso impersonale.
Tuttavia, in casi in cui l'impersonale genera frasi troppo arzigogolate e poco chiare, è concesso passare alla versione con pronomi personali (noi/tu). Questo mi sembrava uno di quei casi. Comunque non importa, perché siamo riusciti a cavarcela con l'impersonale.

Solo a scopo di chiarimento, quindi:

1. uso impersonale > l'alternativa preferibile
2. uso prima plurale ("quando troviamo un documento ...") > alternativa concessa quando l'impersonale non funziona o complica inutilmente la frase
3. uso seconda singolare ("quando trovi un documento ....") > alternativa concessa quando l'impersonale non funziona o complica inutilmente la frase

❌ divisione tra autori e lettori noi vs. voi ("noi abbiamo scritto ... affinché voi leggiate") > da evitare sempre

@Mte90

< li >{{Tag("Extensions")}} e {{Tag("WebExtensions")}} per la documentazione su WebExtension.</ li >
< li >{{Tag("Extensions")}},"estensioni" e {{Tag("WebExtensions")}}, "estensioni-Web" per la documentazione su WebExtension.< /li >

A parte il nbsp da togliere, ho un dubbio su WebExtestension. Forse dirò una scemenza, ma non è una sorta di nome proprio al pari di JavaScript ecc.? Ha senso mettere "estensioni-Web"? Da segnalare a @Mte90 o @Sav22999 per la revisione tecnica.

WebExtensions è il nome del progetto e anche lo standard quindi non si traduce.

Grazie per la risposta. Quindi, penso che possiamo eliderlo?

[Mte90]

Si direi che è meglio lasciare in inglese.
PS: ho cercato sul vocabolario il verbo elidere

[kitsunenosaraT]

Ho applicato le ultime modifiche di cui abbiamo discusso. Ecco il diff dalla revisione.

PS: ho cercato sul vocabolario il verbo elidere

Scusa, ogni tanto mi scappa un po' di gergo da correttori di bozze 😅

Grazie mille @danielebarell e @Mte90 🙇
Possiamo chiudere lo issue.