Re: [RFR] wml://webml/portuguese/Bugs/server-control.wml
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/25/2006 02:32 PM, Tassia Camoes wrote:
> Olá,
>
> Segue arquivo em anexo para revisao.
> Abraços,
Tassia, aproveitei pra revisar outros itens e sugerir mudanças.
O diff está em anexo. Note que eu converti o formato de quebra de linha
do dos para o unix. O patch atual não tem os ^M no final, portanto antes
de aplicar o patch, se você usa vi, faça um :set ff=unix no ser arquivo
.wml.
Eu também reverti poucas mudanças que você fez e fiz ajustes de
comprimento de linha, se aprovar as alterações envio ao repositório, se
tiver dúvidas ou questionamentos vamos discutí-las para que o WML possa
ser publicado o quanto antes.
Abraço,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iD8DBQFEnz4HCjAO0JDlykYRAr9KAKCnl7jG8lR5GZNnhGTU0qAhjDKO+ACgzjJ8
g+yoTZFVIKgK5DuD7c/xwME=
=CwWJ
-----END PGP SIGNATURE-----
--- server-control.wml 2006-06-25 22:50:17.385101552 -0300
+++ faw-server-control.wml 2006-06-25 22:50:21.885417400 -0300
@@ -27,7 +27,7 @@
<code>bug-log-mailserver.txt</code> ou enviando
<code>help</code> para qualquer um dos servidores para detalhes básicos de
operações dos servidores de e-mail e os comandos básicos disponíveis ao enviar
-mensagens para ambos os endereços.</P>
+mensagens para qualquer um dos endereços.</P>
<P>O <A href="server-refcard">cartão de referência</A> para os servidores de
e-mail está disponível via WWW em <code>bug-mailserver-refcard.txt</code> ou
@@ -41,7 +41,7 @@
[ <var>versão</var> ]
<dd>
-Registra que o bug #<var>número do bug</var> é um bug em <var>pacote</var>.
+Registra que o bug #<var>número-do-bug</var> é um bug em <var>pacote</var>.
Pode ser usado para definir o pacote caso o usuário tenha esquecido o
pseudo-cabeçalho ou para mudar uma atribuição anterior. Nenhuma notificação
é enviada para ninguém (a não ser a informação normal no processamento da
@@ -50,45 +50,45 @@
<p>Se você fornecer uma <var>versão</var>, o sistema de acompanhamento de bugs
perceberá que o bug afeta aquela versão do pacote recém-atribuído.
-<dt><code>reopen</code> <var>número do bug</var>
- [ <var>endereço-do-remetente</var> | <code>=</code> | <code>!</code> ]
+<dt><code>reopen</code> <var>número-do-bug</var>
+ [ <var>endereço-do-relator</var> | <code>=</code> | <code>!</code> ]
<dd>
-Reabre #<var>número do bug</var> caso o mesmo esteja fechado.
+Reabre #<var>número-do-bug</var> caso o mesmo esteja fechado.
<p>Por padrão, ou se você especificar <code>=</code>, a pessoa que enviou
originalmente o relatório de bug continua como o remetente do relatório, assim
a mesma poderá receber uma notificação quando o bug for fechado novamente.</p>
-<p>Caso você forneça um <var>endereço-do-remetente</var> o remetente será
+<p>Caso você forneça um <var>endereço-do-relator</var> o remetente será
definido como o endereço que você fornecer. Caso você deseje se tornar o novo
remetente do relatório reaberto você pode usar o atalho <code>!</code> ou
especificar seu próprio endereço de e-mail.</p>
<p>Normalmente é uma boa idéia avisar à pessoa que está prestes a ser
-registrada como o remetente que você está reabrindo o relatório, assim ela
-saberá que poderá esperar a notificação que ela receberá quando o bug for
+registrada como o relator que você está reabrindo o relatório, assim ela
+estará avisada para esperar a notificação que receberá quando o bug for
fechado novamente.</p>
<p>Caso o bug não esteja fechado, reabrir o mesmo não resultará em nada, nem
-mesmo mudar o remetente. Para alterar o remetente de um relatório de bug
+mesmo mudar o relator. Para alterar o remetente de um relatório de bug
aberto, use o comando <code>submitter</code>; note que isto notificará o
-remetente original de que esta mudança foi feita.
+relator original sobre esta mudança.
<p>Se o bug foi registrado como fechado em determinada versão de um pacote
-mas reapareceu em uma versão posterior, é preferível utilizar o comando
+mas reapareceu em uma versão posterior, é melhor utilizar o comando
<code>found</code>.
-<dt><code>found</code> <var>número do bug</var> [ <var>versão</var> ]
+<dt><code>found</code> <var>número-do-bug</var> [ <var>versão</var> ]
-<dd>Registra que #<var>número do bug</var> foi encontrado em determinada
+<dd>Registra que #<var>número-do-bug</var> foi encontrado em determinada
<var>versão</var> do pacote ao qual ele está atribuído.
<p>O sistema de acompanhamento de bugs utiliza essa informação, em conjunto
com as versões corrigidas que são registradas quando bugs são fechados, para
-exibir listas de bugs abertos em várias versões de cada pacote. O sistema
-considera um bug como aberto quando não há uma versão corrigida, ou quando o
-bug é encontrado novamente após ter sido corrigido.
+exibir listas de bugs abertos em várias versões de cada pacote. O sistema
+considera um bug como aberto quando não há uma versão corrigida, ou quando o
+bug é encontrado (found) mais recentemente do que havia sido corrigido.
<p>Caso nenhuma <var>versão</var> seja fornecida, a lista de versões corrigidas
para o bug é esvaziada. Isto é idêntico ao comportamento do <code>reopen</code>.
@@ -97,9 +97,9 @@
era difícil adicionar uma <var>versão</var> à sintaxe desse comando sem sofrer
ambigüidade.
-<dt><code>notfound</code> <var>número do bug</var> <var>versão</var>
+<dt><code>notfound</code> <var>número-do-bug</var> <var>versão</var>
-<dd>Remove o registro de que #<var>número do bug</var> foi encontrado em
+<dd>Remove o registro de que #<var>número-do-bug</var> foi encontrado em
determinada <var>versão</var> do pacote ao qual ele está atribuído.
<p>Isso é diferente de fechar o bug na versão especificada, uma vez que o bug
@@ -107,86 +107,94 @@
sobre aquela versão será conhecida. O objetivo é corrigir erros no registro de
quando um bug foi encontrado.
-<dt><code>submitter</code> <var>numéro do bug</var>
-<var>endereço-do-remetente</var> | <code>!</code>
+<dt><code>submitter</code> <var>número-do-bug</var>
+<var>endereço-do-relator</var> | <code>!</code>
<dd>
-Altera o remetente do #<var>numéro do bug</var> para
-<var>endereço-do-remetente</var>.
+Altera o relador do #<var>número-do-bug</var> para
+<var>endereço-do-relator</var>.
<p>Se você deseja ser o novo remetente do relatório você pode usar o
<code>!</code> ou especificar seu próprio endereço de email.</p>
-<p>Enquanto o comando <code>reopen</code> altera o remetente dos outros bugs
-unidos com o que está sendo aberto novamente, <code>submitter</code> não
+<p>Enquanto o comando <code>reopen</code> altera o relator dos outros bugs
+unidos com o que está sendo aberto novamente, <code>submitter</code> não
afeta bugs unidos.</p>
-<dt><code>forwarded</code> <var>número do bug</var> <var>endereço</var>
+<dt><code>forwarded</code> <var>número-do-bug</var> <var>endereço</var>
<dd>
-Marca que <var>número do bug</var> foi encaminhado para o mantenedor original
+Marca que <var>número-do-bug</var> foi encaminhado para o mantenedor original
em <var>endereço</var>. Isto na verdade não encaminha o relatório. Isso pode
-ser usado para modificar um endereço de encaminhamento existente incorreto ou
+ser usado para modificar um endereço de encaminhamento incorreto existente ou
para registrar um novo endereço para um bug que não tenha sido marcado como
tendo sido encaminhado.
-<dt><code>notforwarded</code> <var>número do bug</var>
+<dt><code>notforwarded</code> <var>número-do-bug</var>
<dd>
-Esquece qualquer vestígio de que <var>número do bug</var> foi encaminhado para
-qualquer mantenedor original. Caso o bug não tenha sido marcado como tendo
-sido encaminhado então isso não causará nada.
+Esquece qualquer vestígio de que <var>número do bug</var> foi encaminhado
+para qualquer mantenedor original. Caso o bug não tenha sido marcado como
+tendo sido encaminhado então isso não causará nada.
-<dt><code>retitle</code> <var>número do bug</var> <var>novo-título</var>
+<dt><code>retitle</code> <var>número-do-bug</var> <var>novo-título</var>
<dd>
Muda o título de um relatório de bug para o especificado (o padrão é
-o campo <code>Assunto</code> do cabeçalho da mensagem do relatório original).
+o cabeçalho <code>Subject</code> — Assunto — da mensagem do
+relatório original).
<p>Diferente da maioria dos outros comandos de manipulação de bugs, quando
-usado em um de um conjunto de relatórios unidos, modificará somente o
-título do bug individual requisitado e não todos aqueles com os quais o mesmo
-está unido.
+usado em um relatório de um conjunto de relatórios unidos, modificará
+somente o título do bug individual requisitado e não todos aqueles com os
+quais o mesmo está unido.
-<dt><code>severity</code> <var>número do bug</var> <var>severidade</var>
+<dt><code>severity</code> <var>número-do-bug</var> <var>severidade</var>
<dd>
-<p>Define o nível de severidade para o relatório de bug #<var>número do bug
-</var> para <var>severidade</var>. Nenhuma notificação é enviada para o usuário
-que reportou o bug.</p>
+<p>Define o nível de severidade para o relatório de bug #<var>número-do-bug
+</var> para <var>severidade</var>. Nenhuma notificação é enviada para o
+usuário que reportou o bug.</p>
<p>As severidades são <code>critical</code>, <code>grave</code>,
<code>serious</code>, <code>important</code>, <code>normal</code>,
<code>minor</code>, e <code>wishlist</code>.
<p>Para <A href="Developer#severities">os significados das severidades</A> por
-favor consulte o documentação geral do sistema de bugs para desenvolvedores.
+favor consulte a documentação geral dos desenvolvedores sobre o sistema de
+bugs.
-<dt><code>clone</code> <var>número do bug</var> <var> novo ID</var> [ <var>novos IDs</var> ... ]
+<dt><code>clone</code> <var>número-do-bug</var> <var>NovoID</var> [ <var>Novos IDs</var> ... ]
<dd>O comando de controle clone permite duplicar um relatório de bug. Ele é
- útil quando um único relatório na verdade indica que múltiplos bugs distintos
- ocorreram. "<var>Novos IDs</var>" são números negativos, separados por
- espaços, que podem ser usados em comandos de controle subseqüentes para se
- referir aos novos bugs duplicados. Um novo relatório é gerado para cada novo
- ID.
+ útil quando um único relatório na verdade indica que múltiplos bugs
+ distintos ocorreram. "<var>Novos IDs</var>" são números negativos,
+ separados por espaços, que podem ser usados em comandos de controle
+ subseqüentes para se referir aos novos bugs duplicados. Um novo relatório
+ é gerado para cada novo ID.
- <p>Exemplo de uso :</p>
+ <p>Exemplo de uso:</p>
<pre>
clone 12345 -1 -2
reassign -1 foo
- retitle -1 foo: foo sucks
+ retitle -1 foo: foo fede
reassign -2 bar
- retitle -2 bar: bar sucks when used with foo
+ retitle -2 bar: bar fede quando usado com foo
severity -2 wishlist
clone 123456 -3
reassign -3 foo
- retitle -3 foo: foo sucks
+ retitle -3 foo: foo fede
merge -1 -3
</pre>
+
+ <p>Lembre-se de escrever o seu relatório de bug em inglês, se precisar de
+ ajuda você pode enviar uma mensagem para
+ <email "debian-devel-portuguese@lists.debian.org"> ou para
+ <email "debian-l10n-portuguese@lists.debian.org">.</p>
+
-<dt><code>merge</code> <var>número do bug</var> <var>número do bug</var> ...
+<dt><code>merge</code> <var>número-do-bug</var> <var>número-do-bug</var> ...
<dd>
Une dois ou mais relatórios de bug. Quando relatórios são unidos, abrir,
@@ -196,43 +204,42 @@
<p>Antes que os bugs possam ser unidos os mesmos precisam estar exatamente
no mesmo estado: ou todos são bugs abertos ou todos são bugs fechados, com
-o mesmo endereço de encaminhamento para o autor original ou todos não marcados
-como encaminhados, todos atribuídos para o(s) mesmo(s) pacote(s) (uma comparação
-exata de strings é feita no pacote para o qual o bug está atribuído),
-e todos da mesma severidade. Caso os mesmos não estejam inicialmente no mesmo
-estado você deve usar <code>reassign</code>, <code>reopen</code> e assim por
-diante para certificar-se que os mesmos estejam no mesmo estado antes de usar
-<code>merge</code>. Os títulos não precisam ser os mesmos, e não serão
-afetados pelo merge. As tags também não precisam ser as mesmas, elas serão
-unidas.</p>
-
-<p>Caso qualquer um dos bugs listados em um comando <code>merge</code> já esteja
-unido com um outro bug, todos os relatórios unidos com quaisquer um dos
-relatórios listados serão todos unidos juntamente. Unir é como eqüalizar: é
+o mesmo endereço de encaminhamento para o autor original ou todos não
+marcados como encaminhados, todos atribuídos para o(s) mesmo(s) pacote(s)
+(uma comparação exata de strings é feita no pacote para o qual o bug está
+atribuído), e todos da mesma severidade. Caso os mesmos não estejam
+inicialmente no mesmo estado você deve usar <code>reassign</code>,
+<code>reopen</code> e assim por diante para certificar-se que os mesmos
+estejam no mesmo estado antes de usar <code>merge</code>. Os títulos não
+precisam ser os mesmos, e não serão afetados pelo merge. As tags também
+não precisam ser as mesmas, elas serão unidas.</p>
+
+<p>Caso qualquer um dos bugs listados em um comando <code>merge</code> já
+esteja unido com um outro bug, todos os relatórios unidos com quaisquer um
+dos relatórios listados serão todos unidos. Unir é como a igualdade: é
reflexivo, transitivo e simétrico.</p>
-<P>Unir relatórios faz com que uma nota apareça no relatório de log de cada
-relatório de bug; nas páginas WWW isto se reflete em inclusões de links para
+<P>Unir relatórios faz com que uma nota apareça no log de cada relatório
+de bug; nas páginas WWW isto faz com que sejam incluídos links para os
outros bugs.</p>
-<P>Relatórios unidos são todos expirados simultaneamente e somente quando todos
-os relatórios separadamente atinjam os critérios para expiração.
+<P>Relatórios unidos são todos expirados simultaneamente e somente quando
+todos os relatórios separadamente atinjam os critérios para expiração.
-<dt><code>forcemerge</code> <var>número do bug</var> <var>número do bug</var>
-...</dt>
+<dt><code>forcemerge</code> <var>número-do-bug</var> <var>número-do-bug</var> ...</dt>
<dd>Une forçadamente dois ou mais relatórios de bug. O primeiro bug listado
é o bug principal, e suas configurações (as configurações que devem ser
iguais numa união normal) são atribuídas aos bugs listados em seguida.
- Para evitar que erros tipográficos unam bugs erroneamente, os bugs precisam
- estar no mesmo pacote. Veja o texto acima para uma descrição do que união
- significa.
+ Para evitar que erros de digitação unam bugs erroneamente, os bugs precisam
+ estar no mesmo pacote. Veja o texto acima para uma descrição do que união
+ ("merge") significa.
<p>Note que isto torna possível o fechamento de bugs na união; você é
- responsável por notificar as pessoas que relataram os bugs com uma
- mensagem de fechamento apropriada se você fizer isto.</p>
+ responsável por notificar os relatores dos bugs com uma mensagem de
+ fechamento apropriada se você fizer isto.</p>
</dd>
-<dt><code>unmerge</code> <var>número do bug</var>
+<dt><code>unmerge</code> <var>número-do-bug</var>
<dd>
Desconecta um relatório de bug de quaisquer outros relatórios com os quais o
@@ -249,14 +256,14 @@
<code>unmerge</code>; caso você queira desconectar mais de um bug simplesmente
inclua diversos comandos <code>unmerge</code> em sua mensagem.
-<dt><code>tags</code> <var>número_do_bug</var> [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>tag</var> [ <var>tag</var> ... ]
+<dt><code>tags</code> <var>número-do-bug</var> [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>tag</var> [ <var>tag</var> ... ]
- <dd>Define tags para o relatório de bug #<var>número_do_bug</var>. Nenhuma
+ <dd>Define tags para o relatório de bug #<var>número-do-bug</var>. Nenhuma
notificação é enviada para o usuário que relatou o bug. Definir a ação
como <code>+</code> significa que cada <var>tag</var> dada deve ser
adicionada, <code>-</code> significa que cada <var>tag</var> deve ser
removida, e <code>=</code> significa que o conjunto atual de tags deve
- ser ignorado e redefinido a partir da lista fornecida. A ação padrão é
+ ser ignorado e definido a partir da lista fornecida. A ação padrão é
adicionar.
<p>Exemplo de uso:</p>
@@ -291,35 +298,36 @@
<code>sid</code> e <code>experimental</code>.
<p>Para <a href="Developer#tags">os significados das tags</a> por favor
- consulte a documentação geral do sistema de bugs para desenvolvedores.
+ consulte a documentação geral dos desenvolvedores sobre sistema de bugs.
-<dt><code>close</code> <var>número do bug</var> [ <var>versão-corrigida</var> ]
+<dt><code>close</code> <var>número-do-bug</var> [ <var>versão-corrigida</var> ]
(ultrapassado)
<dd>
-Fecha o relatório de bug #<var>número do bug</var>.
+Fecha o relatório de bug #<var>número-do-bug</var>.
-<p>Uma notificação é enviada para o usuário que reportou o bug, mas (ao invés
-de enviar uma mensagem para
-<var>número do bug</var><code>-done@bugs.debian.org</code>) o texto da mensagem
-que fechou o bug <strong>não</strong> é incluído na notificação. O mantenedor
-que fecha o relatório precisa certificar-se, provavelmente enviando uma
-mensagem separada, que o usuário que reportou o bug fique sabendo a razão pela
-qual o bug está sendo fechado. O uso deste comando é portanto desencorajado.
-Veja as informações para desenvolvedores sobre <a href="Developer#closing">como fechar um relatório de bug</a>.
+<p>Uma notificação é enviada para o usuário que reportou o bug, mas (ao
+contrário do envio de uma mensagem para
+<var>número-do-bug</var><code>-done@bugs.debian.org</code>) o texto da
+mensagem que fechou o bug <strong>não</strong> é incluído na notificação.
+O mantenedor que fecha o relatório precisa certificar-se, provavelmente
+enviando uma mensagem separada, que o usuário que reportou o bug fique
+sabendo a razão pela qual o bug está sendo fechado. O uso deste comando é
+portanto desencorajado. Veja as informações para desenvolvedores sobre
+<a href="Developer#closing">como fechar um relatório de bug</a>.
<p>Se você fornecer uma <var>versão-corrigida</var>, o sistema de
-acompanhamento de bugs perceberá que o bug foi corrigido para aquela versão do
-pacote.
+acompanhamento de bugs perceberá que o bug foi corrigido para aquela
+versão do pacote.
-<dt><code>package</code> [ <var>nome de pacote</var> ... ]
+<dt><code>package</code> [ <var>nome-do-pacote</var> ... ]
<dd>Limita os próximos comandos, fazendo com que eles sejam aplicados
somente em erros relativos aos pacotes listados. Você pode listar um ou
mais pacotes. Se você não listar nenhum pacote, os próximos comandos
- serão aplicados em qualquer erro. Você é encorajado a usar isto como uma
- medida de segurança para cso de você usar acidentalmente os números de bug
- errados.
+ serão aplicados em todos os bugs. Você é encorajado a usar isto como uma
+ medida de segurança para o caso de você, acidentalmente, usar os números
+ errados dos relatórios de bug.
<p>Exemplo de uso:</p>
@@ -328,33 +336,33 @@
reassign 123456 bar 1.0-1
package bar
- retitle 123456 bar: bar sucks
+ retitle 123456 bar: bar fede
severity 123456 normal
-
+
package
severity 234567 wishlist
</pre>
-<dt><code>owner</code> <var>número do bug</var> <var>endereço</var> | <code>!</code>
+<dt><code>owner</code> <var>número-do-bug</var> <var>endereço</var> | <code>!</code>
- <dd>Define <var>endereço</var> como "dono" do #<var>número do bug</var>.
- O dono de um bug clama a responsabilidade de corrigí-lo e irá receber todos
- os e-mails a seu respeito. Isto é útil para dividir o trabalho em pacotes que
- possuem equipes de mantenedores.
+ <dd>Define <var>endereço</var> como "dono" do #<var>número-do-bug</var>.
+ O dono de um bug clama a responsabilidade de corrigí-lo e irá receber
+ todos os e-mails a seu respeito. Isto é útil para dividir o trabalho em
+ pacotes que possuem equipes de mantenedores.
<p>Se você quer se tornar o dono de um bug, você pode usar a abreviação
<code>!</code> ou especificar seu endereço de e-mail.</p>
-<dt><code>noowner</code> <var>número do bug</var>
+<dt><code>noowner</code> <var>número-do-bug</var>
<dd>Esquece qualquer dono que o bug tenha além do mantenedor usual. Se o
bug não tiver algum dono registrado, esta opção não fará nada.
<dt><code>#</code>...
- <dd>Comentário de uma linha. O <code>#</code> precisa estar no começo da
- linha. O texto dos comentários será incluído na mensagem enviada pelo
- remetente e para os mantenedores afetados, portanto você pode utilizar isto
+ <dd>Comentário de uma linha. O <code>#</code> precisa estar no começo da
+ linha. O texto dos comentários será incluído na mensagem enviada pelo
+ remetente e para os mantenedores afetados, portanto você pode utilizar isto
para documentar as razões de seus comandos.
<dt><code>quit</code>
@@ -362,8 +370,8 @@
<dt><code>thank</code>...
<dt><code>--</code>...
- <dd>Informa ao servidor de controle para parar de processar a mensagem; é
- possível incluir explicações, assinaturas ou qualquer outra coisa no resto
+ <dd>Informa ao servidor de controle para parar de processar a mensagem; é
+ possível incluir explicações, assinaturas ou qualquer outra coisa no resto
da mensagem, nada disso será detectado pelo servidor de controle.
</dl>
@@ -373,4 +381,3 @@
#use "otherpages.inc"
#use "$(ENGLISHDIR)/Bugs/footer.inc"
-
Reply to: