validated llm translation

docs/pt/docs/tutorial/extra-models.md

@@ -1,4 +1,4 @@
-# Modelos Adicionais
+# Modelos Adicionais { #extra-models }
 
 Continuando com o exemplo anterior, será comum ter mais de um modelo relacionado.
 
@@ -6,9 +6,9 @@ Isso é especialmente o caso para modelos de usuários, porque:
 
 * O **modelo de entrada** precisa ser capaz de ter uma senha.
 * O **modelo de saída** não deve ter uma senha.
-* O **modelo de banco de dados** provavelmente precisaria ter uma senha criptografada.
+* O **modelo de banco de dados** provavelmente precisaria ter uma senha com hash.
 
-/// danger
+/// danger | Cuidado
 
 Nunca armazene senhas em texto simples dos usuários. Sempre armazene uma "hash segura" que você pode verificar depois.
 
@@ -16,15 +16,23 @@ Se não souber, você aprenderá o que é uma "senha hash" nos [capítulos de se
 
 ///
 
-## Múltiplos modelos
+## Múltiplos modelos { #multiple-models }
 
 Aqui está uma ideia geral de como os modelos poderiam parecer com seus campos de senha e os lugares onde são usados:
 
-{* ../../docs_src/extra_models/tutorial001.py hl[9,11,16,22,24,29:30,33:35,40:41] *}
+{* ../../docs_src/extra_models/tutorial001_py310.py hl[7,9,14,20,22,27:28,31:33,38:39] *}
 
-### Sobre `**user_in.dict()`
+/// info | Informação
 
-#### O `.dict()` do Pydantic
+No Pydantic v1 o método se chamava `.dict()`, ele foi descontinuado (mas ainda é suportado) no Pydantic v2 e renomeado para `.model_dump()`.
+
+Os exemplos aqui usam `.dict()` por compatibilidade com o Pydantic v1, mas você deve usar `.model_dump()` se puder usar o Pydantic v2.
+
+///
+
+### Sobre `**user_in.dict()` { #about-user-in-dict }
+
+#### O `.dict()` do Pydantic { #pydantics-dict }
 
 `user_in` é um modelo Pydantic da classe `UserIn`.
 
@@ -61,7 +69,7 @@ teríamos um `dict` Python com:
 }
 ```
 
-#### Desembrulhando um `dict`
+#### Desembrulhando um `dict` { #unpacking-a-dict }
 
 Se tomarmos um `dict` como `user_dict` e passarmos para uma função (ou classe) com `**user_dict`, o Python irá "desembrulhá-lo". Ele passará as chaves e valores do `user_dict` diretamente como argumentos chave-valor.
 
@@ -93,7 +101,7 @@ UserInDB(
 )
 ```
 
-#### Um modelo Pydantic a partir do conteúdo de outro
+#### Um modelo Pydantic a partir do conteúdo de outro { #a-pydantic-model-from-the-contents-of-another }
 
 Como no exemplo acima, obtivemos o `user_dict` a partir do `user_in.dict()`, este código:
 
@@ -108,11 +116,11 @@ seria equivalente a:
 UserInDB(**user_in.dict())
 ```
 
-...porque `user_in.dict()` é um `dict`, e depois fazemos o Python "desembrulhá-lo" passando-o para UserInDB precedido por `**`.
+...porque `user_in.dict()` é um `dict`, e depois fazemos o Python "desembrulhá-lo" passando-o para `UserInDB` precedido por `**`.
 
 Então, obtemos um modelo Pydantic a partir dos dados em outro modelo Pydantic.
 
-#### Desembrulhando um `dict` e palavras-chave extras
+#### Desembrulhando um `dict` e palavras-chave extras { #unpacking-a-dict-and-extra-keywords }
 
 E, então, adicionando o argumento de palavra-chave extra `hashed_password=hashed_password`, como em:
 
@@ -132,13 +140,13 @@ UserInDB(
 )
 ```
 
-/// warning
+/// warning | Atenção
 
-As funções adicionais de suporte são apenas para demonstração de um fluxo possível dos dados, mas é claro que elas não fornecem segurança real.
+As funções adicionais de suporte `fake_password_hasher` e `fake_save_user` servem apenas para demonstrar um fluxo possível dos dados, mas é claro que elas não fornecem segurança real.
 
 ///
 
