Resumo

Obrigado por fazer parte do Projeto de Documentação do FreeBSD. A sua contribuição é extremamente valiosa.

Esta cartilha cobre os detalhes necessários para começar a contribuir com o Projeto de Documentação do FreeBSD, incluindo ferramentas, software e a filosofia por trás do Projeto de Documentação.

Este documento é um trabalho em andamento. Correções e adições são sempre bem vindas.


Índice

Lista de Figuras

Lista de Tabelas

Prefácio

Prompts do Shell

Esta tabela mostra o prompt padrão do sistema e o prompt do super usuário. Os exemplos usam estes prompts para indicar com qual usuário o exemplo foi executado.

Usuário Prompt

Usuário normal

%

root

#

Convenções Tipográficas

Esta tabela descreve as convenções tipográficas utilizadas neste livro.

Propósito Exemplos

Nome dos comandos.

Utilize ls -l para listar todos os arquivos.

Nome dos arquivos.

Edite .login.

Saída de um programa na tela do computador

You have mail.

O que o usuário digita, quando contrastado com a saída do programa na tela do computador.

% date +"The time is %H:%M"
The time is 09:18

Referência a uma página de manual.

Utilize su(1) para assumir outro nome de usuário.

Nome de usuário e de grupos de usuários.

Apenas o root pode fazer isso.

Ênfase.

O usuário deve fazer isso.

Texto que o usuário deve substituir com o texto real.

Para buscar por uma palavra chave nas páginas de manual, digite man -k keyword

Variáveis de ambiente.

$HOME aponta para o diretório inicial do usuário.

Notas, Dicas, Informações Importantes, Avisos e Exemplos

Notas, avisos e exemplos aparecem ao longo do texto.

Notas são representadas desta forma, e contêm informações para as quais se deve ficar atento, pois podem afetar o que o usuário faz.

Dicas são representadas desta forma, e contêm informações úteis para o usuário, como as que mostram uma maneira mais fácil de fazer alguma coisa.

Informações importantes são representadas desta forma. Normalmente elas destacam passos extras que o usuário pode precisar realizar.

Avisos são representados deste modo, e contêm informações de alerta sobre possíveis danos se não seguir as instruções. Estes danos podem ser físicos, para o equipamento ou para o usuário, ou podem ser não-físicos, tal como a deleção inadvertida de arquivos importantes.

Exemplo 1. Uma Amostra de Exemplo

Os exemplos são representados deste modo, e normalmente contêm exemplos passo a passo, ou mostram os resultados de uma determinada ação.

Agradecimentos

Meu muito obrigado a Sue Blake, Patrick Durusau, Jon Hamilton, Peter Flynn, e Christopher Maden, por terem gasto parte do seu tempo lendo os primeiros rascunhos deste documento e por terem oferecido muitos comentários e críticas construtivas para este trabalho.

Capítulo 1. Visão geral

Seja bem vindo ao Projeto de Documentação do FreeBSD.(FDP). Documentação de boa qualidade é muito importante para o sucesso do FreeBSD, e nós valorizamos muito suas contribuições.

Este documento descreve como o FDP é organizado, como escrever e como submeter documentos, e como utilizar de forma efetiva as ferramentas que estão disponíveis.

Todos são bem vindos para se juntar ao FDP. A vontade de contribuir é o único requisito de adesão.

Este primer mostra como:

  • Identificar quais partes do FreeBSD são mantidas pelo FDP.

  • Instalar as ferramentas e arquivos de documentação necessários.

  • Realizar alterações na documentação.

  • Enviar de volta alterações para revisão e inclusão na documentação do FreeBSD.

1.1. Introdução

Algumas etapas preparatórias devem ser seguidas antes de editar a documentação do FreeBSD. Primeiro, se registre na lista de discussão do projeto de documentação do FreeBSD. Alguns membros do time também interagem no IRC, canal #bsddocs na rede EFnet. Estas pessoas podem ajudar com questões e problemas envolvendo documentação.

  1. Instale esses pacotes. O meta-port docproj instala todos os aplicativos necessários para editar e compilar a documentação do FreeBSD.

    # pkg install docproj python3
  2. Obtenha uma cópia local da árvore de documentação do FreeBSD em ~/doc (ver A Área de Trabalho).

    % git clone https://git.FreeBSD.org/doc.git ~/doc
  3. Edite os arquivos de documentação que precisam de alterações. Se um arquivo precisar de grandes mudanças, consulte a lista de discussão para obter informações.

    Revise a saída e edite o arquivo para corrigir os problemas informados e, em seguida, execute novamente o comando para verificar os problemas restantes. Repita até que todos os erros sejam resolvidos.

  4. Sempre realize testes de compilação antes de submeter algo. Execute make no diretório de nível superior da documentação e assim será gerado a documentação no formato HTML.

    % make
  5. Quando as alterações estiverem completas e testadas, gere um "arquivo diff":

    % cd ~/doc
    % git diff > bsdinstall.diff.txt

    Dê ao arquivo diff um nome. No exemplo acima, foram feitas alterações na parte bsdinstall do Handbook.

  6. Submeta o arquivo diff file pela web para o sistema de Relatórios de Problema. Se estiver usando o formulário web, insira um Sumário com [patch] descrição curta do problema. Selecione o Componente Documentation. No campo de Descrição, insira uma breve descrição das alterações e quaisquer detalhes importantes sobre elas. Use o botão Add an attachment para anexar o arquivo diff. Finalmente, pressione o botão Submit Bug para enviar seu diff para o sistema de relatório de problemas.

1.2. Conjunto de Documentação do FreeBSD

O FDP é responsável por quatro categorias de documentação do FreeBSD.

  • Handbook: O Handbook almeja ser um compreensivo recurso de referência online para os usuários do FreeBSD.

  • FAQ: O FAQ utiliza um formato curto de pergunta e resposta para abordar dúvidas que são frequentemente realizadas nas listas de discussão e fóruns dedicados ao FreeBSD. Este formato não permite respostas longas e detalhadas.

  • Páginas de Manual: As páginas de manual do sistema de língua inglesa geralmente não são escritas pelo FDP, pois fazem parte do sistema base. Contudo, o FDP pode reformular partes das páginas de manual existentes para torná-las mais claras ou para corrigir imprecisões.

  • Web site: Esta é a presença principal do FreeBSD na web, visite https://www.FreeBSD.org/ e muitos mirrors ao redor do mundo. O site é tipicamente o primeiro contato de um usuário novo com o FreeBSD.

As equipes de tradução são responsáveis por traduzir o manual e o site para diferentes idiomas. As páginas do manual não são traduzidas no momento.

Código fonte do site do FreeBSD, Handbook, e FAQ estão disponíveis no repositório de documentação em https://cgit.freebsd.org/doc/.

Código fonte das páginas de manual estão disponíveis em um repositório diferente localizado em https://cgit.freebsd.org/src/.

As mensagens de commit de documentação podem ser visualizadas com git log. As mensagens de commit também são arquivadas em link:{git-doc-all}.

Endereço web para ambos os repositórios disponíveis em https://cgit.freebsd.org/doc/ e https://cgit.freebsd.org/src/.

Muitas pessoas tem escrito tutoriais e artigos how-to sobre FreeBSD. Alguns são armazenados como parte dos arquivos FDP. Em outros casos, o autor decidiu manter a documentação separada. O FDP esforça-se para fornecer links para o máximo possível dessas documentações externas.

Capítulo 2. Ferramentas

Várias ferramentas são utilizadas para gerenciar a documentação do FreeBSD e renderizá-la para diferentes formatos. Algumas dessas ferramentas são necessárias e devem ser instaladas antes de trabalhar com os exemplos nos capítulos a seguir. Algumas são opcionais, adicionando recursos ou tornando a tarefa de criar documentação mais simples.

2.1. Ferramentas Obrigatórias

Instale o docproj e python3 como mostrado no capítulo de introdução da coleção de Ports. Estes pacotes são necessários para trabalhar com a documentação do FreeBSD. Informações adicionais específicas de alguns componentes serão informadas abaixo.

2.2. Ferramentas Opcionais

Essas ferramentas não são necessárias, mas podem facilitar o trabalho na documentação ou adicionar recursos.

2.2.1. Software

Vim (editors/vim)

Um editor popular para trabalhar com AsciiDoctor.

Emacs (editors/emacs)

Ambos editores incluem um modo especial para editar documentos. Esse modo inclui comandos para reduzir a quantidade de digitação necessária e ajudar a reduzir a possibilidade de erros.

Capítulo 3. A Área de Trabalho

A área de trabalho é uma cópia da árvore de documentação do repositório do FreeBSD baixada no computador local. As alterações são feitas na cópia de trabalho local, testadas e enviadas como patches para serem submetidas no repositório principal.

Uma cópia completa da árvore de documentação pode ocupar 700 megabytes de espaço em disco. Tenha um gigabyte de espaço total para ter sobra para arquivos temporários e versões de teste dos diversos formatos de saída.

O Git é utilizado para gerenciar os arquivos de documentação do FreeBSD. Ele é obtido pela instalação do pacote Git:

# pkg install git-lite

3.1. Documentação e Páginas de Manual

A documentação do FreeBSD não é formada apenas por livros e artigos. Páginas de manual para todos os comandos e arquivos de configuração também fazem parte da documentação e fazem parte do território do FDP. Dois repositórios estão envolvidos: doc para os livros e artigos, e src para o sistema operacional e páginas de manual. Para editar páginas de manual, o repositório src deve ser obtido separadamente.

Repositórios podem conter várias versões de documentação e código-fonte. Novas modificações quase sempre são feitas apenas para a versão mais recente, chamada main.

3.2. Escolhendo um Diretório

A documentação do FreeBSD é tradicionalmente armazenada em /usr/doc/, e o código fonte do sistema com páginas de manual em /usr/src/. Essas árvores são realocáveis e os usuários podem armazenar as cópias de trabalho em outros locais para evitar interferir nas informações existentes nos diretórios principais. Os exemplos a seguir utilizam ~/doc e ~/src, ambos subdiretórios do diretório pessoal do usuário.

3.3. Baixando uma Cópia

O processo de download de um repositório é chamado de clone e é feito com um git clone. Este exemplo faz a clonagem de uma cópia da versão mais recente (main) do repositório de documentação principal:

% git clone https://git.FreeBSD.org/doc.git ~/doc

O checkout do código-fonte para trabalhar nas páginas de manual é muito semelhante:

% git clone https://git.FreeBSD.org/src.git ~/src

3.4. Atualizando

