]> Primer do Projeto de Documentação do FreeBSD para Novos Colaboradores Projeto de Documentação do FreeBSD 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 DocEng Copyright Redistribution and use in source (XML DocBook) and 'compiled' forms (XML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met: Redistributions of source code (XML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Obrigado por fazer parte do Projeto de Documentação do FreeBSD. A sua contribuição é extremamente valiosa. Este primer cobre tudo o que você precisa saber para começar a contribuir com o Projeto de Documentação do FreeBSD, ou FDP, incluindo ferramentas, softwares, 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. 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 su1 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. 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. 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. Quick Start Algumas etapas preparatórias devem ser seguidas antes de editar a documentação do FreeBSD. Primeiro, se registre na lista de email 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. Instale o meta-port textproc/docproj e o Subversion. Este meta-port instala todo software necessário para editar e compilar a documentação do FreeBSD. O pacote Subversion é necessário para obter uma cópia de trabalho da documentação e para gerar patches. # pkg install docproj subversion Obtenha uma cópia local da árvore de documentação do FreeBSD em ~/doc (see ). % svn checkout https://svn.FreeBSD.org/doc/head ~/doc Configure o editor de texto: Defina a quebra de linha para 70 caracteres. Defina a parada de tabulação para 2. Substitua cada grupo de 8 espaços por um tab. Configurações específicas por editor são informados em . Atualize a árvore de trabalho local: % svn up ~/doc 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. Referencias pra uso de tag e entidade podem ser encontradas em and . Após alteração, cheque por eventuais problemas rodando: % igor -R filename.xml | less -RS 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. Sempre realize testes de compilação antes de submeter algo. Execute make no diretório de nível superior da documentação alterada e assim será gerado a documentação no formato HTML com divisões. Por exemplo, pra compilar a versão Inglês do Handbook em HTML, execute make no diretório en_US.ISO8859-1/books/handbook/. Quando as alterações estiverem completas e testadas, gere um arquivo diff: % cd ~/doc % svn diff > bsdinstall.diff.txt Dê ao arquivo diff um nome. No exemplo acima, foram feitas alterações na parte bsdinstall do Handbook. 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. 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://svn.FreeBSD.org/doc/. Código fonte das páginas de manual estão disponíveis em um repositório diferente localizado em https://svn.FreeBSD.org/base/. As mensagens de commit de documentação podem ser visualizadas com svn log. As mensagens de commit também são arquivadas em http://lists.FreeBSD.org/mailman/listinfo/svn-doc-all. Endereço web para ambos os repositórios disponíveis em e . 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. 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. Ferramentas Obrigatórias Instale o textproc/docproj pela Coleção de Ports. Este meta-port instala todos os aplicativos necessários para trabalhar com a documentação do FreeBSD. Informações adicionais específicas de alguns componentes serão informadas abaixo. <acronym>DTD</acronym>s e <acronym>Entidades</acronym> A documentação do FreeBSD utiliza diversas Definições de Tipos de Documento (DTDs) e conjuntos de entidades XML. Estes são todos instalados pelo port textproc/docproj. XHTML DTD (textproc/xhtml) XHTML é a linguagem markup escolhida pela Web, e é utilizada em todo o site do FreeBSD. DocBook DTD (textproc/docbook-xml) O DocBook é projetado para escrever documentação técnica. A maior parte da documentação do FreeBSD é escrita no DocBook. Entidades ISO 8879 (textproc/iso8879) Entidades do padrão ISO 8879:1986 utilizado por muitos DTDs. Inclui símbolos matemáticos nomeados, caracteres adicionais no conjunto de caracteres latinos (acentos, diacríticos e assim por diante) e símbolos Gregos. Ferramentas Opcionais Essas ferramentas não são necessárias, mas podem facilitar o trabalho na documentação ou adicionar recursos. Software Vim (editors/vim) Um editor de texto popular que trabalha com XML and documentos derivados, como DocBook XML. Emacs (editors/emacs) Ambos editores incluem um modo especial para editar documentos marcados como XML DTD. Esse modo inclui comandos para reduzir a quantidade de digitação necessária e ajudar a reduzir a possibilidade de erros. 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 Subversion é utilizado para gerenciar os arquivos de documentação do FreeBSD. Ele é obtido pela instalação do pacote Subversion: # pkg install subversion 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 base para o sistema operacional e páginas de manual. Para editar páginas de manual, o repositório base deve ser registrado 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 head. 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. Baixando uma Cópia O processo de download de um repositório é chamado de checkout e é feito com um svn checkout. Este exemplo faz checkout de uma cópia da versão mais recente (head) do repositório de documentação principal: % svn checkout https://svn.FreeBSD.org/doc/head ~/doc O checkout do código-fonte para trabalhar nas páginas de manual é muito semelhante: % svn checkout https://svn.FreeBSD.org/base/head ~/src 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 svn update no diretório que contém a cópia de trabalho local: % svn update ~/doc Adquira o hábito de proteção de executar svn update antes de editar os arquivos de documentação. Alguém pode ter editado esse arquivo muito recentemente e a cópia de trabalho local não incluirá essas alterações mais recentes até que ela seja 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. 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 svn revert. Por exemplo, para apagar as alterações feitas no chapter.xml e redefini-las para o formato sem modificação: % svn revert chapter.xml 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 svn diff para um arquivo: % cd ~/doc % svn 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: svn 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 % svn diff disks/chapter.xml printers/chapter.xml > disks-printers.diff Referências <application>Subversion</application> Estes exemplos demonstram um uso muito básico do Subversion. Mais detalhes estão disponíveis no Subversion Book e na Documentação do Subversion. Estrutura de Diretórios da Documentação Arquivos e diretórios no repositório doc/ seguem uma estrutura destinada a: Facilitar a conversão do documento para outros formatos. Promover a consistência entre as diferentes organizações de documentação, e assim facilitar a alternância entre diferentes documentos. 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. O Nível Superior, <filename>doc/</filename> Existem dois tipos de diretório em doc/, cada um com nomes de diretório e significados muito específicos. Diretório Uso share Contém arquivos que não são específicos das várias traduções e codificações da documentação. Contém subdiretórios para categorizar ainda mais as informações. Por exemplo, os arquivos que fazem parte da infra-estrutura make1 estão em share/mk, enquanto o suporte adicional a arquivos XML (como o DTBook estendido do FreeBSD DTD) estão em share/xml. lang.encoding Existe um diretório para cada tradução e codificação disponível da documentação, por exemplo, en_US.ISO8859-1/ e zh_TW.UTF-8/. Os nomes são longos, mas ao especificar totalmente o idioma e a codificação, evitamos dores de cabeça futuras quando uma equipe de tradução desejar fornecer documentação no mesmo idioma, mas em mais de uma codificação. Isso também evita problemas que podem ser causados ​​por uma futura mudança para Unicode. Os Diretórios <filename><replaceable>lang</replaceable>.<replaceable>encoding</replaceable>/</filename> Esses diretórios contêm os próprios documentos. A documentação é dividida em até três outras categorias, indicadas pelos diferentes nomes de diretório. Diretório Uso articles Documentação marcada como DocBook article (ou equivalente). Conteúdo curto e dividido em seções. Normalmente disponível apenas como um arquivo XHTML. books Documentação marcada como DocBook book (ou equivalente). Conteúdo longo e dividido em capítulos. Normalmente disponível como um grande arquivo XHTML (para pessoas com conexões rápidas, ou que desejam imprimi-lo facilmente de um navegador) e como uma coleção de arquivos menores e com links. man Para traduções das páginas de manual do sistema. Esse diretório conterá um ou mais diretórios manN, correspondendo às seções que foram traduzidas. Nem todo diretório lang.encoding terá todos esses subdiretórios. Depende de quanto a tradução foi realizada por essa equipe de tradução. Informação Específica de Documentação Esta seção contém informações específicas sobre documentos gerenciados pelo FDP. O Handbook books/handbook/ O Handbook está escrito em DocBook XML usando DTD extendido do DocBook FreeBSD. O Handbook está organizado como um DocBook book. O livro é dividido em parts, cada uma contendo vários chapters. Os chapters são subdivididos em seções (sect1) e subseções (sect2, sect3) e assim por diante. Organização Física Existem vários arquivos e diretórios dentro do diretório handbook. A organização do Handbook pode ser alterada ao longo do tempo, e este documento pode estar defasado quanto ao detalhamento das mudanças organizacionais do mesmo. Envie perguntas sobre a organização do Handbook na lista de discussão do projeto FreeBSD. <filename>Makefile</filename> O Makefile define algumas variáveis ​​que afetam como o fonte XML é convertido em diversos formatos e lista os vários arquivos fontes que compõem o Handbook. Em seguida, ele inclui o doc.project.mk padrão, para inserir o restante do código que manipula a conversão de documentos de um formato para outro. <filename>book.xml</filename> Este é o principal arquivo do Handbook. Ele contém a declaração DOCTYPE, bem como os elementos que descrevem a estrutura do Handbook. book.xml utiliza entidades de parâmetro para carregar os arquivos com a extensão .ent. Esses arquivos (descritos posteriormente) e então definem as entidades gerais que são utilizadas ​​no restante do Handbook. <filename role="directory"><replaceable>directory</replaceable>/chapter.xml</filename> Cada capítulo do Handbook é armazenado em um arquivo chamado chapter.xml em um diretório separado dos outros capítulos. Cada diretório é nomeado após o valor do atributo id no elemento chapter. Por exemplo, se um dos arquivos de capítulo contiver: chapter id="kernelconfig" ... chapter Então ele será chamado de chapter.xml no diretório kernelconfig. Em geral, todo o conteúdo do capítulo está neste único arquivo. Quando a versão XHTML do Handbook for gerada, produzirá o kernelconfig.html. Isso é por causa do valor id e não está relacionado ao nome do diretório. Nas versões anteriores do Handbook, os arquivos eram armazenados no mesmo diretório que book.xml e nomeados após o valor do atributo id no elemento chapter. Agora, é possível incluir imagens em cada capítulo. Imagens para cada capítulo do Handbook são armazenadas em share/images/books/handbook. As imagens devem ser colocadas no mesmo diretório que os fontes XML para cada capítulo. As colisões de Namespace são inevitáveis ​​e é mais fácil trabalhar com vários diretórios que contenham alguns arquivos, do que trabalhar com um único diretório que contenham muitos arquivos. Com uma breve analise pode-se constatar que existem diversos diretórios com arquivos individuais chapter.xml, incluindo basics/chapter.xml, introduction/chapter.xml, e printing/chapter.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. Os arquivos chapter.xml não são arquivos completos de documentos XML que podem ser compilados individualmente. Eles só podem ser compilados como partes de todo o Handbook. O Processo de Compilação da Documentação Este capítulo aborda a organização do processo de compilação da documentação e como o make1 é utilizado para isso. Renderizando DocBook Diferentes tipos de saída podem ser produzidos a partir de um único arquivo fonte DocBook. O tipo de saída desejado é definido com a variável FORMATS. Uma lista de formatos de saída conhecidos é armazenada em KNOWN_FORMATS: % cd ~/doc/en_US.ISO8859-1/books/handbook % make -V KNOWN_FORMATS Formatos de Saída Comuns Valor FORMATS Tipo de Arquivo Descrição html HTML, arquivo único Um único book.html ou article.html. html-split HTML, vários arquivos Vários arquivos HTML, um para cada capítulo ou seção, para uso em um site comum. pdf PDF Portable Document Format
O formato de saída padrão pode variar de acordo com o documento, mas geralmente é html-split. Outros formatos são escolhidos definindo FORMATS para um valor específico. Múltiplos formatos de saída podem ser criados de uma só vez definindo FORMATS para uma lista de formatos. Compilar um Arquivo Único HTML % cd ~/doc/en_US.ISO8859-1/books/handbook % make FORMATS=html Compilar HTML-Split e <acronym>PDF</acronym> % cd ~/doc/en_US.ISO8859-1/books/handbook % make FORMATS="html-split pdf" O Conjunto de Ferramentas de Compilação da Documentação do FreeBSD Estas são as ferramentas utilizadas para compilar e instalar a documentação do FDP. A principal ferramenta de compilação é o make1, especificamente o Berkeley Make. A construção de pacotes é gerenciada pelo pkg-create8 do FreeBSD. gzip1 é usado para criar versões compactadas de um documento. bzip21 também são suportados. tar1 é usado na criação de pacotes. install1 é usado para instalar a documentação. Noções Básicas de <filename>Makefile</filename>s no Repositório de Documentação Existem três tipos principais de Makefiles no repositório de Documentação do Projeto FreeBSD. Makefiles de Subdiretório simplesmente passam os comandos para os diretórios abaixo deles. Makefiles de Documentação descrevem os documentos que devem ser produzidos a partir deste diretório. Make includes são os responsáveis pela produção do documento, e geralmente possuem o nome no formato doc.xxx.mk. <filename>Makefile</filename>s de Subdiretório Estes Makefiles geralmente tem a forma de: SUBDIR =articles SUBDIR+=books COMPAT_SYMLINK = en DOC_PREFIX?= ${.CURDIR}/.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" As quatro primeiras linhas não vazias definem as variáveis ​​do make1, SUBDIR, COMPAT_SYMLINK, e DOC_PREFIX. A declaração SUBDIR e COMPAT_SYMLINK mostram como atribuir um valor a uma variável, sobrescrevendo qualquer valor anterior que a mesma contenha. A segunda declaração SUBDIR mostra como um valor é anexado ao valor atual de uma variável. A variável SUBDIR agora é composta por articles books. A declaração DOC_PREFIX mostra como um valor é atribuído para uma variável, mas somente se ela ainda não estiver definida. Isso é útil se DOC_PREFIX não for onde este Makefilepensa que é - o usuário pode cancelar e fornecer o valor correto. Agora o que tudo isso significa? SUBDIR lista quais subdiretórios abaixo do atual devem ser incluídos no processo de compilação durante a geração do documento. O COMPAT_SYMLINK é específico para compatibilizar os links simbólicos que ligam os idiomas a sua codificação oficial (doc/en deve apontar para en_US.ISO-8859-1). O DOC_PREFIX é o caminho para a raíz da árvore do projeto de documentação do FreeBSD. O qual nem sempre é facil de encontrar, e que também pode ser facilmente sobrescrito, para permitir flexibilidade. O .CURDIR é uma variável interna do make1 que contém o caminho para o diretório atual. A linha final inclui o arquivo principal do make1 doc.project.mk do Projeto de Documentação do FreeBSD, ele é o responsável por converter estas variáveis em instruções de compilação. <filename>Makefile</filename>s de Documentação Estes conjuntos de ​​make1 Makefiles descrevem como construir a documentação contida nesse diretório. Aqui está um exemplo: MAINTAINER=nik@FreeBSD.org DOC?= book FORMATS?= html-split html INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= # SGML content SRCS= book.xml DOC_PREFIX?= ${.CURDIR}/../../.. .include "$(DOC_PREFIX)/share/mk/docproj.docbook.mk" A variável MAINTAINER permite que os committers reivindiquem a propriedade de um documento no Projeto de Documentação do FreeBSD, e sejam responsáveis ​​por mantê-lo. DOC é o nome (sem a extensão .xml) do principal documento criado por este diretório. O SRCS lista todos os arquivos individuais que compõem o documento. Ela também deve incluir os arquivos importantes, nos quais qualquer mudança deve resultar em uma reconstrução. FORMATS indica os formatos nos quais o documento deve ser gerado por padrão. INSTALL_COMPRESSED contém a lista padrão das técnicas de compressão que devem ser usadas no documento depois que ele é gerado. A variável INSTALL_ONLY_COMPRESS, nula por padrão, deve ser definida para um valor não nulo apenas se você desejar gerar exclusivamente a versão compactada do documento. Você já deve estar familiarizado com a atribuição da variável DOC_PREFIX e com as instruções de include. Includes do <application>Make</application> do Projeto de Documentação do FreeBSD make1 includes são melhor explicados por uma inspeção de código. Aqui estão os arquivos include do sistema: doc.project.mk é o principal arquivo include do projeto, que inclui todos os arquivos includes necessários. doc.subdir.mk controla a navegação na árvore de documentação durante o processo de construção e instalação. doc.install.mk fornece as variáveis que afetam a propriedade e a instalação de documentos. doc.docbook.mk é incluído se o DOCFORMAT for docbook e se a variável DOC estiver definida. <filename>doc.project.mk</filename> Por inspeção: DOCFORMAT?= docbook MAINTAINER?= doc@FreeBSD.org PREFIX?= /usr/local PRI_LANG?= en_US.ISO8859-1 .if defined(DOC) .if ${DOCFORMAT} == "docbook" .include "doc.docbook.mk" .endif .endif .include "doc.subdir.mk" .include "doc.install.mk" Variáveis As variáveis DOCFORMAT e MAINTAINER serão atribuídas com valores padrão, se o valor das mesmas não tiver sido definido no arquivo Makefile do documento. PREFIX define o caminho no qual os aplicativos de construção da documentação estão instalados. Para uma instalação normal através de pacotes e/ou ports, este caminho será sempre /usr/local. A variável PRI_LANG deve ser configurada para refletir o idioma e a codificação nativa dos usuários aos quais os documentos se destinam. O Inglês Americano é o padrão. A variável PRI_LANG de maneira alguma afeta quais documentos serão, ou que poderão, ser compilados. Sua função principal é criar links para os documentos referenciados com maior frequência no diretório raiz de instalação da documentação do FreeBSD. Condicionais A linha .if defined(DOC) é um exemplo da condicional do make 1 como em outros programas, define o comportamento se alguma condição é verdadeira ou se é falsa. defined é uma função que retorna se uma dada variável está definida ou não. A seguir, .if ${DOCFORMAT} == "docbook" testa se a variável DOCFORMAT é "docbook", e neste caso, inclue o doc.docbook.mk. Os dois .endifs fecham as duas condicionais anteriores, marcando o fim da sua aplicação. <filename>doc.subdir.mk</filename> Este arquivo é muito longo para ser explicado em detalhes. Estas notas descrevem as principais funcionalidades. Variáveis SUBDIR é a lista de subdiretórios nos quais o processo de construção deve ser executado. ROOT_SYMLINKS são os nomes dos diretórios que devem ser linkados para a raíz de instalação do documento a partir da sua localização atual, se o idioma atual for o idioma primário (especificado por PRI_LANG). COMPAT_SYMLINK já foi descrito na seção Makefiles de Subdiretório. Targets e Macros As dependências são descritas por target: dependência1 dependência2 ..., nas quais, para construir o target, é necessário primeiramente construir as dependências informadas. Depois desta descrição, instruções de como construir o target podem ser passadas, no caso do processo de conversão entre o target e estas dependências não tiver sido previamente definido, ou se esta conversão em particular não for a mesma que a definida pelo método padrão de conversão. A dependência especial .USE define o equivalente a uma macro. _SUBDIRUSE: .USE .for entry in ${SUBDIR} @${ECHO} "===> ${DIRPRFX}${entry}" @(cd ${.CURDIR}/${entry} && \ ${MAKE} ${.TARGET:S/realpackage/package/:S/realinstall/install/} DIRPRFX=${DIRPRFX}${entry}/ ) .endfor No código acima, _SUBDIRUSE é agora uma macro, a qual irá executar determinados comandos quando for listada como dependência. O que diferencia essa macro de outros targets? Basicamente, ela é executada após as instruções passadas no processo de construção por ser uma dependência para o mesmo, e ela não configura o .TARGET, que é a variável que contém o nome do target atual que está sendo construído. clean: _SUBDIRUSE rm -f ${CLEANFILES} No código acima, o clean usará a macro _SUBDIRUSE depois de ter executado a instrução rm -f $ {CLEANFILES}. De fato, isso faz com que clean vá mais a fundo na árvore de diretórios, excluindo os arquivos construídos à medida que vai descendo pelos subdiretórios, e não quando vai na direção oposta. Targets Fornecidos install e package ambos percorrem a árvore de diretórios executando as suas versões reais dentro dos subdiretórios (realinstall e realpackage respectivamente). clean remove arquivos criados pelo processo de compilação (e também desce na árvore de diretórios). cleandir faz a mesma coisa, e também remove o diretório de objetos se este existir. Mais Condicionais exists é outra função condicional que retorna verdadeiro se o arquivo informado existir. empty retorna verdadeiro se a variável informada estiver vazia. target retorna verdadeiro se o target informado ainda não existir. Construções de Looping no <command>make (.for)</command> .for fornece uma maneira de repetir instruções definidas para cada elemento separado por espaço em uma variável. Ele faz isso atribuíndo uma variável para conter o elemento atual da lista que está sendo examinada. _SUBDIRUSE: .USE .for entry in ${SUBDIR} @${ECHO} "===> ${DIRPRFX}${entry}" @(cd ${.CURDIR}/${entry} && \ ${MAKE} ${.TARGET:S/realpackage/package/:S/realinstall/install/} DIRPRFX=${DIRPRFX}${entry}/ ) .endfor No código acima, se SUBDIR estiver vazia, nenhuma ação será executada; se ela possuir um ou mais elementos, as instruções entre .for e .endfor serão repetidas para cada elemento, com o entry sendo substituído com o valor do elemento atual. O Website O web site do FreeBSD é parte da documentação do FreeBSD. Os arquivos para o web site são armazenados no subdiretório en_US.ISO8859-1/htdocs do repositório ~/doc neste exemplo. Variáveis ​​de Ambiente Diversas variáveis ​​de ambiente controlam quais partes do web site são compiladas ou instaladas e para quais diretórios. O sistema de compilação do web site utiliza o make1, e valida variáveis configuradas mesmo se estiverem vazias. Os exemplos aqui mostram as formas recomendadas de configurar e utilizar essas variáveis. Definir ou configurar essas variáveis ​​com outros valores ou métodos pode levar a surpresas inesperadas. DOCDIR DOCDIR especifica o caminho onde os arquivos do web site devem ser instalados. Esta variável é melhor configurada com env1 ou o método do shell do usuário para configurar variáveis ​​de ambiente, setenv para csh1 ou export para sh1. ENGLISH_ONLY Padrão: indefinido. Compile e inclua todas as traduções. ENGLISH_ONLY=yes: compile apenas os documentos em Inglês e ignore todas as traduções. WEB_ONLY Padrão: indefinido. Compile o web site e todos os livros e artigos. WEB_ONLY=yes: Compile ou instale apenas páginas HTML do diretório en_US.ISO8859-1/htdocs. Outros diretórios e documentos, incluindo livros e artigos, serão ignorados. WEB_LANG Padrão: indefinido. Compile e inclua todos os idiomas disponíveis no web site. Defina com uma lista separada por espaços, todos os idiomas a serem incluídos na compilação ou instalação. Os formatos são os mesmos que os nomes de diretório no diretório raiz do documento. Por exemplo, para incluir os documentos alemão e francês: WEB_LANG="de_DE.ISO8859-1 fr_FR.ISO8859-1" WEB_ONLY, WEB_LANG, e ENGLISH_ONLY são variáveis make1 que​e podem ser definidas em /etc/make.conf, Makefile.inc, como variáveis ​​de ambiente na linha de comando, ou em arquivos dot. Compilando e Instalando as Páginas Web Após obter os arquivos fontes da documentação e web site, o site pode ser compilado. Uma instalação real do web site precisa ser executada pelo usuário root porque as permissões no diretório do servidor web não permitirão a instalação de arquivos por um usuário não privilegiado. Para testar, pode ser útil instalar os arquivos com um usuário normal em um diretório temporário. Nestes exemplos, os arquivos do web site são criados pelo usuário jru em seu diretório home, ~/doc, com um caminho completo de /usr/home/jru/doc. A compilação do web site utiliza o arquivo INDEX da Coleção de Ports e pode falhar se este arquivo ou /usr/ports não estiver presente no sistema. A abordagem mais simples é instalar a Coleção de Ports. Compile o Web Site Completo e Todos Documentos Compile o web site e todos os documentos. Os arquivos finais são deixados na árvore de documento: % cd ~/doc/en_US.ISO8859-1/htdocs/ % make all Compile Apenas o Web Site em Inglês Compile o web site apenas em Inglês, como usuário jru, e instale os arquivos finais em /tmp/www para teste: % cd ~/doc/en_US.ISO8859-1/htdocs/ % env DOCDIR=/tmp/www make ENGLISH_ONLY=yes WEB_ONLY=yes all install Alterações em arquivos estáticos geralmente podem ser testadas visualizando os arquivos modificados diretamente com um navegador web. Se o web site foi construído como apresentado acima, a página principal modificada pode ser visualizada com: % firefox /tmp/www/data/index.html Modificações em arquivos dinâmicos podem ser testadas com um servidor web rodando no sistema local. Depois de construir o site como apresentado acima, o /usr/local/etc/apache24/httpd.conf pode ser usado com www/apache24: # httpd.conf for testing the FreeBSD website Define TestRoot "/tmp/www/data" # directory for configuration files ServerRoot "/usr/local" Listen 80 # minimum required modules LoadModule authz_core_module libexec/apache24/mod_authz_core.so LoadModule mime_module libexec/apache24/mod_mime.so LoadModule unixd_module libexec/apache24/mod_unixd.so LoadModule cgi_module libexec/apache24/mod_cgi.so LoadModule dir_module libexec/apache24/mod_dir.so # run the webserver as user and group User www Group www ServerAdmin you@example.com ServerName fbsdtest # deny access to all files <Directory /> AllowOverride none Require all denied </Directory> # allow access to the website directory DocumentRoot "${TestRoot}" <Directory "${TestRoot}"> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory> # prevent access to .htaccess and .htpasswd files <Files ".ht*"> Require all denied </Files> ErrorLog "/var/log/httpd-error.log" LogLevel warn # set up the CGI script directory <Directory "${TestRoot}/cgi"> AllowOverride None Options None Require all granted Options +ExecCGI AddHandler cgi-script .cgi </Directory> Include etc/apache24/Includes/*.conf Inicie o servidor web com # service apache24 onestart O web site pode ser visualizado em . Esteja ciente de que muitos links se referem ao site real do FreeBSD por nome, e esses links ainda levar para o site externo em vez da versão de teste local. O teste completo do web site local exigirá a configuração temporária do DNS para que o endereço www.FreeBSD.org seja resolvido como localhost ou o endereço IP local. Compile e Instale o Web Site Compile o web site e todos os documentos como usuário jru. Instale os arquivos finais como root no diretório padrão, /root/public_html: % cd ~/doc/en_US.ISO8859-1/htdocs % make all % su - Password: # cd /usr/home/jru/doc/en_US.ISO8859-1/htdocs # make install O processo de instalação não exclui nenhum arquivo antigo ou desatualizado que existia anteriormente no mesmo diretório. Se uma nova cópia do web site for criada e instalada todos os dias, esse comando localizará e excluirá todos os arquivos que não foram atualizados em três dias: # find /usr/local/www -ctime 3 -delete Primer XML A maioria das documentações do FDP é escrita com linguagens markup baseadas em XML. Este capítulo explica o que isso significa, como ler e entender os arquivos fontes da documentação e as técnicas de XML utilizadas. Partes desta seção foram inspiradas por Mark Galassi's Get Going With DocBook. 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, use rm1. % 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. Markup é geralmate utilizado assim adicionando valor ou aumentando o custo. O termo tem seus significados realçados quando aplicado ao texto. Markup é um texto adicional incluído no documento, diferenciado de alguma forma do conteúdo do documento, para que os programas que processam o documento possam ler a marcação e utiliza-la ao tomar decisões sobre o documento. Os editores podem ocultar o markup do usuário, para que este não se distraia com ela. A informação extras armazenada no markup adiciona valor ao documento. Adicionar markup ao documento normalmente deve ser feito por uma pessoa - afinal, se os computadores pudessem reconhecer o texto suficientemente bem para adicionar a markup, não haveria necessidade de utilizar markup. Isto aumenta o custo (o esforço necessário) para criar algum documento. O exemplo anterior é representado neste documento da seguinte forma: paraPara remover filename/tmp/foofilename, use &man.rm.1;.para screen&prompt.user; userinputrm /tmp/foouserinputscreen O markup é claramente separado do conteúdo. As linguagens markup definem o que as marcações significam e como elas devem ser interpretadas. Claro, uma linguagem markup pode não ser suficiente. Uma linguagem markup para documentação técnica tem requisitos muito diferentes de uma linguagem markup destinada a receitas de culinária. Isso, por sua vez, seria muito diferente de uma linguagem markup utilizada para descrever uma poesia. O que é realmente necessário é uma primeira linguagem utilizada para escrever essas outras linguagens markup. Uma meta linguagem markup. É exatamente isso que a eXtensible Markup Language (XML) é. Muitas linguagens markup foram escritas em XML, incluindo as duas mais utilizadas pelo FDP, XHTML e DocBook. Cada definição de idioma é mais apropriadamente chamada de gramática, vocabulário, esquema ou Definição de Tipo de Documento (DTD). Existem vários idiomas para especificar uma gramática XML ou um schema. Um schema é uma especificação completa de todos os elementos que podem ser utilizados, a ordem em que devem aparecer, quais elementos são obrigatórios, quais são opcionais e assim por diante. Isso torna possível escrever um XML parser que lê tanto o schema quanto um documento que afirma estar em conformidade com o schema. O parser pode confirmar se todos os elementos exigidos pelo vocabulário estão ou não na ordem correta do documento ou se há algum erro no markup. Isto é normalmente conhecido como a valiidação do documento. A validação confirma se a escolha dos elementos, sua ordenação e assim por diante estão em conformidade com os listados na gramática. Ela não valida se o markup correto foi utilizado no conteúdo. Se todos os nomes de arquivo em um documento fossem marcados como sendo nomes de função, o analisador não sinalizaria isso como um erro (supondo, é claro, que o schema define elementos para nomes de arquivos e funções e que eles possam aparecer no mesmo local). A maioria das contribuições no Projeto de Documentação utilizará markup XHTML ou DocBook, em vez de alterações nos schemas. Por esse motivo, este livro não abordará como escrever um vocabulário. Elementos, Tags e Atributos Todos os vocabulários escritos em XML compartilham certas características. Isso não surpreende, pois a filosofia por trás do XML inevitavelmente irá transparecer. Uma das manifestações mais óbvias desta filosofia é a do conteúdo e dos elementos. A documentação, seja uma única página web ou um livro extenso, é considerada como conteúdo. Este conteúdo é então dividido e subdividido em elementos. A finalidade de adicionar markup é nomear e identificar os limites desses elementos para processamento futuro. Por exemplo, considere um livro típico. No maior nível, o livro é um elemento. Este elemento livro contém obviamente capítulos, que podem ser considerados elementos também. Cada capítulo conterá mais elementos, como parágrafos, citações e notas de rodapé. Cada parágrafo pode conter outros elementos, identificando o conteúdo que foi um discurso direto ou o nome de um personagem na história. Pode ser útil pensar nisso como um conteúdo por pedaços. No nível mais alto é um pedaço, o livro. Olhando um pouco mais, encontra-se mais pedaços, os capítulos individuais. Estes são segmentados em parágrafos, notas de rodapé, nomes de caracteres e assim por diante. Observe como essa diferenciação entre diferentes elementos do conteúdo pode ser feita sem recorrer a quaisquer termos XML. É realmente surpreendentemente simples. Isso pode ser feito com uma caneta marca-texto e um livro impresso, usando cores diferentes para indicar diferentes partes do conteúdo. É claro que não temos um marca-texto eletrônico, então precisamos de outra maneira de indicar a qual elemento cada parte do conteúdo pertence. Em idiomas escritos em XML (XHTML, DocBook, e outros) isto é feito por meio de tags. Uma tag é usada para identificar onde um determinado elemento começa e onde o elemento termina. A tag não faz parte do próprio elemento. Como cada gramática foi normalmente escrita para marcar tipos específicos de informação, cada um reconhecerá elementos diferentes e, portanto, terá nomes diferentes para as tags. Para um elemento chamado nome-do-elemento, a tag inicial normalmente se parecerá com nome-do-elemento. A tag de fechamento correspondente para este elemento é nome-do-elemento. Utilizando um Elemento (Tag Inicial e Final) XHTML possui um elemento para indicar que o conteúdo incluído pelo elemento é um parágrafo, chamado p. pThis is a paragraph. It starts with the start tag for the 'p' element, and it will end with the end tag for the 'p' element.p pThis is another paragraph. But this one is much shorter.p Alguns elementos não possuem conteúdo. Por exemplo, em XHTML, uma linha horizontal pode ser incluída no documento. Para estes elementos vazios, XML trouxe um formato abreviado que é completamente equivalente à versão de duas tags: Usando um Elemento Sem Conteúdo XHTML tem um elemento para indicar uma linha horizontal, chamada hr. Esse elemento não possui conteúdo, e se parece com isso: pOne paragraph.p hrhr pThis is another paragraph. A horizontal rule separates this from the previous paragraph.p A versão abreviada consiste em uma única tag: pOne paragraph.p hr pThis is another paragraph. A horizontal rule separates this from the previous paragraph.p Como mostrado acima, os elementos podem conter outros elementos. No exemplo do livro anterior, o elemento livro continha elementos de capítulo, que por sua vez continham elementos de parágrafo, e assim por diante. Elementos Dentro de Elementos; <tag>em</tag> pThis is a simple emparagraphem where some of the emwordsem have been ememphasizedem.p A gramática consiste em regras que descrevem quais elementos podem conter outros elementos e exatamente o que eles podem conter. As pessoas geralmente confundem os termos tags e elementos e usam os termos como se fossem intercambiáveis. Eles não são. Um elemento é uma parte conceitual do seu documento. Um elemento tem início e fim definidos. As tags marcam onde o elemento começa e termina. Quando este documento (ou qualquer pessoa com conhecimento sobre XML) refere-se a a p tag significa o texto literal que consiste nos três caracteres <, p, e >. Mas a frase o elemento p refere-se ao elemento inteiro. Essa distinção é muito sutil. Mas tenha isso em mente. Elementos podem ter atributos. Um atributo tem um nome e um valor e é usado para adicionar informações extras ao elemento. Isso pode ser uma informação que indica como o conteúdo deve ser renderizado ou pode ser algo que identifica exclusivamente essa ocorrência do elemento ou isso pode ser outra coisa também. Os atributos de um elemento são escritos dentro da tag de início para aquele elemento, e toma o formato nome-do-atributo="valor-do-atributo". Em XHTML, o elemento p tem um atributo chamado align, que sugere um alinhamento (justificação) do parágrafo para o programa exibindo o XHTML. O atributo align pode ter um dos quatro valores definidos, left, center, right e justify. Se o atributo não for especificado, o padrão será left. Usando um Elemento com um Atributo p align="left"The inclusion of the align attribute on this paragraph was superfluous, since the default is left.p p align="center"This may appear in the center.p Alguns atributos só aceitam valores específicos, como left ou justify. Outros permitem qualquer valor. Aspas Simples nos Atributos p align='right'I am on the right!p Os valores de atributos em XML devem ser colocados entre aspas simples ou duplas. Aspas duplas são tradicionais. Aspas simples são úteis quando o valor do atributo contém aspas duplas. Informações sobre atributos, elementos e tags são armazenadas em arquivos de catálogo. O Projeto de Documentação usa catálogos padrão do DocBook e inclui catálogos adicionais para recursos específicos do FreeBSD. Os caminhos para os arquivos de catálogo são definidos em uma variável de ambiente para que possam ser encontradas pelas ferramentas de compilação de documentos. Para Fazer… Antes de rodar os exemplos deste documento, instale o textproc/docproj pela Coleção de Ports do FreeBSD. Este é um meta-port que baixa e instala os programas padrão e arquivos de suporte necessários para o Projeto de Documentação. Os usuários de csh1 devem executar o rehash para que o shell reconheça os novos binários depois de instalados ou efetue logout e, em seguida, faça login novamente. Crie example.xml e insira este texto: !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" html xmlns="http://www.w3.org/1999/xhtml" head titleAn Example XHTML Filetitle head body pThis is a paragraph containing some text.p pThis paragraph contains some more text.p p align="right"This paragraph might be right-justified.p body html Tente validar esse arquivo usando um parser XML. O textproc/docproj inclui o parser xmllint. Execute xmllint para validar o documento: % xmllint --valid --noout example.xml xmllint não retorna nada se o documento for validado com sucesso. Veja o que acontece quando os elementos obrigatórios são omitidos. Exclua a linha com as tags title e title, então execute novamente a validação. % xmllint --valid --noout example.xml example.xml:5: element head: validity error : Element head content does not follow the DTD, expecting ((script | style | meta | link | object | isindex)* , ((title , (script | style | meta | link | object | isindex)* , (base , (script | style | meta | link | object | isindex)*)?) | (base , (script | style | meta | link | object | isindex)* , title , (script | style | meta | link | object | isindex)*))), got () Isso mostra que o erro de validação vem da linha cinco do arquivo example.xml e que o conteúdo de head é a parte que não segue as regras da gramática XHTML. Em seguida, o xmllint mostra a linha onde o erro foi encontrado e marca a posição exata com um sinal ^. Substitua o elemento title. A Declaração DOCTYPE No início de cada documento pode-se especificar o nome do DTD ao qual o documento está em conformidade. Esta declaração DOCTYPE é usada por XML parsers para identificar o DTD e garantir que o documento esteja de acordo com ele. Uma declaração típica para um documento escrito em conformidade com a versão 1.0 do XHTML DTD se parece com isto: !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" Essa linha contém vários componentes diferentes. <! O indicador mostra que esta é uma declaração XML. DOCTYPE Mostra que esta é uma declaração XML do tipo de documento. html Nomeia o primeiro elemento que aparecerá no documento. PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" Lista o Identificador Público Formal (FPI) Formal Public Identifier para o DTD com o qual este documento está em conformidade. O XML parser usa isso para encontrar o DTD correto ao processar este documento. PUBLIC não faz parte do FPI, mas indica ao XML parser como encontrar o DTD mencionado no FPI. Outras formas de informar ao XML parser como encontrar o DTD serão informadas depois. "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" Um nome de arquivo local ou uma URL para encontrar o DTD. > Termina a declaração e retorna ao documento. Identificadores Públicos Formais (<acronym>FPI</acronym>s) Identificador Público Formal Não é necessário conhecer isso, mas pode ser útil e ajudar a depurar problemas quando o XML parser não conseguir localizar o DTD. FPIs devem seguir uma sintaxe específica: "Proprietário //Palavra-chave Descrição //Idioma" Proprietário O proprietário do FPI. O início da string identifica o proprietário do FPI. Por exemplo, o FPI "ISO 8879:1986//ENTITIES Greek Symbols//EN" lista ISO 8879:1986 como sendo o proprietário para o conjunto de entidades de Símbolos Gregos. ISO 8879:1986 é o número na International Organization for Standardization (ISO) para o padrão SGML, o predecessor (e um superset) do XML. Caso contrário, essa sequência seria parecida com -//Proprietário ou +//Proprietário (observe que a única diferença é o + ou -). Se a string começar com -, a informação do proprietário não é registrada, com o + identifica como registrada. A ISO 9070:1991 define como os nomes registrados são gerados. Pode ser derivado do número de uma publicação ISO, um código ISBN ou um código de organização atribuído de acordo com a ISO 6523. Além disso, uma autoridade de registro poderia ser criada para atribuir nomes registrados. O conselho da ISO delegou isso ao American National Standards Institute (ANSI). Como o Projeto FreeBSD não foi registrado, a string de propriedade é -//FreeBSD. Como visto no exemplo, a W3C também não é registrada. Palavra-chave Existem várias palavras-chave que indicam o tipo de informação no arquivo. Algumas das palavras-chave mais comuns são DTD, ELEMENT, ENTITIES e TEXT. DTD é usada apenas para arquivos DTD, ELEMENT é normalmente usada para fragmentos DTD que contêm apenas declarações de elementos ou entidades. TEXT é usada para conteúdo XML (texto e tags). Descrição Qualquer descrição pode ser informada no conteúdo deste campo. Isso pode incluir números de versão ou qualquer texto curto que tenha significado e seja exclusivo para o sistema XML. Idioma Um código de dois caracteres ISO que identifica o idioma nativo do arquivo. EN é usado para o Inglês. Arquivos <filename>catalog</filename> Com a sintaxe acima, um XML parser precisa ter alguma forma de transformar o FPI no nome do arquivo que contém o DTD. Um arquivo de catálogo (normalmente chamado de catalog) contém linhas que mapeiam FPIs para nomes de arquivos. Por exemplo, se o arquivo de catálogo continha a linha: PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "1.0/transitional.dtd" O XML parser sabe que o DTD é chamado de transitional.dtd no subdiretório 1.0 do diretório que continha catalog. Examine o conteúdo de /usr/local/share/xml/dtd/xhtml/catalog.xml. Este é o arquivo de catálogo dos XHTML DTD s que foram instalados como parte do port textproc/docproj . Alternativas para <acronym>FPI</acronym> s Em vez de usar uma FPI para indicar o DTD ao qual o documento está em conformidade (e, portanto, qual arquivo no sistema contém o DTD), o arquivo pode ser explicitamente especificado. A sintaxe é um pouco diferente: !DOCTYPE html SYSTEM "/path/to/file.dtd" A palavra-chave SYSTEM indica que o XML parser deve localizar o DTD de uma maneira específica no sistema. Isso normalmente (mas nem sempre) significa que o DTD será fornecido como um nome de arquivo. Usando FPIs é preferível por razões de portabilidade. Se o identificador SYSTEM for usado, então o DTD deve ser fornecido e mantido no mesmo local para todos. De Volta para o <acronym>XML</acronym> Algumas das sintaxes subjacentes do XML podem ser úteis em documentos. Por exemplo, os comentários podem ser incluídos no documento e serão ignorados pelo parser. Os comentários são inseridos usando a sintaxe XML. Outros usos para a sintaxe XML serão mostrados mais tarde. Seções XML começam com uma tag <! e terminam com >. Essas seções contêm instruções para o parser em vez de elementos do documento. Tudo entre essas tags são sintaxe XML. A declaração DOCTYPE mostrada anteriormente é um exemplo da sintaxe XML incluída no documento. Comentários Um documento XML pode conter comentários. Eles podem aparecer em qualquer lugar, desde que não estejam dentro de tags. Eles até são permitidos em alguns locais dentro do DTD (por exemplo, entre declarações de entidade). Os comentários XML começam com a string <!-- e terminam com a string -->. Aqui estão alguns exemplos de comentários válidos de XML: <acronym>XML</acronym> Comentários Genéricos <!-- This is inside the comment --> <!--This is another comment--> <!-- This is how you write multiline comments --> <p>A simple <!-- Comment inside an element's content --> paragraph.</p> Os comentários XML podem conter quaisquer strings, exceto --: Comentário <acronym>XML</acronym> Incorreto <!-- This comment--is wrong --> Para Fazer… Adicione alguns comentários ao arquivo example.xml e depois o valide utilizando o xmllint. Adicione alguns comentários inválidos ao arquivo example.xml e veja as mensagens de erros que o xmllint irá retornar quando encontrar algum comentário inválido. Entidades Entidades são um mecanismo para atribuir nomes a partes do conteúdo. À medida que um XML parser processa um documento, qualquer entidade encontrada é substituída pelo conteúdo da entidade. Esta é uma boa maneira de ter pedaços de conteúdo reutilizáveis ​​e facilmente alteráveis ​​em documentos XML. Também é a única maneira de incluir um arquivo markup dentro de outro usando XML. Existem dois tipos de entidades para duas situações diferentes: entidades gerais e entidades de parâmetros. Entidades Gerais Entidades gerais são usadas para atribuir nomes a partes reutilizáveis ​​de texto. Essas entidades só podem ser usadas no documento. Elas não podem ser usadas ​​em um contexto XML. Para incluir o texto de uma entidade geral no documento, inclua &nome-da-entidade; no texto. Por exemplo, considere uma entidade geral chamada current.version, que se expande para o número da versão atual de um produto. Para usá-la no documento, escreva: paraThe current version of our product is &current.version;.para Quando o número da versão for alterado, edite a definição da entidade geral, substituindo o valor. Em seguida, reprocesse o documento. Entidades gerais também podem ser usadas para inserir caracteres que não poderiam ser incluídos em um documento XML. Por exemplo, < e & normalmente não podem aparecer em um documento XML. O XML parser vê o símbolo < como o início de uma tag. Da mesma forma, quando o símbolo & é visto, espera-se que o próximo texto seja um nome de entidade. Esses símbolos podem ser incluídos usando duas entidades gerais predefinidas: &lt; e &amp;. Entidades gerais só podem ser definidas dentro de um contexto XML. Tais definições geralmente são feitas imediatamente após a declaração DOCTYPE. Definindo Entidades Gerais <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY current.version "3.0-RELEASE"> <!ENTITY last.version "2.2.7-RELEASE"> ]> A declaração DOCTYPE foi estendida adicionando um colchete no final da primeira linha. As duas entidades são então definidas nas próximas duas linhas, o colchete é fechado e, em seguida, a declaração DOCTYPE é fechada. Os colchetes são necessários para indicar que o DTD indicado pela declaração DOCTYPE está sendo estendido. Entidades de Parâmetro Entidades de parâmetro, como as entidades gerais, são usadas para atribuir nomes a blocos reutilizáveis ​​de texto. Mas as entidades de parâmetro só podem ser usadas dentro de um contexto XML. As definições de entidade de parâmetro são semelhantes àquelas para entidades gerais. No entanto, entradas de parâmetros são incluídas com %nome-da-entidade;. A definição também inclui o % entre a palavra-chave ENTITY e o nome da entidade. Para memorizar, lembre que entidade deParâmetro utiliza o símbolo de Porcentagem. Definindo Entidades de Parâmetro <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY % entity "<!ENTITY version '1.0'>"> <!-- use the parameter entity --> %entity; ]> À primeira vista, as entidades de parâmetros não parecem muito úteis, mas elas tornam possível incluir outros arquivos em um documento XML. Para Fazer… Adicione uma entidade geral ao arquivo example.xml. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY version "1.1"> ]> html xmlns="http://www.w3.org/1999/xhtml" head titleAn Example XHTML Filetitle head <!-- There may be some comments in here as well --> body pThis is a paragraph containing some text.p pThis paragraph contains some more text.p p align="right"This paragraph might be right-justified.p pThe current version of this document is: &version;p body html Valide o documento usando o xmllint. Carregue example.xml em um navegador web. Ele pode ter que ser copiado para o example.html antes que o navegador o reconheça como um documento XHTML. Navegadores mais antigos com parsers simples podem não renderizar esse arquivo conforme o esperado. A referência de entidade &version; pode não ser substituída pelo número da versão, ou o fechamento de contexto XML ]> pode não ser reconhecido e em vez disso, apresentado literalmente. A solução é normalizar o documento com um normalizador XML. O normalizador lê um XML válido e grava outro XML igualmente válido. Uma maneira pela qual o normalizador transforma a entrada é expandindo todas as referências de entidade no documento, substituindo as entidades pelo texto que elas representam. O xmllint pode ser usado para isso. Ele também tem a opção de remover a seção inicial DTD para que ]> não confunda os navegadores: % xmllint --noent --dropdtd example.xml > example.html Uma cópia normalizada do documento com entidades expandidas é produzida em example.html, pronta para ser carregada em um navegador web. Usando Entidades para Incluir Arquivos Ambas as entidades geral e parâmetro são particularmente úteis para incluir um arquivo dentro de outro . Usando Entidades Gerais para Incluir Arquivos Considere algum conteúdo para um livro XML organizado em arquivos, um arquivo por capítulo, chamado chapter1.xml, chapter2.xml e assim por diante, com um book.xml que conterá esses capítulos. Para usar o conteúdo desses arquivos como valores para entidades, eles são declarados com a palavra-chave SYSTEM. Isso direciona o XML parser a incluir o conteúdo do arquivo nomeado como o valor da entidade. Usando Entidades Gerais para Incluir Arquivos <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY chapter.1 SYSTEM "chapter1.xml"> <!ENTITY chapter.2 SYSTEM "chapter2.xml"> <!ENTITY chapter.3 SYSTEM "chapter3.xml"> <!-- And so forth --> ]> html xmlns="http://www.w3.org/1999/xhtml" <!-- Use the entities to load in the chapters --> &chapter.1; &chapter.2; &chapter.3; html Ao usar entidades gerais para incluir outros arquivos em um documento, os arquivos que estão sendo incluídos ( chapter1.xml, chapter2.xml e assim por diante) não devem começar com uma declaração DOCTYPE. Este é um erro de sintaxe porque as entidades são constructors de baixo nível e são transformadas antes que qualquer análise ocorra. Usando Entidades de Parâmetro para Incluir Arquivos As entidades de parâmetro só podem ser usadas dentro de um contexto XML. A inclusão de um arquivo em um contexto XML pode ser usada para garantir que as entidades gerais sejam reutilizáveis. Suponha que haja muitos capítulos no documento, e esses capítulos foram reutilizados em dois livros diferentes, cada livro organizando os capítulos de maneira diferente. As entidades podem ser listadas no topo de cada livro, mas isso rapidamente se torna difícil de gerenciar. Em vez disso, coloque as definições gerais da entidade em um arquivo e use uma entidade de parâmetro para incluir esse arquivo no documento. Usando Entidades de Parâmetro para Incluir Arquivos Coloque as definições de entidade em um arquivo separado chamado chapters.ent contendo este texto: <!ENTITY chapter.1 SYSTEM "chapter1.xml"> <!ENTITY chapter.2 SYSTEM "chapter2.xml"> <!ENTITY chapter.3 SYSTEM "chapter3.xml"> Crie uma entidade de parâmetro para se referir ao conteúdo do arquivo. Em seguida, use a entidade de parâmetro para carregar o arquivo no documento, o que tornará todas as entidades gerais disponíveis para uso. Em seguida, use as entidades gerais como antes: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!-- Define a parameter entity to load in the chapter general entities --> <!ENTITY % chapters SYSTEM "chapters.ent"> <!-- Now use the parameter entity to load in this file --> %chapters; ]> html xmlns="http://www.w3.org/1999/xhtml" &chapter.1; &chapter.2; &chapter.3; html Para Fazer… Use Entidades Gerais para Incluir Arquivos Crie três arquivos, para1.xml, para2.xml e para3.xml. Coloque conteúdo como este em cada arquivo: pThis is the first paragraph.p Edite example.xml para que fique assim: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY version "1.1"> <!ENTITY para1 SYSTEM "para1.xml"> <!ENTITY para2 SYSTEM "para2.xml"> <!ENTITY para3 SYSTEM "para3.xml"> ]> html xmlns="http://www.w3.org/1999/xhtml" head titleAn Example XHTML Filetitle head body pThe current version of this document is: &version;p &para1; &para2; &para3; body html Gere example.html ao normalizar example.xml. % xmllint --dropdtd --noent example.xml > example.html Carregue example.html no navegador web e confirme se os arquivos paran.xml foram incluídos em example.html. Use Entidades de Parâmetro para Incluir Arquivos As etapas anteriores devem ser concluídas antes dessa etapa. Edite example.xml para que fique assim: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY % entities SYSTEM "entities.ent"> %entities; ]> html xmlns="http://www.w3.org/1999/xhtml" head titleAn Example XHTML Filetitle head body pThe current version of this document is: &version;p &para1; &para2; &para3; body html Crie um novo arquivo chamado entities.ent com este conteúdo: <!ENTITY version "1.1"> <!ENTITY para1 SYSTEM "para1.xml"> <!ENTITY para2 SYSTEM "para2.xml"> <!ENTITY para3 SYSTEM "para3.xml"> Gere example.html ao normalizar example.xml. % xmllint --dropdtd --noent example.xml > example.html Carregue example.html no navegador web e confirme se os arquivos paran.xml foram incluídos em example.html. Seções Marcadas XML fornece um mecanismo para indicar que partes específicas do documento devem ser processadas de uma maneira especial. Estes são chamados de seções marcadas. Estrutura de uma Seção Marcada <![KEYWORD[ Contents of marked section ]]> Como esperado de um construct XML, uma seção marcada começa com <!. O primeiro colchete inicia a seção marcada. KEYWORD descreve como esta seção marcada deve ser processada pelo parser. O segundo colchete indica o início do conteúdo da seção marcada. A seção marcada é concluída, fechando os dois colchetes e, em seguida, retornando ao contexto do documento do contexto XML com >. Palavras-chave da Seção Marcada <literal>CDATA</literal> Essas palavras-chave indicam as seções marcadas pelo modelo de conteúdo e permitem que você a altere do padrão. Quando um XML parser está processando um documento, ele acompanha o modelo de conteúdo. O modelo de conteúdo descreve o conteúdo que o parser espera ver e o que ele fará com esse conteúdo. O modelo de conteúdo CDATA é um dos mais úteis. CDATA é para Dados de Caractere. Quando o parser está neste modelo de conteúdo, ele espera ver apenas caracteres. Nesse modelo, os símbolos < e & perdem seu status especial e serão tratados como caracteres comuns. Ao usar CDATA em exemplos de texto marcados em XML, lembre-se de que o conteúdo de CDATA não é validado. O texto incluído deve ser verificado por outros meios. Por exemplo, o conteúdo poderia ser escrito em outro documento, validado e depois colado na seção CDATA. Usando uma Seção Marcada <literal>CDATA</literal> paraHere is an example of how to include some text that contains many literal&lt;literal and literal&amp;literal symbols. The sample text is a fragment of acronymXHTMLacronym. The surrounding text (para and programlisting) are from DocBook.para programlisting<![CDATA[pThis is a sample that shows some of the elements within acronymXHTMLacronym. Since the angle brackets are used so many times, it is simpler to say the whole example is a CDATA marked section than to use the entity names for the left and right angle brackets throughout.p ul liThis is a listitemli liThis is a second listitemli liThis is a third listitemli ul pThis is the end of the example.p]]>programlisting <literal>INCLUDE</literal> e <literal>IGNORE</literal> Quando a palavra-chave é INCLUDE, o conteúdo da seção marcada será processado. Quando a palavra-chave é IGNORE, a seção marcada é ignorada e não será processada. Não aparecerá na saída. Usando <literal>INCLUDE</literal> e <literal>IGNORE</literal> em Seções Marcadas <![INCLUDE[ This text will be processed and included. ]]> <![IGNORE[ This text will not be processed or included. ]]> Por si só, isso não é muito útil. O texto a ser removido do documento pode ser recortado ou estar em forma de comentários. Ele se torna mais útil quando controlado por entidades de parâmetro, mas esse uso é limitado a arquivos de entidades. Por exemplo, suponha que a documentação tenha sido produzida em uma versão impressa e em uma versão eletrônica. Algum texto extra é desejado no conteúdo da versão eletrônica que não deveria aparecer na cópia impressa. Crie um arquivo de entidade que defina entidades gerais para incluir cada capítulo e proteja essas definições com uma entidade de parâmetro que pode ser definida como INCLUDE ou IGNORE para controlar se a entidade está definida . Após essas definições de entidades gerais condicionais, coloque mais uma definição para cada entidade geral para defini-las como um valor vazio. Essa técnica faz uso do fato de que as definições de entidade não podem ser substituídas, mas a primeira definição sempre entra em vigor. Assim, a inclusão do capítulo é controlada com a entidade de parâmetro correspondente. Definido como INCLUDE, a primeira definição de entidade geral será lida e a segunda será ignorada. Definido como IGNORE, a primeira definição será ignorada e a segunda será utilizada. Usando uma Entidade de Parâmetro para Controlar uma Seção Marcada <!ENTITY % electronic.copy "INCLUDE"> <![%electronic.copy;[ <!ENTITY chap.preface SYSTEM "preface.xml"> ]]> <!ENTITY chap.preface ""> Ao produzir a versão impressa, altere a definição do parâmetro de entidade para: <!ENTITY % electronic.copy "IGNORE"> Para Fazer… Modifique entidades.ent para conter o seguinte texto: <!ENTITY version "1.1"> <!ENTITY % conditional.text "IGNORE"> <![%conditional.text;[ <!ENTITY para1 SYSTEM "para1.xml"> ]]> <!ENTITY para1 ""> <!ENTITY para2 SYSTEM "para2.xml"> <!ENTITY para3 SYSTEM "para3.xml"> Normalize example.xml e observe que o texto condicional não está presente no documento de saída. Altere o parâmetro de entidade para INCLUDE e gere novamente o documento normalizado, dessa forma e o texto aparecerá novamente. Esse método faz sentido se houver mais partes condicionais dependendo da mesma condição. Por exemplo, para controlar a geração de texto impresso ou on-line. Conclusão Essa é a conclusão deste primer XML. Por razões de espaço e complexidade, vários assuntos não foram cobertos bem afundo. No entanto, as seções anteriores abrangem o suficiente de XML para apresentar a organização da documentação do FDP. <acronym>XHTML</acronym> Markup Introdução Este capítulo descreve o uso da linguagem XHTML markup usada no site do FreeBSD. XHTML é a versão XML da HyperText Markup Language, a linguagem markup escolhida na World Wide Web. Mais informações podem ser encontradas em http://www.w3.org/. XHTML é usado para escrever páginas no site do FreeBSD. Geralmente não é usado para escrever outra documentação, uma vez que o DocBook oferece um conjunto muito mais rico de elementos para se escolher. Consequentemente, as páginas XHTML normalmente só serão encontradas ao escrever para o web site. O HTML passou por várias versões. A versão compatível com XML descrita aqui é chamada XHTML. A versão mais recente generalizada é o XHTML 1.0, disponível nas variantes strict e transitional. Os XHTML DTDs estão disponíveis na Coleção de Ports em textproc/xhtml. Eles são automaticamente instalados pelo port textproc/docproj. Isto não é uma lista completa de elementos, uma vez que isso apenas repetiria a documentação de XHTML. O objetivo é listar os elementos mais utilizados. Por favor, poste perguntas sobre elementos ou usos não abordados aqui na lista de discussão do projeto de documentação do FreeBSD. Inline Versus Block No restante deste documento, ao descrever elementos, inline significa que o elemento pode estar dentro de um elemento de bloco e não causa uma quebra de linha. Um elemento block, por outro lado, causará uma quebra de linha (e outro processamento) quando for encontrado. Identificador Público Formal (<acronym>FPI</acronym>) Existem vários XHTML FPIs, dependendo da versão, ou da versão do XHTML ao qual um documento está em conformidade. A maioria dos documentos XHTML no site do FreeBSD está de acordo com a versão de transição do XHTML 1.0. PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" Seções de Elementos Um documento XHTML é normalmente dividido em duas seções. A primeira seção, chamada de head, contém meta-informações sobre o documento, como seu título, o nome do autor, o documento pai e assim por diante. A segunda seção, obody, contém o conteúdo que será exibido ao usuário. Essas seções são indicadas com os elementos head e body, respectivamente. Esses elementos estão dentro do elemento html de nível superior. Estrutura de um Documento <acronym>XHTML</acronym> html xmlns="http://www.w3.org/1999/xhtml" head titleThe Document's Titletitle head body … body html Elementos Block Cabeçalhos XHTML tem tags para indicar títulos no documento em até seis níveis diferentes. O maior e mais importante título é h1, depois h2, seguindo até h6. O conteúdo do elemento é o texto do cabeçalho. <tag>h1</tag>, <tag>h2</tag> e Outras Tags de Cabeçalho Uso: h1First sectionh1 <!-- Document introduction goes here --> h2This is the heading for the first sectionh2 <!-- Content for the first section goes here --> h3This is the heading for the first sub-sectionh3 <!-- Content for the first sub-section goes here --> h2This is the heading for the second sectionh2 <!-- Content for the second section goes here --> Geralmente, uma página XHTML deve ter um título de primeiro nível (h1). Nela pode conter muitos títulos de segundo nível (h2), que por sua vez podem conter muitos cabeçalhos de terceiro nível. Não deixe lacunas na numeração. Parágrafos O XHTML suporta um único elemento de parágrafo, p. Exemplo <tag>p</tag> Uso: pThis is a paragraph. It can contain just about any other element.p Bloco de Citações Um bloco de citação é uma citação estendida de outro documento que aparecerá em um parágrafo separado. Exemplo <tag>blockquote</tag> Uso: pA small excerpt from the US Constitution:p blockquoteWe the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.blockquote Listas O XHTML pode apresentar ao usuário três tipos de listas: ordenadas, desordenadas e de definição. Entradas em uma lista ordenada serão numeradas, enquanto as entradas em uma lista não ordenada serão precedidas por marcadores. Listas de definições têm duas seções para cada entrada. A primeira seção é o termo que está sendo definido e a segunda seção é a definição. As listas ordenadas são indicadas pelo elemento ol, listas não ordenadas pelo elemento ul e listas de definição pelo elemento dl. As listas ordenadas e não ordenadas contêm listitens, indicadas pelo elemento li. Um listitem pode conter conteúdo textual ou pode ser envoltos em um ou mais elementos p. As listas de definições contêm termos de definição (dt) e descrições de definição (dd). Um termo de definição pode conter apenas elementos in-line. Uma descrição de definição pode conter outros elementos de bloco. Exemplo <tag>ul</tag> and <tag>ol</tag> Uso: pAn unordered list. Listitems will probably be preceded by bullets.p ul liFirst itemli liSecond itemli liThird itemli ul pAn ordered list, with list items consisting of multiple paragraphs. Each item (note: not each paragraph) will be numbered.p ol lipThis is the first item. It only has one paragraph.pli lipThis is the first paragraph of the second item.p pThis is the second paragraph of the second item.pli lipThis is the first and only paragraph of the third item.pli ol Listas de Definição com <tag>dl</tag> Uso: dl dtTerm 1dt ddpParagraph 1 of definition 1.p pParagraph 2 of definition 1.pdd dtTerm 2dt ddpParagraph 1 of definition 2.pdd dtTerm 3dt ddpParagraph 1 of definition 3.pdd dl Texto Pré-formatado Texto pré-formatado é apresentado para o usuário exatamente como está no arquivo. O texto é mostrado em uma fonte fixa. Vários espaços e quebras de linha são mostrados exatamente como estão no arquivo. Deixe o texto pré-formatado no elemento pre. Exemplo <tag>pre</tag> Por exemplo, as tags pre podem ser usadas para marcar uma mensagem de email: pre From: nik@FreeBSD.org To: freebsd-doc@FreeBSD.org Subject: New documentation available There is a new copy of my primer for contributors to the FreeBSD Documentation Project available at &lt;URL:https://people.FreeBSD.org/~nik/primer/index.html&gt; Comments appreciated. Npre Tenha em mente que < e & ainda são reconhecidos como caracteres especiais no texto pré-formatado. É por isso que o exemplo mostrado teve que usar &lt; em vez de <. Para consistência, o &gt; também foi usado no lugar de >. Fique atento com os caracteres especiais que podem aparecer no texto copiado de uma fonte de texto simples, como uma mensagem de e-mail ou código de programa. Tabelas Marque as informações tabulares usando o elemento table. Uma tabela consiste em uma ou mais linhas da tabela (tr), cada uma contendo uma ou mais células de dados da tabela (td). Cada célula pode conter outros elementos de bloco, como parágrafos ou listas. Também pode conter outra tabela (esse aninhamento pode repetir indefinidamente). Se a célula contiver apenas um parágrafo, o elemento p não será necessário. Uso Simples de <tag>table</tag> Uso: pThis is a simple 2x2 table.p table tr tdTop left celltd tdTop right celltd tr tr tdBottom left celltd tdBottom right celltd tr table Uma célula pode abranger várias linhas e colunas adicionando os atributos rowspan ou colspan com valores para o número de linhas ou colunas a serem abrangido. Usando <tag class="attribute">rowspan</tag> Uso: pOne tall thin cell on the left, two short cells next to it on the right.p table tr td rowspan="2"Long and thintd tr tr tdTop celltd tdBottom celltd tr table Usando <tag class="attribute">colspan</tag> Uso: pOne long cell on top, two short cells below it.p table tr td colspan="2"Top celltd tr tr tdBottom left celltd tdBottom right celltd tr table Usando <tag class="attribute">rowspan</tag> e <tag class="attribute">colspan</tag> Juntos Uso: pOn a 3x3 grid, the top left block is a 2x2 set of cells merged into one. The other cells are normal.p table tr td colspan="2" rowspan="2"Top left large celltd tdTop right celltd tr tr <!-- Because the large cell on the left merges into this row, the first <td> will occur on its right --> tdMiddle right celltd tr tr tdBottom left celltd tdBottom middle celltd tdBottom right celltd tr table Elementos In-line Realçando Informação Dois níveis de ênfase estão disponíveis em XHTML, em e strong. em é para um nível normal de ênfase e strong indica ênfase mais forte. em é normalmente renderizado em itálico e o strong é renderizado em negrito. Isso nem sempre assim e não deve ser considerado ao pé da letra. De acordo com as práticas recomendadas, as páginas web armazenam apenas informações estruturais e semânticas, e as folhas de estilo são aplicadas posteriormente a elas. Pense na semântica, não na formatação, ao usar essas tags. Exemplo <tag>em</tag> e <tag>strong</tag> Uso: pemThisem has been emphasized, while strongthisstrong has been strongly emphasized.p Indicando Texto Fixo O conteúdo que deve ser renderizado em um tipo fixo de texto (typewriter) é marcado com tt (para teletype). Exemplo <tag>tt</tag> Uso: pMany system settings are stored in tt/etctt.p Links Links também são elementos in-line. Criando Links para Outros Documentos na Web Um link aponta para uma URL de um documento na web. O link é indicado com a a, e o atributo href contém a URL do documento de destino. O conteúdo do elemento se torna o link, indicado ao usuário, mostrando-o em uma cor diferente ou com um sublinhado. Usando <tag class="starttag">a href="..."</tag> Uso: pMore information is available at the a href="http://www.&os;.org/"&os; web sitea.p Esse link sempre leva o usuário ao topo do documento que foi linkado. Criando Links para Partes Específicas de Documentos Para linkar a um ponto específico dentro de um documento, esse documento deve incluir uma âncora no ponto desejado. As âncoras são incluídas configurando o atributo id de um elemento para um nome. Este exemplo cria uma âncora definindo o atributo id de um elemento p. Criando uma Âncora Uso: p id="samplepara"This paragraph can be referenced in other links with the name ttsampleparatt.p Links para âncoras são semelhantes aos links simples, mas incluem um símbolo # e o ID da âncora no final da URL. Criando Link para uma Parte Nomeada de um Outro Documento O exemplo samplepara é parte de um documento chamado foo.html. Um link para esse parágrafo específico no documento é construído neste exemplo. pMore information can be found in the a href="foo.html#samplepara"sample paragrapha of ttfoo.htmltt.p Para vincular-se a uma âncora nomeada no mesmo documento, omita a URLdo documento, e use apenas o símbolo # seguido do nome da âncora. Criando Link para uma Parte Nomeada no Mesmo Documento O exemplo samplepara reside neste documento. Para vincular a ele: pMore information can be found in the a href="#samplepara"sample paragrapha of this document.p DocBook Markup Introdução Este capítulo é uma introdução ao DocBook e como ele é usado na documentação do FreeBSD. O DocBook é um sistema de marcação extenso e complexo, mas o subconjunto descrito aqui abrange as partes mais usadas para a documentação do FreeBSD. Enquanto um subconjunto moderado é coberto, é impossível antecipar todas as situações. Por favor, poste questões que este documento não responde à lista de discussão do projeto de documentação do FreeBSD. DocBook foi originalmente desenvolvido por HaL Computer Systems and O'Reilly & Associates para ser uma Definição de Tipo de Documento (DTD) para escrever documentação técnica Um breve histórico pode ser encontrado em http://www.oasis-open.org/docbook/intro.shtml#d0e41.. Desde 1998, ele é mantido pelo Comitê Técnico do DocBook. Como tal, e ao contrário do LinuxDoc e do XHTML, o DocBook é fortemente orientado para um markup que descreve o que alguma coisa é, em vez de descrever como deve ser apresentado. O DocBook DTD está disponível na coleção Ports textproc/docbook-xml. Ele é instalado automaticamente como parte do port textproc/docproj. Formal Versus Informal Alguns elementos podem existir em duas formas, formal e informal. Normalmente, a versão formal do elemento consistirá em um título seguido pela versão informal do elemento. A versão informal não terá um título. Inline Versus Block No restante deste documento, ao descrever elementos, inline significa que o elemento pode estar dentro de um elemento de bloco e não causa uma quebra de linha. Um elemento block, por outro lado, causará uma quebra de linha (e outro processamento) quando for encontrado. Extensões do FreeBSD O Projeto de Documentação do FreeBSD estendeu o DocBook DTD com elementos e entidades adicionais. Essas adições servem para tornar algumas das marcações mais fáceis ou mais precisas. Ao longo deste documento, o termo DocBook é usado para indicar o DocBook DTD estendido do FreeBSD. A maioria dessas extensões não é exclusiva do FreeBSD, foi apenas identificado que elas eram melhorias úteis para este projeto. Se alguém de qualquer um dos outros *nix (NetBSD, OpenBSD, Linux,…) estiverem interessados em colaborar em um conjunto de extensão DocBook padrão, entre em contato com a Equipe de Engenharia de Documentação doceng@FreeBSD.org. Elementos do FreeBSD Os elementos adicionais do FreeBSD não estão (atualmente) na Coleção de Ports. Eles são armazenados na repositório Subversion do FreeBSD, como head/share/xml/freebsd.dtd. Os elementos específicos do FreeBSD usados ​​nos exemplos abaixo estão claramente marcados. Entidades do FreeBSD Esta tabela mostra algumas das entidades mais úteis disponíveis no FDP. Para obter uma lista completa, consulte os arquivos *.ent em doc/share/xml. Entidades de Nome do FreeBSD &os; FreeBSD &os.stable; FreeBSD-STABLE &os.current; FreeBSD-CURRENT Entidades de Página de Manual &man.ls.1; ls1 Uso: &man.ls.1; é a página de manual para o <command>ls</command>. &man.cp.1; cp1 Uso: A página de manual para <command>cp</command> é &man.cp.1;. &man.command.sectionnumber; link para a página de manual command na seção sectionnumber As entidades são definidas para todas as páginas de manual do FreeBSD. Entidades das Listas de Email do FreeBSD &a.doc; Lista de discussão do projeto de documentação do FreeBSD Uso: Um link para a &a.doc;. &a.questions; Lista de discussão de assuntos gerais do FreeBSD Uso: Um link para a &a.questions;. &a.listname; link para listname Foram criadas entidades para todas as listas de email do FreeBSD. Entidades de Link de Documento do FreeBSD &url.books.handbook;a @@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook Uso: Um link para o capítulo <link xlink:href="&url.books.handbook;/advanced-networking.html">Rede Avançado</link> do Handbook. &url.books.bookname; caminho relativo parabookname As entidades são definidas para todos os livros FreeBSD. &url.articles.committers-guide; @@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/committers-guide Uso: Um link para o artigo <link xlink:href="&url.articles.committers-guide;">Guia dos Committer's</link>. &url.articles.articlename; caminho relativo para articlename As entidades são definidas para todos os artigos do FreeBSD. Outras Entidades de Sistema Operacional &linux; Linux O sistema operacional Linux. &unix; UNIX O sistema operacional UNIX. &windows; Windows O sistema operacional Windows. Entidades Diversas &prompt.root; # O prompt de usuário root . &prompt.user; % Um prompt para um usuário sem privilégios. &postscript; PostScript A linguagem de programação PostScript. &tex; TeX A linguagem de composição tipográfica TeX. &xorg; Xorg Xorg, Sistema X Window de código aberto. Identificador Público Formal (FPI) Em conformidade com as diretrizes do DocBook, para escrever FPIs customizadas do DocBook, o FPI para o DocBook DTD estendido do FreeBSD é: PUBLIC "-//FreeBSD//DTD DocBook V4.2-Based Extension//EN" Estrutura do Documento O DocBook permite a documentação de estruturação de várias maneiras. O Projeto de Documentação do FreeBSD usa dois tipos principais de documentos do DocBook: o book e o article. Os livros (books) são organizados em chapter s. Este é um requisito obrigatório. Pode haver partes entre o livro e o capítulo para fornecer outra camada de organização. Por exemplo, o Handbook é organizado dessa maneira. Um capítulo(chapter) pode (ou não) conter uma ou mais seções. Estes são indicados com o elemento sect1. Se uma seção contiver outra seção, use o elemento sect2 e assim por diante, até sect5. Capítulos e seções contêm o restante do conteúdo. Um artigo é mais simples que um livro e não utiliza capítulos. Em vez disso, o conteúdo de um artigo é organizado em uma ou mais seções, usando os mesmos elementos sect1 (e sect2 e assim por diante) que são usados ​​em livros. A natureza do documento que está sendo escrito deve ser usada para determinar se ele é melhor marcado como um livro ou um artigo. Os artigos são adequados à informação que não precisa ser dividida em vários capítulos, ou seja, relativamente curta, em até 20-25 páginas de conteúdo. Os livros são mais adequados para informações que podem ser divididas em vários capítulos, possivelmente com apêndices e conteúdo similar também. Os Tutoriais do FreeBSD estão todos marcados como artigos, enquanto este documento, o FAQ e o Handbook estão todos marcados como livros, por exemplo. Iniciando um Livro O conteúdo de um livro está dentro do elemento book. Além de conter marcação estrutural, esse elemento pode conter elementos que incluem informações adicionais sobre o livro. Isso é uma meta-informação, usada para fins de referência ou conteúdo adicional usado para produzir um título de página. Esta informação adicional está em um elemento info. Exemplo de <tag>book</tag> com <tag>info</tag> book info titleYour Title Heretitle author personname firstnameYour first namefirstname surnameYour surnamesurname personname affiliation address emailYour email addressemail address affiliation author copyright year1998year holder role="mailto:your email address"Your nameholder copyright releaseinfo$FreeBSD$releaseinfo abstract paraInclude an abstract of the book's contents here.para abstract info … book Iniciando um Artigo O conteúdo do artigo está dentro do elemento article. Além de conter marcação estrutural, esse elemento pode conter elementos que incluem informações adicionais sobre o artigo. Isso é uma meta-informação, usada para fins de referência ou conteúdo adicional usado para produzir um título de página. Esta informação adicional está em um elemento info. Exemplo de <tag>article</tag> com <tag>info</tag> article info titleYour title heretitle author personname firstnameYour first namefirstname surnameYour surnamesurname personname affiliation address emailYour email addressemailaddress address affiliation author copyright year1998year holder role="mailto:your email address"Your nameholder copyright releaseinfo$FreeBSD$releaseinfo abstract paraInclude an abstract of the article's contents here.para abstract info … article Criando Capítulos Use chapter para marcar seus capítulos. Cada capítulo tem um title obrigatório. Os artigos não contêm capítulos, eles são reservados para livros. Um Capítulo Simples chapter titleThe Chapter's Titletitle ... chapter Um capítulo não pode estar vazio; ele deve conter elementos além do title. Se você precisar incluir um capítulo vazio, basta usar um parágrafo vazio. Capítulos Vazios chapter titleThis is An Empty Chaptertitle parapara chapter Seções Abaixo dos Capítulos Nos livros, os capítulos podem (mas não precisam) ser divididos em seções, subseções e assim por diante. Nos artigos, as seções são o principal elemento estrutural e cada artigo deve conter pelo menos uma seção. Use o elemento sectn. O n indica o número da seção, que identifica o nível da seção. A primeira sectn é sect1. Você pode ter um ou mais destes em um capítulo. Eles podem conter um ou mais elementos sect2 e assim por diante, até sect5. Seções em Capítulos chapter titleA Sample Chaptertitle paraSome text in the chapter.para sect1 titleFirst Sectiontitle … sect1 sect1 titleSecond Sectiontitle sect2 titleFirst Sub-Sectiontitle sect3 titleFirst Sub-Sub-Sectiontitle … sect3 sect2 sect2 titleSecond Sub-Section (1.2.2)title … sect2 sect1 chapter Os números de seção são gerados automaticamente e anexados aos títulos quando o documento é renderizado em um formato de saída. Os números de seção e títulos gerados a partir do exemplo acima serão: 1.1. First Section 1.2. Second Section 1.2.1. First Sub-Section 1.2.1.1. First Sub-Sub-Section 1.2.2. Second Sub-Section Subdividindo Utilizando Elementos <tag>part</tag> partes adiciona outro nível de organização entre book e chapter com uma ou mais partes. Isso não pode ser utilizado em um article. part titleIntroductiontitle chapter titleOverviewtitle ... chapter chapter titleWhat is FreeBSD?title ... chapter chapter titleHistorytitle ... chapter part Elementos Block Parágrafos O DocBook suporta três tipos de parágrafos: formalpara, para e simpara. Quase todos os parágrafos da documentação do FreeBSD usam para. formalpara inclui um elemento title, e simpara desabilita alguns elementos de um para. Utilize mais o para . Exemplo de um <tag>para</tag> Uso: paraThis is a paragraph. It can contain just about any other element.para Aparência: This is a paragraph. It can contain just about any other element. Bloco de Citações Uma cotação em bloco é uma cotação estendida de outro documento que não deve aparecer no parágrafo atual. Estes raramente são necessários. Os blockquotes podem, opcionalmente, conter um título e uma atribuição (ou podem ser deixados sem título e sem atribuição). Exemplo <tag>blockquote</tag> Uso: paraA small excerpt from the US Constitution:para blockquote titlePreamble to the Constitution of the United Statestitle attributionCopied from a web site somewhereattribution paraWe the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.para blockquote Aparência: A small excerpt from the US Constitution:
Preamble to the Constitution of the United States Copiado de um site qualquer We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.
Dicas, Notas, Avisos, Cuidados e Informações Importantes Informações adicionais podem precisar ser separadas do texto principal. Normalmente, essa é a informação meta da qual o usuário deve estar ciente. Vários tipos de informações estão disponíveis: tip, note, warning, caution, e important. O tipo a ser escolhido depende da situação. A documentação do DocBook sugere: A nota é para informações onde todos os leitores devem prestar atenção. Importante é uma variação de Nota. Cuidado é para informações sobre possíveis perdas de dados ou danos ao software. Aviso é para informações sobre possíveis danos ao hardware, sobre risco de vida ou de ferimento a um membro. Example de <tag>tip</tag> e <tag>important</tag> Uso: tip para&os; may reduce stress.para tip important paraPlease use admonitions sparingly. Too many admonitions are visually jarring and can have the opposite of the intended effect.para important Aparência: FreeBSD may reduce stress. Please use admonitions sparingly. Too many admonitions are visually jarring and can have the opposite of the intended effect. Exemplos Exemplos podem ser apresentados com example. <tag>example</tag> Uso: example paraEmpty files can be created easily:para screen&prompt.user; userinputtouch file1 file2 file3userinputscreen example Aparência: <tag>example</tag> Renderizado Empty files can be created easily: % touch file1 file2 file3 Listas e Procedimentos Muitas vezes, as informações precisam ser apresentadas como listas ou como uma série de etapas que devem ser realizadas para atingir um objetivo específico. Para fazer isso, utilize itemizedlist, orderedlist, variablelist ou procedure. Existem outros tipos de elementos de lista no DocBook, mas não os cobriremos aqui. itemizedlist e orderedlist são semelhantes às suas contrapartes em HTML, ul e ol. Cada um consiste em um ou mais elementos listitem, e cada listitem contém um ou mais elementos de bloco. Os elementos listitem são análogos às tags li do HTML. No entanto, ao contrário do HTML, eles são obrigatórios. Exemplo de <tag>itemizedlist</tag> e <tag>orderedlist</tag> Uso: itemizedlist listitem paraThis is the first itemized item.para listitem listitem paraThis is the second itemized item.para listitem itemizedlist orderedlist listitem paraThis is the first ordered item.para listitem listitem paraThis is the second ordered item.para listitem orderedlist Aparência: This is the first itemized item. This is the second itemized item. This is the first ordered item. This is the second ordered item. Uma maneira alternativa e frequentemente útil de apresentar informações é a variablelist. Estas são listas onde cada entrada tem um termo e uma descrição. Eles são adequados para muitos tipos de descrições e apresentam informações de uma forma que geralmente é mais fácil para o leitor do que seções e subseções. Uma variablelist tem um title e, em seguida, pares de entradas term e listitem. Exemplo<tag>variablelist</tag> Uso: variablelist varlistentry termParallelterm listitem paraIn parallel communications, groups of bits arrive at the same time over multiple communications channels.para listitem varlistentry varlistentry termSerialterm listitem paraIn serial communications, bits arrive one at a time over a single communications channel.para listitem varlistentry variablelist Aparência: Parallel In parallel communications, groups of bits arrive at the same time over multiple communications channels. Serial In serial communications, bits arrive one at a time over a single communications channel. Um procedure mostra uma série de steps, que por sua vez consistem em mais steps ou substeps. Cada step contém elementos de bloco e pode incluir um título opcional. Às vezes, os passos não são sequenciais, mas apresentam uma escolha: fazer isso ou fazer aquilo, mas não ambos. Para essas escolhas alternativas, use stepalternatives. Exemplo <tag>procedure</tag> Uso: procedure step paraDo this.para step step paraThen do this.para step step substeps step paraAnd now do this smaller thing.para step step paraAnd now do this other smaller thing.para step substeps step step paraFinally, do one of these:para stepalternatives step paraGo left.para step step paraGo right.para step stepalternatives step procedure Aparência: Do this. Then do this. And now do this small thing. And this other small thing. Finally, do one of these: Go left. Go right. Mostrando Exemplos de Arquivos Fragmentos de um arquivo (ou talvez um arquivo completo) são mostrados agrupando-os no elemento programlisting. Espaço em branco e quebra de linha dentro de programlisting são importantes. Em particular, isso significa que a tag de abertura deve aparecer na mesma linha que a primeira linha da saída, e a tag de fechamento deve aparecer na mesma linha da última linha da saída, caso contrário linhas vazias podem ser incluídas. Exemplo <tag>programlisting</tag> Uso: paraWhen finished, the program will look like this:para programlisting#include &lt;stdio.h&gt; int main(void) { printf("hello, world\n"); return 0; }programlisting Observe como os colchetes angulares na linha #include precisam ser referenciados por suas entidades, em vez de serem incluídos literalmente. Aparência: When finished, the program will look like this: #include <stdio.h> int main(void) { printf("hello, world\n"); return 0; } Chamadas Uma chamada é um marcador visual para se referenciar a um texto ou a uma posição específica em um exemplo. As chamadas são marcadas com o elemento co. Cada elemento deve ter um id único atribuído a ele. Após o exemplo, inclua uma calloutlist que descreve cada frase de destaque. Exemplo <tag>co</tag> e <tag>calloutlist</tag> paraWhen finished, the program will look like this:para programlisting#include &lt;stdio.h&gt; co xml:id="co-ex-include" int co xml:id="co-ex-return" main(void) { printf("hello, world\n"); co xml:id="co-ex-printf" }programlisting calloutlist callout arearefs="co-ex-include" paraIncludes the standard IO header file.para callout callout arearefs="co-ex-return" paraSpecifies that functionmain()function returns an int.para callout callout arearefs="co-ex-printf" paraThe functionprintf()function call that writes literalhello, worldliteral to standard output.para callout calloutlist Aparência: When finished, the program will look like this: #include <stdio.h> int main(void) { printf("hello, world\n"); } Includes the standard IO header file. Specifies that main() returns an int. The printf() call that writes hello, world to standard output. Tabelas Ao contrário de HTML, o DocBook não precisa de tabelas para fins de layout, já que a folha de estilo lida com esses problemas. Em vez disso, basta usar tabelas para marcar dados tabulares. Em termos gerais (e veja a documentação do DocBook para mais detalhes), uma tabela (que pode ser formal ou informal) consiste em um elemento table. Este contém pelo menos um elemento tgroup, que especifica (como um atributo) o número de colunas neste grupo de tabelas. Dentro do tgroup há um elemento thead, que contém elementos para os títulos da tabela (cabeçalhos da coluna), e um tbody que contém o corpo da tabela. Ambos tgroup e thead contêm elementos row, que por sua vez contêm elementos entry. Cada elemento entry especifica uma célula na tabela. Exemplo <tag>informaltable</tag> Uso: informaltable pgwide="1" tgroup cols="2" thead row entryThis is Column Head 1entry entryThis is Column Head 2entry row thead tbody row entryRow 1, column 1entry entryRow 1, column 2entry row row entryRow 2, column 1entry entryRow 2, column 2entry row tbody tgroup informaltable Aparência: This is Column Head 1 This is Column Head 2 Row 1, column 1 Row 1, column 2 Row 2, column 1 Row 2, column 2 Sempre use o atributo pgwide com um valor 1 com o elemento informaltable. Um erro no Internet Explorer pode fazer com que a tabela seja renderizada incorretamente se isso for omitido. As bordas da tabela podem ser escondidas configurando o atributo frame para none no elemento informaltable. Por exemplo, informaltable frame="none". Exemplo de Tabela com <literal>frame="none"</literal> Aparência: This is Column Head 1 This is Column Head 2 Row 1, column 1 Row 1, column 2 Row 2, column 1 Row 2, column 2 Exemplos para o Usuário Seguir Exemplos para o usuário seguir são freqüentemente necessários. Normalmente, eles consistem em diálogos com o computador; o usuário digita um comando, o usuário recebe uma resposta de volta, o usuário digita outro comando e assim por diante. Vários elementos e entidades podem ser utilizados nestes casos. screen Tudo o que o usuário vê neste exemplo estará na tela do computador, então o próximo elemento é screen . Dentro da screen, o espaço em branco é significativo. prompt, &prompt.root; and &prompt.user; Algumas das coisas que o usuário irá visualizar na tela são prompts do computador (seja do sistema operacional, da linha de comando shell ou de uma aplicação). Estes prompts devem ser marcados usando prompt. Por serem especiais, os prompts de shell do usuário normal e do usuário root estão disponíveis como uma entidade. Sempre que quiser indicar que o usuário está em um prompt do shell, use &prompt.root; para o usuário root e &prompt.user; para o usuário normal, conforme for necessário. Estas entidades não precisam estar dentro de um prompt. &prompt.root; e &prompt.user; são extensões do FreeBSD ao DocBook e não são parte do DTD original. userinput Ao exibir o texto que o usuário deve digitar, coloque-o nas tags userinput. Ele provavelmente será mostrado diferente para o usuário. Exemplos <tag>screen</tag>, <tag>prompt</tag>, e <tag>userinput</tag> Uso: screen&prompt.user; userinputls -1userinput foo1 foo2 foo3 &prompt.user; userinputls -1 | grep foo2userinput foo2 &prompt.user; userinputsuuserinput promptPassword: prompt &prompt.root; userinputcat foo2userinput This is the file called 'foo2'screen Aparência: % ls -1 foo1 foo2 foo3 % ls -1 | grep foo2 foo2 % su Password: # cat foo2 This is the file called 'foo2' Ainda que estejamos mostrando o conteúdo do arquivo foo2, ele não está marcado como programlisting. Deixe o programlisting para mostrar fragmentos de arquivos fora do contexto de ações do usuário. Elementos In-line Realçando Informação Para enfatizar uma palavra ou frase em particular, use emphasis. Isso pode ser apresentado em itálico ou negrito, ou pode ser falado diferentemente com um sistema de conversão de texto em fala. Não há uma maneira de mudar a apresentação da ênfase no documento, não existe um equivalente a b e i do HTML . Se as informações apresentadas forem importantes, considere apresentá-las em important em vez de emphasis. Exemplo de <tag>emphasis</tag> Uso: para&os; is without doubt emphasistheemphasis premiere &unix;-like operating system for the Intel architecture.para Aparência: FreeBSD is without doubt the premiere UNIX-like operating system for the Intel architecture. Siglas Muitos termos de computador são siglas, palavras formadas a partir da primeira letra de cada palavra em uma frase. Os acrônimos são marcados com elementos acronym. É útil para o leitor quando um acrônimo é definido no primeiro uso, como mostrado no exemplo abaixo. Exemplo <tag>acronym</tag> Uso: paraRequest For Comments (acronymRFCacronym) 1149 defined the use of avian carriers for transmission of Internet Protocol (acronymIPacronym) data. The quantity of acronymIPacronym data currently transmitted in that manner is unknown.para Aparência: Request For Comments (RFC) 1149 defined the use of avian carriers for transmission of Internet Protocol (IP) data. The quantity of IP data currently transmitted in that manner is unknown. Citações Para citar texto de outro documento ou fonte, ou para denotar uma frase que é usada de forma figurada, use quote. A maioria das tags de marcação disponíveis para texto normal também está disponível em quote. Exemplo <tag>quote</tag> Uso: paraHowever, make sure that the search does not go beyond the quoteboundary between local and public administrationquote, as acronymRFCacronym 1535 calls it.para Aparência: However, make sure that the search does not go beyond the boundary between local and public administration, as RFC 1535 calls it. Teclas, Botões do Mouse e Combinações Para se referir a uma tecla específica no teclado, use keycap. Para se referir a um botão do mouse, use mousebutton. E para se referir a combinações de pressionamentos de teclas ou cliques do mouse, coloque todos eles em keycombo. keycombo tem um atributo chamado action, que pode ser um dos click, double-click, other, press, seq, ou simul. Os dois últimos valores indicam se as teclas ou botões devem ser pressionados em sequência ou simultaneamente. As folhas de estilo adicionam automaticamente quaisquer símbolos de conexão, como +, entre os nomes das chaves, quando agrupados em keycombo. Exemplos de Teclas, Botões do Mouse e Combinações Uso: paraTo switch to the second virtual terminal, press keycombo action="simul"keycapAltkeycap keycapF1keycapkeycombo.para paraTo exit commandvicommand without saving changes, type keycombo action="seq"keycapEsckeycapkeycap:keycap keycapqkeycapkeycap!keycapkeycombo.para paraMy window manager is configured so that keycombo action="simul"keycapAltkeycap mousebuttonrightmousebutton keycombo mouse button is used to move windows.para Aparência: To switch to the second virtual terminal, press Alt F1. To exit vi without saving changes, type Esc : q !. My window manager is configured so that Alt right mouse button is used to move windows. Aplicativos, Comandos, Opções e Citações Ambos os aplicativos e comandos são frequentemente utiilzados ao escrever uma documentação. A distinção entre eles é que um aplicativo é o nome de um programa ou conjunto de programas que preenche uma tarefa específica. Um comando é o nome do arquivo de um programa que o usuário pode digitar e executar em uma linha de comando. Muitas vezes é necessário mostrar algumas das opções que um comando pode ter. Finalmente, muitas vezes é útil listar um comando com seu número de seção do manual, no formato command(number) que é comum em manuais Unix. Marque nomes de aplicações com application. Para listar um comando com seu número de seção do manual (que deve ser utilizado com maior frequência), o elemento DocBook é citerefentry. Isto irá conter mais dois elementos, refentrytitle e manvolnum. O conteúdo de refentrytitle é o nome do comando, e o conteúdo do manvolnum é a seção da página de manual. Isso pode ser trabalhoso para escrever e assim uma série de entidades gerais foram criadas para tornar esse processo mais fácil. Cada entidade assume o formato &man.manual-page.manual-section;. O arquivo que contém essas entidades está em doc/share/xml/man-refs.ent e pode ser referenciado usando este FPI: PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN" Portanto, a introdução à documentação do FreeBSD geralmente incluirá isto: <!DOCTYPE book PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ <!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> %man; … ]> Use command para incluir um nome de comando in-line, mas mostre como algo que o usuário deve digitar. Use option para marcar as opções que serão passadas para um comando. Ao se referir ao mesmo comando várias vezes nas proximidades, é preferível usar a notação &man.command.section; para marcação a primeira referência e use command para marcar as referências subsequentes. Isso faz com que a saída gerada, especialmente HTML, apareça visualmente melhor. Exemplo de Aplicações, Comandos e Opções Uso: paraapplicationSendmailapplication is the most widely used Unix mail application.para paraapplicationSendmailapplication includes the citerefentry refentrytitlesendmailrefentrytitle manvolnum8manvolnum citerefentry, &man.mailq.1;, and &man.newaliases.1; programs.para paraOne of the command line parameters to citerefentry refentrytitlesendmailrefentrytitle manvolnum8manvolnum citerefentry, option-bpoption, will display the current status of messages in the mail queue. Check this on the command line by running commandsendmail -bpcommand.para Aparência: Sendmail é o aplicativo de email Unix mais utilizado. O Sendmail inclui o os programas sendmail8 , mailq1, e o newaliases1. Um dos parâmetros da linha de comando para o sendmail8 , , exibirá o status atual das mensagens no fila de email. Verifique isso na linha de comando executando sendmail -bp. Observe como a notação &man..section; é mais fácil de ser seguida. Arquivos, Diretórios, Extensões, Nomes de Dispositivo Para se referir ao nome de um arquivo, um diretório, uma extensão de arquivo ou um nome de dispositivo, use filename. Exemplo <tag>filename</tag> Uso: para O código fonte do Handbook em inglês é encontrada em   filename/usr/doc/en_US.ISO8859-1/books/handbook/filename.   O arquivo principal é chamado filenamebook.xmlfilename.   Há também um filenameMakefilefilename e vários arquivos com a extensão filename.entfilename.para parafilenamekbd0filename é o primeiro teclado detectado   pelo sistema e aparece em   filename/devfilename. para Aparência: O código fonte do Handbook em inglês é encontrada em /usr/doc/en_US.ISO8859-1/books/handbook/. O arquivo principal é chamado book.xml. Há também um Makefile e vários arquivos com a extensão .ent. kbd0 é o primeiro teclado detectado pelo sistema e aparece em /dev. Nome dos Ports Extensão FreeBSD Estes elementos fazem parte da extensão do FreeBSD ao DocBook, e não existem no DocBook DTD original. Para incluir o nome de um programa da Coleção de Ports do FreeBSD no documento, use a tag package. Como a Coleção de Ports pode ser instalada em qualquer local, inclua apenas a categoria e o nome do port; não inclua /usr/ports. Por padrão, package refere-se a um pacote binário. Para se referir a um port que será compilado a partir do código fonte, configure o atributo role para port. Exemplo de <tag>package</tag> Uso: paraInstale o pacote binário packagenet/wiresharkpackage para visualizar o tráfego de rede.para parapackage role="port"net/wiresharkpackage também pode ser compilado e instalado pela Coleção de Ports.para Aparência: Instale o pacote binário net/wireshark para visualizar o tráfego de rede. O net/wireshark também pode ser compilado e instalado pela Coleção de Ports. Hosts, Domínios, Endereços IP, Usuário, Grupo e Outros Itens do Sistema Extensão FreeBSD Estes elementos fazem parte da extensão do FreeBSD ao DocBook, e não existem no DocBook DTD original. Informações para itens do sistema estão marcadas com systemitem. O atributo class é usado para identificar o tipo específico de informação mostrada. class="domainname" O texto é um nome de domínio, como FreeBSD.org ou ngo.org.uk. Não há nenhum componente de nome de host. class="etheraddress" O texto é um endereço Ethernet MAC, expresso como uma série de números hexadecimais de 2 dígitos separados por dois pontos. class="fqdomainname" O texto é um nome de domínio FQDM, com ambos nome de domínio e hostname. class="ipaddress" O texto é um endereço de IP. class="netmask" O texto é uma máscara de rede, que pode ser expressa igual a um IP, uma sequência hexadecimal ou como um / seguido por um número (notação CIDR). class="systemname" Com class="systemname", as informações marcadas são o nome do host simples, como freefall ou wcarchive. class="username" O texto é um nome de usuário, como root. class="groupname" O texto é um grupo, como wheel. Exemplos <tag>systemitem</tag> Uso: paraThe local machine can always be referred to by the name systemitem class="systemname"localhostsystemitem, which will have the IP address systemitem class="ipaddress"127.0.0.1systemitem.para paraThe systemitem class="domainname"FreeBSD.orgsystemitem domain contains a number of different hosts, including systemitem class="fqdomainname"freefall.FreeBSD.orgsystemitem and systemitem class="fqdomainname"bento.FreeBSD.orgsystemitem.para paraWhen adding an acronymIPacronym alias to an interface (using commandifconfigcommand) emphasisalwaysemphasis use a netmask of systemitem class="netmask"255.255.255.255systemitem (which can also be expressed as systemitem class="netmask"0xffffffffsystemitem).para paraThe acronymMACacronym address uniquely identifies every network card in existence. A typical acronymMACacronym address looks like systemitem class="etheraddress"08:00:20:87:ef:d0systemitem.para paraTo carry out most system administration functions requires logging in as systemitem class="username"rootsystemitem.para Aparência: A máquina local sempre pode ser referenciada pelo nome localhost, que terá o endereço IP 127.0.0.1. O domínio FreeBSD.org contém vários hosts diferentes, incluindo freefall.FreeBSD.org e bento.FreeBSD.org. Ao adicionar um alias de IP a uma interface (usando ifconfig) sempre use uma máscara de rede de 255.255.255.255 (que também pode ser expressa como 0xffffffff). O endereço MAC identifica exclusivamente todas as placas de rede existentes. Um endereço MAC típico se parece com 08:00:20:87:ef:d0. Para executar a maioria das funções de administração do sistema, é necessário efetuar login como root. Identificadores Uniformes de Recursos (<acronym>URI</acronym>s) Ocasionalmente, é útil mostrar um Identificador de Recurso Uniforme (URI) sem torná-lo um hiperlink ativo. O elemento uri torna isso possível: Exemplo <tag>uri</tag> Uso: paraEsta URL é mostrada apenas como texto: urihttps://www.FreeBSD.orguri. Não é criado um link.para Aparência: Esta URL é mostrada apenas como texto: https://www.FreeBSD.org. Não é criado um link. Para criar links, consulte . Endereços de Email Os endereços de email são marcados como elementos email. No formato de saída HTML, o texto marcado se torna um hiperlink para o endereço de email. Outros formatos de saída que suportam hiperlinks também podem tornar o endereço de email em um link. Exemplo de Hiperlink com <tag>email</tag> Uso: para Um endereço de email que não existe, como   emailnotreal@example.comemail, pode ser usado como um   exemplo para Aparência: Um endereço de email que não existe, como notreal@example.com, pode ser usado como exemplo. Uma extensão específica do FreeBSD permite configurar o atributo role para nolink para evitar a criação do hiperlink para o endereço de email. Exemplo de <tag>email</tag> Sem Hiperlink Uso: para Às vezes, o link para um endereço de email como   email role="nolink"notreal@example.comemail não é   desejado.para Aparência: Às vezes, o link para um endereço de email como notreal@example.com não é desejado. Descrevendo <filename>Makefile</filename>s Extensão FreeBSD Estes elementos fazem parte da extensão do FreeBSD ao DocBook, e não existem no DocBook DTD original. Existem dois elementos para descrever partes de Makefiles, buildtarget e varname. buildtarget identifica um destino de compilação exportado por um Makefile que pode ser fornecido como um parâmetro para o make. varname identifica uma variável que pode ser definida (no ambiente, na linha de comando com o make, ou dentro do Makefile) para influenciar o processo. Exemplo de <tag>buildtarget</tag> e <tag>varname</tag> Uso: paraTwo common targets in a filenameMakefilefilename are buildtargetallbuildtarget and buildtargetcleanbuildtarget.para paraTypically, invoking buildtargetallbuildtarget will rebuild the application, and invoking buildtargetcleanbuildtarget will remove the temporary files (filename.ofilename for example) created by the build process.para parabuildtargetcleanbuildtarget may be controlled by a number of variables, including varnameCLOBBERvarname and varnameRECURSEvarname.para Aparência: Dois targets comuns em um Makefile são all e clean. Normalmente, invocar all irá reconstruir o aplicativo, e invocar clean removerá os arquivos temporários (.o por exemplo) criados pelo processo de compilação. clean pode ser controlado por várias de variáveis, incluindo CLOBBER e RECURSE. Texto Literal O texto literal, ou texto que deve ser inserido na íntegra, é frequentemente necessário na documentação. Este é um texto extraído de outro arquivo ou que deve ser copiado exatamente como mostrado na documentação em um outro arquivo. Na maioria das vezes, programlisting será suficiente para denotar este texto. Mas programlisting nem sempre é apropriado, particularmente quando você quer incluir uma parte de um arquivo in-line com o resto do parágrafo. Nestes casos, use literal. Exemplo <tag>literal</tag> Uso: paraThe literalmaxusers 10literal line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support.para Aparência: A linha maxusers 10 no arquivo de configuração do kernel determina o tamanho de muitas tabelas do sistema e é um guia aproximado de quantos logins simultâneos o sistema suportará. Mostrando Itens que o Usuário <emphasis>Deve</emphasis> Preencher Haverá diversos momentos em que o usuário irá ver o que fazer, ou será referenciado a um arquivo ou linha de comando, mas não poderá simplesmente copiar o exemplo fornecido. Em vez disso, eles precisam fornecer algumas informações. replaceable é projetado para essa eventualidade. Use isso dentro de outros elementos para indicar partes do conteúdo desse elemento que o usuário deve substituir. Exemplo de <tag>replaceable</tag> Uso: screen&prompt.user; userinputman replaceablecommandreplaceableuserinputscreen Aparência: % man command replaceable pode ser usado em diversos elementos, incluindo literal. Este exemplo também mostra que o replaceable deve estar apenas em torno do conteúdo que o usuário está destinado a fornecer. O outro conteúdo deve ser deixado de lado. Uso: paraThe literalmaxusers replaceablenreplaceableliteral line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support.para paraFor a desktop workstation, literal32literal is a good value for replaceablenreplaceable.para Aparência: A linha maxusers n no arquivo de configuração do kernel determina o tamanho de muitas tabelas do sistema e é um guia aproximado de quantos logins simultâneos o sistema suportará. Para uma estação de trabalho, 32 é um bom valor para n. Mostrando Botões <acronym>GUI</acronym> Os botões apresentados por uma interface gráfica do usuário são marcados com guibutton. Para tornar o texto mais parecido com um botão gráfico, colchetes e espaços não separáveis ​​são adicionados em volta do texto. Exemplo <tag>guibutton</tag> Uso: paraEdit the file, then click guibutton[&nbsp;Save&nbsp;]guibutton to save the changes.para Aparência: Edite o arquivo e clique em [Salvar] para salvar as alterações. Citações de Erros do Sistema Erros de sistema gerados pelo FreeBSD são marcados com errorname. Isso indica o erro exato que aparece. Exemplo <tag>errorname</tag> Uso: screenerrornamePanic: cannot mount rooterrornamescreen Aparência: Panic: cannot mount root Imagens O suporte de imagem na documentação é um pouco experimental. Os mecanismos descritos aqui provavelmente não mudarão, mas isso não é garantido. Para fornecer conversão entre diferentes formatos de imagem, o port graphics/ImageMagick deve estar instalado. Esse port não está incluído no meta port textproc/docproj e deve ser instalado separadamente. Um bom exemplo do uso de imagens é o documento graphics/ImageMagick. Examine os arquivos nesse diretório para ver como esses elementos são usados ​​juntos. Crie formatos de saída diferentes para ver como o formato determina quais imagens são mostradas no documento renderizado. Formatos de Imagem Os seguintes formatos de imagem são suportados atualmente. Um arquivo de imagem será automaticamente convertido em bitmap ou imagem vetorial, dependendo do formato do documento de saída. Estes são os formatos somente nos quais as imagens devem ser enviadas para o repositório de documentação. EPS (Encapsulated Postscript) Imagens com base principalmente em vetores, como diagramas de rede, linhas de tempo e similares, devem estar nesse formato. Estas imagens têm uma extensão .eps. PNG (Portable Network Graphic) Para bitmaps, como capturas de tela, use este formato. Essas imagens têm a extensão .png. PIC (PIC graphics language) PIC é uma linguagem para desenhar figuras baseadas em vetor simples usadas no utilitário pic 1. Essas imagens têm a extensão .pic. SCR (SCReen capture) Este formato é específico para capturas de tela da saída do console. O seguinte comando gera um arquivo SCR shot.scr do buffer de vídeo /dev/ttyv0: # vidcontrol -p < /dev/ttyv0 > shot.scr É preferível o formato PNG para capturas de tela porque o arquivo SCR contém texto sem formatação das linhas de comando para que possa ser convertido em uma imagem PNG ou um texto simples, dependendo do formato do documento de saída. Use o formato apropriado para cada imagem. A documentação geralmente tem uma mistura de imagens EPS e PNG. O Makefile assegura que a imagem de formato correta seja escolhida dependendo do formato de saída usado. Não envie a mesma imagem ao repositório em dois formatos diferentes. O Projeto de Documentação pode eventualmente mudar para o formato SVG (Scalable Vector Graphic) para imagens vetoriais. No entanto, o estado atual das ferramentas de edição compatíveis com SVG torna isso inviável. Localizações das Imagens As imagens podem ser armazenados em um dos diversos locais abaixo, dependendo do documento e da imagem: No mesmo diretório do documento em si, geralmente feito para artigos e pequenos livros que mantêm todos os arquivos em um único diretório. Em um subdiretório do documento principal. Geralmente feito quando um livro grande usa subdiretórios separados para organizar capítulos individuais. Quando as imagens são armazenadas em um subdiretório do diretório do documento principal, o nome do subdiretório deve ser incluído em seus caminhos no Makefile e no elemento imagedata. Em um subdiretório de doc/share/images nomeado após o documento. Por exemplo, as imagens do Handbook estão armazenadas em doc/share/images/books/handbook. Imagens que funcionam para várias traduções são armazenadas neste nível superior da árvore de arquivos da documentação. Geralmente, estas são imagens que podem ser usadas inalteradas em traduções não inglesas do documento. Marcação em Imagem As imagens são incluídas como parte de um mediaobject. O mediaobject pode conter outros objetos mais específicos. Estamos preocupados com dois, o imageobject e o textobject. Inclua um imageobject e dois elementos textobject. O imageobject apontará para o nome do arquivo de imagem sem a extensão. Os elementos textobject contêm informações que serão apresentadas ao usuário, bem como, ou em vez da própria imagem. Elementos de texto são mostrados ao leitor em várias situações. Quando o documento é exibido em HTML, elementos de texto são mostrados enquanto a imagem está sendo carregada ou se o ponteiro do mouse estiver sobre a imagem ou se um navegador somente texto estiver sendo usado. Em formatos como texto simples, onde os gráficos não são possíveis, os elementos de texto são mostrados em vez dos gráficos. Este exemplo mostra como incluir uma imagem chamada fig1.png em um documento. A imagem é um retângulo com um A dentro dela: mediaobject imageobject imagedata fileref="fig1" imageobject textobject literallayout class="monospaced"+---------------+ | A | +---------------+literallayout textobject textobject phraseA picturephrase textobject mediaobject Inclua um elemento imagedata dentro do elemento imageobject. O atributo fileref deve conter o nome do arquivo da imagem a ser incluída, sem a extensão. As folhas de estilo irão descobrir qual extensão deve ser adicionada ao nome do arquivo automaticamente. O primeiro textobject contém um elemento literallayout, onde o atributo class é definido como monospaced. Esta é uma oportunidade para demonstrar habilidades artísticas em ASCII. Este conteúdo será usado se o documento for convertido em texto simples. Observe como a primeira e a última linha do conteúdo do elemento literallayout aparecem ao lado das tags do elemento. Isso garante que nenhum espaço em branco seja incluído. O segundo textobject contém um único elemento phrase. O conteúdo desta frase se tornará o atributo alt para a imagem quando este documento for convertido para HTML. Entradas de Imagem no <filename>Makefile</filename> As imagens devem estar listadas no Makefile na variável IMAGES. Esta variável deve conter os nomes de todas as imagens source. Por exemplo, se houver três figuras, fig1.eps, fig2.png, fig3.png, então o Makefile deve ter linhas como esta. … IMAGES= fig1.eps fig2.png fig3.png … ou … IMAGES= fig1.eps IMAGES+= fig2.png IMAGES+= fig3.png … Novamente, o Makefile irá elaborar a lista completa de imagens necessárias para compilar o documento, você só precisa listar os arquivos de imagem que você forneceu. Imagens e Capítulos em Subdiretórios Tenha cuidado ao separar a documentação em arquivos menores em diretórios diferentes (consulte ). Imagine que haja um livro com três capítulos e os capítulos sejam armazenados em seus próprios diretórios, chamados chapter1/chapter.xml, chapter2/chapter.xml e chapter3/chapter.xml. Se cada capítulo tiver imagens associadas, coloque essas imagens no subdiretório de cada capítulo (chapter1/, chapter2/, e chapter3/). No entanto, fazer isso requer a inclusão dos nomes de diretório na variável IMAGES no Makefile, e a inclusão do nome do diretório no elemento imagedata no documento. Por exemplo, se o livro tiver chapter1/fig1.png, então chapter1/chapter.xml deve conter: mediaobject imageobject imagedata fileref="chapter1/fig1" imageobject … mediaobject O nome do diretório deve ser incluído no atributo fileref. O Makefile deve conter: … IMAGES= chapter1/fig1.png … Links Links também são elementos in-line. Para mostrar uma URI sem criar um link, consulte . Atributos <literal>xml:id</literal> A maioria dos elementos DocBook aceita um atributo xml:id para dar a essa parte do documento um nome exclusivo. O xml:id pode ser usado como um destino para uma referência cruzada ou link. Qualquer parte do documento que será um destino de link deve ter um atributo xml:id. Atribuir um xml:id a todos os capítulos e seções, mesmo que não haja planos atuais para criar link para eles, é uma boa ideia. Esses xml:id s podem ser usados ​​como pontos de referência exclusivos por qualquer pessoa que se refira à versão do documento HTML. <literal>xml:id</literal> em Ccapítulos e sSeções de eExemplo chapter xml:id="introduction" titleIntroductiontitle paraThis is the introduction. It contains a subsection, which is identified as well.para sect1 xml:id="introduction-moredetails" titleMore Detailstitle paraThis is a subsection.para sect1 chapter Use valores descritivos para nomes de xml:id. Os valores devem ser exclusivos em todo o documento, não apenas em um único arquivo. No exemplo, a subseção xml:id é construída anexando o texto ao capítulo xml:id. Isso garante que os xml:id s sejam exclusivos. Ele também ajuda o leitor e qualquer um que editar o documento a ver onde o link está localizado no documento, semelhante a um caminho de diretório para um arquivo. Referências Cruzadas com <literal>xref</literal> xref fornece ao leitor um link para ir para outra seção do documento. O destino xml:id é especificado no atributo linkend e xref gera o texto do link automaticamente. Exemplo <tag>xref</tag> Imagine que esse fragmento apareça em algum lugar em um documento que inclua o exemplo xml:id mostrado acima: paraMore information can be found in xref linkend="introduction".para paraMore specific information can be found in xref linkend="introduction-moredetails".para O texto do link será gerado automaticamente, parecendo como (O enfatizado indica o texto do link):
Mais informações podem ser encontradas no Capítulo 1, Introdução. Informações mais específicas podem ser encontradas em Seção 1.1, Mais Detalhes.
O texto do link é gerado automaticamente a partir do capítulo e número da seção e elementos title. Criando Links para Outros Documentos na Web O elemento link descrito aqui permite que o escritor defina o texto do link. Quando o texto do link é usado, é muito importante ser descritivo para dar ao leitor uma ideia de onde o link vai. Lembre-se que o DocBook pode ser renderizado para vários tipos de mídia. O leitor pode estar olhando para um livro impresso ou outra forma de mídia onde não há links. Se o texto do link não for descritivo o suficiente, talvez o leitor não consiga localizar a seção vinculada. O atributo xlink:href é a URL da página, e o conteúdo do elemento é o texto que será exibido para o usuário ativar. Em muitas situações, é preferível mostrar a URL real em vez do texto. Isso pode ser feito deixando de fora o texto do elemento. <tag>link</tag> para um Exemplo de Página Web de Documentação do FreeBSD Link para uma URL de uma entidade. de livro ou artigo Para criar um link para um capítulo específico de um livro, adicione uma barra e o nome do arquivo do capítulo, seguido por uma âncora opcional dentro do capítulo. Para artigos, crie um link para a entidade URL do artigo, seguida por uma âncora opcional no artigo. As entidades URL podem ser encontradas em doc/share/xml/urls.ent. Uso para links de livros do FreeBSD: paraRead the link xlink:href="&url.books.handbook;/svn.html#svn-intro"SVN introductionlink, then pick the nearest mirror from the list of link xlink:href="&url.books.handbook;/svn.html#svn-mirrors"Subversion mirror siteslink.para Aparência: Leia a Introdução ao SVN, em seguida, escolha o espelho mais próximo do lista de sites espelho do Subversion. Uso para links de artigos do FreeBSD: paraRead this link xlink:href="&url.articles.bsdl-gpl;"article about the BSD licenselink, or just the link xlink:href="&url.articles.bsdl-gpl;#intro"introductionlink.para Aparência: Leia este artigo sobre a licença BSD, ou apenas a sua introdução. <tag>link</tag> para um Exemplo de Página Web do FreeBSD Uso: paraOf course, you could stop reading this document and go to the link xlink:href="&url.base;/index.html"FreeBSD home pagelink instead.para Aparência: Claro, você pode parar de ler este documento e ir para a página inicial do FreeBSD. <tag>link</tag> para um Exemplo de Página Web Externa Uso: paraWikipedia has an excellent reference on link xlink:href="http://en.wikipedia.org/wiki/GUID_Partition_Table"GUID Partition Tableslink.para Aparência: A Wikipedia tem uma excelente referência em Tabelas de Partição GUID. O texto do link pode ser omitido para mostrar a URL real: paraWikipedia has an excellent reference on GUID Partition Tables: link xlink:href="http://en.wikipedia.org/wiki/GUID_Partition_Table"link.para O mesmo link pode ser inserido usando notação mais curta em vez de uma tag de finalização separada: paraWikipedia has an excellent reference on GUID Partition Tables: link xlink:href="http://en.wikipedia.org/wiki/GUID_Partition_Table".para Os dois métodos são equivalentes. Aparência: A Wikipedia tem uma excelente referência em Tabelas de Partição GUID: http://en.wikipedia.org/wiki/GUID_Partition_Table . Folhas de Estilo O XML se preocupa com o conteúdo e não diz nada sobre como esse conteúdo deve ser apresentado ao leitor ou renderizado no papel. Múltiplas linguagens de folha de estilo foram desenvolvidas para descrever o layout visual, incluindo a Transformação de Linguagem de Folha de Estilo Extensível (XSLT), Semântica de Estilo de Documento e Linguagem de Especificação (DSSSL ) e Folhas de Estilo em Cascata (CSS). Os documentos do FDP usam folhas de estilo XSLT para transformar o DocBook em XHTML, e então a formatação CSS é aplicada nas páginas XHTML. A saída imprimível é atualmente renderizada com folhas de estilo legadas do DSSSL, mas isso provavelmente mudará no futuro. <acronym>CSS</acronym> Folhas de estilos em cascata (CSS) são um mecanismo para anexar informações de estilo (font, weight, size, color e assim por diante) a elementos em um documento XHTML sem abusar de XHTML para o fazer. Os Documentos DocBook As folhas de estilo XSLT e DSSSL do FreeBSD se referem a docbook.css, que deve estar presente no mesmo diretório que os arquivos XHTML. O arquivo CSS de todo o projeto é copiado de doc/share/misc/docbook.css quando os documentos são convertidos para XHTML e são instalados automaticamente . 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. O FAQ é mantido pela Equipe de Engenharia de Documentação doceng@FreeBSD.org. 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. 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. 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. 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. Quais softwares eu preciso conhecer? É fortemente recomendado que você mantenha uma cópia local do repositório Subversion do FreeBSD (pelo menos a parte da documentação). Isso pode ser feito executando: % svn checkout https://svn.FreeBSD.org/doc/head/ head svn.FreeBSD.org é um servidor público SVN. Verifique o certificado do servidor na lista de Mirrors de Subversion. Será necessário que o pacote devel/subversion esteja instalado. Você deverá ter conhecimentos básicos de svn. 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 r33733 e r33734 do en_US.ISO8859-1/books/fdp-primer/book.xml, execute: % svn diff -r33733:33734 en_US.ISO8859-1/books/fdp-primer/book.xml Por favor, veja a explicação completa de como usar o Subversion no FreeBSD no FreeBSD Handbook. 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 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. 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. 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). Eu sou a única pessoa trabalhando na tradução para este idioma, como faço para enviar minha tradução? ou Somos uma equipe de tradução e queremos enviar a documentação que nossos membros traduziram para nós. 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. Atualmente a documentação do FreeBSD é armazenada em um diretório de nível superior chamado head/. 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: head/ sv_SE.ISO8859-1/ Makefile htdocs/ docproj/ books/ faq/ Makefile book.xml sv_SE.ISO8859-1 é o nome da tradução, no formato lang.encoding . Repare nos dois Makefiles, que serão usados ​​para compilar a documentação. Usetar1 e gzip1 para compactar sua documentação e enviá-lo para o projeto. % cd doc % tar cf swedish-docs.tar sv_SE.ISO8859-1 % gzip -9 swedish-docs.tar Coloque swedish-docs.tar.gz em algum lugar. Se você não tiver acesso ao seu próprio espaço web (talvez seu ISP não disponibilize um), envie um email para a Equipe de Engenharia da Documentação doceng@FreeBSD.org e combine o envio dos arquivos por email conveniente quando for conveniente. De qualquer maneira, 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, as seguintes coisas serão analisadas: Todos os seus arquivos usam strings RCS (tais como "ID")? O make all no diretório sv_SE.ISO8859-1 funciona corretamente? O make install 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. 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. Como os caracteres específicos do idioma podem ser incluídos? Caracteres não-ASCII na documentação devem ser incluídos usando entidades SGML. Resumidamente, eles se parecem com um "e" comercial (&), o nome da entidade e um ponto e vírgula (;). Os nomes das entidades são definidos em ISO8879, que está na árvore de ports em textproc/iso8879. Alguns exemplos incluem: Entidade Aparência Descrição &eacute; é e minúsculo com acento agudo &Eacute; É E maiúsculo com acento agudo &uuml; ü u minúsculo com trema Depois de instalar o port iso8879, os arquivos em /usr/local/share/xml/iso8879 conterão a lista completa. 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. 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: <!-- The FreeBSD Documentation Project $FreeBSD$ --> 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 Subversion, 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: <!-- The FreeBSD Spanish Documentation Project $FreeBSD$ Original revision: r38674 --> Traduções <acronym>PO</acronym> 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. Quick Start Supõe-se que o procedimento mostrado em 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. Instale um Editor <acronym>PO</acronym> É necessário um editor PO para editar os arquivos de tradução. Este exemplo utiliza o editors/poedit. # cd /usr/ports/editors/poedit # make install clean 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: Crie um diretório para a nova tradução. O código fonte do artigo em Inglês está em ~/doc/en_US.ISO8859-1/articles/leap-seconds/. A tradução em Espanhol estará em ~/doc/es_ES.ISO8859-1/articles/leap-seconds/. O caminho é o mesmo, exceto pelo nome do diretório de idiomas. % svn mkdir --parents ~/doc/es_ES.ISO8859-1/articles/leap-seconds/ Copie o Makefile do documento original para o diretório de tradução: % svn cp ~/doc/en_US.ISO8859-1/articles/leap-seconds/Makefile \ ~/doc/es_ES.ISO8859-1/articles/leap-seconds/ 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. Extraia as strings traduzíveis da versão original em Inglês para um arquivo PO: % cd ~/doc/es_ES.ISO8859-1/articles/leap-seconds/ % make po 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. O nome do arquivo PO é o código de idioma de dois caracteres seguido por um código de região de também dois caracteres, seprados por um underline. Para espanhol, o nome do arquivo é es_ES.po. % poedit es_ES.po Gerando um Documento Traduzido Gere o documento traduzido: % cd ~/doc/es_ES.ISO8859-1/articles/leap-seconds/ % make tran O nome do documento gerado corresponde ao nome do original em Inglês, geralmente article.xml para artigos ou book.xml para livros. Verifique o arquivo gerado renderizando-o para HTML e exibindo-o com um navegador web: % make FORMATS=html % firefox article.html 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_REGION . lang é um código minúsculo de dois caracteres. Ele é seguido por um caractere underline, em seguida, pelo código de duas letras maiúsculas REGION. Nomes de Idioma Língua Região Nome do Diretório Traduzido Nome do Arquivo PO Conjunto de Caracteres Inglês Estados Unidos en_US.ISO8859-1 en_US.po ISO 8859-1 Bengali Bangladesh bn_BD.UTF-8 bn_BD.po UTF-8 Dinamarquês Dinamarca da_DK.ISO8859-1 da_DK.po ISO 8859-1 Alemão Alemanha de_DE.ISO8859-1 de_DE.po ISO 8859-1 Grego Grécia el_GR.ISO8859-7 el_GR.po ISO 8859-7 Espanhol Espanha es_ES.ISO8859-1 es_ES.po ISO 8859-1 Francês França fr_FR.ISO8859-1 fr_FR.po ISO 8859-1 Húngaro Hungria hu_HU.ISO8859-2 hu_HU.po ISO 8859-2 Italiano Itália it_IT.ISO8859-15 it_IT.po ISO 8859-15 Japonês Japão ja_JP.eucJP ja_JP.po EUC JP Coreano Coréia ko_KR.UTF-8 ko_KR.po UTF-8 Mongol Mongólia mn_MN.UTF-8 mn_MN.po UTF-8 Holandês Holanda nl_NL.ISO8859-1 nl_NL.po ISO 8859-1 Polonês Polônia pl_PL.ISO8859-2 pl_PL.po ISO 8859-2 Português Brasil pt_BR.ISO8859-1 pt_BR.po ISO 8859-1 Russo Rússia ru_RU.KOI8-R ru_RU.po KOI8-R Turco Turquia tr_TR.ISO8859-9 tr_TR.po ISO 8859-9 Chinês China zh_CN.UTF-8 zh_CN.po UTF-8 Chinês Taiwan zh_TW.UTF-8 zh_TW.po UTF-8
As traduções estão em subdiretórios do diretório principal da documentação, aqui assumido como ~/doc/ como mostrado em . Por exemplo, as traduções em alemão estão localizadas em ~/doc/de_DE.ISO8859-1/ e as traduções em francês estão em ~/doc/fr_FR.ISO8859-1/. 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/fr_FR.ISO8859-1/articles/nanobsd/, e a tradução em Mongol do manual está em ~/doc/mn_MN.UTF-8/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. As compilações da documentação do FreeBSD são controladas por um Makefile no mesmo diretório. Com artigos simples, o Makefile muitas vezes pode ser copiado literalmente do diretório original em inglês. O processo de tradução combina vários arquivos book.xml e chapter.xml de livros em um único arquivo, portanto, o Makefile para as traduções de livros deve ser copiado e modificado. 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/en_US.ISO8859-1/books/porters-handbook/. O diretório de livros em Espanhol ~/doc/es_ES.ISO8859-1/books/ já existe, portanto, apenas um novo subdiretório para o Porter's Handbook é necessário: % cd ~/doc/es_ES.ISO8859-1/books/ % svn mkdir porters-handbook A porters-handbook Copie o Makefile do livro original: % cd ~/doc/es_ES.ISO8859-1/books/porters-handbook % svn cp ~/doc/en_US.ISO8859-1/books/porters-handbook/Makefile . A Makefile Modifique o conteúdo do Makefile para esperar apenas um único book.xml: # # $FreeBSD$ # # Build the FreeBSD Porter's Handbook. # MAINTAINER=doc@FreeBSD.org DOC?= book FORMATS?= html-split INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= # XML content SRCS= book.xml # Images from the cross-document image library IMAGES_LIB+= callouts/1.png IMAGES_LIB+= callouts/2.png IMAGES_LIB+= callouts/3.png IMAGES_LIB+= callouts/4.png IMAGES_LIB+= callouts/5.png IMAGES_LIB+= callouts/6.png IMAGES_LIB+= callouts/7.png IMAGES_LIB+= callouts/8.png IMAGES_LIB+= callouts/9.png IMAGES_LIB+= callouts/10.png IMAGES_LIB+= callouts/11.png IMAGES_LIB+= callouts/12.png IMAGES_LIB+= callouts/13.png IMAGES_LIB+= callouts/14.png IMAGES_LIB+= callouts/15.png IMAGES_LIB+= callouts/16.png IMAGES_LIB+= callouts/17.png IMAGES_LIB+= callouts/18.png IMAGES_LIB+= callouts/19.png IMAGES_LIB+= callouts/20.png IMAGES_LIB+= callouts/21.png URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" Agora a estrutura do documento está pronta para o tradutor começar a tradução com make po. Criando uma tradução em Francês do Artigo Chaves Open <acronym>PGP</acronym> Crie uma nova tradução em Francês do artigo Chaves Open PGP. O original é um artigo em ~/doc/en_US.ISO8859-1/articles/pgpkeys/. O diretório de artigos em Francês ~/doc/fr_FR.ISO8859-1/articles/ já existe, portanto, apenas um novo subdiretório para o artigo Chaves Open PGP é necessário: % cd ~/doc/fr_FR.ISO8859-1/articles/ % svn mkdir pgpkeys A pgpkeys Copie o Makefile do artigo original: % cd ~/doc/fr_FR.ISO8859-1/articles/pgpkeys % svn cp ~/doc/en_US.ISO8859-1/articles/pgpkeys/Makefile . A Makefile Verifique o conteúdo do Makefile. Este é um artigo simples e neste caso, o Makefile pode ser usado sem altaração. A string $FreeBSD...$ na segunda linha será substituída pelo sistema de controle de versão quando este arquivo sofrer um commit. # # $FreeBSD$ # # Article: PGP Keys DOC?= article FORMATS?= html WITH_ARTICLE_TOC?= YES INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= SRCS= article.xml # To build with just key fingerprints, set FINGERPRINTS_ONLY. URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" Com a estrutura do documento completa, o arquivo PO pode ser criado com make po. 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. editores/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. Traduzindo o Porter's Handbook para o Espanhol Digite as traduções para o Espanhol do conteúdo do Porter's Handbook. Mude para o diretório Espanhol do Porter's Handbook e atualize o arquivo PO. O arquivo PO gerado é chamado es_ES.po como mostrado em . % cd ~/doc/es_ES.ISO8859-1/books/porters-handbook % make po Realize as traduções usando um editor de PO: % poedit es_ES.po Dicas para Tradutores Preservando Tags <acronym>XML</acronym> Preserve as tags XML mostradas no original em Inglês. Preservando Tags <acronym>XML</acronym> Inglês original: If acronymNTPacronym is not being used Tradução para o Espanhol: Si acronymNTPacronym no se utiliza 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. Tags O conteúdo de algumas tags devem ser copiadas igualmente, sem realizar tradução: citerefentry command filename literal manvolnum orgname package programlisting prompt refentrytitle screen userinput varname Strings <literal>$FreeBSD$</literal> As strings da versão $FreeBSD$ usadas nos arquivos requerem tratamento especial. Nos exemplos como , essas strings não devem ser expandidas. Os documentos em inglês usam entidades &dollar; para evitar a inclusão de sinais reais de dólar no arquivo: &dollar;FreeBSD&dollar; As entidades &dollar; não são vistas como cifrões pelo sistema de controle de versão e, portanto, a string não é expandida em uma string de versão. Quando um arquivo PO é criado, as entidades &dollar; usadas nos exemplos são substituídas por cifrões reais. A sequência literal $FreeBSD$ será expandida incorretamente pelo sistema de controle de versão quando o arquivo sofrer algum commit. A mesma técnica usada nos documentos em Inglês pode ser usada na tradução. O &dollar; é usado para substituir o sinal de dólar na tradução inserida no editor PO: &dollar;FreeBSD&dollar; 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 utiilizável. Construindo o Porter's Handbook Espanhol Compile e visualize a versão em Espanhol do Porter's Handbook criado em um exemplo anterior. Compile o documento traduzido. Como o original é um livro, o documento gerado é book.xml. % cd ~/doc/es_ES.ISO8859-1/books/porters-handbook % make tran Renderize o book.xml traduzido para HTML e visualize-o com o Firefox. Este é o mesmo procedimento usado com a versão em Inglês dos documentos, e outros FORMATS podem ser usados ​​aqui da mesma maneira. Veja . % make FORMATS=html % firefox book.html 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. Tradução Espanhola do Artigo NanoBSD Adicione a string FreeBSD na primeira linha do arquivo PO: #$FreeBSD$ Adicione o Makefile, o arquivo PO e o arquivo traduzido XML que foi gerado para o controle de versão: % cd ~/doc/es_ES.ISO8859-1/articles/nanobsd/ % ls Makefile article.xml es_ES.po % svn add Makefile article.xml es_ES.po A Makefile A article.xml A es_ES.po Configure as propriedades Subversion svn:keywords nesses arquivos para FreeBSD=%H para que as strings $FreeBSD$ sejam expandidas com o caminho, revisão, data e autor quando o arquivo sofrer o commit: % svn propset svn:keywords FreeBSD=%H Makefile article.xml es_ES.po property 'svn:keywords' set on 'Makefile' property 'svn:keywords' set on 'article.xml' property 'svn:keywords' set on 'es_ES.po' Defina os tipos MIME dos arquivos. Estes são text/xml para livros e artigos, e text/x-gettext-translation para o arquivo PO. % svn propset svn:mime-type text/x-gettext-translation es_ES.po property 'svn:mime-type' set on 'es_ES.po' % svn propset svn:mime-type text/xml article.xml property 'svn:mime-type' set on 'article.xml' 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 svn diff es_ES.ISO8859-1/articles/nanobsd/ > /tmp/es_nanobsd.diff Tradução Coreana <acronym>UTF-8</acronym> do Artigo Explicando o BSD Adicione a string FreeBSD na primeira linha do arquivo PO: #$FreeBSD$ Adicione o Makefile, o arquivo PO e o arquivo traduzido XML que foi gerado para o controle de versão: % cd ~/doc/ko_KR.UTF-8/articles/explaining-bsd/ % ls Makefile article.xml ko_KR.po % svn add Makefile article.xml ko_KR.po A Makefile A article.xml A ko_KR.po Configure as propriedades Subversion svn:keywords nesses arquivos para FreeBSD=%H para que as strings $FreeBSD$ sejam expandidas com o caminho, revisão, data e autor quando o arquivo sofrer o commit: % svn propset svn:keywords FreeBSD=%H Makefile article.xml ko_KR.po property 'svn:keywords' set on 'Makefile' property 'svn:keywords' set on 'article.xml' property 'svn:keywords' set on 'ko_KR.po' Defina os tipos MIME dos arquivos. Como esses arquivos usam o conjunto de caracteres UTF-8, isso também é especificado. Para evitar que o sistema de controle de versão confunda esses arquivos com arquivos binários, a propriedade fbsd:notbinary também é configurada: % svn propset svn:mime-type 'text/x-gettext-translation; charset=UTF-8' ko_KR.po property 'svn:mime-type' set on 'ko_KR.po' % svn propset fbsd:notbinary yes ko_KR.po property 'fbsd:notbinary' set on 'ko_KR.po' % svn propset svn:mime-type 'text/xml; charset=UTF-8' article.xml property 'svn:mime-type' set on 'article.xml' % svn propset fbsd:notbinary yes article.xml property 'fbsd:notbinary' set on 'article.xml' Crie um diff desses novos arquivos no diretório base ~/doc/: % cd ~/doc svn diff ko_KR.UTF-8/articles/explaining-bsd > /tmp/ko-explaining.diff Páginas de Manual 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 man1. 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. 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: Número da Seção Categoria 1 Comandos Gerais 2 System Calls 3 Library Functions 4 Interfaces de Kernel 5 Formatos de Arquivo 6 Jogos 7 Diversos 8 System Manager 9 Desenvolvedor Kernel Marcação Vários formulários de marcação e programas de renderização foram usados ​​para páginas de manual. O FreeBSD usou groff7 e o mais recente mandoc1. A maioria das páginas de manual do FreeBSD, e todas as novas, usam o formulário mdoc7 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 gzip1 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 man1. 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. man1 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 ./: % man ./mynewmanpage.8 Um caminho absoluto também pode ser usado: % man /home/xsmith/mynewmanpage.8 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: Nome da Seção Descrição NAME Nome do Comando SYNOPSIS Formato das opções e argumentos DESCRIPTION Descrição da finalidade e uso ENVIRONMENT Configurações de ambiente que afetam a operação EXIT STATUS Códigos de erro retornados na saída EXAMPLES Exemplos de uso COMPATIBILITY Compatibilidade com outras implementações SEE ALSO Referência cruzada para páginas de manual relacionadas STANDARDS Compatibilidade com padrões como o POSIX HISTORY História de implementação BUGS Bugs conhecidos AUTHORS Pessoas que criaram o comando ou escreveram a página de manual. 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. Macros A marcação mdoc7 é 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 ls1: .Dd December 1, 2015 .Dt LS 1 .Sh NAME .Nm ls .Nd list directory contents .Sh SYNOPSIS .Nm .Op Fl -libxo .Op Fl ABCFGHILPRSTUWZabcdfghiklmnopqrstuwxy1, .Op Fl D Ar format .Op Ar .Sh DESCRIPTION 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. O Document date e Document title são definidos. O Cabeçalho da Seção para a seção NAME é definido. Em seguida, são definidos o Nome do comando e uma Descrição do Nome de uma linha. A seção SYNOPSIS começa. Esta seção descreve as opções e argumentos de linha de comando que são aceitos. Nome (.Nm) já foi definido, e repeti-lo aqui apenas exibe o valor definido no texto. Uma Optional Flag chamada -libxo é mostrada. A macro Fl adiciona um traço ao início das flags, portanto, isso aparece na página de manual como --libxo. Uma longa lista de sinalizadores opcionais de caracteres únicos é apresentada. Uma flag opcional -D é definida. Se a flag -D for informada, ela deve ser seguida por um Argumento. O argumento é um format, uma string que diz ls1 o que exibir e como exibi-lo. Detalhes sobre a string de formato são fornecidos posteriormente na página de manual. Um argumento opcional final é definido. Como nenhum nome é especificado para o argumento, o padrão file ... é usado. O Cabeçalho da Seção 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. Diretrizes de Marcação A linguagem de marcação mdoc7 não é muito rigorosa. Para maior clareza e consistência, o projeto 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. 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,. Macros Importantes Algumas macros muito comuns serão mostradas aqui. Para obter mais exemplos de uso, consulte mdoc7, groff_mdoc7, 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' Macros Organizacionais Algumas macros são usadas para definir blocos lógicos de uma página de manual. Macro Organizacional Uso .Sh Section header (Cabeçalho da seção). Seguido pelo nome da seção, tradicionalmente com os caracteres todos em maiúsculas. Pense neles como títulos de capítulos. .Ss Subsection header (Cabeçalho da subseção). Seguido pelo nome da subseção. Usado para dividir uma seção .Sh em subseções. .Bl Begin list. Comece uma lista de itens. .El End a list (Finalize uma lista). .Bd Begin display (Comece a exibição). Comece em uma área especial de texto, como uma área recuada. .Ed End display (Termine a exibição). Macros Inline Muitas macros são usadas para marcar texto embutido. Macro Inline Uso .Nm Name. Chamado com um nome como parâmetro no primeiro uso, usado depois sem o parâmetro para exibir o nome que já foi definido. .Pa Path to a file (Caminho para um arquivo). Usado para marcar nomes de arquivos e caminhos de diretório. 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. 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 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 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 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. Página Manual Caminho para o local de origem cp1 /usr/src/bin/cp/cp.1 vt4 /usr/src/share/man/man4/vt.4 crontab5 /usr/src/usr.sbin/cron/crontab/crontab.5 gpart8 /usr/src/sbin/geom/class/part/gpart.8 Recursos Recursos para escritores de páginas manuais: man1 mandoc1 groff_mdoc7 Manuais Práticos do UNIX: mdoc História das Man pages do UNIX Estilo de escrita 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. 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ível. 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. 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. 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. 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.
É 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, o comando, o arquivo e o comando man são frequentemente redundantes. Por exemplo, comandos: Errado: Use o comando svn para atualizar o código fonte. Correto: Use o svn 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 &man.csh.1;):. Errado: Veja man csh para mais informações. Correto: Veja csh1. Dois espaços entre frases Sempre use dois espaços entre as sentenças, pois isso melhora a legibilidade e facilita o uso de ferramentas como o Emacs. Um período e espaços seguidos por uma letra maiúscula nem sempre marcam uma nova sentença, especialmente em nomes. Jordan K. Hubbard é um bom exemplo. Ele tem um capital H após um período e um espaço, e certamente não é uma nova sentença. Para mais informações sobre o estilo de escrita, consulte Elementos de Estilo, de William Strunk. 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. Letter Case As tags são digitadas em minúsculas, para, não PARA. O texto que aparece em contextos SGML é geralmente escrito em letras maiúsculas, <! ENTITY ... >, e <! DOCTYPE… >, não <! entity… > e <! doctype… >. Siglas Os acrônimos devem ser definidos na primeira vez que aparecerem em um documento, como em: Network Time Protocol (NTP). Depois que o acrônimo tiver sido definido, use apenas o acrônimo, a menos que faça mais sentido contextualmente usar todo o termo. Acrônimos geralmente são definidos apenas uma vez por capítulo ou por documento. Todos os acrônimos devem ser colocados em tags acronym. Indentação A primeira linha em cada arquivo começa sem recuo, independentemente do nível de recuo do arquivo que pode conter o arquivo atual. Tags de abertura aumentam o nível de recuo por dois espaços. Tags de fechamento diminuem o nível de recuo por dois espaços. Blocos de oito espaços no início de uma linha devem ser substituídos por um tab. Não use espaços na frente das tabs e não adicione espaço em branco extra no final de uma linha. O conteúdo nos elementos deve ser indentado por dois espaços se o conteúdo for executado em mais de uma linha. Por exemplo, a fonte desta seção é assim: chapter title...title sect1 title...title sect2 titleIndentationtitle paraThe first line in each file starts with no indentation, emphasisregardlessemphasis of the indentation level of the file which might contain the current file.para ... sect2 sect1 chapter Tags contendo atributos longos seguem as mesmas regras. Seguir as regras de recuo neste caso ajuda editores e escritores a ver qual conteúdo está dentro das tags: paraSee the link linkend="gmirror-troubleshooting"Troubleshootinglink section if there are problems booting. Powering down and disconnecting the original filenameada0filename disk will allow it to be kept as an offline backup.para paraIt is also possible to journal the boot disk of a &os; system. Refer to the article link xlink:href="&url.articles.gjournal-desktop;"Implementing UFS Journaling on a Desktop PClink for detailed instructions.para Quando um elemento é muito longo para caber no restante de uma linha sem quebrá-la, mover a tag inicial para a próxima linha pode facilitar a leitura do código. Neste exemplo, o elemento systemitem foi movido para a próxima linha para evitar a quebra e o recuo: paraWith file flags, even systemitem class="username"rootsystemitem can be prevented from removing or altering files.para Configurações para ajudar vários editores de texto a operar em conformidade com estas diretrizes podem ser encontradas em . Estilo de Tag Espaçamento de tag Tags que começam no mesmo recuo como uma tag anterior devem ser separadas por uma linha em branco, e aquelas que não estão no mesmo recuo como uma tag anterior não devem: article lang='en' articleinfo titleNIStitle pubdateOctober 1999pubdate abstract para... ... ...para abstract articleinfo sect1 title...title para...para sect1 sect1 title...title para...para sect1 article Separando Tags Tags como itemizedlist, que sempre terão outras tags dentro delas, e de fato não pegam dados de caractere, estão sempre sozinhas em uma linha. Tags como para e term não precisam de outras tags para conter dados de caracteres normais, e seus conteúdos começam imediatamente após a tag, na mesma linha . O mesmo se aplica quando esses dois tipos de tags fecham. Isso leva a um problema óbvio ao misturar essas tags. Quando uma tag inicial que não pode conter dados de caractere segue diretamente uma tag do tipo que requer outras tags dentro dela para usar dados de caractere, elas estão em linhas separadas. A segunda tag deve estar corretamente recuada. Quando uma tag que pode conter dados de caractere é fechada diretamente após uma tag que não pode conter dados de caractere fechados, eles coexistem na mesma linha. Mudanças no espaço em branco Não faça commit de mudanças no conteúdo ao mesmo tempo em que faz mudanças na formatação. Quando as alterações de conteúdo e espaço em branco são mantidas separadas, as equipes de tradução podem ver facilmente se uma alteração foi de um conteúdo que deve ser traduzido ou apenas espaço em branco. Por exemplo, se duas sentenças foram adicionadas a um parágrafo para que os comprimentos de linha passem de 80 colunas, primeiro faça commit da alteração com as linhas longas demais. Em seguida, corrija a quebra de linha e confirme essa segunda alteração. Na mensagem de confirmação da segunda alteração, indique que esta é uma alteração somente de espaço em branco a qual pode ser ignorada pelos tradutores. Espaços Não Separáveis (Non-Breaking Space) Evite quebras de linha em locais onde elas pareçam feias ou dificultem o entendimento de uma frase. Quebras de linha dependem da largura do meio de saída escolhido. Em particular, a visualização da documentação em HTML com um navegador de texto pode levar a parágrafos mal formatados como o seguinte: A capacidade de dados varia de 40 MB a 15 GB Compressão de hardware… A entidade geral &nbsp; proíbe as quebras de linha entre as partes que estão juntas. Use espaços não separáveis ​​nos seguintes locais: entre números e unidades: 57600&nbsp;bps entre nomes de programas e números de versão: &os;&nbsp;9.2 entre nomes com várias palavras (use com cautela ao aplicar isso em nomes de mais de 3-4 palavras como The FreeBSD Portuguese Portuguese Documentation Project): Sun &Microsystems Lista de palavras Esta lista de palavras mostra a ortografia e letras maiúsculas corretas quando usadas na documentação do FreeBSD. Se uma palavra não estiver nesta lista, pergunte sobre isso na lista de discussão do projeto de documentação do FreeBSD. Palavra Código XML Notas CD-ROM acronymCD-ROMacronym DoS (negação de serviço) acronymDoSacronym email sistema de arquivo IPsec Internet página de manual servidor de email nome do servidor Coleção de Ports somente leitura Soft Updates stdin varnamestdinvarname stdout varnamestdoutvarname stderr varnamestderrvarname Subversion applicationSubversionapplication Não se refira ao aplicativo Subversion como SVN em letras maiúsculas. Para se referir ao comando, use commandsvncommand. UNIX &unix; userland coisas que se aplicam ao espaço do usuário, não ao kernel servidor web 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 FDP. <application>Vim</application> Instale-o a partir de editors/vim, editors/vim-console, ou editors/vim-tiny e siga as instruções de configuração em . Uso Pressione P para reformatar parágrafos ou texto selecionado no modo Visual. Pressione T para substituir grupos de oito espaços por um tab. 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 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() <application>Emacs</application> Instale-o a partir de editors/emacs ou editors/emacs-devel. 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 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. 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")))) <application>nano</application> Instale o aplicativo partir de editors/nano ou editors/nano-devel. 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 Uso Especifique opções úteis adicionais ao executar o editor: % nano -AKipwz -r 70 -T8 chapter.xml Usuários do csh1 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 chapter.xml Veja também Este documento não é deliberadamente uma discussão exaustiva de XML, das DTDs listadas e o Projeto de Documentação do FreeBSD. Para mais informações sobre estes, você é encorajado a consultar os seguintes sites. O projeto de documentação do FreeBSD As Páginas Web do Projeto de Documentação do FreeBSD O Handbook do FreeBSD XML Página W3C's XML Página Web SGML/XML HTML O Consórcio World Wide Web A especificação HTML 4.0 DocBook O Comitê Técnico do DocBook , mantenedores do DocBook DTD DocBook: O Guia Definitivo , a documentação online do DocBook DTD O DocBook Open Repository contém folhas de estilo DSSSL e outros recursos para pessoas que usam DocBook Exemplos Estes exemplos não são exaustivos - eles não contêm todos os elementos que podem ser desejáveis ​​de usar, particularmente em relação ao inicio dos documentos (Front Matter). Para mais exemplos de marcação DocBook, examine o código XML para este e outros documentos disponíveis no repositório Subversion doc ou disponível on-line a partir de http://svnweb.FreeBSD.org/doc/. <tag>Livro</tag> DocBook <tag>Livro</tag> DocBook <!DOCTYPE book PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd"> book xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" info titleAn Example Booktitle author personname firstnameYour first namefirstname surnameYour surnamesurname personname affiliation address emailfoo@example.comemail address affiliation author copyright year2000year holderCopyright string hereholder copyright abstract paraIf your book has an abstract then it should go here.para abstract info preface titlePrefacetitle paraYour book may have a preface, in which case it should be placed here.para preface chapter titleMy First Chaptertitle paraThis is the first chapter in my book.para sect1 titleMy First Sectiontitle paraThis is the first section in my book.para sect1 chapter book <tag>Artigo</tag> DocBook <tag>Artigo</tag> DocBook <!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd"> article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" info titleAn Example Articletitle author personname firstnameYour first namefirstname surnameYour surnamesurname personname affiliation address emailfoo@example.comemail address affiliation author copyright year2000year holderCopyright string hereholder copyright abstract paraIf your article has an abstract then it should go here.para abstract info sect1 titleMy First Sectiontitle paraThis is the first section in my article.para sect2 titleMy First Sub-Sectiontitle paraThis is the first sub-section in my article.para sect2 sect1 article