-## Reduzir duplicação
+## Reduzir duplicação { #reduce-duplication }
 
 Reduzir a duplicação de código é uma das ideias principais no **FastAPI**.
 
@@ -154,25 +162,25 @@ Toda conversão de dados, validação, documentação, etc. ainda funcionará no
 
 Dessa forma, podemos declarar apenas as diferenças entre os modelos (com `password` em texto claro, com `hashed_password` e sem senha):
 
-{* ../../docs_src/extra_models/tutorial002.py hl[9,15:16,19:20,23:24] *}
+{* ../../docs_src/extra_models/tutorial002_py310.py hl[7,13:14,17:18,21:22] *}
 
-## `Union` ou `anyOf`
+## `Union` ou `anyOf` { #union-or-anyof }
 
-Você pode declarar uma resposta como o `Union` de dois tipos, o que significa que a resposta seria qualquer um dos dois.
+Você pode declarar uma resposta como o `Union` de dois ou mais tipos, o que significa que a resposta seria qualquer um deles.
 
 Isso será definido no OpenAPI com `anyOf`.
 
-Para fazer isso, use a dica de tipo padrão do Python <a href="https://docs.python.org/3/library/typing.html#typing.Union" class="external-link" target="_blank">`typing.Union`</a>:
+Para fazer isso, use a anotação de tipo padrão do Python <a href="https://docs.python.org/3/library/typing.html#typing.Union" class="external-link" target="_blank">`typing.Union`</a>:
 
-/// note
+/// note | Nota
 
 Ao definir um <a href="https://docs.pydantic.dev/latest/concepts/types/#unions" class="external-link" target="_blank">`Union`</a>, inclua o tipo mais específico primeiro, seguido pelo tipo menos específico. No exemplo abaixo, o tipo mais específico `PlaneItem` vem antes de `CarItem` em `Union[PlaneItem, CarItem]`.
 
 ///
 
-{* ../../docs_src/extra_models/tutorial003.py hl[1,14:15,18:20,33] *}
+{* ../../docs_src/extra_models/tutorial003_py310.py hl[1,14:15,18:20,33] *}
 
-### `Union` no Python 3.10
+### `Union` no Python 3.10 { #union-in-python-3-10 }
 
 Neste exemplo, passamos `Union[PlaneItem, CarItem]` como o valor do argumento `response_model`.
 
@@ -184,27 +192,27 @@ Se estivesse em uma anotação de tipo, poderíamos ter usado a barra vertical,
 some_variable: PlaneItem | CarItem
 ```
 
-Mas se colocarmos isso em `response_model=PlaneItem | CarItem` teríamos um erro, pois o Python tentaria executar uma **operação inválida** entre `PlaneItem` e `CarItem` em vez de interpretar isso como uma anotação de tipo.
+Mas se colocarmos isso na atribuição `response_model=PlaneItem | CarItem`, teríamos um erro, pois o Python tentaria executar uma **operação inválida** entre `PlaneItem` e `CarItem` em vez de interpretar isso como uma anotação de tipo.
 
-## Lista de modelos
+## Lista de modelos { #list-of-models }
 
 Da mesma forma, você pode declarar respostas de listas de objetos.
 
 Para isso, use o padrão Python `typing.List` (ou simplesmente `list` no Python 3.9 e superior):
 
-{* ../../docs_src/extra_models/tutorial004.py hl[1,20] *}
+{* ../../docs_src/extra_models/tutorial004_py39.py hl[18] *}
 
-## Resposta com `dict` arbitrário
+## Resposta com `dict` arbitrário { #response-with-arbitrary-dict }
 
 Você também pode declarar uma resposta usando um simples `dict` arbitrário, declarando apenas o tipo das chaves e valores, sem usar um modelo Pydantic.
 
 Isso é útil se você não souber os nomes de campo / atributo válidos (que seriam necessários para um modelo Pydantic) antecipadamente.
 
-Neste caso, você pode usar `typing.Dict` (ou simplesmente dict no Python 3.9 e superior):
+Neste caso, você pode usar `typing.Dict` (ou simplesmente `dict` no Python 3.9 e superior):
 
-{* ../../docs_src/extra_models/tutorial005.py hl[1,8] *}
+{* ../../docs_src/extra_models/tutorial005_py39.py hl[6] *}
 
-## Em resumo
+## Recapitulação { #recap }
 
 Use vários modelos Pydantic e herde livremente para cada caso.