Os documentos e arquivos no repositório do FreeBSD mudam diariamente. As pessoas modificam arquivos e submetem alterações com frequência. Mesmo após um checkout inicial, já haverá alterações entre a cópia de trabalho local e o repositório principal do FreeBSD. Para atualizar a versão local com as mudanças que foram feitas no repositório principal, execute git pull no diretório que contém a cópia de trabalho local:

% cd ~/doc
% git pull --ff-only

Adquira o hábito protetor de usar git pull antes de editar arquivos de documentos. Alguém pode ter editado aquele arquivo recentemente, e a cópia de trabalho local não incluirá as últimas mudanças até que tenha sido atualizada. Editar a versão mais recente de um arquivo é muito mais fácil do que tentar combinar um arquivo local editado mais antigo com a versão mais recente do repositório.

3.5. Revertendo Alterações

De vez em quando acontece que algumas mudanças não eram necessárias, ou o escritor só quer começar novamente. Arquivos podem ser "resetados" para sua forma anterior com git restore. Por exemplo, para apagar as alterações feitas no _index.adoc e redefini-las para o formato sem modificação:

% git restore _index.adoc

3.6. Criando um Diff

Após finalizar as alterações em um arquivo ou grupo de arquivos, as diferenças entre a cópia de trabalho local e a versão no repositório do FreeBSD devem ser coletadas em um único arquivo para ser submetido. Estes arquivos diff são produzidos redirecionando a saída de git diff para um arquivo:

% cd ~/doc
% git diff > doc-fix-spelling.diff

Dê ao arquivo um nome significativo que identifique o conteúdo. O exemplo acima é para correção ortográfica em toda a árvore de documentação.

Se o arquivo diff for enviado com a interface web "Submit a FreeBSD problem report", adicione uma extensão .txt para que o formulário web identifique que o conteúdo do arquivo é texto plano.

Tenha cuidado: git diff inclui todas as alterações feitas no diretório atual e em quaisquer subdiretórios. Se houver arquivos na cópia de trabalho com edições que ainda não estão prontas para serem enviadas, forneça uma lista apenas dos arquivos a serem incluídos:

% cd ~/doc
% git diff disks/_index.adoc printers/_index.adoc > disks-printers.diff

3.7. Referências Git

Estes exemplos demonstram um uso muito básico do Git. Mais detalhes estão disponíveis no Git Book e na Documentação do Git.

Capítulo 4. Estrutura de Diretórios da Documentação

Arquivos e diretórios no repositório doc/ seguem uma estrutura destinada a:

  1. Facilitar a conversão do documento para outros formatos.

  2. Promover a consistência entre as diferentes organizações de documentação, e assim facilitar a alternância entre diferentes documentos.

  3. Facilitar a decisão de onde a nova documentação deve ser colocada.

Além disso, o repositório de documentação deve acomodar documentos em vários idiomas e codificações diferentes. É importante que a estrutura do repositório de documentação não imponha quaisquer padrões particulares ou preferências culturais.

4.1. O Nível Superior, doc/

Existem dois tipos de diretório em doc/, documentation e website, ambos compartilham a mesma estrutura.

Diretório Uso

documentation

Contém todos os artigos e livros em formato AsciiDoc. Contém subdiretórios para categorizar ainda mais as informações por idiomas.

shared

Contém arquivos que não são específicos para as várias traduções da documentação. Contém subdiretórios para categorizar ainda mais as informações por idiomas e três arquivos para armazenar as informações dos autores, lançamentos e espelhos. Este diretório é compartilhado entre documentation e o website.

website

Contém o site do FreeBSD no formato AsciiDoc. Contém subdiretórios para categorizar ainda mais as informações por idiomas.

4.2. Os Diretórios

Esses diretórios contêm a documentação e o website. A documentação está organizada em subdiretórios abaixo deste nível, seguindo o estrutura de diretórios Hugo.

Diretório Uso

archetypes

Contém templates para criar novos artigos, livros e páginas web. Para mais informações, veja aqui.

config

Contém os arquivos de configuração do Hugo. Um arquivo principal e um arquivo por idioma. Para mais informações, veja aqui.

content

Contém os livros, artigos e páginas web. Existe um diretório para cada tradução disponível da documentação, por exemplo en e` zh-tw`.

data

Contem dados personalizados para compilar o site no formato TOML. Este diretório é usado para armazenar os eventos, notícias, imprensa, etc. Para mais informações, veja aqui.

static

Contem ativos estáticos. Imagens, avisos de segurança, pgpkeys, etc. Para mais informações, veja aqui.

themes

Contém os modelos na forma de arquivos .html que especificam a aparência do site. Para mais informações, veja aqui.

tools

Contém ferramentas usadas para aprimorar a construção da documentação. Por exemplo, para gerar o índice dos livros, etc.

beastie.png

Esta imagem não precisa de introdução ;)

LICENSE

Licença da documentação e site. Licença BSD de 2 cláusulas.

Makefile

O Makefile que executa o processo de compilação da documentação e do website.

4.3. Informação Específica de Documentação

Esta seção contém informações específicas sobre documentos gerenciados pelo FDP.

4.4. Os Livros: books/

Os livros são escritos em AsciiDoc.

Os livros são organizados como um livro AsciiDoc. Os livros estão divididos em partes, cada uma das quais contém vários capítulos. Os capítulos são subdivididos em seções (=) e subseções (==, ===) e assim por diante.

4.4.1. Organização Física

Existem vários arquivos e diretórios no diretório books, todos com a mesma estrutura.

4.4.1.1. _index.adoc

O _index.adoc define algumas variáveis AsciiDoc que afetam como o código AsciiDoc é convertido para outros formatos e lista o Índice, a Tabela de Exemplos, a Tabela de Figuras, a Tabela de Tabelas e a seção de resumo.

4.4.1.2. book.adoc

O _index.adoc define algumas variáveis AsciiDoc que afetam como o código AsciiDoc é convertido para outros formatos e lista o Índice, a Tabela de Exemplos, a Tabela de Figuras, a Tabela de Tabelas, a seção de resumo e todos os capítulos. Este arquivo é usado para gerar o PDF com asciidoctor-pdf e para gerar o livro em uma página html.

4.4.1.3. part*.adoc

Os arquivos part*.adoc armazenam uma breve introdução de uma parte do livro.

4.4.1.4. toc*.adoc

Os arquivos toc*.adoc armazenam o Índice, Índice de figuras, Índice de Exemplos, Índice de Tabelas e diferentes Índices para cada parte. Todos esses arquivos são gerados por scripts Python. Por favor, não os edite.

4.4.1.5. chapters-order.adoc

O arquivo chapters-order.adoc armazena a ordem dos capítulos do livro.

Por favor, tome cuidado com este arquivo. Ele é usado pelos scripts Python para gerar o Índice dos livros. Em caso de edição deste arquivo, primeiro entre em contato com a equipe de Engenharia de Documentação.

4.4.1.6. directory/_index.adoc

Cada capítulo do Handbook é armazenado em um arquivo chamado _index.adoc em um diretório separado dos outros capítulos.

Por exemplo, este é um exemplo do cabeçalho de um capítulo:

---
title: Chapter 8. Configuring the FreeBSD Kernel
part: Part II. Common Tasks
prev: books/handbook/multimedia
next: books/handbook/printing
---

[[kernelconfig]]
\= Configuring the FreeBSD Kernel (1)
...
1 O caractere no final da linha não deve ser usado em um documento de produção. Este caractere está aqui para ignorar este título nos arquivos toc-*.adoc gerados automaticamente.

Quando a versão HTML5 do Handbook é produzida, será gerado o kernelconfig/index.html.

Uma breve olhada mostrará que existem muitos diretórios com arquivos _index.adoc individuais, incluindo basics/_index.adoc, introduction/_index.adoc, e printing/_index.xml.

Não nomeie capítulos ou diretórios com a ordenação do Handbook. Essa ordenação pode mudar conforme o conteúdo do Handbook é reorganizado. A reorganização deve ser realizada sem renomear arquivos, a menos que capítulos inteiros sejam promovidos ou rebaixados dentro da hierarquia.

4.5. Os Artigos: articles/

Os artigos são escritos em AsciiDoc.

Os artigos são organizados como um artigo do AsciiDoc. Os artigos são divididos em seções (=) e subseções (==, ===) e assim por diante.

4.5.1. Organização Física

Existe um arquivo _index.adoc por artigo.

4.5.1.1. _index.adoc

O arquivo _index.adoc contém todas as variáveis AsciiDoc e o conteúdo.

Por exemplo, este é um exemplo de um artigo, a estrutura é muito semelhante a um capítulo de livro:

---
title: Why you should use a BSD style license for your Open Source Project
authors:
  - author: Bruce Montague
    email: brucem@alumni.cse.ucsc.edu
releaseinfo: "$FreeBSD$"
trademarks: ["freebsd", "intel", "general"]
---

\= Why you should use a BSD style license for your Open Source Project (1)
:doctype: article
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:source-highlighter: rouge
:experimental:

'''

toc::[]

[[intro]]
\== Introduction (1)
1 O caractere no final da linha não deve ser usado em um documento de produção. Este caractere está aqui para ignorar este título nos arquivos toc-*.adoc gerados automaticamente.

Capítulo 5. Processo de Compilação da Documentação do FreeBSD

Este capítulo cobre a organização do processo de compilação da documentação e como o make(1) é usado para controlá-lo.

5.1. Renderizando AsciiDoc

Diferentes tipos de formato podem ser gerados a partir de um único arquivo AsciiDoc.

Formatos Tipo de Arquivo Descrição

html

HTML

Um capítulo de artigo or livro.

pdf

PDF

Portable Document Format.

epub

EPUB

Electronic Publication. ePub file format.

5.1.1. Renderizando em html

Para renderizar a documentação e o site em html, use um dos seguintes exemplos.

Exemplo 2. Compile a documentação
% cd ~/doc/documentation
% make
Exemplo 3. Compile o website
% cd ~/doc/website
% make
Exemplo 4. Compile todo o projeto de documentação
% cd ~/doc
% make -j2

Exemplos avançados de compilação são apresentados abaixo:

Exemplo 5. Compile a documentação com mensagens de debug e no modo verboso
% cd ~/doc/documentation
% make HUGO_ARGS="--verbose --debug --path-warnings"
Exemplo 6. Compile e sirva o conteúdo com o servidor web interno do Hugo
% cd ~/doc/documentation
% make run

Este servidor web roda em localhost, porta`1313` por padrão.

Para servir o conteúdo com o servidor web interno do Hugo em um endereço IP específico:

% make run BIND=192.168.15.10

Um hostname também pode ser definido como url base para o servidor web interno do Hugo:

% make run BIND=192.168.15.10 HOSTNAME=example.com

5.1.2. Renderizando em pdf

Para gerar um documento no formato pdf use este comando. Neste exemplo, o Handbook em Inglês será usado. Para exportar o documento corretamente, todas as extensões devem ser passadas usando o argumento -r.

Exemplo 7. Compilar um documento em pdf
% cd ~/doc/documentation
% asciidoctor-pdf \
  -r ./shared/lib/man-macro.rb \
  -r ./shared/lib/git-macro.rb \
  -r ./shared/lib/packages-macro.rb \
  -r ./shared/lib/inter-document-references-macro.rb \
  -r ./shared/lib/sectnumoffset-treeprocessor.rb \
  --doctype=book \
  -a skip-front-matter \
  -a pdf-theme=./themes/default-pdf-theme.yml \
  -o /tmp/handbook.pdf \
  content/en/books/handbook/book.adoc

5.2. O Conjunto de Ferramentas de Compilação da Documentação do FreeBSD

Essas são as ferramentas usadas para compilar e instalar a documentação FDP.

  • A principal ferramenta de compilação é o make(1), especificamente o Berkeley Make.

  • Python é usado para gerar o Índice e outras Tabelas relacionadas.

  • Hugo

  • AsciiDoctor

  • Git

5.3. Compreendendo o Makefile na Árvore de Documentação

Existem três arquivos Makefile para compilar em parte ou todo o projeto de documentação.

  • O Makefile no diretório documentation irá compilar apenas a documentação.

  • O Makefile no diretório website irá compilar apenas a website.

  • O Makefile na raíz irá compilar a documentação e o site.

O Makefile dos subdiretórios também suportam make run para servir o conteúdo compilado com o servidor web interno do Hugo. Este servidor web roda na porta 1313 por padrão.

5.3.1. Makefile da Documentação

Este Makefile suporta o seguinte:

# Generate the FreeBSD documentation
#
# Copyright (c) 2020-2021, The FreeBSD Documentation Project
# Copyright (c) 2020-2021, Sergio Carlavilla <carlavilla@FreeBSD.org>
#
# Targets intended for use on the command line
#
# all (default)	-	generate the books TOC and compile all the documentation
# run	-			serves the built documentation site for local browsing
#
# The run target uses hugo's built-in webserver to make the documentation site
# available for local browsing.  The documentation should have been built prior
# to attempting to use the `run` target.  By default, hugo will start its
# webserver on port 1313.

MAINTAINER=carlavilla@FreeBSD.org (1)

PYTHON_CMD =	/usr/local/bin/python3 (2)
HUGO_CMD =	/usr/local/bin/hugo (3)
LANGUAGES =	en,es,pt_BR,de,ja,zh_CN,zh_TW,ru,el,hu,it,mn,nl,pl,fr (4)
RUBYLIB =	../shared/lib
.export	RUBYLIB

.ifndef HOSTNAME
.HOST+=localhost
.else
.HOST+=$(HOSTNAME)
.endif

.ORDER: all run(5)

.ORDER: starting-message generate-books-toc
.ORDER: starting-message build
.ORDER: generate-books-toc build

all: starting-message generate-books-toc build (6)

starting-message: .PHONY (7)
	@echo ---------------------------------------------------------------
	@echo                   Building the documentation
	@echo ---------------------------------------------------------------

generate-books-toc: .PHONY (8)
	${PYTHON_CMD} ./tools/books-toc-parts-creator.py -l ${LANGUAGES}
	${PYTHON_CMD} ./tools/books-toc-creator.py -l ${LANGUAGES}
	${PYTHON_CMD} ./tools/books-toc-figures-creator.py -l ${LANGUAGES}
	${PYTHON_CMD} ./tools/books-toc-tables-creator.py -l ${LANGUAGES}
	${PYTHON_CMD} ./tools/books-toc-examples-creator.py -l ${LANGUAGES}

run: .PHONY (9)
	${HUGO_CMD} server -D --baseURL="http://$(.HOST):1313"

build: .PHONY (10)
	${HUGO_CMD} --minify
1 A flag MAINTAINER especifica quem é o mantenedor deste Makefile.
2 A flag PYTHON_CMD especifica a localização do binário Python.
3 A flag HUGO_CMD especifica a localização do binário Hugo.
4 A flag LANGUAGES especifica em quais idiomas o índice deve ser gerado.
5 As diretivas .ORDER são usadas para garantir que vários makes possam ser executados sem problemas.
6 O target all gera os índices dos livros ("TOCs"), compila a documentação e coloca o resultado em ~/doc/documentation/public.
7 starting-message mostra uma mensagem no console para mostrar ao usuário que o processo está em execução.
8 generate-books-toc chama os scripts para gerar os TOCs dos livros.
9 run executa o servidor web hugo na porta 1313, ou uma porta livre aleatória se esta já estiver em uso.
10 build compila a documentação e coloca o resultado em ~/doc/documentation/public.

5.3.2. Makefile do Website

Este é o Makefile:

# Generate the FreeBSD website
#
# Copyright (c) 2020-2021, The FreeBSD Documentation Project
# Copyright (c) 2020-2021, Sergio Carlavilla <carlavilla@FreeBSD.org>
#
# Targets intended for use on the command line
#
# all (default)	-	generate the releases.toml and compile all the website
# run	-			serves the built documentation site for local browsing
#
# The run target uses hugo's built-in webserver to make the documentation site
# available for local browsing.  The documentation should have been built prior
# to attempting to use the `run` target.  By default, hugo will start its
# webserver on port 1313.

MAINTAINER=carlavilla@FreeBSD.org (1)

PYTHON_CMD =	/usr/local/bin/python3 (2)
HUGO_CMD =	/usr/local/bin/hugo (3)
RUBYLIB =	../shared/lib
.export	RUBYLIB

.ifndef HOSTNAME
.HOST+=localhost
.else
.HOST+=$(HOSTNAME)
.endif

.ORDER: all run(4)

.ORDER: starting-message generate-releases
.ORDER: starting-message build
.ORDER: generate-releases build

all: starting-message generate-releases run (5)

starting-message: .PHONY (6)
	@echo ---------------------------------------------------------------
	@echo                   Building the website
	@echo ---------------------------------------------------------------

generate-releases: .PHONY (7)
	${PYTHON_CMD} ./tools/releases-toml.py -p ./shared/releases.adoc

run: .PHONY (8)
	${HUGO_CMD} server -D --baseURL="http://$(.HOST):1313"

build: .PHONY (9)
	${HUGO_CMD}
1 A flag MAINTAINER especifica quem é o mantenedor deste Makefile.
2 A flag PYTHON_CMD especifica a localização do binário Python.
3 A flag HUGO_CMD especifica a localização do binário Hugo.
4 As diretivas .ORDER são usadas para garantir que vários makes possam ser executados sem problemas.
5 O target all gera os índices dos livros ("TOCs"), compila a documentação e coloca o resultado em ~/doc/website/public.
6 starting-message mostra uma mensagem no console para mostrar ao usuário que o processo está em execução.
7 generate-releases chama o script usado para converter as variáveis AsciiDoc em variáveis TOML. Com esta conversão, as variáveis de releases podem ser utilizadas no AsciiDoc e nos templates personalizados do Hugo.
8 run executa o servidor web hugo na porta 1313, ou uma porta livre aleatória se esta já estiver em uso.
9 build compila o website e coloca o resultado em ~/doc/website/public.

Capítulo 6. Primer AsciiDoctor

A maioria das documentações do FDP é escrita em AsciiDoc. Este capítulo explica o que isso significa, como ler e entender o código da documentação e as técnicas usadas. Para obter uma referência completa dos recursos do AsciiDoctor, consulte a documentação do Asciidoctor. Alguns exemplos usados neste capítulo foram retirados da Referência rápida de sintaxe AsciiDoc.

6.1. Visão geral

Nos primórdios da era computacional, o texto eletrônico era simples. Havia poucos conjuntos de caracteres como ASCII ou EBCDIC, e apenas isso. Texto era texto, e o que você lia era realmente o texto que você tinha. Sem frescuras, sem formatação, sem inteligência.

Inevitavelmente, isso não era suficiente. Quando o texto está em um formato utilizável por computadores, espera-se que eles possam usá-lo e manipulá-lo de maneira inteligente. Os autores querem indicar que certas frases devem ser enfatizadas, adicionadas a um glossário ou transformadas em hiperlinks. Os nomes dos arquivos podem ser apresentados em uma fonte de estilo "typewriter" para exibição na tela do computador, ou como "itálico" quando impressos, ou qualquer outra opção dentre uma infinidade de opções para apresentação.

Esperava-se que a Inteligência Artificial (IA) facilitasse isso. O computador leria o documento e identificaria automaticamente frases-chave, nomes de arquivos, textos que o leitor deveria digitar, exemplos e outros tipos. Infelizmente, na vida real não foi dessa forma, e os computadores ainda precisam de assistência antes que possam processar o texto de maneira significativa.

Mais precisamente, eles precisam de ajuda para identificar o que é o quê. Considere este texto:

Para remover /tmp/foo, utilize o rm(1).

% rm /tmp/foo

É fácil identificar quais partes são nomes de arquivos, quais são comandos a serem digitados, quais partes são referências a páginas de manual e assim por diante. Mas o computador que processa o documento não consegue. Para isso, precisamos utilizar markup.

O exemplo anterior é representado neste documento da seguinte forma:

Para remover [.filename]#/tmp/foo#, utilize o man:rm[1].

[source,shell]
----
% rm /tmp/foo
----

6.2. Cabeçalhos

AsciiDoctor suporta seis níveis de cabeçalhos. Se o tipo de documento for artigo, apenas um nível 0 (=) pode ser usado. Se o tipo de documento for livro, pode haver vários títulos de nível 0 (=).

Estes são exemplos de cabeçalhos em um artigo.

 = Título do Documento (Nível 0)

 == Título da Seção de Nível 1

 === Título da Seção de Nível 2

 ==== Título da Seção de Nível 3

 ===== Título da Seção de Nível 4

 ====== Título da Seção de Nível 5

 == Outro Título de Seção de Nível 1

Os níveis de seção não podem ser ignorados ao aninhar seções.

A sintaxe a seguir não está correta.

 = Título do Documento

 == Nível 2

 ==== Nível 4

6.3. Parágrafos

Os parágrafos não precisam de marcação especial no AsciiDoc. Um parágrafo é definido por uma ou mais linhas consecutivas de texto. Para criar um novo parágrafo, deixe uma linha em branco.

Por exemplo, este é um título com dois parágrafos.

 = Este é o título

 Este é o primeiro parágrafo.
 Este também é o primeiro parágrafo.

 E este é o segundo parágrafo.

6.4. Listas

AsciiDoctor suporta alguns tipos de listas, as mais comuns são ordenadas e` não ordenadas`. Para obter mais informações sobre listas, consulte o Referência Rápida da Sintaxe AsciiDoc.

6.4.1. Listas ordenadas

Para criar uma lista ordenada, use o caractere ..

Por exemplo, esta é uma lista ordenada.

. Primeiro item
. Segundo item
.. Sub-segundo item
. Terceiro item

E isso seria processado como.

  1. Primeiro item

  2. Segundo item

    1. Sub-segundo item

  3. Terceiro item

6.4.2. Listas não ordenadas

Para criar uma lista não ordenada, use o caractere *.

Por exemplo, esta é uma lista não ordenada.

* Primeiro item
* Segundo item
** Sub-segundo item
* Terceiro item

E isso seria processado como.

  • Primeiro item

  • Segundo item

    • Sub-segundo item

  • Terceiro item

Para apontar para outro site, a macro link deve ser usada.

link:https://www.FreeBSD.org[FreeBSD]

Como a documentação do AsciiDoctor descreve, a macro link não é necessária quando o link começa com um esquema de URL como`https`. No entanto, é uma boa prática fazer o uso assim para garantir que o AsciiDoctor renderize o link corretamente, especialmente em idiomas não latinos como o Japonês.

Para apontar para outro livro ou artigo, as variáveis AsciiDoctor devem ser usadas. Por exemplo, se estamos no artigo cups e queremos apontar para`ipsec-must`, esses passos devem ser usados.

  1. Inclua o arquivo urls.adoc da pasta ~/doc/shared.

    include::shared/{lang}/urls.adoc[]
  2. Em seguida, crie um link usando a variável AsciiDoctor para o artigo ipsec-must.

    link:{ipsec-must}[Artigo IPSec-Must]

    E isso seria processado como.

6.6. Conclusão

Esta é a conclusão deste primer do AsciiDoctor. Por razões de espaço e complexidade, várias assuntos não foram abordadas em profundidade (ou completamente).

Capítulo 7. Rosetta Stone

7.1. Comparação entre Docbook e AsciiDoc

Esta rosetta stone tenta mostrar as diferenças entre Docbook e AsciiDoc.

Tabela 1. Comparação entre Docbook e AsciiDoc
Language Feature Docbook AsciiDoc

Bold

<strong>bold</strong>

*bold*

Italic

<emphasis>Italic</emphasis>

_Italic_

Monospace

<literal>Monospace</literal>

`Monospace`

Paragraph

<para>This is a paragraph</para>

This is a paragraph

Keycap

<keycap>F11</keycap>

kbd:[F11]

Links

<link xlink:href="https://www.freebsd.org/where/">Download FreeBSD</link>
link:https://www.freebsd.org/where/[Download FreeBSD]

Sections

  <sect1 xml:id="id">
    <title>Section 1</title>
  </sect1>
 [[id]]
 = Section 1

Unordered list

<itemizedlist>
  <listitem>
    <para>When to build a custom kernel.</para>
  </listitem>

  <listitem>
    <para>How to take a hardware inventory.</para>
  </listitem>
</itemizedlist>
* When to build a custom kernel.
* How to take a hardware inventory.

Ordered list

<orderedlist>
  <listitem>
    <para>One</para>
  </listitem>
  <listitem>
    <para>Two</para>
  </listitem>
  <listitem>
    <para>Three</para>
  </listitem>
  <listitem>
    <para>Four</para>
  </listitem>
</orderedlist>
. One
. Two
. Three
. Four

Variable list

<variablelist>
  <varlistentry>
    <term>amd64</term>
    <listitem>
      <para>This is the most common desktop...</para>
    </listitem>
  </varlistentry>
</variablelist>
amd64::
This is the most common desktop...

Source code

<screen>
  &prompt.root; <userinput>mkdir -p /var/spool/lpd/lp</userinput>
</screen>
[source,shell]
----
# mkdir -p /var/spool/lpd/lp
----

Literal block

<programlisting>
include GENERIC
ident MYKERNEL

options         IPFIREWALL
options         DUMMYNET
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         IPDIVERT
</programlisting>
....
include GENERIC
ident MYKERNEL

options         IPFIREWALL
options         DUMMYNET
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         IPDIVERT
....

Images

<figure xml:id="bsdinstall-newboot-loader-menu">
  <title>FreeBSD Boot Loader Menu</title>

  <mediaobject>
    <imageobject>
      <imagedata fileref="bsdinstall/bsdinstall-newboot-loader-menu"/>
    </imageobject>
    <textobject>
      </literallayout>ASCII art replacement is no longer supported.</literallayout>
    </textobject>
    <textobject>
      <phrase>The FreeBSD loader menu, with options 1-6 to boot
          multi-user, boot single user, escape to loader prompt, reboot,
          select a kernel to load, and select boot options</phrase>
    </textobject>
  </mediaobject>
</figure>
[[bsdinstall-newboot-loader-menu]]
.FreeBSD Boot Loader Menu
image::bsdinstall/bsdinstall-newboot-loader-menu[The FreeBSD loader menu, with options 1-6 to boot multi-user, boot single user, escape to loader prompt, reboot, select a kernel to load, and select boot options]

Includes

n/a

include::chapter.adoc[]

Tables

<table xml:id="partition-schemes" frame="none" rowsep="1" pgwide="1">
  <title>Partitioning Schemes</title>

  <tgroup cols="2" align="left">
    <thead>
      <row>
        <entry align="left">Abbreviation</entry>
        <entry align="left">Description</entry>
      </row>
    </thead>

    <tbody>
      <row>
        <entry>APM</entry>
        <entry>Apple Partition Map, used by PowerPC(R).</entry>
      </row>
    </tbody>
  </tgroup>
</table>
[[partition-schemes]]
.Partitioning Schemes
[cols="1,1", frame="none", options="header"]
|===
| Abbreviation
| Description

|APM
|Apple Partition Map, used by PowerPC(R).

|===

Admonitions

<tip>
  <para>This is a tip</para>
</tip>
[TIP]
====
This is a tip
====

Capítulo 8. Traduções

Este é o FAQ para pessoas que estão traduzindo a documentação do FreeBSD (FAQ, Handbook, tutoriais, páginas de manual e outros) para diferentes idiomas.

Ele é fortemente baseado na tradução do FAQ do Projeto de Documentação Alemão do FreeBSD, originalmente escrito por Frank Gründer elwood@mc5sys.in-berlin.de e traduzido de volta para o Inglês por Bernd Warken bwarken@mayn.de.

8.1. O que significa i18n e l10n?

i18n significa internacionalização e l10n significa localização. São apenas uma abreviação.

i18n pode ser lido como "i" seguido por 18 letras, seguido por "n". Da mesma forma, l10n é "l" seguido por 10 letras, seguido por "n".

8.2. Existe uma lista de discussão para tradutores?

Sim. Diferentes grupos de tradução têm suas próprias listas de discussão. A lista dos projetos de tradução possui mais informações sobre as listas de discussão e sites web mantidos por cada projeto de tradução. Além disso, existe a freebsd-translators@freebsd.org para discussão geral de tradução.

8.3. São necessários mais tradutores?

Sim. Quanto mais pessoas trabalham na tradução, mais rápido ela será finalizada, e mais rapidamente as mudanças na documentação em Inglês serão refletidas nos documentos traduzidos.

Você não precisa ser um tradutor profissional para poder ajudar.

8.4. Quais idiomas eu preciso saber?

Idealmente, você deverá possuir um bom conhecimento de Inglês escrito, e obviamente, precisará ser fluente no idioma para o qual está traduzindo.

Inglês não é estritamente necessário. Por exemplo, você poderia fazer uma tradução Húngara do FAQ da tradução em Espanhol.

8.5. Quais softwares eu preciso conhecer?

É fortemente recomendado que você mantenha uma cópia local do repositório Git do FreeBSD (pelo menos a parte da documentação). Isso pode ser feito executando:

% git clone https://git.FreeBSD.org/doc.git ~/doc

git.FreeBSD.org é um servidor público git.

Será necessário que o pacote git-lite esteja instalado.

Você deverá ter conhecimentos básicos de git. Ele permitirá que você veja o que mudou entre as diferentes versões dos arquivos que compõem a documentação.

Por exemplo, para ver as diferenças entre as revisões abff932fe8 e 2191c44469 de documentation/content/en/articles/committers-guide/_index.adoc, execute:

% git diff abff932fe8 2191c44469 documentation/content/en/articles/committers-guide/_index.adoc

Por favor, veja a explicação completa de como usar o Git no FreeBSD no FreeBSD Handbook.

8.6. Como eu faço para descobrir se já existem outras pessoas traduzindo documentos para o meu idioma?

A página do Projeto de Tradução da Documentação lista os trabalhos de tradução que são conhecidos. Se outras pessoas já estiverem trabalhando na tradução de documentação para o seu idioma, por favor, não duplique os esforços. Em vez disso, entre em contato para saber como você pode ajudar.

Se não existir nenhum projeto de tradução para o seu idioma listado nesta página, envie uma mensagem para a lista de discussão do projeto de documentação do FreeBSD para o caso de alguém estar pensando em fazer a tradução, mas ainda não tiver anunciado nada.

8.7. Ninguém mais está traduzindo para o meu idioma. O que eu faço?

Parabéns, você acabou de iniciar o "Projeto de Tradução da Documentação do FreeBSD em seu idioma aqui". Bem vindo a bordo.

Primeiro, pense se você terá o tempo necessário. Uma vez que você é a única pessoa trabalhando no seu idioma no momento, será sua a responsabilidade de publicar o seu trabalho e coordenar qualquer voluntário que queira ajudá-lo.

Escreva um email para a lista de discussão do Projeto de Documentação, anunciando que você irá traduzir a documentação, assim a página do Projeto de Traduções de Documentação poderá ser atualizada.

Se já existir alguém em seu país provendo o espelhamento de serviços do FreeBSD, você deve contacta-lo e perguntar se você pode ter algum espaço web para seu projeto, e se possível um endereço de email ou mesmo um serviço de lista de discussão.

Então escolha um documento e comece a traduzir. É melhor começar com algo razoavelmente pequeno—como o FAQ ou um dos tutoriais.

8.8. Eu já tenho alguns documentos traduzidos, para onde eu devo enviá-los?

Isso depende. Se você já está trabalhando com uma equipe de tradução (tal como a equipe Japonesa, ou a equipe Alemã) então ela terá seus próprios procedimentos para manipular a documentação submetida, e estes serão descritos em seus web sites.

Se você for a única pessoa trabalhando em um determinado idioma (ou se você é o responsável pelo projeto de tradução e quer submeter suas mudanças de volta para o projeto FreeBSD) então você deve enviar sua tradução ao Projeto FreBSD (veja pergunta seguinte).

8.9. Eu sou a única pessoa trabalhando na tradução para este idioma, como faço para enviar minha tradução?

Primeiro, verifique se sua tradução está organizada corretamente. Isso significa que ele deve cair na árvore de documentação existente e ser compilada de maneira correta.

Os diretórios abaixo desse são nomeados de acordo com o código do idioma em que estão escritos, conforme definido na ISO639 (/usr/share/misc/iso639 em uma versão do FreeBSD mais recente que 20 de janeiro de 1999).

Hugo precisa dos códigos de idioma em letras minúsculas. Por exemplo, em vez de pt_BR, Hugo utiliza`pt-br`.

Atualmente a documentação do FreeBSD é armazenada em um diretório de nível superior chamado documentation/. Os diretórios abaixo desse são nomeados de acordo com o código do idioma em que estão escritos, conforme definido na ISO639 (/usr/share/misc/iso639 em uma versão do FreeBSD mais recente que 20 de janeiro de 1999).

Se o seu idioma puder ser codificado de maneiras diferentes (por exemplo, Chinês), deve haver diretórios abaixo desse, um para cada formato de codificação fornecido.

Finalmente, você deve ter diretórios para cada documento.

Por exemplo, em uma hipotética tradução Sueca ficaria assim:

documentation/
  content/
    sv/
      books/
        faq/
          _index.adoc

sv é o nome da tradução, no formato lang. Repare nos dois Makefiles, que serão usados para compilar a documentação.

Utilize o comando git diff para gerar a alteração e envia-la ao sistema de revisão.

% git diff > sv-faq.diff

Você deve usar o Bugzilla para enviar um relatório indicando que você enviou a documentação. Seria muito útil se você conseguir outras pessoas para checar sua tradução primeiro, já que é improvável que a pessoa que irá fazer o commit seja fluente no idioma.

Alguém (provavelmente o Gerente do Projeto de Documentação, atualmente Equipe de Engenharia de Documentação <doceng@FreeBSD.org>) irá então pegar sua tradução e checar se ela compila. Em particular, os seguintes itens serão analisados:

  1. O make no diretório root funciona corretamente?

Se houver algum problema, quem estiver validando a submissão irá entrar em contato para que seja feito as correções.

Se não houver problemas, sua tradução será disponibilizada o mais rápido possível.

8.10. Posso incluir um texto específico do idioma ou do país em minha tradução?

Nós preferimos que você não faça isso.

Por exemplo, suponha que você esteja traduzindo o Handbook para o Coreano e queira incluir uma seção sobre varejistas na Coreia em seu Handbook.

Não há razão pela qual esta informação não deva estar nas versões em Inglês (ou Alemão, ou Espanhol, ou Japonês, ou …). É possível que uma pessoa que fale Inglês na Coréia possa tentar obter uma cópia do FreeBSD enquanto esteja ali. Isso também ajuda a aumentar a presença perceptível do FreeBSD ao redor do mundo, o que não é uma coisa ruim.

Se você tiver informações específicas do país, submeta-as como uma alteração do Handbook em Inglês (usando o Bugzilla) e em seguida, traduza a alteração de volta para o seu idioma no Handbook traduzido.

Obrigado.

8.10.1. Dirigindo-se ao leitor

Nos documentos em Inglês, o leitor é tratado por "você", não há distinção entre formal/informal como existe em alguns idiomas.

Se você estiver traduzindo para um idioma que tenha esta distinção, use qualquer forma que normalmente é usada em outras documentações técnicas. Na dúvida, use a forma mais educada.

8.10.2. Preciso incluir informações adicionais nas minhas traduções?

Sim.

O cabeçalho da versão em Inglês de cada documento será algo parecido com isto:

 ---
 title: Why you should use a BSD style license for your Open Source Project
 releaseinfo: "$FreeBSD: head/en_US.ISO8859-1/articles/bsdl-gpl/article.xml 53942 2020-03-01 12:23:40Z carlavilla $"
 trademarks: ["freebsd", "intel", "general"]
 ---

 = Why you should use a BSD style license for your Open Source Project

O forma exata pode mudar, mas sempre incluirá uma linha $FreeBSD$ e a frase The FreeBSD Documentation Project. Note que a parte do $FreeBSD é expandida automaticamente pelo Git, portanto ela deve estar vazia (apenas $FreeBSD$) para novos arquivos.

Seus documentos traduzidos devem incluir sua própria linha FreeBSD, e mudar a linha FreeBSD Documentation Project para The FreeBSD language Documentation Project.

Você deve ainda adicionar uma terceira linha que indicará qual revisão do texto em inglês o texto é baseado.

Assim, a versão em Espanhol desse arquivo pode começar com:

 ---
 title: Soporte para segundos intercalares en FreeBSD
 releaseinfo: "$FreeBSD: head/es_ES.ISO8859-1/articles/leap-seconds/article.xml 53090 2019-06-01 17:52:59Z carlavilla $"
 ---

 = Soporte para segundos intercalares en FreeBSD

Capítulo 9. Traduções PO

9.1. Introdução

O GNU gettext oferece aos tradutores uma maneira fácil de criar e manter traduções de documentos. Sequências traduzíveis são extraídas do documento original em um arquivo PO (Portable Object). Versões traduzidas das strings são inseridas com um editor separado. As strings podem ser usadas diretamente ou incorporadas em uma versão traduzida completa do documento original.

9.2. Introdução

Supõe-se que o procedimento mostrado no Quick Start já tenha sido executado. A opção TRANSLATOR é necessária e já está ativada por padrão no port textproc/docproj.

Este exemplo mostra a criação de uma tradução em Espanhol do pequeno artigo Leap Seconds.

Procedimento. Instale um Editor PO
  1. É necessário um editor PO para editar os arquivos de tradução. Este exemplo utiliza o editors/poedit.

    # pkg install poedit
Procedimento. Configuração Inicial

Quando uma nova tradução é criada pela primeira vez, a estrutura do diretório e o Makefile devem ser criados ou copiados do original em Inglês:

  1. Crie um diretório para a nova tradução. O código fonte do artigo em Inglês está em ~/doc/documentation/content/en/articles/leap-seconds/. A tradução em Espanhol estará em ~/doc/documentation/content/es/articles/leap-seconds/. O caminho é o mesmo, exceto pelo nome do diretório de idiomas.

    % mkdir ~/doc/documentation/content/es/articles/leap-seconds
  2. Copie o _index.adoc do documento original para o diretório de tradução:

    % cp ~/doc/documentation/content/en/articles/leap-seconds/_index.adoc \
      ~/doc/documentation/content/es/articles/leap-seconds/
Procedimento. Tradução

A tradução de um documento consiste em duas etapas: extrair strings traduzíveis do documento original e inserir as traduções dessas strings. Essas etapas são repetidas até que o tradutor sinta que o documento foi traduzido o suficiente para produzir um documento traduzido que seja utilizável.

  1. Extraia as strings traduzíveis da versão original em Inglês para um arquivo PO:

    % cd ~/doc
    % po4a-gettextize \
      --format asciidoc \
      --option compat=asciidoctor \
      --option yfm_keys=title,part,description \
      --master "documentation/content/en/articles/leap-seconds/_index.adoc" \
      --master-charset "UTF-8" \
      --copyright-holder "The FreeBSD Project" \
      --package-name "FreeBSD Documentation" \
      --po "documentation/content/es/articles/leap-seconds/_index.po"
  2. Use um editor PO para inserir as traduções no arquivo PO. Existem vários editores diferentes disponíveis. O poedit do editors/poedit é mostrado aqui.

    % poedit documentation/content/es/articles/leap-seconds/_index.po
Procedimento. Gerando um Documento Traduzido
  1. Gere o documento traduzido:

    % cd ~/doc
    % po4a-translate \
      --format asciidoc \
      --option compat=asciidoctor \
      --option yfm_keys=title,part,description \
      --master "documentation/content/en/articles/leap-seconds/_index.adoc" \
      --master-charset "UTF-8" \
      --po "documentation/content/es/articles/leap-seconds/_index.po" \
      --localized "documentation/content/es/articles/leap-seconds/_index.adoc" \
      --localized-charset "UTF-8" \
      --keep 0

    O nome do documento gerado corresponde ao nome do original em Inglês, geralmente _index.adoc.

  2. Verifique o arquivo gerado renderizando-o para HTML e exibindo-o com um navegador web:

    % cd ~/doc/documentation
    % make

9.3. Criando Novas Traduções

O primeiro passo para criar um novo documento traduzido é localizar ou criar um diretório para mantê-lo. O FreeBSD coloca documentos traduzidos em um subdiretório nomeado para seu idioma e região no formato lang . lang é um código minúsculo de dois caracteres.

Tabela 2. Nomes de Idioma
Language Region Translated Directory Name

English

United States

en

Bengali

Bangladesh

bn

Danish

Denmark

da

German

Germany

de

Greek

Greece

el

Spanish

Spain

es

French

France

fr

Hungarian

Hungary

hu

Italian

Italy

it

Japanese

Japan

ja

Korean

Korea

ko

Mongolian

Mongolia

mn

Dutch

Netherlands

nl

Polish

Poland

pl

Portuguese

Brazil

pt-br

Russian

Russia

ru

Turkish

Turkey

tr

Chinese

China

zh-cn

Chinese

Taiwan

zh-tw

As traduções estão em subdiretórios do diretório principal da documentação, aqui assumido como ~/doc/documentation/ como apresentado no Introdução. Por exemplo, as traduções em Alemão estão localizadas em ~/doc/documentation/content/de/ e as traduções em Francês estão em ~/doc/documentation/content/fr/.

Cada diretório de idiomas contém subdiretórios separados para os tipos de documentos, geralmente articles/ e books/.

A combinação desses nomes de diretórios fornece o caminho completo para um artigo ou livro. Por exemplo, a tradução Francesa do artigo NanoBSD está em ~/doc/documentation/content/fr/articles/nanobsd/, e a tradução em Mongol do manual está em ~/doc/documentation/content/mn/books/handbook/.

Um novo diretório de idioma deve ser criado ao traduzir um documento para um novo idioma. Se o diretório de idiomas já existir, somente um subdiretório no diretório articles/ ou books/ será necessário.

Exemplo 8. Criando uma Tradução em Espanhol do Porter’s Handbook

Crie uma nova tradução em Espanhol do Porter’s Handbook. O original é um livro em ~/doc/documentation/content/en/books/porters-handbook/.

  1. O diretório de livros em Espanhol ~/doc/documentation/content/es/books/ já existe, portanto, apenas um novo subdiretório para o Porter’s Handbook é necessário:

    % cd ~/doc/documentation/content/es/books
    % mkdir porters-handbook
  2. Copie o conteúdo do livro original:

    % cd porters-handbook
    % cp -R ~/doc/documentation/content/en/books/porters-handbook/* .

    Agora a estrutura do documento está pronta para o tradutor começar a tradução com o poedit.

9.4. Traduzindo

O sistema gettext reduz bastante o número de itens que devem ser rastreados por um tradutor. As strings a serem traduzidas são extraídas do documento original em um arquivo PO. Em seguida, um editor PO é usado para inserir as traduções de cada string.

O sistema de tradução PO do FreeBSD não sobrescreve os arquivos PO, portanto a etapa de extração pode ser executada a qualquer momento para atualizar o arquivo PO.

Um editor PO é usado para editar o arquivo. editors/poedit é usado nestes exemplos porque é simples e tem requisitos mínimos. Outros editores PO oferecem recursos para facilitar o trabalho de tradução. A Coleção de Ports oferece vários desses editores, incluindo o devel/gtranslator.

É importante preservar o arquivo PO. Ele contém todo o trabalho que os tradutores fizeram.

Exemplo 9. Traduzindo o Porter’s Handbook para o Espanhol
  1. Mude para o diretório base e atualize todos os arquivos PO.

    % cd ~/doc
    % po4a-gettextize \
      --format asciidoc \
      --option compat=asciidoctor \
      --option yfm_keys=title,part,description \
      --master "documentation/content/en/books/porters-handbook/_index.adoc" \
      --master-charset "UTF-8" \
      --copyright-holder "The FreeBSD Project" \
      --package-name "FreeBSD Documentation" \
      --po "documentation/content/es/books/porters-handbook/_index.po"
  2. Realize as traduções usando um editor de PO:

    % poedit documentation/content/es/books/porters-handbook/_index.po

Essas etapas são necessárias para todos os arquivos .adoc, exceto chapters-order.adoc e toc-*.adoc.

9.5. Dicas para Tradutores

9.5.1. Preservando macros AsciiDoc

Preserve as macros AsciiDoc que são mostradas no original em Inglês.

Exemplo 10. Preservando macros AsciiDoc

Inglês original:

msgid ""
"This example shows the creation of a Spanish translation of the short "
"link:{leap-seconds}[Leap Seconds] article."

Tradução para o Espanhol:

msgid ""
"Este ejemplo muestra la creación de un artículo con poco contenido como el artículo "
"link:{leap-seconds}[Leap Seconds]."

9.5.2. Preservando Espaços

Preserve os espaços existentes no início e no final das strings a serem traduzidas. A versão traduzida também deve ter esses espaços.

9.5.3. Tags

O conteúdo de algumas tags devem ser copiadas igualmente, sem realizar tradução:

  • man(1)

  • package

  • link

  • image

  • include

  • Admonitions

  • id’s

  • Heading tags

  • source

9.6. Compilando um Documento Traduzido

Uma versão traduzida do documento original pode ser criada a qualquer momento. Quaisquer porções não traduzidas do original serão incluídas em Inglês no documento resultante. A maioria dos editores PO tem um indicador que mostra quanto da tradução foi realizada. Isso torna mais fácil para o tradutor ver quantas strings foram traduzidas para tornar a compilação do documento final utilizável.

9.7. Submetendo a Nova Tradução

Prepare os novos arquivos de tradução para envio. Isso inclui adicionar os arquivos ao sistema de controle de versão, definir propriedades adicionais e criar um diff para a submissão.

Os arquivos diff criados por esses exemplos podem ser anexados a um relatório de bug de documentação ou revisão de código.

Exemplo 11. Tradução Espanhola do Artigo NanoBSD
  1. Crie um diff dos novos arquivos a partir do diretório base ~/doc/ para que o caminho completo seja mostrado com os nomes dos arquivos. Isso ajuda os committers a identificar o diretório do idioma de destino.

    % cd ~/doc
    % git diff documentation/content/es/articles/nanobsd/ > /tmp/es_nanobsd.diff

Capítulo 10. Páginas de Manual

10.1. Introdução

Páginas de manual, geralmente abreviadas como man pages, foram concebidas como lembretes prontamente disponíveis para sintaxe de comandos, detalhes de drivers de dispositivos ou formatos de arquivos de configuração. Elas se tornaram uma referência rápida extremamente valiosa de linha de comando para usuários, administradores de sistema e programadores.

Embora tenham sido planejados como material de referência em vez de tutoriais, as seções EXEMPLOS das páginas de manual geralmente fornecem casos de uso detalhados.

Páginas de manual são geralmente mostradas interativamente pelo comando man(1). Quando o usuário digita man ls, uma pesquisa é executada para uma página de manual que corresponde a ls. O primeiro resultado correspondente é exibido.

10.2. Seções

As páginas de manual são agrupadas em seções. Cada seção contém páginas de manual para uma categoria específica de documentação:

Section Number Category

1

General Commands

2

System Calls

3

Library Functions

4

Kernel Interfaces

5

File Formats

6

Games

7

Miscellaneous

8

System Manager

9

Kernel Developer

10.3. Marcação

Vários formulários de marcação e programas de renderização foram usados para páginas de manual. O FreeBSD usou groff(7) e o mais recente mandoc(1). A maioria das páginas de manual do FreeBSD, e todas as novas, usam o formulário mdoc(7) de marcação. Esta é uma marcação simples baseada em linhas que é razoavelmente expressiva. É principalmente semântico: partes do texto são marcadas para o que são, em vez de como devem aparecer quando renderizadas. Existe alguma marcação baseada em aparência que geralmente é melhor evitar.

O código fonte de página de manual geralmente é interpretada e exibido na tela interativamente. Os arquivos fontes podem ser arquivos de texto comuns ou compactados com gzip(1) para economizar espaço.

As páginas de manual também podem ser renderizadas para outros formatos, incluindo PostScript para impressão ou geração de PDF. Veja man(1).

10.3.1. Seções de Página de Manual

Páginas de manual são compostas por várias seções padrão. Cada seção tem um título em letras maiúsculas e as seções de um determinado tipo de página de manual aparecem em uma ordem específica. Para uma página de manual do Comando Geral da categoria 1, as seções são:

Section Name Description

NAME

Name of the command

SYNOPSIS

Format of options and arguments

DESCRIPTION

Description of purpose and usage

ENVIRONMENT

Environment settings that affect operation

EXIT STATUS

Error codes returned on exit

EXAMPLES

Examples of usage

COMPATIBILITY

Compatibility with other implementations

SEE ALSO

Cross-reference to related manual pages

STANDARDS

Compatibility with standards like POSIX

HISTORY

History of implementation

BUGS

Known bugs

AUTHORS

People who created the command or wrote the manual page.

Algumas seções são opcionais e a combinação de seções para um tipo específico de página manual pode variar. Exemplos dos tipos mais comuns são mostrados mais adiante neste capítulo.

10.3.2. Macros

A marcação mdoc(7) é baseada em macros. As linhas que começam com um ponto contêm comandos de macro, com duas ou três letras. Por exemplo, veja esta parte da página de manual do ls(1):

.Dd December 1, 2015  (1)
.Dt LS 1
.Sh NAME  (2)
.Nm ls
.Nd list directory contents
.Sh SYNOPSIS  (3)
.Nm  (4)
.Op Fl -libxo  (5)
.Op Fl ABCFGHILPRSTUWZabcdfghiklmnopqrstuwxy1,  (6)
.Op Fl D Ar format  (7)
.Op Ar  (8)
.Sh DESCRIPTION  (9)
For each operand that names a
.Ar file
of a type other than
directory,
.Nm
displays its name as well as any requested,
associated information.
For each operand that names a
.Ar file
of type directory,
.Nm
displays the names of files contained
within that directory, as well as any requested, associated
information.
1 O Document date e Document title são definidos.
2 O Section header para a seção NAME é definido. Em seguida, o Name do comando e um Name description de uma linha são definidos.
3 A seção SYNOPSIS começa. Esta seção descreve as opções de linha de comando e os argumentos que são aceitos.
4 Name (.Nm) já foi definido, e repeti-lo aqui apenas exibe o valor definido no texto.
5 Uma Optional Flag chamada -libxo é mostrada. A macro Fl adiciona um traço ao início das flags, então isso aparece na página de manual como`--libxo`.
6 Uma longa lista de flags opcionais de um único caractere é mostrada.
7 Uma flag opcional -D é definida. Se a flag -D for fornecida, ele deve ser seguido por um Argument. O argumento é um format, uma string que diz ao ls(1) o que mostrar e como mostrar. Detalhes sobre a string de formato são fornecidos posteriormente na página do manual.
8 Um argumento opcional final é definido. Visto que nenhum nome é especificado para o argumento, o padrão de file …​ é usado.
9 O Section header para a seção DESCRIPTION é definido.

Quando renderizado com o comando man ls, o resultado exibido na tela é semelhante ao seguinte:

LS(1)                   FreeBSD General Commands Manual                  LS(1)

NAME
     ls - list directory contents

SYNOPSIS
     ls [--libxo] [-ABCFGHILPRSTUWZabcdfghiklmnopqrstuwxy1,] [-D format]
        [file ...]

DESCRIPTION
     For each operand that names a file of a type other than directory, ls
     displays its name as well as any requested, associated information.  For
     each operand that names a file of type directory, ls displays the names
     of files contained within that directory, as well as any requested,
     associated information.

Valores opcionais são mostrados entre colchetes.

10.3.3. Diretrizes de Marcação

A linguagem de marcação mdoc(7) não é muito rigorosa. Para maior clareza e consistência, o projeto de Documentação do FreeBSD adiciona algumas diretrizes de estilo adicionais:

Apenas a primeira letra das macros é maiúscula

Sempre use maiúsculas para a primeira letra de uma macro e minúscula para as letras restantes.

Comece novas frases em novas linhas

Inicie uma nova frase em uma nova linha, não a inicie na mesma linha de uma frase existente.

Atualizar .Dd ao fazer alterações não triviais em uma página de manual

A Data do documento informa o leitor sobre a última vez que a página de manual foi atualizada. É importante atualizar sempre que alterações não triviais forem feitas nas páginas de manual. Alterações triviais, como correções ortográficas ou de pontuação que não afetam o uso, podem ser feitas sem atualizar .Dd.

Apresentando exemplos

Apresente exemplos ao leitor sempre que possível. Mesmo exemplos triviais são valiosos, porque o que é trivial para o escritor não é necessariamente trivial para o leitor. Três exemplos são um bom objetivo. Um exemplo trivial mostra os requisitos mínimos, um exemplo afundo mostra o uso real e um exemplo detalhado demonstra uma funcionalidade incomum ou não óbvia.

Inclua a licença BSD

Inclua a licença BSD em novas páginas de manual. A licença preferencial está disponível no Guia dos Committer’s.

10.3.4. Truques de Marcação

Adicione um espaço antes da pontuação em uma linha com macros. Exemplo:

.Sh SEE ALSO
.Xr geom 4 ,
.Xr boot0cfg 8 ,
.Xr geom 8 ,
.Xr gptboot 8

Observe como as vírgulas no final das linhas .Xr foram colocadas após um espaço. A macro .Xr espera dois parâmetros, o nome de uma página de manual externa e um número de seção. O espaço separa a pontuação do número da seção. Sem o espaço, os links externos apontariam incorretamente para a seção 4, ou 8,.

10.3.5. Macros Importantes

Algumas macros muito comuns serão mostradas aqui. Para obter mais exemplos de uso, consulte mdoc(7), groff_mdoc(7), ou procure por uso real no diretório /usr/share/man/man*. Por exemplo, para procurar exemplos da macro .Bd Begin display:

% find /usr/share/man/man* | xargs zgrep '.Bd'
10.3.5.1. Macros Organizacionais

Algumas macros são usadas para definir blocos lógicos de uma página de manual.

Organizational Macro Use

.Sh

Section header. Followed by the name of the section, traditionally all upper case. Think of these as chapter titles.

.Ss

Subsection header. Followed by the name of the subsection. Used to divide a .Sh section into subsections.

.Bl

Begin list. Start a list of items.

.El

End a list.

.Bd

Begin display. Begin a special area of text, like an indented area.

.Ed

End display.

10.3.5.2. Macros Inline

Muitas macros são usadas para marcar texto embutido.

Inline Macro Use

.Nm

Name. Called with a name as a parameter on the first use, then used later without the parameter to display the name that has already been defined.

.Pa

Path to a file. Used to mark up filenames and directory paths.

10.4. Exemplo de Estruturas de Página de Manual

Esta seção mostra o conteúdo mínimo desejável para um página de manual para várias categorias comuns de páginas de manual.

10.4.1. Seção 1 ou 8 sobre um comando

A estrutura básica preferida para uma seção 1 ou 8 sobre um comando:

.Dd August 25, 2017
.Dt EXAMPLECMD 8
.Os
.Sh NAME
.Nm examplecmd
.Nd "command to demonstrate section 1 and 8 man pages"
.Sh SYNOPSIS
.Nm
.Op Fl v
.Sh DESCRIPTION
The
.Nm
utility does nothing except demonstrate a trivial but complete
manual page for a section 1 or 8 command.
.Sh SEE ALSO
.Xr exampleconf 5
.Sh AUTHORS
.An Firstname Lastname Aq Mt flastname@example.com

10.4.2. Seção 4 sobre um Driver de Dispositivo

A estrutura básica preferida para a seção 4 sobre um driver de dispositivo:

.Dd August 25, 2017
.Dt EXAMPLEDRIVER 4
.Os
.Sh NAME
.Nm exampledriver
.Nd "driver to demonstrate section 4 man pages"
.Sh SYNOPSIS
To compile this driver into the kernel, add this line to the
kernel configuration file:
.Bd -ragged -offset indent
.Cd "device exampledriver"
.Ed
.Pp
To load the driver as a module at boot, add this line to
.Xr loader.conf 5 :
.Bd -literal -offset indent
exampledriver_load="YES"
.Ed
.Sh DESCRIPTION
The
.Nm
driver provides an opportunity to show a skeleton or template
file for section 4 manual pages.
.Sh HARDWARE
The
.Nm
driver supports these cards from the aptly-named Nonexistent
Technologies:
.Pp
.Bl -bullet -compact
.It
NT X149.2 (single and dual port)
.It
NT X149.8 (single port)
.El
.Sh DIAGNOSTICS
.Bl -diag
.It "flashing green light"
Something bad happened.
.It "flashing red light"
Something really bad happened.
.It "solid black light"
Power cord is unplugged.
.El
.Sh SEE ALSO
.Xr example 8
.Sh HISTORY
The
.Nm
device driver first appeared in
.Fx 49.2 .
.Sh AUTHORS
.An Firstname Lastname Aq Mt flastname@example.com

10.4.3. Seção 5 sobre um Arquivo de Configuração

A estrutura básica preferida para a seção 5 sobre um arquivo de configuração:

.Dd August 25, 2017
.Dt EXAMPLECONF 5
.Os
.Sh NAME
.Nm example.conf
.Nd "config file to demonstrate section 5 man pages"
.Sh DESCRIPTION
.Nm
is an example configuration file.
.Sh SEE ALSO
.Xr example 8
.Sh AUTHORS
.An Firstname Lastname Aq Mt flastname@example.com

10.5. Testando

O teste de uma nova página de manual pode ser um desafio quando o arquivo não está localizado no caminho de pesquisa normal da páginas de manual. man(1) também não procura no diretório atual. Se a nova página de manual estiver no diretório atual, prefixe o nome do arquivo com um ./

Use o linter de mandoc(1) para verificar se há erros:

% mandoc -T lint ./mynewmanpage.8

Use o textproc/igor para revisar a página do manual:

% igor ./mynewmanpage.8

Use man(1) para verificar o resultado final de suas alterações:

% man ./mynewmanpage.8

Você pode usar col(1) para filtrar a saída de man(1) e se livrar dos caracteres backspace antes de carregar o resultado em seu editor favorito para verificação ortográfica:

% man ./mynewmanpage.8 | col -b | vim -R -

A verificação ortográfica com dicionários completos é incentivada e pode ser realizada usando textproc/hunspell ou textproc/aspell combinado com textproc/en-hunspell ou textproc/en-aspell, respectivamente. Por exemplo:

% aspell check --lang=en --mode=nroff ./mynewmanpage.8

10.6. Exemplos de páginas de manuais para usar como modelos

Algumas destas páginas de manual são adequadas para serem usadas como exemplos detalhados.

Manual Page Path to Source Location

cp(1)

/usr/src/bin/cp/cp.1

vt(4)

/usr/src/share/man/man4/vt.4

crontab(5)

/usr/src/usr.sbin/cron/crontab/crontab.5

gpart(8)

/usr/src/sbin/geom/class/part/gpart.8

10.7. Recursos

Recursos para escritores de páginas manuais:

Capítulo 11. Estilo de escrita

11.1. Dicas

A documentação técnica pode ser melhorada pelo uso consistente de vários princípios. A maioria destes pode ser classificada em três objetivos: ser claro, ser completo e ser conciso. Essas metas podem entrar em conflito umas com as outras. Uma boa escrita consiste em um equilíbrio entre eles.

11.1.1. Seja claro

A clareza é extremamente importante. O leitor pode ser um novato ou ler o documento em um segundo idioma. Esforce-se por um texto simples e descomplicado que explique claramente os conceitos.

Evite discurso florido ou embelezado, piadas ou expressões coloquiais. Escreva da maneira mais simples e clara possível. Um texto simples é mais fácil de se entender e de se traduzir.

Mantenha as explicações o mais curtas, simples e claras possíveis. Evite frases vazias como "a fim de" as quais normalmente significam apenas um "para". Evite palavras potencialmente paternalistas tais como "basicamente". Evite termos latinos como "i.e." ou "cf.", os quais podem ser desconhecidos fora de grupos acadêmicos ou científicos.

Escreva em um estilo formal. Evite dirigir-se ao leitor como "você". Por exemplo, digamos "copie o arquivo para /tmp" em vez de "você pode copiar o arquivo para /tmp".

Dê exemplos claros, corretos, e testados. Um exemplo trivial é melhor do que nenhum exemplo. Um bom exemplo é ainda melhor. Não dê exemplos ruins, identificáveis por desculpas ou frases como "mas realmente isso nunca deve ser feito dessa forma". Exemplos ruins são piores que nenhum exemplo. Dê bons exemplos, porque mesmo quando avisado para não usar o exemplo como mostrado , o leitor normalmente só usa o exemplo como mostrado.

Evite palavras vazias como "deveria", "poderia", "tentaria", ou "podia". Estas palavras implicam que o autor não tem certeza dos fatos e cria dúvidas no leitor.

Da mesma forma, dê instruções como comandos imperativos: não utilize "você deve fazer isso", mas apenas "faça isso".

11.1.2. Seja completo

Não faça suposições sobre as habilidades do leitor. Diga-lhes o que precisam saber. Dê links para outros documentos para fornecer informações básicas sem precisar recriá-las. Coloque-se no lugar do leitor, antecipe as perguntas que eles farão e responda-os.

11.1.3. Seja conciso

Embora as funcionalidades devam ser documentadas completamente, às vezes existe tanta informação que o leitor não consegue encontrar facilmente os detalhes específicos de que necessita. O equilíbrio entre ser completo e ser conciso é um desafio. Uma abordagem é ter uma introdução e, em seguida, uma seção de "início rápido" que descreve a situação mais comum, seguida por uma seção de referência aprofundada.

11.2. Diretrizes

Para promover a consistência entre os inúmeros autores da documentação do FreeBSD, algumas diretrizes foram elaboradas para os autores seguirem.

Use a Ortografia do Inglês Americano

Existem várias variantes do Inglês, com grafias diferentes para a mesma palavra. Onde as grafias diferem, use a variante do Inglês Americano. "color", não "colour", "rationalize", não "rationalise", e assim por diante.

O uso do Inglês Britânico pode ser aceito no caso de um artigo contribuído, no entanto, a ortografia deve ser consistente em todo o documento. Os outros documentos, como livros, site, páginas de manual, etc., terão que usar o Inglês Americano.

Não use contrações

Não use contrações. Sempre soletre a frase na íntegra. "Do not" é a forma correta, "Don’t" é a errada.

Evitar contrações contribui para um tom mais formal, é mais preciso e é um pouco mais fácil para os tradutores.

Use a vírgula serial

Em uma lista de itens dentro de um parágrafo, separe cada item dos outros com uma vírgula. Separe o último item dos outros com uma vírgula e a letra "e".

Por exemplo:

Esta é uma lista de um, dois e três itens.

Esta é uma lista de três itens, "um", "dois", e "três", ou uma lista de dois itens, "um" e "dois" e "três"?

É melhor ser explícito e incluir uma vírgula serial:

Esta é uma lista de um, dois, e três itens.

Evite frases redundantes

Não use frases redundantes. Em particular, "the command", "the file", e "man command" são frequentemente redundantes.

Por exemplo, comandos:

Errado: Use o comando git para atualizar o código fonte.

Correto: Use o git para atualizar o código fonte.

Nomes de arquivo:

Errado: …​ no nome do arquivo /etc/rc.local…​

Correto: …​ no /etc/rc.local…​

Referências de páginas de manual (o segundo exemplo usa citerefentry com a entidade csh(1)):.

Errado: veja man csh para mais informações.

Certo: Veja csh(1).

Para mais informações sobre o estilo de escrita, consulte Elements of Style, de William Strunk.

11.3. Guia de estilo

Para manter o código fonte da documentação consistente quando muitas pessoas diferentes a estiverem editando, siga estas convenções de estilo.

11.4. Uma frase por linha

Use quebras de linha semântica na documentação, uma técnica chamada "uma frase por linha". A ideia dessa técnica é ajudar os usuários a escrever e ler a documentação. Para obter mais informações sobre essa técnica, leia a página Semantic Line Breaks.

Este é um exemplo que não usa "uma frase por linha".

All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.

E este é um exemplo que usa a técnica.

All human beings are born free and equal in dignity and rights.
They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.

11.4.1. Siglas

As siglas devem ser definidas na primeira vez que aparecerem em um documento, como em: "Network Time Protocol (NTP)". Depois que o acrônimo tiver sido definido, use apenas a sigla, a menos que faça mais sentido contextualmente usar todo o termo. Siglas geralmente são definidos apenas uma vez por capítulo ou por documento.

Todas as siglas devem ser incluídas com o caractere `.

11.5. Lista de Caracteres Especiais

Esta lista de caracteres especiais mostra a sintaxe correta e a saída quando usada na documentação do FreeBSD. Se um caractere não está nesta lista, pergunte sobre ele na lista de discussão do projeto de documentação do FreeBSD.

Nome Sintaxe Renderizado

Copyright

(C)

©

Registrado

(R)

®

Marca Comercial

(TM)

Travessão

--

 — 

Elipses

...

…​

Seta simples para a direita

->

Seta dupla para a direita

=>

Seta simples para a esquerda

<-

Seta dupla para a esquerda

<=

Capítulo 12. Configuração do Editor

Ajustar a configuração do editor de texto pode tornar o trabalho nos arquivos da documentação mais rápido e fácil, além de ajudar os documentos a ficarem em conformidade com as diretrizes do projeto.

12.1. Vim

Instale-o a partir de editors/vim, editors/vim-console, ou editors/vim-tiny e siga as instruções de configuração em Configuração.

12.1.1. Uso

Pressione P tpara reformatar parágrafos ou texto selecionado no modo Visual. Pressione T para substituir grupos de oito espaços por um tab.

12.1.2. Configuração

Edite o ~/.vimrc, adicionando estas linhas ao final do arquivo:

if has("autocmd")
    au BufNewFile,BufRead *.sgml,*.ent,*.xsl,*.xml call Set_SGML()
    au BufNewFile,BufRead *.[1-9] call ShowSpecial()
endif " has(autocmd)

function Set_Highlights()
    "match ExtraWhitespace /^\s* \s*\|\s\+$/
    highlight default link OverLength ErrorMsg
    match OverLength /\%71v.\+/
    return 0
endfunction " Set_Highlights()

function ShowSpecial()
    setlocal list listchars=tab:>>,trail:*,eol:$
    hi def link nontext ErrorMsg
    return 0
endfunction " ShowSpecial()

function Set_SGML()
    setlocal number
    syn match sgmlSpecial "&[^;]*;"
    setlocal syntax=sgml
    setlocal filetype=xml
    setlocal shiftwidth=2
    setlocal textwidth=70
    setlocal tabstop=8
    setlocal softtabstop=2
    setlocal formatprg="fmt -p"
    setlocal autoindent
    setlocal smartindent
    " Rewrap paragraphs
    noremap P gqj
    " Replace spaces with tabs
    noremap T :s/        /\t/<CR>
    call ShowSpecial()
    call Set_Highlights()
    return 0
endfunction " Set_SGML()

12.2. Emacs

Instale-o a partir de editors/emacs ou editors/emacs-devel.

12.2.1. Validação

O modo nxml do Emacs usa esquemas NG relax compacto para validar o XML. Um esquema NG relax compacto para a extensão do FreeBSD para DocBook 5.0 está incluído no repositório de documentação. Para configurar o modo nxml para validar usando este esquema, crie ~/.emacs.d/schema/schemas.xml e adicione estas linhas ao arquivo:

locatingRules xmlns="http://thaiopensource.com/ns/locating-rules/1.0"
  documentElement localName="section" typeId="DocBook"
  documentElement localName="chapter" typeId="DocBook"
  documentElement localName="article" typeId="DocBook"
  documentElement localName="book" typeId="DocBook"
  typeId id="DocBook" uri="/usr/local/share/xml/docbook/5.0/rng/docbook.rnc"
locatingRules

12.2.2. Revisão Automatizada com Flycheck e Igor

O pacote Flycheck está disponível no Emacs Lisp Package Archive da Milkypostman (MELPA). Se a MELPA ainda não estiver nos repositórios de pacotes do Emacs, ele pode ser adicionado executando

(add-to-list 'package-archives '("melpa" . "http://stable.melpa.org/packages/") t)

Adicione a linha ao arquivo de inicialização do Emacs (qualquer um deles, ~/.emacs, ~/.emacs.el, ou ~.emacs.d/init.el) para tornar esta alteração permanente.

Para instalar o Flycheck, execute

(package-install 'flycheck)

Crie um verificador Flycheck para textproc/igor executando

(flycheck-define-checker igor
  "FreeBSD Documentation Project sanity checker.

See URLs https://www.freebsd.org/docproj/ and
http://www.freshports.org/textproc/igor/."
  :command ("igor" "-X" source-inplace)
  :error-parser flycheck-parse-checkstyle
  :modes (nxml-mode)
  :standard-input t)

  (add-to-list 'flycheck-checkers 'igor 'append)

Novamente, adicione essas linhas ao arquivo de inicialização do Emacs para tornar as mudanças permanentes.

12.2.3. Configurações Específicas da Documentação do FreeBSD

Para aplicar configurações específicas para o projeto de documentação do FreeBSD, crie o arquivo .dir-locals.el no diretório raiz do repositório de documentação e adicione estas linhas ao arquivo:

;;; Directory Local Variables
;;; For more information see (info "(emacs) Directory Variables")

((nxml-mode
  (eval . (turn-on-auto-fill))
  (fill-column . 70)
  (eval . (require 'flycheck))
  (eval . (flycheck-mode 1))
  (flycheck-checker . igor)
  (eval . (add-to-list 'rng-schema-locating-files "~/.emacs.d/schema/schemas.xml"))))

12.3. nano

Instale o aplicativo partir de editors/nano ou editors/nano-devel.

12.3.1. Configuração

Copie o arquivo com a amostra da regra para realce da sintaxe XML para o diretório inicial do usuário:

% cp /usr/local/share/nano/xml.nanorc ~/.nanorc

Use um editor para substituir as linhas do ~/.nanorc referentes ao bloco syntax "xml" por estas regras:

syntax "xml" "\.([jrs]html?|xml|xslt?)$"
# trailing whitespace
color ,blue "[[:space:]]+$"
# multiples of eight spaces at the start a line
# (after zero or more tabs) should be a tab
color ,blue "^([TAB]*[ ]{8})+"
# tabs after spaces
color ,yellow "( )+TAB"
# highlight indents that have an odd number of spaces
color ,red "^(([ ]{2})+|(TAB+))*[ ]{1}[^ ]{1}"
# lines longer than 70 characters
color ,yellow "^(.{71})|(TAB.{63})|(TAB{2}.{55})|(TAB{3}.{47}).+$"

Processe o arquivo para criar guias incorporadas:

% perl -i'' -pe 's/TAB/\t/g' ~/.nanorc

12.3.2. Uso

Especifique opções úteis adicionais ao executar o editor:

% nano -AKipwz -r 70 -T8 _index.adoc

Usuários do csh(1) podem definir um alias em ~/.cshrc para automatizar estas opções:

alias nano "nano -AKipwz -r 70 -T8"

Depois que o alias é definido, as opções serão adicionadas automaticamente:

% nano _index.adoc

Capítulo 13. Veja também

Este documento não é deliberadamente uma discussão exaustiva de AsciiDoc e o Projeto de Documentação do FreeBSD. Para mais informações sobre estes, você é encorajado a consultar os seguintes sites.

13.2. AsciiDoctor

Apêndice A: Exemplos

Estes exemplos não são extensos - eles não contêm todos os elementos que podem ser desejáveis de usar, particularmente em relação ao início dos documentos (Front Matter). Para mais exemplos de marcação AsciiDoctor, examine o código fonte em AsciiDoctor deste e de outros documentos disponíveis no repositório Git doc ou no link https://cgit.freebsd.org/doc/.

A.1. AsciiDoctor book

Exemplo 12. AsciiDoctor book
---
title: An Example Book
authors:
  - author: The FreeBSD Documentation Project
copyright: 1995-2021 The FreeBSD Documentation Project
releaseinfo: ""
trademarks: ["general"]
---

\= An Example Book
:doctype: book
:toc: macro
:toclevels: 2
:icons: font
:xrefstyle: basic
:relfileprefix: ../
:outfilesuffix:
:sectnums:
:sectnumlevels: 6
:partnums:
:chapter-signifier: Chapter
:part-signifier: Part
:source-highlighter: rouge
:experimental:
:skip-front-matter:
:book: true
:pdf: false

:chapters-path: content/en/books/bookname/



[abstract]
Abstract

Abstract section

'''

toc::[]

:sectnums!:

include::{chapters-path}preface/_index.adoc[leveloffset=+1]

:sectnums:

include::{chapters-path}parti.adoc[lines=7..18]

include::{chapters-path}chapter-name/_index.adoc[leveloffset=+1]

A.2. AsciiDoctor article

Exemplo 13. AsciiDoctor article
---
title: An Example Article
authors:
  - author: Your name and surname
    email: foo@example.com
trademarks: ["general"]
---

\= An Example Article
:doctype: article
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:source-highlighter: rouge
:experimental:

'''

toc::[]

\== My First Section

This is the first section in my article.

\== My First Sub-Section

This is the first sub-section in my article.