--- a/PortugueseBook/Model/Model.tex
+++ b/PortugueseBook/Model/Model.tex
@@ -617,122 +617,139 @@ foi apelidado para \ct{basicAddTraitSelector:withMethod:}.
 Suporte à traits está sendo adicionado aos browsers atualmente.
 
 %=========================================================
-\section{Everything happens by message sending}
+\section{Tudo acontece por meio do envio de mensagens}
 
 %\ruleref{message}
 
-This rule captures the essence of programming in \st.
-
-In procedural programming, the choice of which piece of code to execute when a procedure is called is made by the caller.
-The caller chooses the procedure or function to execute \emph{statically}, by name.  
-
-In object-oriented programming, we do \emph{not} ``call methods'': we ``\subind{message}{send} messages.''
-The choice of terminology is significant.
-Each object has its own responsibilities.
-We do not \emph{tell} an object what to do by applying some procedure to it.
-Instead, we politely \emph{ask} an object to do something for us by sending it a message.
-The message is \emph{not} a piece of code: it is nothing but a name and a list of arguments.
-The receiver then decides how to respond by selecting its own \emph{method} for doing what was asked.
-Since different objects may have different methods for responding to the same message, the method must be chosen \emph{dynamically}, when the message is received.
+Esta regra captura a essencia da programação em \st.
+Em programação procedual, a escolha de qual porção de código a ser executada quando o procedimento
+é chamado é feito pelo chamador.
+O chamador escolhe o procedimento ou função a ser executado \emph{estaticamente}, por nome.
+
+Em programação orientada a objeto, nós \emph{não} ``chamamos métodos'': nós ``\index{mensagem!envio} enviamos mensagens''. A escolha da terminologia é significante.
+Cada objeto tem suas próprias responsabilidades.
+Nós não \emph{dizemos} à um objeto o que fazer aplicando um procedimento a ele.
+Ao invés disso, nós educadamente \emph{pedimos} à um objeto para fazer algo para nós enviando uma mensagem.
+A mensagem \emph{não} é uma porção de código: é apenas um nome e uma lista de argumentos.
+O receptor, então, decide como responder selecionando seu próprio \emph{método} para realizar o que foi pedido.
+Uma vez que diferentes objetos podem ter métodos diferentes para responder à mesma mensagem,
+o método deve ser escolhido \emph{dinamicamente}, quando a mensagem é recebida.
 \begin{code}{@TEST}
-3 + 4         --> 7          "send message + with argument 4 to integer  3"
-(1@2) + 4 --> 5@6    "send message + with argument 4 to point (1@2)"
+3 + 4         --> 7          "envia a mensagem + com argumento 4 para o inteiro 3"
+(1@2) + 4 --> 5@6    "envia a mensagem + com argumento 4 para o ponto (1@2)"
 \end{code}
 \noindent
-As a consequence, we can send the \emph{same message} to different objects, each of which may have \emph{its own method} for responding to the message.
-We do not tell the \ct{SmallInteger} \ct{3} or the \ct{Point} \ct{1@2} how to respond to the message \ct{+ 4}.
-Each has its own method for \ct{+}, and responds to \ct{+ 4} accordingly.
-
-One of the consequences of \st's model of message sending is that it encourages a style in which objects tend to have very small methods and delegate tasks to other objects, rather than implementing huge, procedural methods that assume too much responsibility.
+Como conseqüência, nós podemos enviar a \emph{mesma mensagem} para diferentes objetos, cada qual
+pode ter \emph{seu próprio método} para responder à mesma mensagem.
+Nós não dizemos ao \ct{SmallInteger} \ct{3} ou o \ct{Point} \ct{1@2} como responder a mensagem \ct{+ 4}.
+Cada um tem seu próprio método para \ct{+}, e responde à \ct{+ 4} de acordo.
+
+Uma das conseqüências do modelo de envio de mensagens do \st é que ele encoraja um estilo em que
+objetos tendem a ter métodos muito pequenos e delegam tarefas à outros objetos, ao invés de implementar
+enormes métodos procedurais que assumem muita responsabilidade.
 Joseph Pelrine
 \ab{Citation?}
 \on{sorry, just personal communication and my own lecture notes!}
