updating translation

git-svn-id: https://svn.php.net/repository/phpdoc/pt_BR/trunk@339425 c90b9560-bf6c-de11-be94-00142212c4b1

security/apache.xml

@@ -1,13 +1,13 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 96c9d88bad9a7d7d44bfb7f26c226df7ee9ddf26 Maintainer: narigone Status: ready -->
+<!-- EN-Revision: ab6785b01ce1006e3a9761988575289f40c9b678 Maintainer: fabioluciano Status: ready --><!-- CREDITS: narigone, fabioluciano -->
 <!-- splitted from ./index.xml, last change in rev 1.66 -->
   <chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook">
    <title>Instalado como módulo do Apache</title>
    <simpara>
-    Quando o PHP é usado como módulo do Apache, ele herda as permissões
+    Quando o <acronym>PHP</acronym> é usado como módulo do Apache, ele herda as permissões
     do usuário do Apache (normalmente as do usuário "nobody"). Isso tem
     vários impactos de segurança e autorização. Por exemplo, se você estiver usando
-    o PHP para acessar um banco de dados, a menos que o banco de dados tenha um controle
+    o <acronym>PHP</acronym> para acessar um banco de dados, a menos que o banco de dados tenha um controle
     de acesso interno, você terá que faz o banco de dados acessível ao usuário
     "nobody". Isso significa que um script malicioso pode acessar e modificar
     o banco de dados, mesmo sem um usuário e senha. É possível que um web spider
@@ -15,12 +15,12 @@
     e remover todos os bancos de dados. Você pode se proteger contra isso
     usando autorização do Apache, ou você pode desenvolver
     seu modelo de acesso prório usando LDAP, arquivos &htaccess;, etc. e incluir
-    esse código como parte dos seus scripts PHP.
+    esse código como parte dos seus scripts <acronym>PHP</acronym>.
    </simpara>
    <simpara>
     Normalmente, uma vez que a segurança está estabelecida até esse ponto onde o
-    usuário do PHP (no caso, o usuário apache) tem pouco risco atribuído a ele,
-    você descobre que o PHP não tem permissão de escrita nos
+    usuário do <acronym>PHP</acronym> (no caso, o usuário apache) tem pouco risco atribuído a ele,
+    você descobre que o <acronym>PHP</acronym> não tem permissão de escrita nos
     diretórios dos usuários. Ou talvez tenha sido proibido de acessar
     ou alterar bancos de dados. Também foi proibido de escrever
     arquivos, bons ou ruins, ou fazer transações de bancos de dados, boas ou ruins.
@@ -38,9 +38,8 @@
    </simpara>
    <simpara>
     Existem algumas soluções mais simples. Usando a diretiva
-    <link linkend="ini.open-basedir">open_basedir</link>
-    você pode controlar e restringir quais
-    diretórios o PHP tem permissão de usar. Você também pode configurar
+    <link linkend="ini.open-basedir">open_basedir</link> pode-se controlar e restringir quais
+    diretórios o <acronym>PHP</acronym> tem permissão de usar. Você também pode configurar
     area exclusivas para o Apache, restringir todas as atividades web para arquivo
     que não sejam de algum usuário ou do sistema.
    </simpara>

security/errors.xml

@@ -1,5 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 803bd2e9ce69bcdd3f2cd2a9dff61e2945400734 Maintainer: narigone Status: ready -->
+<?xml version="1.0" encoding="utf-8"?>
+<!-- EN-Revision: 96c9d88bad9a7d7d44bfb7f26c226df7ee9ddf26 Maintainer: fabioluciano Status: ready --><!-- CREDITS: narigone, fabioluciano -->
 <!-- splitted from ./index.xml, last change in rev 1.66 -->
   <chapter xml:id="security.errors" xmlns="http://docbook.org/ns/docbook">
    <title>Relatando Erros</title>
@@ -101,7 +101,6 @@
     rapidamente encontrar áreas onde suas variáveis podem sofrer alterações nocivas
     ou modificações quaisquer. Uma vez que estiver pronto para produção,
     você deve ou desabilitar mensagens de erro completamente configurando a diretiva
-
     <function>error_reporting</function> com o valor 0, ou desligar o envio
     de erros usando a opção <literal>display_errors</literal> do arquivo &php.ini;,
     para evitar sondagem do seu código. Se você escolher a segunda opção,

security/intro.xml

@@ -1,5 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 803bd2e9ce69bcdd3f2cd2a9dff61e2945400734 Maintainer: narigone Status: ready -->
+<?xml version="1.0" encoding="utf-8"?>
+<!-- EN-Revision: 96c9d88bad9a7d7d44bfb7f26c226df7ee9ddf26 Maintainer: fabioluciano Status: ready --><!-- CREDITS: narigone, fabioluciano -->
 <!-- splitted from ./index.xml, last change in rev 1.66 -->
  <chapter xml:id="security.intro" xmlns="http://docbook.org/ns/docbook">
   <title>Introdução</title>

security/variables.xml

@@ -1,10 +1,10 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 96c9d88bad9a7d7d44bfb7f26c226df7ee9ddf26 Maintainer: narigone Status: ready -->
+<!-- EN-Revision: ab6785b01ce1006e3a9761988575289f40c9b678 Maintainer: fabioluciano Status: ready --><!-- CREDITS: narigone, fabioluciano -->
 <!-- splitted from ./index.xml, last change in rev 1.66 -->
 <chapter xml:id="security.variables" xmlns="http://docbook.org/ns/docbook">
  <title>Dados Enviados pelo Usuário</title>
  <para>
-  A maior fraqueza na maioria dos programas PHP não é inerente a
+  A maior fraqueza na maioria dos programas <acronym>PHP</acronym> não é inerente a
   linguagem em si, mas meramente um problema de código escrito desconsiderando a
   segurança. Por essa razão, você sempre deve investir um pouco de tempo
   considerando as implicações de um certo pedaço de código, para ter certeza
@@ -74,7 +74,7 @@ exec ($evil_var);
   Você também pode considerar desligar as diretivas register_globals,
   magic_quotes, ou outras configurações convenientes que pode confundir
   você em relação a validade, origem, ou valor de uma variável qualquer.
-  Trabalhar com PHP em modo error_reporting(E_ALL) também pode ajudar avisando
+  Trabalhar com <acronym>PHP</acronym> em modo error_reporting(E_ALL) também pode ajudar avisando
   sobre variáveis sendo usadas antes de serem checadas ou
   inicializadas (então você pode previnir que dados incomuns sejam
   operados).