Modified:
trunk/docs/i18n_pt-br.txt
Log:
Algumas correções de português, acerto das colunas para 80 caracteres, e mais 100 linhas traduzidas
Modified: trunk/docs/i18n_pt-br.txt
==============================================================================
--- trunk/docs/i18n_pt-br.txt (original)
+++ trunk/docs/i18n_pt-br.txt Sat Jul 26 05:48:54 2008
@@ -16,40 +16,41 @@
Internacionalização
====================
-O Django tem um suporte completo para internacionalização dos textos dos códigos e
-templates.
+O Django tem um suporte completo para internacionalização dos textos dos
+códigos e templates.
Aqui é mostrado como isto funciona.
Introdução
==========
-O objetivo da internacionalização é permitir que uma única aplicação web ofereça
-seus conteúdos e funcionalidades em múltiplas linguagens.
+O objetivo da internacionalização é permitir que uma única aplicação web
+ofereça seus conteúdos e funcionalidades em múltiplas linguagens.
-Você, o desenvolvedor Django, pode conseguir isto adicionando uns poucos hooks no
-seu código Python e templates. Estes hooks, chamados **translation strings**,
+Você, o desenvolvedor Django, pode conseguir isto adicionando uns poucos hooks
+no seu código Python e templates. Estes hooks, chamados **translation strings**,
dizem ao Django: "Este texto deve ser traduzido para o idioma do usuário,
se a tradução para este texto estiver disponível nesta língua."
-O Django se preocupa em usar estes hooks para traduzir as aplicações Web, em tempo de
-execução, conforme as preferências de idioma do usuário.
+O Django se preocupa em usar estes hooks para traduzir as aplicações Web, em
+tempo de execução, conforme as preferências de idioma do usuário.
Essencialmente, o Django faz duas coisas:
- * Ele permite que o desenvolvedor e autor de templates especificarem quais
+ * Ele permite que o desenvolvedor e autor de templates especificarem quais
partes de sua aplicação pode ser traduzida.
- * Ele usa os hooks para traduzir a aplicação web para um usuário em particular
- de acordo com sua preferência.
+ * Ele usa os hooks para traduzir a aplicação web para um usuário em
+ particular de acordo com sua preferência.
Se você não necessita de internacionalização em sua aplicação
=============================================================
-Os hooks de internacionalização do Django estão habilitados por padrão, o que
+Os hooks de internacionalização do Django estão habilitados por padrão, o que
significa que existe um consumo de processamento por parte do i18n em certas
-partes do framework. Se você não usa internacionalização, você deve gastar 2 segundos
-para setar ``USE_I18N = False`` no seu arquivo de configuração. Se o ``USE_I18N`` for
-``False``, então o Django irá realizar algumas otimizações como não carregar o maquinário
-para internacionalização. Veja a `documentação para USE_I18N`_.
+partes do framework. Se você não usa internacionalização, você deve gastar 2
+segundos para setar ``USE_I18N = False`` no seu arquivo de configuração. Se o
+``USE_I18N`` for ``False``, então o Django irá realizar algumas otimizações
+como não carregar o maquinário para internacionalização. Veja a `documentação
+para USE_I18N`_.
Você provavelmente irá querer remover ``'django.core.context_processors.i18n'``
de sua configuração do ``TEMPLATE_CONTEXT_PROCESSORS``.
@@ -74,9 +75,10 @@
1. Como especificar as translation strings
==========================================
-Translation strings especifica "Este texto deve ser traduzido." Estas strings podem
-aparecer no seu código Python e templates. É de sua responsabilidade marcar as strings
-traduzíveis; o sistema somente consegue traduzir o que ele sabe que tem que traduzir.
+Translation strings especifica "Este texto deve ser traduzido." Estas strings
+podem aparecer no seu código Python e templates. É de sua responsabilidade
+marcar as strings traduzíveis; o sistema somente consegue traduzir o que ele
+sabe que tem que traduzir.
No código Python
----------------
@@ -88,20 +90,23 @@
a convenção para importar o alias ``_``, limpando a escrita.
.. note::
- Na biblioteca padrão do Python o módulo ``gettext`` instala uma função ``_()``
- no namespace global, que funciona como um alias para ``gettext()``. No Django,
- nos temos que escolher não seguir esta prática, por algumas razões:
+ Na biblioteca padrão do Python o módulo ``gettext`` instala uma função
+ ``_()`` no namespace global, que funciona como um alias para
+ ``gettext()``. No Django, nos temos que escolher não seguir esta prática,
+ por algumas razões:
1. Para suporte a caracteres internacionais (Unicode), ``ugettext()`` é
mais usual do que ``gettext()``. Algumas vezes, você deve usar
- ``ugettext_lazy()`` como o método padrão de tradução para um arquivo em
- particular. Sem o ``_()`` no namespace global, o desenvolvedor tem que
- pensar sobre qual nome seria mais apropriado para a função de tradução.
+ ``ugettext_lazy()`` como o método padrão de tradução para um arquivo
+ em particular. Sem o ``_()`` no namespace global, o desenvolvedor tem
+ que pensar sobre qual nome seria mais apropriado para a função de
+ tradução.
2. O caractere sublinhado (``_``) é usado para representar "o resultado
prévio" no shell interativo do Python e nos testes doctest. Instalando
uma função global ``_()`` causa interferencias. Se você importa
- explicitamente a função ``ugettext()`` como ``_()`` evita este problema.
+ explicitamente a função ``ugettext()`` como ``_()`` evita este
+ problema.
Neste exemplo, o texto ``"Welcome to my site."`` é marcado como uma translation
string::
@@ -121,7 +126,7 @@
output = ugettext("Welcome to my site.")
return HttpResponse(output)
-A tradução funciona sobre valores computados. Este exemplo é igual ao
+A tradução funciona sobre valores computados. Este exemplo é igual ao
anterior::
def my_view(request):
@@ -149,15 +154,15 @@
output = _('%(name)s is my name.') % {'name': n}
return HttpResponse(output)
-Esta técnica permite reordenar os marcadores para a tradução de língua-específicas.
-Por exemplo, uma tradução inglesa pode ser ``"Adrian is my name."``,
-enquanto que em espanhol pode ser ``"Me llamo Adrian".`` -- com o marcador %(name)
-colocado após o texto traduzido ao invés de antes.
-
-Por esta razão, você deve usar a interpolação por named-string (e.g.,``%(name)``)
-ao invés de interpolação posicional (e.g.,``%s`` or ``%d``) quando você tiver mais
-de um paramêtro. Se você usou interpolação posicional, as traduções não poderiam ser
-capazes de reordenar o texto.
+Esta técnica permite reordenar os marcadores para a tradução de
+língua-específicas. Por exemplo, uma tradução inglesa pode ser ``"Adrian is my
+name."``, enquanto que em espanhol pode ser ``"Me llamo Adrian".`` -- com o
+marcador %(name) colocado após o texto traduzido ao invés de antes.
+
+Por esta razão, você deve usar a interpolação por named-string
+(e.g.,``%(name)``) ao invés de interpolação posicional (e.g.,``%s`` or ``%d``)
+quando você tiver mais de um paramêtro. Se você usou interpolação posicional,
+as traduções não poderiam ser capazes de reordenar o texto.
Marcando strings como no-op
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -166,12 +171,12 @@
como uma translation string sem traduzí-la. A string é traduzida no final vinda
da variável.
-Use isto se você tem strings contantes que devem ser armazenadas no idioma originário
-porquê eles são trocados pelo systema ou usuários -- como uma string no banco de dados
--- mas deve ser traduzida em um possível último momento, como quando a string é
-apresentada para o usuário.
+Use isto se você tem strings contantes que devem ser armazenadas no idioma
+originário porquê eles são trocados pelo systema ou usuários -- como uma string
+no banco de dados -- mas deve ser traduzida em um possível último momento, como
+quando a string é apresentada para o usuário.
-Tradução tardía
+Tradução tardia
~~~~~~~~~~~~~~~~
Use a função ``django.utils.translation.ugettext_lazy()`` para traduzir strings
@@ -185,12 +190,12 @@
class MyThing(models.Model):
name = models.CharField(help_text=ugettext_lazy('This is a help text'))
-Neste exemplo, ``ugettext_lazy()`` armazena uma referência da string -- não da tradução
-atual. A tradução por si só será feita quando a string é usada num contexto, como a
-renderização na administração do Django.
+Neste exemplo, ``ugettext_lazy()`` armazena uma referência da string -- não da
+tradução atual. A tradução por si só será feita quando a string é usada num
+contexto, como a renderização na administração do Django.
-Se você não gosta do nome ``ugettext_lazy``, você pode somente usa o alias ``_``
-(underscore), então::
+Se você não gosta do nome ``ugettext_lazy``, você pode somente usa o alias
+``_`` (underscore), então::
from django.utils.translation import ugettext_lazy as _
@@ -214,8 +219,8 @@
Pluralização
~~~~~~~~~~~~
-Use a função ``django.utils.translation.ungettext()`` para especificar mensagens
-pluralizadas. Exemplo::
+Use a função ``django.utils.translation.ungettext()`` para especificar
+mensagens pluralizadas. Exemplo::
from django.utils.translation import ungettext
def hello_world(request, count):
@@ -224,8 +229,9 @@
}
return HttpResponse(page)
-``ungettext`` recebe três argumentos: uma translation string no singular, uma translation
-string no plural e o número de objetos (que é passado para as traduções como uma variavél ``count``).
+``ungettext`` recebe três argumentos: uma translation string no singular, uma
+translation string no plural e o número de objetos (que é passado para as
+traduções como uma variavél ``count``).
No código do template
---------------------
@@ -282,14 +288,14 @@
* ``LANGUAGES`` é uma lista de tuplas em que o primeiro elemento é o código
da língua e o segundo é o nome da língua (em que língua).
* ``LANGUAGE_CODE`` é o idioma corrente do usuário, como uma string.
- Exemplo: ``en-us``. (Veja "Como as preferências de linguagem são descobertas",
- abaixo).
- * ``LANGUAGE_BIDI`` é a direção do idioma corrente. Se True, ela é língua que se
- escreve da direita-para-esquerda, e.g: Ebreu, Árabe. Se False da
+ Exemplo: ``en-us``. (Veja "Como as preferências de linguagem são
+ descobertas", abaixo).
+ * ``LANGUAGE_BIDI`` é a direção do idioma corrente. Se True, ela é língua
+ que se escreve da direita-para-esquerda, e.g: Ebreu, Árabe. Se False da
esquerda-para-direita, e.g: Inglês, Português, Francês, etc.
-SE você não usa a extensão ``RequestContext``, você pode acessar esses valores com
-três tags::
+Se você não usa a extensão ``RequestContext``, você pode acessar esses valores
+com três tags::
{% get_current_language as LANGUAGE_CODE %}
{% get_available_languages as LANGUAGES %}
@@ -297,43 +303,41 @@
Estas tags também requerem um ``{% load i18n %}``.
-Translation hooks are also available within any template block tag that accepts
-constant strings. In those cases, just use ``_()`` syntax to specify a
-translation string. Example::
+Os Hooks de traduções estão disponíveis também dentro de qualquer tag de bloco
+de template que aceite strings constantes. Neste caso, use somente a sintaxe
+``_()`` para especificar uma translation string. Exemplo::
{% some_special_tag _("Page not found") value|yesno:_("yes,no") %}
-In this case, both the tag and the filter will see the already-translated
-string, so they don't need to be aware of translations.
+Neste caso, ambas as tags e filtros irão receber a string já traduzida, então
+elas não precisam se preocupar com as traduções.
.. note::
- In this example, the translation infrastructure will be passed the string
- ``"yes,no"``, not the individual strings ``"yes"`` and ``"no"``. The
- translated string will need to contain the comma so that the filter
- parsing code knows how to split up the arguments. For example, a German
- translator might translate the string ``"yes,no"`` as ``"ja,nein"``
- (keeping the comma intact).
+ Neste exemplo, é passada a string ``"yes,no"`` para a infraestrutura de
+ tradução, não elas em separado ``"yes"`` e ``"no"``. A string traduzida
+ precisará conter a vírgula para que o parse do filtro consiga separar os
+ argumentos. Por exemplo, um tradudor alemão pode traduzir a string
+ ``"yes,no"`` como ``"ja,nein"`` (mantendo as vírgulas intáctas).
.. _templates Django: ../templates_python/
-Working with lazy translation objects
--------------------------------------
+Trabalhando com objetos de traduções tardias
+--------------------------------------------
-Using ``ugettext_lazy()`` and ``ungettext_lazy()`` to mark strings in models
-and utility functions is a common operation. When you're working with these
-objects elsewhere in your code, you should ensure that you don't accidentally
-convert them to strings, because they should be converted as late as possible
-(so that the correct locale is in effect). This necessitates the use of a
-couple of helper functions.
-
-Joining strings: string_concat()
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Standard Python string joins (``''.join([...])``) will not work on lists
-containing lazy translation objects. Instead, you can use
-``django.utils.translation.string_concat()``, which creates a lazy object that
-concatenates its contents *and* converts them to strings only when the result
-is included in a string. For example::
+Usar ``ugettext_lazy()`` e ``ungettext_lazy()`` para marcar as strings nos
+models e funções utilitárias é uma operação comum. Quando você está trabalhando
+com esses objetos no seu código, você deve se assegurar que não os converteu em
+strings acidentalmente, porque eles devem ser convertidos o mais tardiamente
+possível (para que o efeito ocorra no local correto). Isto requer o uso de alguns helpers.
+
+Juntando strings: string_concat()
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+O padrão do Python para junção de strings (``''.join([...])``) não irá
+funcionar nas listas contendo objetos de tradução tardia. Ao invés disso, você
+pode usar ``django.utils.translation.string_concat``, que cria um objeto tardio
+e concatena seu conteúdo *e* os converte para strings somente quando o
+resultado é incluído em uma outra string. Por exemplo::
from django.utils.translation import string_concat
...
@@ -341,48 +345,50 @@
instrument = ugettext_lazy(u'guitar')
result = string_concat([name, ': ', instrument])
-In this case, the lazy translations in ``result`` will only be converted to
-strings when ``result`` itself is used in a string (usually at template
-rendering time).
-
-The allow_lazy() decorator
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Django offers many utility functions (particularly in ``django.utils``) that
-take a string as their first argument and do something to that string. These
-functions are used by template filters as well as directly in other code.
-
-If you write your own similar functions and deal with translations, you'll
-face the problem of what to do when the first argument is a lazy translation
-object. You don't want to convert it to a string immediately, because you might
-be using this function outside of a view (and hence the current thread's locale
-setting will not be correct).
-
-For cases like this, use the ``django.utils.functional.allow_lazy()``
-decorator. It modifies the function so that *if* it's called with a lazy
-translation as the first argument, the function evaluation is delayed until it
-needs to be converted to a string.
+Neste caso, a tradução tardia no ``result`` irá somente ser convertido para
+uma string quando ``result`` por si só for usado numa string (usalmente na hora
+de renderizar o template).
+
+O decorador allow_lazy()
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+O Django oferece muitas funções utilitárias (particulamente ``django.utils``)
+que recebe uma string como primeiro argumento e faz algo com ela. Estas funções
+são usadas por filtros nos templates, bem como em outros códigos.
+
+ * be using this function outside of a view (and hence the current thread's locale
+ * setting will not be correct).
+
+Se você escrever suas próprias funções similar e tratar algumas traduções, você
+irá se deparar com um problema, o que fazer quando o primeiro argumento é um
+objeto de tradução tardia? Você não espera convertê-lo para uma string
+imediatamente, porque você pode estar usando esta função fora de um view ().
+
+Para o casos como estes, use o decorador ``django.utils.functional.allow_lazy()``.
+Ele modifica a função para que *se* ela é chamada com uma tradução tardia como
+primeiro argumento, a função de avaliação é mostrada até que necessite ser
+convertida para uma string.
-For example::
+Por exemplo::
from django.utils.functional import allow_lazy
def fancy_utility_function(s, ...):
- # Do some conversion on string 's'
+ # Realiza alguma conversão sobre a string 's'
...
fancy_utility_function = allow_lazy(fancy_utility_function, unicode)
-The ``allow_lazy()`` decorator takes, in addition to the function to decorate,
-a number of extra arguments (``*args``) specifying the type(s) that the
-original function can return. Usually, it's enough to include ``unicode`` here
-and ensure that your function returns only Unicode strings.
-
-Using this decorator means you can write your function and assume that the
-input is a proper string, then add support for lazy translation objects at the
-end.
+O decorador ``allow_lazy()`` recebe, além da função para docorar, um argumento
+extra (``*args``) especificando o(s) tipo(s) que a função original pode
+retornar. Usualmente, é suficiete incluir ``unicode`` alí, e assegurar que sua
+função retorne somente strings Unicode.
+
+Usando este decorador significa que você pode escrever suas funções e assumir
+que a entrada é uma string apropriada, então adiciona um suporte para objetos
+de tradução tardia no final.
-2. How to create language files
-===============================
+2. Como criar arquivos de linguagem
+===================================
Once you've tagged your strings for later translation, you need to write (or
obtain) the language translations themselves. Here's how that works.