-expresses this principle succinctly as follows:
-\important{Don't do anything that you can push off onto someone else.}
+expressa este princípio sucintamente como se segue:
+\important{Não faça nada que você possa delegar para qualquer outro.}
 \index{Pelrine, Joseph}
 
-Many object-oriented languages provide both static and dynamic operations for objects; in \st there are only dynamic message sends. Instead of providing static class operations, for instance, classes are objects and we simply send messages to classes.
+Muitas linguagens orientadas a objeto oferecem operações estáticas e dinâmicas para objetos; em \st 
+existem apenas envio de mensagens dinâmicas. Ao invés de oferecer operações de classe estáticas, por exemplo,
+classes são objetos e nós simplesmente enviamos mensagens para as classes.
 
-\emph{Nearly} everything in \st happens by message sends.
-At some point action must take place:
+\emph{Quase} tudo em \st acontece por envio de mensagens.
+Em algum momento, a ação deve acontecer:
 \begin{itemize}
-  \item \emph{Variable declarations} are not message sends.
-  		In fact, variable \subind{variable}{declaration}{}s are not even executable.
-  		Declaring a variable just causes space to be allocated for an object reference.
-  \item \emph{Assignments} are not message sends.
-  		An \ind{assignment} to a variable causes that variable name to be freshly bound in the scope of its definition.
-  \item \emph{Returns} are not message sends.
-  		A \ind{return} simply causes the computed result to be returned to the sender.
-  \item \emph{Primitives} are not message sends.
-  		They are implemented in the \ind{virtual machine}.
-		\index{primitive}
+  \item \emph{Declaração de variáveis} não são envios de mensagens.
+  		De fato, \subind{variável}{declaração} de variáveis nem são executáveis.
+  		Declarar uma variável apenas aloca espaço para uma referência à um objeto.
+  \item \emph{Atribuições} não são envios de mensagens.
+  		Uma \ind{atribuição} à uma variável associa o nome da variável no escopo de sua definição.
+	        % FIXME: en_US(freshly bound) == pt_BR(?)
+  \item \emph{Retornos} não são envios de mensagens.
+  		Um \ind{retorno} apenas retorna o resultado computado para o remetente da mensagem.
+  \item \emph{Primitivas} não são envios de mensagens.
+  		Elas são implementadas na \ind{máquina virtual}.
+		\index{primitiva}
 \end{itemize}
-Other than these few exceptions, pretty much everything else does truly happen by sending messages.
-In particular, since there are no ``public fields'' in \st, the only way to update an \ind{instance variable} of another object is to send it a message asking that it update its own field.
-Of course, providing setter and getter methods for all the instance variables of an object is not good object-oriented style.
-Joseph Pelrine also states this very nicely:
-\important{Don't let anyone else play with your data.}
+Além destas poucas exceções, tudo o mais realmente acontece por envio de mensagens.
+Em particular, já que não há ``campos públicos'' em \st, a única forma de atualizar uma
+\ind{variável de instância} de outro objeto é enviando uma mensagem a ele pedindo para
+que atualize seu próprio campo.
+Obviamente, oferecer métodos \emph{setter} e \emph{getter} para todas as variáveis de instância
+de um objeto não é um bom estilo de orientação a objeto.
+Joseph Pelrine também coloca isso muito bem:
+\important{Não deixe que ninguém mais brinque com seus dados.}
 
 %=========================================================
-\section{Method lookup follows the inheritance chain} 
+\section{A busca de método segue a cadeia de herança} 
+%FIXME: en_US(lookup) == pt_BR(?)
 
 %\ruleref{lookup}
 
-What exactly happens when an object receives a message?
+O que exatamente acontece quando um objeto recebe uma mensagem?
 
-The process is quite simple:
-the class of the receiver looks up the method to use to handle the message.
-If this class does not have a method, it asks its \ind{superclass}, and so on, up the \ind{inheritance} chain.
-When the method is found, the arguments are bound to the parameters of the method, and the \ind{virtual machine} executes it.
-\index{method!lookup}
+O processo é bem simples:
+a classe do receptor busca o método a ser utilizado para lidar com a mensagem.
+Se a classe não tem o método, ela pede a sua \ind{superclasse}, e assim por diante, subindo
+na cadeia hierárquica.
+Quando o método é encontrado, os argumentos são associados aos parâmetros do método, e a
+\ind{máquina virtual} a executa.
+\index{método!busca}
 
-It is essentially as simple as this.
-Nevertheless there are a few questions that need some care to answer:
+É essencialmente tão simples quanto isso.
+No entanto, existem algumas questões que precisam de alguns cuidados ao serem respondidas:
 
 \begin{itemize}
-  \item \emph{What happens when a method does not explicitly return a value?}
-  \item \emph{What happens when a class reimplements a superclass method?}
-  \item \emph{What is the difference between \pvind{self} and \pvind{super} sends?}
-  \item \emph{What happens when no method is found?}
+  \item \emph{O que acontece quando um método não retorna explicitamente um valor?}
+  \item \emph{O que acontece quando a classe reimplementa o método da superclasse?}
+  \item \emph{Qual é a diferença entre \pvind{self} e \pvind{super} \emph{sends}?}
+  \item \emph{O que acontece quando nenhum método é encontrado?}
 \end{itemize}
 
-The rules for method lookup that we present here are conceptual: virtual machine implementors use all kinds of tricks and optimizations to speed-up method lookup. 
-That's their job, but you should never be able to detect that they are doing something different from our rules.
-% Whatever the implementation does, these rules will give you a clear understanding of the semantics of sending messages to \self and \super.
+As regras para busca de métodos que nós apresentamos são conceituais: implementadores de máquinas
+virtuais usam todo tipo de truques e otimizações para aumentar a velocidade da busca de métodos.
+Este é o trabalho deles, mas você nunca deve ser capaz de detectar que eles estão fazendo
+algo diferente com nossas regras.
 
-First let us look at the basic lookup strategy, and then consider these further questions.
+Primeiro, vamos observar as estratégias básicas de busca, e então, considere estas questões.
 
 %---------------------------------------------------------
-\subsection{Method lookup}
-Suppose we create an instance of \ct{EllipseMorph}.
+\subsection{Busca de métodos}
+Suponha que nós criamos uma instância de \ct{EllipseMorph}.
 \begin{code}{@TEST | anEllipse |}
 anEllipse := EllipseMorph new.
 \end{code}
 \noindent
-If we now send this object the message \ct{defaultColor}, we get the result \ct{Color yellow}:
+Se nós enviarmos à este objeto a mensagem \ct{defaultColor}, nós recebemos \ct{Color yellow} como resultado:
 \begin{code}{@TEST | anEllipse | anEllipse := EllipseMorph new.}
 anEllipse defaultColor --> Color yellow
 \end{code}
 \noindent
-The class \ct{EllipseMorph} implements \ct{defaultColor}, so the appropriate method is found immediately.
+A classe \ct{EllipseMorph} implementa \ct{defaultColor}, portanto o método apropriado é encontrado imediatamente.
 
-\begin{method}[defaultColor]{A locally implemented method}
+\begin{method}[defaultColor]{Um método implementado localmente}
 EllipseMorph>>>defaultColor
-	"answer the default color/fill style for the receiver"
+	"responde o estilo de cor/preenchimento padrao para o receptor"
 	^ Color yellow
 \end{method}
+%FIXME: "padrao" sem acento
 \cmindex{EllipseMorph}{defaultColor}
 
-In contrast, if we send the message \ct{openInWorld} to \ct{anEllipse}, the method is not immediately found, since the class \ct{EllipseMorph} does not implement \ct{openInWorld}.
-The search therefore continues in the superclass, \lct{BorderedMorph}, and so on, until an \ct{openInWorld} method is found in the class \ct{Morph} (see \figref{openInWorldLookup}).
+Em contraste, se nós enviarmos a mensagem \ct{openInWorld} para \ct{anEllipse}, o método não
+é encontrado imediatamente, uma vez que a classe \ct{EllipseMorph} não implementa \ct{openInWorld}.
+A busca, portanto, continua na superclasse, \lct{BorderedMorph}, e assim por diante, até que
+um método \ct{openInWorld} seja encontrado na classe \ct{Morph} (ver \figref{openInWorldLookup}).
 
-\begin{method}[openInWorld]{An inherited method}
+\begin{method}[openInWorld]{Um método herdado}
 Morph>>>openInWorld
-	"Add this morph to the world.  If in MVC, then provide a Morphic window for it."
+	"Adiciona este morph ao mundo.  Se em um MVC, entao oferece uma Morphic window para ele."
 	self couldOpenInMorphic
 		ifTrue: [self openInWorld: self currentWorld]
 		ifFalse: [self openInMVC]
 \end{method}
+%FIXME: "entao" sem acento
 \cmindex{Morph}{openInWorld}
 
 \begin{figure}[htb]
@@ -740,7 +757,7 @@ Morph>>>openInWorld
 \ifluluelse
 	{\includegraphics[width=\textwidth]{openInWorldLookup}}
 	{\includegraphics[width=0.8\textwidth]{openInWorldLookup}}
-\caption{Method lookup follows the inheritance hierarchy.\label{fig:openInWorldLookup}}
+\caption{A busca de métodos segue a hierarquia de herança.\label{fig:openInWorldLookup}}
 \end{center}
 \end{figure}