Typographical Guidelines/it: Difference between revisions

From KDE Wiki Sandbox
(Created page with "Il codice dovrebbe essere presentato utilizzando testo a larghezza fissa, di solito in un riquadro, come mostrato sotto. Il testo inserito verrà visualizzato su uno sfondo giall...")
(Updating to match new version of source page)
 
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<languages />
<languages />


''Ci sono pagine a parte che spiegano la [[PageLayout|Struttura della pagina]] e la [[Toolbox|sintassi]] con codici di esempio.''
''Ci sono pagine a parte che spiegano la [[PageLayout|struttura della pagina]] e la [[Toolbox|sintassi]] con codici di esempio.''


{{Remember|3=Importante|1=Aderire a queste linee guida tipografiche ti garantisce che la tua documentazione potrà essere esportata in modo facile ed accurato per scopi di traduzione. Alcune linee guida possono non essere applicabili alle altre lingue (non inglese). Questo dovrebbe essere segnalato nella pagine specifiche delle lingue collegate a [[Special:myLanguage/Translation_Workflow|Modalità di traduzione]]. Se non esiste una pagina di questo tipo per la tua lingua, aggiungine una e segna lì le linee guida.}}
{{Remember/it|2=Importante|1=Aderire a queste linee guida tipografiche ti garantisce che la tua documentazione potrà essere esportata in modo facile ed accurato per scopi di traduzione. Alcune linee guida possono non essere applicabili alle altre lingue (non inglese). Questo dovrebbe essere segnalato nella pagine specifiche delle lingue collegate a [[Special:myLanguage/Translation_Workflow|Modalità di traduzione]]. Se non esiste una pagina di questo tipo per la tua lingua, aggiungine una e segna lì le linee guida.}}


==Testo grassetto==
==Testo grassetto==
Line 41: Line 41:
==Testo a larghezza fissa==
==Testo a larghezza fissa==


Il codice dovrebbe essere presentato utilizzando testo a larghezza fissa, di solito in un riquadro, come mostrato sotto. Il testo inserito verrà visualizzato su uno sfondo giallo pallido. Per il testo del risultato il colore di sfondo sarà un viola grigiastro.   
Il codice dovrebbe essere presentato utilizzando testo a larghezza fissa, di solito in un riquadro, come mostrato sotto. Il testo inserito verrà visualizzato su uno sfondo giallo pallido. Per il testo del risultato il colore di sfondo sarà grigio.   


* Code, whether single lines or blocks, use templates to ensure consistency
* Per ottenere un risultato coerente utilizza i modelli sia per le righe di codice singole che multiple.


* Utilizza il modello Input così: {{Input|1=<nowiki>{{Input|1=<nowiki>
* Utilizza il modello Input così: {{Input|1=<nowiki>{{Input|1=<nowiki>
Line 56: Line 56:




* Output works the same way: {{Output|1=<nowiki>{{Output|1=<nowiki>terminal output
* Output funziona allo stesso modo: {{Output|1=<nowiki>{{Output|1=<nowiki>anche il risultato nel terminale
is also shown as code,  
viene mostrato come codice,  
but on a grey background&lt;/nowiki>}}</nowiki>}} which displays as {{Output|1=<nowiki>terminal output
ma su sfondo grigio&lt;/nowiki>}}</nowiki>}} che viene visualizzato {{Output|1=<nowiki>anche il risultato nel terminale
is also shown as code,  
viene mostrato come codice,  
but on a grey background</nowiki>}}
ma su sfondo grigio</nowiki>}}


{{Note|1=Note the use of <code><nowiki>1=<nowiki> some text &lt;/nowiki></nowiki></code> to avoid situations that break the display format}}
<div class="mw-translate-fuzzy">
{{Note/it|1=Utilizza <code><nowiki>1=<nowiki> un po' di testo &lt;/nowiki></nowiki></code> per evitare situazioni che possono compromettere il formato di visualizzazione.}}
</div>


* Starting an Input or Output template on a new line will break the display format if it is within lists. Simply continue on the same line if you need to correct this.
* L'inserimento di un modello Input o Output in una nuova riga compromette il formato di visualizzazione se è all'interno di elenchi. Semplicemente continua sulla stessa riga se hai bisogno di correggere questo problema.


* You can also combine input/output areas with [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi GeSHi syntaxhiglighting]. An input area like this {{Input|1=<nowiki>{{Input|<syntaxhighlight lang="php" line>
* Puoi anche combinare le aree input/output con [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi l'evidenziazione della sintassi GeSHi]. Un'area input come questa {{Input|1=<nowiki>{{Input|<syntaxhighlight lang="php" line>
# Initialise common code
# Initialise common code
$preIP = dirname( __FILE__ );
$preIP = dirname( __FILE__ );
require_once( "$preIP/includes/WebStart.php" );
require_once( "$preIP/includes/WebStart.php" );
</syntaxhighlight>}}</nowiki>
</syntaxhighlight>}}</nowiki>
}} will result in {{Input|<syntaxhighlight lang="php" line>
}} darà come risultato {{Input|<syntaxhighlight lang="php" line>
# Initialise common code
# Initialise common code
$preIP = dirname( __FILE__ );
$preIP = dirname( __FILE__ );
Line 77: Line 79:
</syntaxhighlight>}}
</syntaxhighlight>}}


* Single code words can be kept in-line by using {{Input|1=<nowiki><code></code></nowiki>}}  It will <code>display</code> like this.
<div class="mw-translate-fuzzy">
* Le singole parole di codice possono essere tenute nella riga utilizzando {{Input|1=<nowiki><code></code></nowiki>}}  Verrà <code>visualizzato</code> così.
</div>


* {{Input|1=<nowiki>&lt;tt> &lt;/tt></nowiki>}} is useful for displaying filenames and paths.  This looks like this: <tt> a/path/to/here </tt>
<div class="mw-translate-fuzzy">
* I percorsi e i nomi dei file dovrebbero utilizzare il modello Path in questo modo: <nowiki>{{Path|1=percorso/del/file}}</nowiki> per ottenere un risultato simile a questo {{Path|1=percorso/del/file}}.
</div>


==Block Quotes==
{{Warning|1=In-line code markup should be short! It looks strange - and ugly - if a string of code words is split between lines. And remember: even if it looks good in your browser, not everyone uses the same screen size! And even if your text looks good on all screen sizes translations may still suffer. It is best to use the Input template for code unless it is really short.}}
 
{{Note|1=Please avoid using shell commands or other code words as verbs. This does not translate well. Always treat code words as proper names.}}
 
==Blocco di citazione==


The tags <nowiki><blockquote></nowiki> and <nowiki></blockquote></nowiki> should be used when quoting other works or other pages.  This produces a proportional italic font, with some padding.
The tags <nowiki><blockquote></nowiki> and <nowiki></blockquote></nowiki> should be used when quoting other works or other pages.  This produces a proportional italic font, with some padding.
Line 94: Line 104:


Bold text should be avoided in the text within these templates.  Italic text for emphasis may still be used - use sparingly for maximum effect.
Bold text should be avoided in the text within these templates.  Italic text for emphasis may still be used - use sparingly for maximum effect.
 
<span id="Lists"></span>
==Elenchi==
==Elenchi==


You can have various kinds of lists in your pages &mdash; bulleted, numbered or itemized. Find details on the [[Special:myLanguage/Toolbox#Bulleted Lists|Toolbox]] page.
You can have various kinds of lists in your pages &mdash; bulleted, numbered or itemized. Find details on the [[Special:myLanguage/Toolbox#Bulleted Lists|Toolbox]] page.
 
<span id="Keeping things together"></span>
==Keeping things together==
==Keeping things together==


After your text is written some markup is automatically added by the translation system. This means that whenever it sees a blank line, it starts a new unit. When your text is presented to translators, they typically see it one unit at a time, so it is important not to leave a blank lines in the middle of something that should be treated as a unit. Normally an entire paragraph should be kept in a single unit; and under no circumstance should a sentence be split between units!
After your text is written some markup is automatically added by the translation system. This means that whenever it sees a blank line, it starts a new unit. When your text is presented to translators, they typically see it one unit at a time, so it is important not to leave a blank lines in the middle of something that should be treated as a unit. Normally an entire paragraph should be kept in a single unit; and under no circumstance should a sentence be split between units!


If you need a linebreak in the middle of a section, the preferred way to achieve this is without breaking units is to use <nowiki><br /></nowiki> at the end of the line where you want to break to occur (not on a new line). If you need space between the lines add <nowiki><br /><br /></nowiki>.
If you need a linebreak in the middle of a section, the preferred way to achieve this without breaking units is to use <nowiki><br /></nowiki> at the end of the line where you want to break to occur (not on a new line). If you need space between the lines add <nowiki><br /><br /></nowiki>.
 
<span id="Unbalanced brackets"></span>
==Unbalanced brackets==
==Unbalanced brackets==


Line 116: Line 126:


==Special Tags==
==Special Tags==
=== Key presses and menu selections ===


* <nowiki> <keycap></nowiki> and <nowiki> </keycap> </nowiki> denote (keyboard) key names e.g. <keycap>Enter</keycap>
* <nowiki> <keycap></nowiki> and <nowiki> </keycap> </nowiki> denote (keyboard) key names e.g. <keycap>Enter</keycap>
Line 121: Line 133:
* Sequences of menu choices should use <nowiki> <menuchoice> </nowiki>and <nowiki> </menuchoice> </nowiki> for example <menuchoice> View -> Message List -> Aggregation -> Standard Mailing List </menuchoice>
* Sequences of menu choices should use <nowiki> <menuchoice> </nowiki>and <nowiki> </menuchoice> </nowiki> for example <menuchoice> View -> Message List -> Aggregation -> Standard Mailing List </menuchoice>
* In general, if the user needs to choose an element, even if it is not in a menu, the <nowiki><menuchoice></menuchoiсe></nowiki> markup should be used.
* In general, if the user needs to choose an element, even if it is not in a menu, the <nowiki><menuchoice></menuchoiсe></nowiki> markup should be used.
* If you are contributing to a manual page, you should always use the markup describes above. For other pages, though, there is a template to enter menu selections: <nowiki>{{Menu|Top|sub|...}}</nowiki>. Fx, <nowiki>{{Menu | View | Message List | Aggregation | Standard Mailing List}}</nowiki> yields {{Menu | View | Message List | Aggregation | Standard Mailing List}}
* If you want to use the <nowiki><menuchoice></nowiki> but use &rarr; in stead of ->, you write <code>& rarr;</code> (without a space between '&' and r!) as in <nowiki><menuchoice> View</menuchoice> & rarr; <menuchoice>Message List</menuchoice></nowiki> which yields <menuchoice> View</menuchoice> &rarr; <menuchoice>Message List</menuchoice>. (Note, that the &rarr; character has to be outside of the menuchoice tags to be shown properly
=== Files and file paths ===
Traditionally, file names and paths have been marked up between <nowiki><tt>...</tt></nowiki> tags.
{{Input|1=<nowiki><tt>~/.kde/share</tt></nowiki>}}
yields
{{output|1=<tt>~/.kde/share</tt>}}
There is now also a template for this, which should be preferred in new content for ordinary UserBase pages (but not for manual pages, please!):
{{Input|1=<nowiki>{{Path | ~/.kde/share }}</nowiki>}}
yields
{{Output|1={{Path | ~/.kde/share }} }}


== The Problematic Pipe ==
== The Problematic Pipe ==
Line 133: Line 165:
==Translatable Content==
==Translatable Content==


Everything that is translatable is contained within <nowiki><translate> and </translate></nowiki> tags.  In most cases any images should be contained within the translatable section, as it is sometimes necessary to use localised versions of the images to explain a point.  The rule of thumb is "If in doubt, include it!".
Everything that is translatable is contained within &lt;translate> and &lt;/translate> tags.  In most cases any images should be contained within the translatable section, as it is sometimes necessary to use localised versions of the images to explain a point.  The rule of thumb is "If in doubt, include it!".


[[Category:Contribuire/it]]
[[Category:Contribuire/it]]

Latest revision as of 17:38, 31 May 2021

Ci sono pagine a parte che spiegano la struttura della pagina e la sintassi con codici di esempio.

Importante
Aderire a queste linee guida tipografiche ti garantisce che la tua documentazione potrà essere esportata in modo facile ed accurato per scopi di traduzione. Alcune linee guida possono non essere applicabili alle altre lingue (non inglese). Questo dovrebbe essere segnalato nella pagine specifiche delle lingue collegate a Modalità di traduzione. Se non esiste una pagina di questo tipo per la tua lingua, aggiungine una e segna lì le linee guida.


Testo grassetto

Utilizza il testo grassetto per evidenziare

  • titoli delle finestre,
  • etichette comuni non configurabili dall'utente,
  • didascalie delle icone,
  • nomi dei programmi.

Per esempio:

  • evidenziazione di una selezione di testo che sarà copiato in Klipper.

Testo corsivo

Utilizza testo corsivo per enfatizzare

  • parole o frasi come nella normale scrittura,
  • titoli quando fanno riferimento ad altri lavori,
  • la prima occorrenza di una parola insolita.

Alcuni esempi:

  • A questo punto salva il tuo lavoro.
  • I dettagli sono disponibili in Samba 3 tramite esempi...
  • I manuali KDE sono in formato Docbook.
Suggerimento
I programmi sono avviati dagli utenti, i componenti sono utilizzati dai programmi.


Testo in grassetto e corsivo combinati

Utilizza questa combinazione per testo variabile o sostituibile.

Alcuni esempi:

  • per connetterti al tuo server remoto digita ssh nomeutente@dominio.nome in Konsole.
  • Nelle distribuzioni basate su rpm il comando rpm -q nomepacchetto darà come risultato pacchetto-versione-rilascio.

Testo a larghezza fissa

Il codice dovrebbe essere presentato utilizzando testo a larghezza fissa, di solito in un riquadro, come mostrato sotto. Il testo inserito verrà visualizzato su uno sfondo giallo pallido. Per il testo del risultato il colore di sfondo sarà grigio.

  • Per ottenere un risultato coerente utilizza i modelli sia per le righe di codice singole che multiple.
  • Utilizza il modello Input così:
    {{Input|1=<nowiki>
    qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
    rm -r ~/.kde/share/apps/nepomuk
    rm -r ~/.kde4/share/apps/nepomuk
    nepomukserver</nowiki>}}
    Verrà visualizzato in questo modo:
    qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
    rm -r ~/.kde/share/apps/nepomuk
    rm -r ~/.kde4/share/apps/nepomuk
    nepomukserver


  • Output funziona allo stesso modo:
    {{Output|1=<nowiki>anche il risultato nel terminale 
    viene mostrato come codice, 
    ma su sfondo grigio</nowiki>}}
    che viene visualizzato
    anche il risultato nel terminale 
    viene mostrato come codice, 
    ma su sfondo grigio
Nota
Utilizza 1=<nowiki> un po' di testo </nowiki> per evitare situazioni che possono compromettere il formato di visualizzazione.


  • L'inserimento di un modello Input o Output in una nuova riga compromette il formato di visualizzazione se è all'interno di elenchi. Semplicemente continua sulla stessa riga se hai bisogno di correggere questo problema.
  • Puoi anche combinare le aree input/output con l'evidenziazione della sintassi GeSHi. Un'area input come questa
    {{Input|<syntaxhighlight lang="php" line>
    # Initialise common code
    $preIP = dirname( __FILE__ );
    require_once( "$preIP/includes/WebStart.php" );
    </syntaxhighlight>}}
    darà come risultato
    # Initialise common code
    $preIP = dirname( __FILE__ );
    require_once( "$preIP/includes/WebStart.php" );
    
  • Le singole parole di codice possono essere tenute nella riga utilizzando
    <code></code>
    Verrà visualizzato così.
  • I percorsi e i nomi dei file dovrebbero utilizzare il modello Path in questo modo: {{Path|1=percorso/del/file}} per ottenere un risultato simile a questo percorso/del/file.
Warning
In-line code markup should be short! It looks strange - and ugly - if a string of code words is split between lines. And remember: even if it looks good in your browser, not everyone uses the same screen size! And even if your text looks good on all screen sizes translations may still suffer. It is best to use the Input template for code unless it is really short.


Note
Please avoid using shell commands or other code words as verbs. This does not translate well. Always treat code words as proper names.


Blocco di citazione

The tags <blockquote> and </blockquote> should be used when quoting other works or other pages. This produces a proportional italic font, with some padding.

Here is an example of the display that you get by using the blockquote tags.

Text in Section Headers

Even though the criteria above may be met, do not use Bold text in section headers or in links.

Text in Information, Note, Tip or Warning Templates

Bold text should be avoided in the text within these templates. Italic text for emphasis may still be used - use sparingly for maximum effect.

Elenchi

You can have various kinds of lists in your pages — bulleted, numbered or itemized. Find details on the Toolbox page.

Keeping things together

After your text is written some markup is automatically added by the translation system. This means that whenever it sees a blank line, it starts a new unit. When your text is presented to translators, they typically see it one unit at a time, so it is important not to leave a blank lines in the middle of something that should be treated as a unit. Normally an entire paragraph should be kept in a single unit; and under no circumstance should a sentence be split between units!

If you need a linebreak in the middle of a section, the preferred way to achieve this without breaking units is to use <br /> at the end of the line where you want to break to occur (not on a new line). If you need space between the lines add <br /><br />.

Unbalanced brackets

The translation system marks any translated unit as incompletely translated if it contains any kind of unbalanced brackets. If you need to have unbalanced brackets in your text, please add a balancing bracket in a comment tag, like this:

<!-- }} -->{{ A line 

Another line}}<!-- {{ -->

This goes for all kinds of brackets, even ordinary parentheses. (Of course it is normally better to avoid blank lines within a mark up unit - see Keeping things together.)

Special Tags

Key presses and menu selections

  • <keycap> and </keycap> denote (keyboard) key names e.g. Enter
  • <keycap></keycap> can also be used around groups of keys to be used concurrently, e.g. Ctrl + Alt + F1 to launch a virtual terminal. (Note that "(space)+(space)" is used to link keys to be pressed concurrently).
  • Sequences of menu choices should use <menuchoice> and </menuchoice> for example View -> Message List -> Aggregation -> Standard Mailing List
  • In general, if the user needs to choose an element, even if it is not in a menu, the <menuchoice></menuchoiсe> markup should be used.
  • If you are contributing to a manual page, you should always use the markup describes above. For other pages, though, there is a template to enter menu selections: {{Menu|Top|sub|...}}. Fx, {{Menu | View | Message List | Aggregation | Standard Mailing List}} yields View Message List Aggregation Standard Mailing List
  • If you want to use the <menuchoice> but use → in stead of ->, you write & rarr; (without a space between '&' and r!) as in <menuchoice> View</menuchoice> & rarr; <menuchoice>Message List</menuchoice> which yields ViewMessage List. (Note, that the → character has to be outside of the menuchoice tags to be shown properly

Files and file paths

Traditionally, file names and paths have been marked up between <tt>...</tt> tags.

<tt>~/.kde/share</tt>

yields

~/.kde/share

There is now also a template for this, which should be preferred in new content for ordinary UserBase pages (but not for manual pages, please!):

{{Path | ~/.kde/share }}

yields

 ~/.kde/share 

The Problematic Pipe

In some situations the pipe symbol can't be used - for instance when adding parameters into a template. In any such case, please use {{!}} which will display as a pipe symbol. For example, if you want to display a command line containing the pipe character using the {{Input|...}} template, the simplest way to do it is this: {{Input|1=cmd1 {{!}} cmd2}} which displays

cmd1 | cmd2


If you just write {{Input|cmd1 | cmd2}} you get instead

cmd1 

the problem being, that cmd2 is seen as a second parameter to the template, which in this case is not used.

In many cases, you can also enclose the text containing the pipe character between <nowiki>... </nowiki> tags, like this {{Input|1=<nowiki>cmd1 | cmd2</nowiki>}}, which also displays

cmd1 | cmd2

Translatable Content

Everything that is translatable is contained within <translate> and </translate> tags. In most cases any images should be contained within the translatable section, as it is sometimes necessary to use localised versions of the images to explain a point. The rule of thumb is "If in doubt, include it!".