Help:Style (Italiano)

Articoli correlati
Help:Style/Formatting and punctuation
Help:Editing (Italiano)
Help:Reading
Le seguenti convenzioni di stile sono volte a rendere gli articoli ordinati, ben organizzati e visivamente coerenti tra loro. Tutti i collaboratori di ArchWiki sono incoraggiati a seguirle nel modificare le pagine.
Articoli
Titolo
Se l'argomento dell'articolo è comunemente conosciuto sia con il nome completo che con un acronimo, si preferisca usare il nome completo nel titolo dell'articolo. Evitare di includere nel titolo sia il nome completo che l'acronimo (ad esempio tra parentesi), ma piuttosto si crei un
redirect
per l'acronimo che reindirizzi alla pagina titolata con il nome completo.
Si veda anche
Help:Article naming guidelines
.
Struttura
Ordinare i vari elementi di un articolo come segue:
#Magic words
(opzionali)
#Categorie
#Interlink
#Template di stato dell'articolo
(opzionali)
#Articoli correlati
(opzionale)
#Prefazione o introduzione
Tabella dei contenuti (automatica)
Sezioni specifiche dell'articolo
Magic words
I behavior switch, e in generale tutte le
magic word
che modificano la maniera in cui è mostrato o si comporta un articolo senza aggiungere contenuto di per sé, devono essere aggiunte all'inizio del codice di ogni articolo.
Questa regola si applica in particolare a
{{DISPLAYTITLE:title}}
e
Template:Lowercase title
, che fa uso del primo.
Categorie
Ogni articolo dev'essere categorizzato in almeno una categoria tra quelle esistenti.
Un articolo può appartenere a più di una categoria, ammesso che nessuna di esse sia contenuta, direttamente o indirettamente, in una delle altre categorie presenti.
Le categorie devono essere specificate all'inizio del codice di ogni articolo, subito sotto le eventuali magic words.
Nota
Questo metodo differisce da altri progetti MediaWiki come Wikipedia, i quali includono le categorie in fondo agli articoli.
Non devono esserci righe vuote tra le categorie e la prima linea di testo (o gli interlink, se presenti), dato che introdurrebbero dello spazio bianco all'inizio dell'articolo.
Vedere anche
Recategorizing Pages
.
Interlink
Se l'articolo ha delle traduzioni nella wiki locale o in wiki di Arch Linux esterne, bisogna includere i relativi interlink subito sotto le categorie e sopra la prima linea di testo.
Notare che effettivamente appariranno nell'apposita colonna alla sinistra della pagina.
Non devono esserci righe vuote tra gli interlink e la prima linea di testo, dato che introdurrebbero dello spazio bianco all'inizio dell'articolo.
Quando si aggiungono o modificano interlink, bisogna fare attenzione a ripetere tale azione per tutte le traduzioni dell'articolo già esistenti.
Non aggiungere più di un interlink per ciascuna lingua in un articolo.
Non aggiungere interlink per la medesima lingua dell'articolo.
Gli interlink devono essere ordinati alfabeticamente secondo l'abbreviazione della lingua, non il nome locale, per cui ad esempio
[[fi:Title]]
viene prima di
[[fr:Title]]
nonostante "Suomi" verrebbe dopo "Français".
Vedere anche
Help:i18n
e
Aiuto:Interlink
.
Template di stato dell'articolo
I
template di stato dell'articolo
[
broken link
: invalid section]
possono essere inclusi subito sotto le categorie (o gli interlink, se presenti) e subito sopra l'introduzione (o gli articoli correlati, se presenti).
I template di stato dell'articolo possono anche essere usati all'interno delle sezioni, ove appropriato.
I template di stato dell'articolo devono essere sempre accompagnati da qualche parola di spiegazione nell'apposito spazio (vedere gli esempi nelle varie pagine dei template), eventualmente aprendo anche una sezione nella pagina di discussione.
Articoli correlati
Presenta una semplice lista di link ad articoli interni correlati.
Opzionalmente incluso subito sotto le categorie (o gli interlink, o i template di stato dell'articolo, se presenti).
Può essere composto solamente da
Template:Related articles start (Italiano)
,
Template:Related
,
Template:Related2
e
Template:Related articles end
. Leggere anche le linee guida nelle pagine di tali template.
Usare la
sezione "Altre risorse"
per una lista più completa e dettagliata che includa anche descrizioni e link interwiki o esterni.
Prefazione o introduzione
Descrive l'argomento dell'articolo.
Piuttosto che parafrasare o scrivere la propria (magari troppo soggettiva) descrizione di un particolare software, si può usare la descrizione dell'autore originale, che di solito può essere trovata sulla pagina home o about del sito ufficiale del progetto, se esistente. Un esempio è
MediaTomb
.
Inclusa subito sopra la prima sezione dell'articolo.
Non creare esplicitamente una sezione
==Introduzione==
o
==Prefazione==
: lasciare invece che appaia sopra il primo titolo di sezione. Quando c'è un numero sufficiente di sezioni nell'articolo, tra la prefazione e la prima sezione viene mostrata automaticamente la tabella dei contenuti.
Vedere anche
Writing Article Introductions
.
Titoli di sezione
I livelli dei titoli di sezione devono cominciare dal secondo (
==
), infatti il primo livello è riservato per i titoli degli articoli.
Evitare di saltare livelli quando si creano sottosezioni, perciò una sottosezione di un livello 2 avrà un titolo di livello 3 e così via.
I titoli di sezione usano le maiuscole come le normali frasi:
Una nuova sezione
e non
Una Nuova Sezione
.
Evitare di usare link nei titoli, dato che creano una discontinuità di stile ed inoltre non sono facilmente individuabili. In genere il testo del link si può trovare anche nel contenuto della sezione, altrimenti è possibile usare semplici frasi del tipo
Si veda anche
My new page
.
Per lo stesso motivo, si eviti anche di usare qualunque altro tipo di markup (html o wiki), inclusi i
#Template di formattazione del codice
. Leggere anche
Help:Style/Formatting and punctuation
.
Vedere anche
Effective Use of Headers
.
Linee vuote
Evitare di inserire più linee vuote consecutive per aumentare lo spazio bianco tra paragrafi o sezioni.
Si veda
Help:Editing#Line breaks
per maggiori informazioni.
Template di formattazione del codice
Usare
{{ic|codice}}
per rappresentare, nelle righe del testo, corte linee di codice, nomi di file, nomi di comandi, nomi di variabili e simili, ad esempio:
Eseguire
sh ./hello_world.sh
nella console.
Usare
{{bc|codice}}
per rappresentare in un blocco separato singole o multiple linee di codice (input o output della linea di comando e contenuto dei file), ad esempio:
$ sh ./hello_world.sh
Hello World
#!/bin/sh

# Demo
echo "Hello World"
Per corte linee di codice è anche ammesso iniziarle con uno spazio invece di usare
{{bc|code}}
(vedere
Help:Editing (Italiano)
).
Usare
{{hc|input|output}}
quando si ha bisogno di rappresentare sia l'input che l'output della linea di comando, ad esempio:
$ sh ./hello_world.sh
Hello World
Quando si ha bisogno di rappresentare il contenuto di un file e si teme che possa essere difficile per i lettori capire a quale file si riferisca tale codice, è anche possibile usare
{{hc|nomefile|contenuto}}
per mostrare il nome del file nell'intestazione, ad esempio:
~/hello_world.sh
#!/bin/sh

# Demo
echo "Hello World"
Cosnultare anche
Help:Template
per maggiori informazioni e per risolvere i problemi legati ad alcuni caratteri nei template, come
=
o
|
.
Testo da linea di comando
Usare
$
come prompt per comandi da utente normale; usare
#
come prompt per comandi da root.
Nota
Dato che
#
è usato anche per indicare i commenti nei file di testo, bisognerebbe sempre cercare di evitare equivoci, magari scrivendo esplicitamente di eseguire il comando o editare un file di testo.
La frase introduttiva per un comando dovrebbe in genere terminare con i
:
.
Preferire l'uso di
# command
invece di scrivere
$ sudo command
a meno che non sia strettamente necessario.
Non presupporre che l'utente usi
sudo
o un'altra applicazione per ottenere i permessi di root (ad esempio
gksu
,
kdesu
).
# sudo command
è ridondante e dev'essere evitato. L'unica eccezione si ha quando
sudo
è invocato con l'opzione
-u
: in questo caso si può usare il prompt delle altre linee nello stesso blocco di comandi, o ricadere su
$
.
Non aggiungere commenti nella stessa cornice di un comando (ad esempio
# pacman -S foo  #Installa il pacchetto foo
)
Evitare di scrivere linee di codice eccessivamente lunghe: usare dei metodi per spezzare le linee quando possibile.
Richieste di modifica di file
Non presupporre l'uso di specifici editor di testo (nano, vim, emacs, ...) nel richiedere modifiche a file di testo, a parte quando necessario.
Non usare comandi impliciti per richiedere modifiche a file di testo, a meno che sia strettamente necessario. Ad esempio al posto di
$ echo -e "clear\nreset" >> ~/.bash_logout
sarebbe meglio scrivere:
Aggiungere le seguenti linee a
~/.bash_logout
:
clear
reset
Tasti della tastiera
Il modo standard per rappresentare tasti della tastiera negli articoli è usare istanze di
Template:ic
.
I tasti delle lettere devono essere rappresentati in minuscolo:
a
. Per rappresentare lettere maiuscole, usare
Shift+a
invece che
Shift+A
o
A
.
La maniera corretta per rappresentare combinazioni di tasti è fare uso del simbolo
+
, senza spazi addizionali a destra o sinistra, in una singola istanza del template:
Ctrl+c
.
Ctrl + c
,
Ctrl
+
c
,
Ctrl-c
sono rappresentazioni non conformi, pertanto dovrebbero essere evitate.
I seguenti sono esempi standard per rappresentare alcuni tasti speciali:
Shift
(non
SHIFT
)
Ctrl
(non
CTRL
o
Control
)
Alt
(non
ALT
)
Super
(non
Windows
o
Mod
)
Invio
(non
Enter
,
ENTER
o
Return
)
Esc
(non
ESC
o
Escape
)
Spazio
(non
SPAZIO
)
Backspace
Tab
Ins
(non
INS
o
Inserisci
)
Canc
(non
CANC
o
Cancella
)
Stampa Schermo
Istruzioni per la gestione dei pacchetti
Pacchetti ufficiali
Si prega di evitare di usare esempi di comandi di pacman per dare istruzioni per l'installazione di pacchetti ufficiali: questo è stato stabilito sia per semplicità (ogni utente di Arch dovrebbe conoscere l'articolo su
pacman
a memoria) sia per evitare errori come
pacman -Sy package
o eventuali discussioni senza fine come la scelta tra
pacman -S package
e
pacman -Syu package
. A maggior ragione non si deve suggerire l'uso di frontend o wrapper per pacman per installare pacchetti ufficiali.
Si usi invece una frase simile alla seguente:
Installare
package
, disponibile nei
repository ufficiali
.
Oppure, se il nome dell'applicazione è diverso da quello del pacchetto:
MyApplication
può essere
installato
con il pacchetto
my-app-pkg
, disponibile nei
repository ufficiali
.
Le istruzioni per l'installazione di una lista di pacchetti potrebbero apparire come:
Installare
package1
,
package2
e
package3
, disponibili nei
repository ufficiali
.
È ovviamente consentito adattare la formulazione alle specifiche necessità di ciascun articolo.
I link ai pacchetti menzionati sono obbligatori e dovrebbero essere creati usando
Template:Pkg
, ad esempio
{{Pkg|package}}
.
Gli esempi riportati sopra fanno inoltre uso di un link implicito all'articolo di
pacman (Italiano)
(ad esempio
[[pacman (Italiano)|Installare]] ...
) ed uno a
Official repositories (Italiano)
(
[[Official Repositories (Italiano)|repository ufficiali]]
): il loro uso è raccomandato almeno per la prima occorrenza di una richiesta di installazione, specialmente negli articoli che hanno maggiore probabilità di essere consultati da principianti di Arch.
Se il pacchetto è ospitato in
core
,
extra
o
community
, si eviti di fare riferimento al nome del repository, facilitando così la manutenzione dato che non è infrequente che un pacchetto sia spostato in un repository differente. Se però il pacchetto è ospitato in un repository ufficiale che non è abilitato di default (
multilib
,
testing
ecc.), è preferibile menzionarlo, usando una frase simile alla seguente:
Installare
package
, disponibile nel repository ufficiale
multilib
.
Pacchetti dell'AUR
Si prega di evitare di usare esempi su come installare pacchetti dell'AUR, né con il metodo ufficiale né menzionando l'uso di un AUR helper: ogni utente che installa pacchetti non ufficiali deve aver letto l'articolo
Arch User Repository (Italiano)
ed essere cosciente di tutte le possibili conseguenze sul proprio sistema.
Si usi invece una frase simile alla seguente:
Installare
package
AUR
, disponibile nell'
Arch User Repository
.
È ovviamente consentito adattare la formulazione alle specifiche necessità di ciascun articolo, leggere la sezione sui
#Pacchetti ufficiali
per ulteriori esempi.
I link ai pacchetti menzionati sono obbligatori e dovrebbero essere creati usando
Template:AUR
, ad esempio
{{AUR|package}}
.
È sempre necessario specificare che il pacchetto non è ufficiale, anche linkando all'articolo
Arch User Repository (Italiano)
o a uno dei suoi redirect, per esempio
AUR (Italiano)
.
Repository non ufficiali
Nel suggerire l'uso di un repository non ufficiale per installare un pacchetto precompilato, non fornire istruzioni su come abilitare il repository, ma assicurarsi che tale repository sia incluso in
Unofficial user repositories
e quindi semplicemente creare un link ad esso. Si prega inoltre di evitare di usare esempi di comandi di
pacman
. Ad esempio:
Installare
package
dal repository
example
.
Se il pacchetto è disponibile anche in
AUR
:
Installare
package
AUR
dall'
Arch User Repository
o dal repository
example
.
Se il pacchetto è disponibile in
AUR
con un nome differente:
Installare
aurpackage
AUR
dall'
Arch User Repository
o
builtpackage
dal repository
example
.
È consentito adattare la formulazione alle specifiche necessità di ciascun articolo.
Il link a
Unofficial user repositories
è obbligatorio e deve puntare all'appropriata sezione del repository, ad esempio
[[Unofficial User Repositories#example|example]]
.
Operazioni con i moduli del kernel
Fornire esempi su come caricare, rimuovere, mettere in blacklist o eseguire una qualunque altra operazione di base con i moduli è una pratica deprecata: la formulazione standard prevede una lista dei moduli da aggiungere, eventualmente facendo notare dipendenze o conflitti con altri moduli, una descrizione delle azioni che devono essere eseguite e un link a
Kernel modules (Italiano)
.
Operazioni con i demoni
Fornire esempi su come abilitare (
enable
), avviare (
start
) o eseguire una qualunque altra operazione di base con i demoni è una pratica deprecata: la formulazione standard prevede una lista dei demoni da aggiungere, eventualmente facendo notare dipendenze o conflitti con altri demoni, una descrizione delle azioni che devono essere eseguite e un link a
systemd (Italiano)
.
Template Nota, Attenzione, Suggerimento
Template:Nota
dovrebbe essere usato per informazioni che in qualche modo divergono da ciò che il lettore si aspetterebbe più naturalmente di trovare in una parte di un articolo. Questa definizione include anche note che danno informazioni più dettagliate su un particolare e che altrimenti sarebbero considerate un po' estranee all'articolo. Un altro esempio si ha quando è necessario esporre un annuncio temporaneo come per esempio il cambio di nome di un pacchetto.
Una Nota può anche essere usata per sottolineare importanti informazioni che potrebbero essere facilmente trascurate da lettori non molto competenti sull'argomento.
Template:Attenzione
dovrebbe essere usato per descrivere procedure che potrebbero avere conseguenze negative come essere particolarmente difficili ad essere annullate o addirittura danneggiare il sistema. I template Attenzione dovrebbero generalmente indicare sia le varie possibili conseguenze negative, sia le condizioni a causa delle quali esse potrebbero verificarsi o al contrario essere evitate.
Template:Suggerimento
dovrebbe indicare un metodo o una procedura che potrebbe essere utile e portare beneficio per alcuni lettori, benché assolutamente non necessaria per completare l'operazione in esame, e pertanto tranquillamente trascurabile.
Quando due o più template Nota, Attenzione o Suggerimento devono apparire uno dopo l'altro in un certo punto di un articolo, è preferibile raggruppare i loro contenuti in una lista dentro un unico template, evitando di mettere i template uno sopra l'altro, a meno che essi non siano per niente correlati uno con l'altro. Ad esempio:
Suggerimento
Esempio di suggerimento #1.
Esempio di suggerimento #2.
Shell
Non presupporre che l'utente stia usando una shell in particolare (ad esempio Bash), tranne quando effettivamente necessario: cercare di essere il più possibile neutrale riguardo alle shell nello scrivere o editare gli articoli.
Metafora dell'ipertesto
Cercare di creare link reciproci tra il proprio articolo e quanti più altri possibile, utilizzando le varie parole-chiave nel testo.
Per i termini tecnici come
chiamata di sistema
che non sono trattati in nessun articolo dell'ArchWiki, creare un link alla relativa pagina di Wikipedia.
Nel creare link ad altri articoli della wiki, non usare gli URL completi, ma sfruttare la speciale sintassi per i link interni:
[[Articolo della wiki]]
. Questo metodo permetterà inoltre al software wiki di tenere traccia dei link interni, facilitando così la manutenzione.
Leggere
Help:Editing (Italiano)#Collegamenti
per informazioni più dettagliate e usi più avanzati della sintassi dei link interni.
Eccetto in rari casi, non si dovrebbe lasciare un articolo senza che questo fornisca link a qualche altro, né si dovrebbero creare pagine orfane, cioè articoli che non sono linkati da nessun'altra pagina.
Prima di scrivere una procedura specifica in un articolo, o descrivere qualcosa in particolare, controllare sempre che non esista già una pagina che tratta quella parte in dettaglio: in quel caso, creare un collegamento a quell'articolo invece di duplicare il suo contenuto.
Se la documentazione ufficiale per l'argomento del proprio articolo è ben scritta e aggiornata, preferire scrivere solamente adattamenti specifici per Arch, e linkare alla documentazione ufficiale per le informazioni generiche.
Non usare link interwiki per collegamenti alle pagine locali nella stessa lingua dell'articolo editato, infatti non sarebbero mostrati nelle pagine
Special:WhatLinksHere
. Ad esempio usare
[[:it:Main Page]]
in un articolo in Italiano è sbagliato, mentre
[[Main Page (Italiano)]]
è corretto.
Usare questo tipo di link tra lingue differenti è invece accettabile, dato che renderebbe più facile spostare gli articoli su una wiki esterna nel caso questa sia creata.
Infine, notare la differenza di questo tipo di link con gli
#Interlink
, i quali non hanno i
:
all'inizio.
Stile del codice
Nell'aggiungere comandi o script, usare uno stile di codice coerente per tutto l'articolo, eventualmente anche riferendosi ad altri articoli, specialmente se ce ne sono di correlati. Se disponibili, rispettare le regole di stile ufficiali o più diffuse per il linguaggio utilizzato.
Evitare funzionalità obsolete del linguaggio di programmazione/scripting che si sta usando: ad esempio usare la sintassi
$()
per la sostituzione dei comandi nella shell invece della sintassi
``
.
Versioni del kernel supportate
Non rimuovere note o adattamenti relativi a versioni del kernel maggiori o uguali alla versione minima tra l'attuale
linux-lts
e il kernel sulla più recente
immagine d'installazione
.
Sezioni "Trucchi e consigli"
Suggerimenti avanzati o esempi dell'utilizzo del software.
Il titolo standard è
Trucchi e consigli
.
I vari trucchi e consigli devono essere organizzati in sottosezioni.
Sezioni "Risoluzione di problemi"
Domande frequenti riguardo al software, o soluzioni a problemi comuni (confrontare con
#Sezioni "Problemi noti"
).
Il titolo standard è
Risoluzione di problemi
; usare l'Inglese
Troubleshooting
non è considerato conforme a queste linee-guida.
È anche possibile riportare soluzioni temporanee per bug conosciuti, ma in tal caso è fortemente preferibile fornire un link al bug report, e nel caso questo non esista ancora si consiglia di crearlo, in maniera da aumentare le possibilità che il bug venga corretto in maniera appropriata.
Linkare a un bug report porta grandi benefici sia ai lettori che a coloro che mantengono l'articolo:
Per i lettori, la Wiki non è un vicolo cieco: viene invece data loro la possibilità di trovare maggiori informazioni, più vicine alla fonte, che magari potrebbero non aver trovato con i propri metodi di ricerca.
Per i redattori della Wiki, viene resa più facile la manutenzione riducendo gli sforzi necessari per controllare se il bug riportato è stato risolto nel frattempo; questo può anche dare modo ad un lettore di aggiornare autonomamente l'articolo nel caso trovi informazioni più recenti nel bug report.
Sezioni "Problemi noti"
Elencano bug conosciuti o problemi di utilizzo per cui ancora non esiste una soluzione (confrontare con
#Sezioni "Risoluzione di problemi"
).
Il titolo standard è
Problemi noti
.
Se esiste un bug report per il problema, è fortemente preferibile includere un link ad esso; nel caso non esista, bisognerebbe provvedere a riportarlo, in maniera da aumentare le probabilità che il bug venga corretto.
Sezioni "Altre risorse"
Una lista di link a pagine di riferimento e fonti per informazioni addizionali.
Dovrebbe essere una lista in cui ogni voce comincia con
*
.
Il titolo standard è
Altre risorse
, è meglio evitare altri titoli simili come
Link esterni
,
Vedere anche
ecc.
Contenuti non ammessi
Si prega di non aggiungere la propria firma agli articoli, né di ringraziare o citare gli autori di un articolo: l'ArchWiki è un'opera di tutta la comunità, e la cronologia di ogni articolo è sufficiente per riconoscere i meriti di coloro che vi hanno contribuito.
Ciononostante, è buona norma riportare le fonti usate per scrivere un articolo: a questo scopo è possibile usare la sezione "Altre risorse".
Il caricamento dei file è disabilitato per gli utenti normali, e non è ammesso includere negli articoli le immagini esistenti. In alternativa è possibile includere collegamenti a immagini o gallery esterne, e se c'è bisogno di disegnare semplici schemi è possibile usare un editor ASCII come
Asciiflow
. Giustificazione:
Manutenzione: Arch è rolling release, e le immagini renderebbero molto più complicato l'aggiornamento degli articoli.
Necessità: Arch non sviluppa né mantiene alcuna applicazione con interfaccia grafica, per cui non è necessario mostrare alcuno screenshot.
Moderazione: il caricamento libero di immagini richiederebbe di spendere del tempo per rimuovere immagini sovradimensionate o inappropriate.
Accessibilità: supporto per connessioni lente, browser testuali, screen reader e simili.
Efficienza: le immagini sprecano banda della connessione dei server e spazio su disco.
Semplicità: gli articoli senza immagini appaiono più semplici e ordinati.
Registro linguistico
Gli articoli devono essere scritti mantenendo un linguaggio formale, professionale e conciso.
Ricordarsi di non dare risposta solo al
come
, ma anche al
perché
. Le spiegazioni devono sempre cercare di insegnare qualcosa invece di fornire solamente istruzioni.
Evitare di rivolgersi al lettore in seconda persona ("installa/installate questo programma", "apri/aprite il tuo/vostro file manager" etc.). In alternativa è consigliato usare forme infinite ("installare questo programma", "aprire il proprio file manager"), impersonali ("si installi questo programma", "si apra il proprio file manager") o passive ("dev'essere installato questo programma", "dev'essere aperto il proprio file manager").
Evitare
abbreviazioni
non necessarie: ad esempio invece di "repo," "distro," e "config," preferire "repository," "distribuzione," e "configurazione."
Scrivere obiettivamente: non includere commenti personali negli articoli, usare le pagine di discussione per tale scopo. In generale, non scrivere in prima persona.
Suggerimento
Gli utenti impegnati nella traduzione di articoli in Italiano potrebbero essere interessati a leggere anche
ArchWiki Translation Team (Italiano)#Linee guida
.
Pagine di discussione
Aggiungere le nuove discussioni in fondo alle pagine di discussione, con un titolo di sezione appropriato. A questo scopo è anche possibile usare la targhetta
+
sul bordo superiore di ogni pagina di discussione.
Indentare le proprie risposte utilizzando sequenze di
:
all'inizio di ogni linea di testo.
Non editare i propri post se qualcuno ha già replicato, altrimenti si farà perdere il filo della discussione rendendo più difficile per gli altri dare ulteriori risposte. È solamente consentito marcare con una linea parole o frasi (usando i tag


), ma la relativa spiegazione dev'essere fornita con un normale post.
Terminare sempre i propri interventi con la firma dell'utente (
~~~~
).
Le pagine di discussione non possono essere categorizzate.
Bisognerebbe ricordarsi di marcare con una linea i titoli delle discussioni terminate, usando i tag


.
Le discussioni terminate saranno cancellate qualche tempo dopo essere state marcate.
Leggere anche
Help:Editing (Italiano)#Pagine di discussione
.
Pagine delle categorie
Ogni categoria dev'essere a sua volta adeguatamente categorizzata sotto almeno una categoria-madre, escluse le categorie di base.
Le categorie di base sono
Category:DeveloperWiki
, [[:Category:Languages] e
Category:Sandbox
.
Una categoria può essere categorizzata sotto più di una categoria-madre, ammesso che nessuna di queste sia a sua volta categoria-madre (o in generale "antenato") di una delle altre.
Evitare relazioni circolari: due categorie non possono essere "antenati" reciproci.
Non categorizzare una categoria sotto sé stessa (categoria auto-categorizzata).
Le categorie devono essere incluse in cima al testo sorgente di ogni pagina di categoria.
Le categorie non possono fare redirezioni.
Pagine di redirezione
Le pagine di redirezione devono contenere solamente il codice per la redirezione, niente di più.
Redirigere solamente agli articoli interni; non usare redirezioni con link interwiki.
Pagine dei template
Leggere
Help:Template
.
Pagine degli utenti
Le pagine nel namespace
User
non possono essere categorizzate.
Le pagine nel namespace
User
possono essere linkate solamente da altre pagine nei namespace
User
o
talk
, a meno che sia stata fornita autorizzazione dagli Amministratori per fare diversamente.
Regole generali
Oggetto
Le modifiche fatte ogni giorno agli articoli sono coraggiosamente controllate da pochi appassionati
volontari
, che è necessario aiutare ricordandosi di riempire sempre il campo dell'"Oggetto" con una spiegazione per ogni edit.
Se la modifica è
minore
, ad esempio correzioni ortografiche o grammaticali o la semplice riformulazione di una frase, una breve descrizione della propria modifica è perfettamente sufficiente.
Se si sta effettuando una modifica rilevante, ad esempio l'aggiunta, spostamento, modifica o rimozione di contenuti, oltre a fare un riassunto della modifica è necessario spiegare il
motivo
per cui è stata fatta, magari fornendo un link alla relativa discussione sulla wiki o ad un thread sul forum, se esistente.
Non è necessario fornire spiegazioni per le modifiche alle pagine di discussione, infatti il
motivo
dovrebbe essere comunque evidente.
Quando però si rimuovono discussioni che erano già state chiuse, una piccola giustificazione è richiesta (ad esempio "discussione chiusa", "risolto" ecc.) ed includere anche il titolo della discussione medesima potrebbe aiutare a ritrovarla nella cronologia nel caso ci sia bisogno di riaprirla in futuro.
Suggerimento
Dare un'occhiata agli oggetti nelle
Ultime modifiche
per farsi un'idea di cosa scrivere nell'oggetto della propria modifica, pur tenendo conto del fatto che purtroppo non tutti gli utenti rispettano queste linee guida.
Nell'effettuare modifiche rilevanti ad uno o più articoli, è bene cercare di dividere il proprio lavoro in più modifiche separate, basandosi sui vari passi logici necessari per completare l'operazione.
Specialmente quando si spostano intere sezioni (sia nello stesso articolo che tra articoli differenti), è bene evitare di modificarne il contenuto nel medesimo edit, altrimenti si renderà più difficile controllarne il conseguente diff.
Tag HTML
L'uso di tag HTML è generalmente da evitare: meglio preferire l'uso del markup della wiki o i template quando possibile: a tal proposito leggere
Help:Editing (Italiano)
e gli articoli correlati.
Quando si è tentati di usare
<pre>codice</pre>
, usare sempre
{{bc|codice}}
al suo posto. Invece di usare
<tt>codice</tt>
o
<code>codice</code>
, usare sempre
{{ic|codice}}
.
Evitare in particolare i commenti HTML (
<!-- commento -->
): è molto probabile che una nota aggiunta in un commento HTML possa essere mostrata esplicitamente nella pagina di discussione dell'articolo.
Valutare se aggiungere un
template di stato dell'articolo
[
broken link
: invalid section]
appropriato al posto del commento.
Usare
<br>
solo quando necessario: per cominciare un nuovo paragrafo o spezzare una linea basta inserire una linea vuota subito sotto.
Le più comuni eccezioni a questa regola si hanno quando è necessario spezzare una linea in una voce di una lista, e non è possibile usare una sotto-voce, oppure dentro un template, e non è possibile usare una lista.