diff --git a/DESCRIPTION b/DESCRIPTION
index 1f3e5cf07..c29c06d75 100644
--- a/DESCRIPTION
+++ b/DESCRIPTION
@@ -1,4 +1,4 @@
-Package: rOpenScidevguide
+Package: ropenscidevguide
 Type: Website
 Title: rOpenSci Packages: Development, Maintenance, and Peer Review
 Description: rOpenSci Packages: Development, Maintenance, and Peer Review
diff --git a/R/translate.R b/R/translate.R
index e91f0d58f..7865c0338 100644
--- a/R/translate.R
+++ b/R/translate.R
@@ -1,5 +1,9 @@
-translate_page <- function(page_path) {
-  git_branch_name <- sprintf("%s-es-auto", page_path)
+translate_page <- function(page_path, language, glossary = NULL) {
+  git_branch_name <- sprintf(
+    "%s-%s-auto",
+    page_path,
+    tolower(strsplit(language, "-")[[1]][[1]])
+  )
 
   gert::git_branch_checkout("main")
   gert::git_pull()
@@ -9,17 +13,18 @@ translate_page <- function(page_path) {
     gert::git_branch_checkout(git_branch_name)
   }
   withr::local_envvar("DEEPL_API_URL" = "https://api.deepl.com")
+  withr::local_envvar("DEEPL_API_KEY" = keyring::key_get("deepl"))
   babeldown::deepl_translate(
     path = page_path,
     out_path = page_path,
-    glossary = "glosario",
+    glossary = glossary,
     source_lang = "EN",
-    target_lang = "ES",
+    target_lang = language,
     formality = "less"
   )
 
   gert::git_add(page_path)
-  gert::git_commit(sprintf("Add Spanish automatic translation %s", page_path))
+  gert::git_commit(sprintf("Add %s automatic translation %s", language, page_path))
   gert::git_push()
   usethis::pr_init(git_branch_name)
   usethis::pr_push()
diff --git a/approval2template.pt.Rmd b/approval2template.pt.Rmd
index a5fa1a581..6c6ad66d0 100644
--- a/approval2template.pt.Rmd
+++ b/approval2template.pt.Rmd
@@ -2,7 +2,7 @@
 repo-actions: true
 ---
 
-# Reviewer approval comment template {#approval2template}
+# Modelo de comentário de aprovação do(a) revisor(a) {#approval2template}
 
 ::: {.content-hidden when-format="pdf"}
 
@@ -10,7 +10,7 @@ repo-actions: true
 ```{r}
 #| results: 'asis'
 #| echo: false
-#| child: "templates/reviewer-approval.md"
+#| child: "templates/reviewer-approval.pt.md"
 ```
 ````
 
@@ -19,7 +19,7 @@ repo-actions: true
 ::: {.content-visible when-format="pdf"}
 
 ```{r}
-#| child: "templates/reviewer-approval.md"
+#| child: "templates/reviewer-approval.pt.md"
 
 ```
 
diff --git a/booknews.Rmd b/booknews.Rmd
index 673051f47..c7691cf47 100644
--- a/booknews.Rmd
+++ b/booknews.Rmd
@@ -2,6 +2,12 @@
 
 ## dev (0.9.0)
 
+- 2023-09-15, add suggestions for API packages (#496).
+
+- Translation to Spanish!
+
+- 2023-07-17, Update Aims and Scope to include translation packages, remove experimental text-processing categories, and provide clarifications around API wrappers
+
 - 2023-05-04, Added link to Bioconductor book (#663, `@llrs`).
 
 - 2023-04-26, Changed suggested lifecycle stage in authors guide (#661, `@bart1`).
diff --git a/bot_cheatsheet.pt.Rmd b/bot_cheatsheet.pt.Rmd
new file mode 100644
index 000000000..3b0b60ac3
--- /dev/null
+++ b/bot_cheatsheet.pt.Rmd
@@ -0,0 +1,158 @@
+# Comandos do bot {#bot-commands}
+
+## Para todos {#for-everyone}
+
+Vale ressaltar que nós limpamos os tópicos de problemas ao remover todo conteúdo estranho, portanto, o registro de que você solicitou ajuda de bots será rapidamente apagado ou ocultado.
+
+### Veja a lista de comandos disponíveis para você {#see-the-list-of-commands-available-to-you}
+
+Se você precisar de um lembrete rápido!
+
+```markdown
+@ropensci-review-bot help
+```
+
+### Veja o código de conduta {#see-the-code-of-conduct}
+
+```markdown
+@ropensci-review-bot code of conduct
+```
+
+
+## Para autores {#for-authors}
+
+### Verificar o pacote com o pkgcheck {#check-package-with-pkgcheck}
+
+Quando seu pacote tiver mudado substancialmente.
+
+```markdown
+@ropensci-review-bot check package
+```
+
+### Enviar resposta aos revisores {#submit-response-to-reviewers}
+
+Para registrar sua resposta aos revisores.
+
+```markdown
+@ropensci-review-bot submit response <response-url>
+```
+
+onde `<response_url>` é o link para o comentário de resposta no tópico do problema.
+
+### Finalizar a transferência do repositório {#finalize-repo-transfer}
+
+Depois que você aceitar o convite para a organização do GitHub do rOpenSci e transferir seu repositório do GitHub para ela, execute este comando para obter novamente o acesso de administrador ao seu repositório.
+
+```markdown
+@ropensci-review-bot finalize transfer of <package-name>
+```
+
+### Obter um novo convite após a aprovação {#get-a-new-invite-after-approval}
+
+Se você perdeu o prazo de uma semana para aceitar o convite para a organização do rOpenSci no GitHub, execute isso para receber um novo convite.
+
+```markdown
+@ropensci-review-bot invite me to ropensci/<package-name>
+```
+
+## Para o editor-chefe {#for-the-editor-in-chief}
+
+### Atribua um (a) editor (a) {#assign-an-editor}
+
+```markdown
+@ropensci-review-bot assign @username as editor
+```
+
+### Colocar o envio em espera {#put-submission-on-hold}
+
+Veja [política editorial](#policiesreviewprocess).
+
+```markdown
+@ropensci-review-bot put on hold
+```
+
+### Indique que o envio está fora do escopo {#indicate-the-submission-is-out-of-scope}
+
+Não se esqueça de publicar primeiro um comentário explicando a decisão e agradecendo ao(s) autor(es) pelo envio.
+
+```markdown
+@ropensci-review-bot out-of-scope
+```
+
+## Para o editor designado {#for-assigned-editor}
+
+### Colocar o envio em espera {#put-submission-on-hold}
+
+Veja [política editorial](#policiesreviewprocess).
+
+```markdown
+@ropensci-review-bot put on hold
+```
+
+### Verificar o pacote com o pkgcheck {#check-package-with-pkgcheck}
+
+Geralmente, apenas em consultas pré-submissão ou quando os autores indicam que o pacote foi substancialmente alterado.
+
+```markdown
+@ropensci-review-bot check package
+```
+
+### Verificar padrões estatísticos {#check-statistical-standards}
+
+Geralmente, apenas em consultas pré-submissão ou quando os autores indicam que o pacote foi substancialmente alterado.
+
+```markdown
+@ropensci-review-bot check srr
+```
+
+### Verifique se o README tem o selo de revisão de software {#check-that-readme-has-software-review-badge}
+
+No final do processo de envio.
+
+```markdown
+@ropensci-review-bot check readme
+```
+
+### Indique que você está procurando revisores {#indicate-you-are-now-seeking-reviewers}
+
+```markdown
+@ropensci-review-bot seeking reviewers
+```
+
+### Atribuir um (a) revisor (a) {#assign-a-reviewer}
+
+```markdown
+@ropensci-review-bot assign @username as reviewer
+```
+
+ou
+
+```markdown
+@ropensci-review-bot add @username as reviewer
+```
+
+### Remover um (a) revisor (a) {#remove-a-reviewer}
+
+```markdown
+@ropensci-review-bot remove @username from reviewers
+```
+
+### Ajustar a data de vencimento da revisão {#tweak-review-due-date}
+
+```markdown
+@ropensci-review-bot set due date for @username to YYYY-MM-DD
+```
+
+### Registre que uma revisão foi enviada {#record-that-a-review-was-submitted}
+
+```markdown
+@ropensci-review-bot submit review <review-url> time <time in hours>
+```
+
+### Aprovar o pacote {#approve-package}
+
+```markdown
+@ropensci-review-bot approve <package-name>
+```
+
+
diff --git a/editortemplate.pt.Rmd b/editortemplate.pt.Rmd
new file mode 100644
index 000000000..bb2e15e46
--- /dev/null
+++ b/editortemplate.pt.Rmd
@@ -0,0 +1,28 @@
+---
+repo-actions: true
+---
+
+# Editor's template {#editortemplate}
+
+::: {.content-hidden when-format="pdf"}
+
+````markdown
+```{r}
+#| results: 'asis'
+#| echo: false
+#| child: "templates/editor.md"
+```
+````
+
+:::
+
+::: {.content-visible when-format="pdf"}
+
+```{r}
+#| child: "templates/editor.md"
+
+```
+
+:::
+
+
diff --git a/index.Rmd b/index.Rmd
index f74d9e5ce..e5bb585d7 100644
--- a/index.Rmd
+++ b/index.Rmd
@@ -8,10 +8,11 @@
 #| echo: false
 #| results: 'asis' 
 #| warning: false
+#| eval: fase
 cat("\n```bibtex\n")
 u <- "https://zenodo.org/record/2553043" # universal URL redirects to latest
 s <- rvest::session(u)
-u <- paste0(s$url, "/export/hx") # redirected
+u <- paste0(s$url, "/export/bibtex") # redirected
 out <- rvest::read_html(u)
 bibentry <- rvest::html_text(rvest::html_element(out, "pre"))
 cat(bibentry)
diff --git a/index.es.Rmd b/index.es.Rmd
index 2921cdd69..d0e6e4a30 100644
--- a/index.es.Rmd
+++ b/index.es.Rmd
@@ -6,6 +6,7 @@
 
 
 ```{r} 
+#| eval: fase
 #| echo: false
 #| results: 'asis' 
 #| warning: false
diff --git a/index.pt.Rmd b/index.pt.Rmd
index 3e25bceec..40d27b4cc 100644
--- a/index.pt.Rmd
+++ b/index.pt.Rmd
@@ -5,6 +5,7 @@
 <a rel="license" href="https://creativecommons.org/licenses/by-nc-sa/3.0/us/"><img alt="Licença Creative Commons" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-sa/3.0/us/88x31.png" /></a><br /> Este trabalho está licenciado com uma licença [Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License](https://creativecommons.org/licenses/by-nc-sa/3.0/us/). Utilize o [Zenodo DOI](https://doi.org/10.5281/zenodo.2553043) para citar esta obra.
 
 ```{r} 
+#| eval: fase
 #| echo: false
 #| results: 'asis' 
 #| warning: false
diff --git a/maintenance_changing_maintainers.pt.Rmd b/maintenance_changing_maintainers.pt.Rmd
new file mode 100644
index 000000000..1e2255fdc
--- /dev/null
+++ b/maintenance_changing_maintainers.pt.Rmd
@@ -0,0 +1,66 @@
+---
+aliases: 
+  - changing-maintainers.html
+---
+
+# Mudando os(as) mantenedores(as) de um pacote {#changing-maintainers}
+
+```{block, type="summaryblock"}
+Este capítulo apresenta um guia sobre como assumir a manutenção de um pacote.
+```
+
+## Você quer desistir da manutenção do seu pacote? {#do-you-want-to-give-up-maintenance-of-your-package}
+
+Temos uma seção em nosso boletim informativo para chamadas de novos(as) colaboradores(as) que é publicado a cada duas semanas. A seção se chama *Chamada para colaboradores*. Nessa seção, destacamos os pacotes que estão à procura de novos(as) mantenedores(as). Se você deseja desistir da função de mantenedor(a) do seu pacote, entre em contato conosco e poderemos destacar o seu pacote em nosso boletim informativo. Tivemos muito sucesso até o momento, ao encontrarmos novos(as) mantenedores(as) para seis dos seis pacotes anunciados.
+
+## Você quer assumir a manutenção de um pacote? {#do-you-want-to-take-over-maintenance-of-a-package}
+
+Temos uma seção em nosso boletim informativo para chamadas de novos(as) colaboradores(as) que é publicado a cada duas semanas. A seção se chama *Chamada para colaboradores*. Nessa seção, destacamos os pacotes que estão à procura de novos(as) mantenedores(as). Se você ainda não está inscrito no boletim informativo, é uma boa ideia [assinar](https://news.ropensci.org/) para que você seja notificado quando houver um pacote procurando por um novo(a) mantenedor(a).
+
+## Assumir a manutenção de um pacote {#taking-over-maintenance-of-a-package}
+
+- Adicione você como o(a) novo(a) mantenedor(a) no arquivo DESCRIPTION, com `role = c("aut", "cre")`, e, altere o(a) antigo(a) mantenedor(a) para o papel `aut` apenas;
+- Certifique-se de alterar o(a) mantenedor(a) para o seu nome em qualquer outro lugar do pacote, mantendo o(a) antigo(a) mantenedor(a) como autor (por exemplo, em manuais do pacote, CONTRIBUTING.md, CITATION etc.);
+- Os [Guia de Colaboração](#collaboration) tem orientações sobre como adicionar novos(as) mantenedores(as) e colaboradores(as);
+- Pacotes que foram arquivados ou [órfãos][orphaned] no CRAN não precisam da permissão do(a) mantenedor(a) anterior para serem retomados no CRAN. Nesses casos, entre em contato conosco para que possamos oferecer a ajuda necessária;
+- Se o pacote não tiver sido arquivado pelo CRAN e houver uma mudança de mantenedor(a), peça ao(à) mantenedor(a) antigo(a) que envie um e-mail ao CRAN e informe por escrito quem é o(a) novo(a) mantenedor(a). Certifique-se de mencionar esse e-mail sobre a mudança de mantenedor(a) quando você enviar a primeira nova versão ao CRAN. Se o(a) antigo(a) mantenedor(a) estiver inacessível ou não enviar esse e-mail, entre em contato com a equipe do rOpenSci;
+- Se o(a) mantenedor(a) anterior estiver acessível, agendar uma reunião ajudará você a conhecer melhor a situação atual do pacote;
+
+### Perguntas frequentes para novos(as) mantenedores(as) {#faq-for-new-maintainers}
+
+- Existem alguns problemas no pacote que ainda não foram resolvidos, e que eu não sei como corrigir. A quem posso pedir ajuda?
+  
+  Depende; aqui está o que você deve fazer em diferentes cenários:
+  
+  - Se for possível entrar em contato com o(a) antigo(a) mantenedor(a): entre em contato com ele(a) e peça ajuda;
+  - Slack do rOpenSci: bom para obter ajuda em problemas específicos ou gerais, consulte o canal #package-maintenance;
+  - [Fórum de discussão do rOpenSci](https://discuss.ropensci.org/c/package-development/29) este forum é uma boa opção, sinta-se à vontade para fazer perguntas;
+  - [Equipe do rOpenSci](https://ropensci.org/about/#team) sinta-se livre para entrar em contato com um de nós, seja por e-mail ou nos marcando em um problema no GitHub, ficaremos felizes em ajudar;
+  - é claro, também existem vários centros de ajuda geral sobre o R, se isso atender às suas necessidades: Fórum da comunidade RStudio, StackOverflow, Twitter #rstats, etc.
+
+- O quanto você pode/deve alterar no pacote?
+  
+  Para obter ajuda geral sobre como alterar o código em um pacote, consulte a seção [Evolução do pacote](#evolution)
+  de pacotes.
+  
+  Quando você pensa nisso, há muitas considerações a se fazer.
+  
+  Quanto tempo você tem para dedicar ao pacote? Se você tiver um tempo muito limitado, seria melhor se concentrar nas tarefas mais importantes, sejam elas quais forem para o pacote em questão. Se você tiver bastante tempo, suas metas poderão ter um escopo maior.
+  
+  Qual é o grau de maturidade do pacote? Se o pacote for maduro, muitas pessoas provavelmente têm códigos que dependem da API do pacote (ou seja, as funções exportadas e seus parâmetros). Além disso, se houver outros pacotes que dependam do seu pacote no CRAN, você precisa verificar se as suas alterações vão quebrar ou não esses outros pacotes. Quanto mais maduro for o pacote, mais cuidadoso(a) você precisará ser ao fazer alterações, especialmente com os nomes das funções exportadas, seus parâmetros e a estrutura exata do que as funções exportadas retornam. É mais fácil fazer alterações que afetem apenas os aspectos internos do pacote.
+
+## Tarefas da equipe do rOpenSci {#tasks-for-ropensci-staff}
+
+Como organização, a rOpenSci está interessada em garantir que os pacotes de nossa suíte estejam disponíveis enquanto forem úteis para a comunidade. Como os(as) mantenedores(as) precisam seguir em frente, na maioria dos casos tentaremos conseguir um(a) novo(a) mantenedor(a) para cada pacote. Para isso, as tarefas a seguir são de responsabilidade da equipe da rOpenSci.
+
+- Se um repositório não tiver nenhuma atividade (commits, issues, pull requests) há muito tempo, ele pode ser simplesmente um pacote maduro com pouca necessidade de alterações/etc., portanto, leve isso em consideração.
+- O(a) mantenedor(a) atual não responde a problemas/solicitações pull há muitos meses, por meio de e-mails, problemas no GitHub ou mensagens no Slack:
+  - Entre em contato e veja qual é a situação. Ele(a) pode dizer que gostaria de deixar o cargo de mantenedor(a) e, nesse caso, procure um(a) novo(a) mantenedor(a)
+- O(a) mantenedor(a) atual está completamente ausente/não está respondendo
+  - Se isso acontecer, tentaremos entrar em contato com o(a) mantenedor(a) por até um mês. No entanto, se a atualização do pacote for urgente, poderemos usar nosso acesso de administrador para fazer alterações em seu nome.
+- Faça uma chamada na seção "Call for Contributors" do boletim informativo da rOpenSci para um(a) novo(a) mantenedor(a) - abra um problema no [repositório do boletim informativo](https://github.com/ropensci/monthly/).
+
+[orphaned]: https://cran.r-project.org/src/contrib/Orphaned/README
+
+
+
diff --git a/maintenance_cheatsheet.pt.Rmd b/maintenance_cheatsheet.pt.Rmd
new file mode 100644
index 000000000..d79513f77
--- /dev/null
+++ b/maintenance_cheatsheet.pt.Rmd
@@ -0,0 +1,50 @@
+# Folha de dicas de manutenção do pacote rOpenSci {#maintainer-cheatsheet}
+
+```{block, type="summaryblock"}
+Um lembrete da infraestrutura e dos canais de contato para mantenedores de pacotes rOpenSci.
+
+```
+
+## Você precisa de ajuda? {#help-needed}
+
+Se você precisar de ajuda pontual (por exemplo, uma revisão de PR; ou alguma solução de problemas de CI), ou ajuda para procurar co-mantenedores ou um novo mantenedor, ou se precisar que retiremos seu pacote, envie-nos um ping no GitHub via `@ropensci/admin` ou envie um e-mail para você `info@ropensci.org`.
+Você também pode usar nosso canal de manutenção de pacotes no Slack.
+
+Nunca hesite em pedir ajuda.
+
+## Acesso ao repositório do GitHub {#git-hub-repository-access}
+
+Você deve ter acesso administrativo ao repositório do GitHub do seu pacote.
+Se esse não for mais o caso (por exemplo, o processo automatizado falhou ou você perdeu o acesso depois de ter que desativar temporariamente a autenticação de dois fatores),
+entre em contato conosco via `info@ropensci.org`.
+
+## Outros tópicos do GitHub {#other-git-hub-topics}
+
+Se tiver alguma pergunta ou solicitação sobre o GitHub (por exemplo, adicionar um colaborador à organização do GitHub), você pode usar um canal público do espaço de trabalho slack do rOpenSci ou enviar um ping para `@ropensci/admin` no GitHub.
+
+## Documentação do pkgdown {#pkgdown-documentation}
+
+Veja [Documentos do rOpenSci](#rodocsci).
+
+## Acesso ao espaço de trabalho do rOpenSci no Slack {#access-to-ropensci-slack-workspace}
+
+Os mantenedores e desenvolvedores de pacotes devem ter acesso a [Slack do rOpenSci](https://contributing.ropensci.org/resources.html#channels).
+Se você não recebeu o convite ou não o aceitou a tempo,
+ou se você quiser que um novo colaborador regular receba um convite, envie um e-mail para `info@ropensci.org`,
+indicando para qual endereço de e-mail você deseja receber o convite.
+
+Você pode achar que o canal #package-maintenance é relevante para perguntas e respostas, bem como para uma comiseração amigável quando necessário.
+
+## Publicações no blog sobre pacotes {#package-blog-posts}
+
+Consulte nosso [guia do blog](https://blogguide.ropensci.org/).
+
+## Promoção de problemas de pacotes {#package-issues-promotion}
+
+Rotular as edições com "procura-se ajuda" para obtê-las [para que sejam transmitidos à comunidade](https://ropensci.org/help-wanted/).
+
+## Promoção de casos de uso de pacotes {#package-use-cases-promotion}
+
+Você pode relatar casos de uso do seu pacote ou incentivar os usuários a relatá-los por meio do nosso fórum para obtê-los [publicados em nosso site](https://ropensci.org/usecases/) e em nosso boletim informativo.
+
+
diff --git a/maintenance_collaboration.pt.Rmd b/maintenance_collaboration.pt.Rmd
new file mode 100644
index 000000000..05eac3813
--- /dev/null
+++ b/maintenance_collaboration.pt.Rmd
@@ -0,0 +1,165 @@
+---
+aliases:
+  - collaboration.html
+---
+
+# Collaboration Guide {#collaboration}
+
+```{block, type="summaryblock"}
+Having contributors will improve your package, and if you onboard some of them as package authors with [write permissions to the repo](https://help.github.com/articles/repository-permission-levels-for-an-organization/), your package will be more sustainably developed.
+It can also be very enjoyable to work as a team!
+
+This chapter contains our guidance for collaboration, in a [section about making your repo contribution- and collaboration-friendly](#friendlyfiles) by infrastructure (code of conduct, contribution guidelines, issue labels); and [ a section about how to collaborate with new contributors](#workingcollaborators), in particular in the context of the rOpenSci's "ropensci" GitHub organization.
+
+Besides these mostly technical tips, it is important to remember to be kind, and to take others' perspective into account especially when their priorities differ from yours.
+```
+
+## Make your repo contribution and collaboration friendly {#friendlyfiles}
+
+### Code of conduct {#coc-file}
+
+After transfer to our GitHub organization, [rOpenSci Code of Conduct](https://ropensci.org/code-of-conduct/) will apply to your project.
+Please add this text to the README
+
+```markdown
+Please note that this package is released with a [Contributor
+Code of Conduct](https://ropensci.org/code-of-conduct/). 
+By
+contributing to this project, you agree to abide by its terms.
+```
+
+And delete the package current code of conduct if there was one.
+
+### Contributing guide {#contributing-guide}
+
+You can use issue, pull request and contributing guidelines.
+Having a contributing file as `.github/CONTRIBUTING.md` or `docs/CONTRIBUTING.md` is compulsory.
+An easy way to insert a template for a contributing guide is the [`use_tidy_contributing()` function from the `usethis` package](https://usethis.r-lib.org/reference/tidyverse.html), which inserts [this template](https://github.com/r-lib/usethis/blob/main/inst/templates/tidy-contributing.md) as `.github/CONTRIBUTING.md`.
+A more extensive example is [this template by Peter Desmet](https://gist.github.com/peterdesmet/e90a1b0dc17af6c12daf6e8b2f044e7c), or the comprehensive [GitHub wiki pages for the mlr3 package](https://github.com/mlr-org/mlr3/wiki).
+These and other templates will generally need to be modified for use with an rOpenSci package, particularly by referring and linking to our [Code of Conduct](https://ropensci.org/code-of-conduct/), as described elsewhere [in this book](#code-of-conduct).
+Modifying a generic contributing guide to add a personal touch also tends to make it look less generic and more sincere.
+Personal preferences in a contributing guide include:
+
+- Style preferences? You might however prefer to make style a configuration (of [lintr](https://github.com/jimhester/lintr), [styler](https://styler.r-lib.org/)) or to [fix code style yourself](https://github.com/rstudio/blogdown/pull/432#pullrequestreview-368391904) especially if you don't use a popular code style like the [tidyverse coding style](https://style.tidyverse.org/).
+
+- Infrastructure like roxygen2?
+
+- Workflow preferences? Issue before a PR?
+
+- A scope statement, like [in the skimr package](https://github.com/ropensci/skimr/blob/main/.github/CONTRIBUTING.md#understanding-the-scope-of-skimr)?
+
+- Sandbox account creation? Mocking in tests? Linking to external docs?
+
+rOpenSci further encourages contributing guides to include a lifecycle statement clarifying visions and expectations for the future development of your package, like [in this example](https://github.com/ecohealthalliance/fasterize/blob/master/CONTRIBUTING.md#roadmap).
+Statistical packages are required to have a lifecycle statement, as specified in [*General Statistical Stanards* G1.2](https://stats-devguide.ropensci.org/standards.html#documentation).
+That links provides a template for a simple lifecycle statement.
+CONTRIBUTING.md files can also describe how you acknowledge contributions (see [this section](#attributions)).
+
+We encourage you to direct feedback that is not a bug report or a feature request to [rOpenSci forum](https://discuss.ropensci.org/), after making sure you'd see such questions on the forum. Users can use the forum to ask questions about use and report their use cases, and you can subscribe to individual categories and tags to receive notifications about your package.  Feel free to mention this in the docs of your package and/or the contributing guidelines/issue template.  Please direct your users to tag posts with the package name.
+
+Once a pull request is closer to being merged, you could use [a GitHub Actions PR workflow to style the code with styler](https://github.com/r-lib/actions/blob/master/examples/pr-commands.yaml).
+
+### Issue management {#issue-management}
+
+By using GitHub features around issues you can help potential contributors find them, and make your roadmap public.
+
+#### Issue templates {#issue-templates}
+
+You could use one or several [issue template(s)](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-templates=) to help users fill better bug reports or feature requests.
+When there are several issue templates, users who click on opening a new issue see a menu that guide their choices.
+
+You can even [configure one of the choices](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#configuring-the-template-chooser=) to point to somewhere outside of your repository (for instance a discussion forum).
+
+Refer to [GitHub docs](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository).
+
+#### Issue labelling {#issue-labelling}
+
+You can use labels such as "help wanted" and "good first issue" to help potential collaborators, including newbies, find your repo. [Cf GitHub article](https://help.github.com/articles/helping-new-contributors-find-your-project-with-labels/). You can also use the "Beginner" label. See [examples of beginner issues over all ropensci repos](https://github.com/search?q=user%3Aropensci+user%3Aropenscilabs+label%3ABeginner+state%3Aopen&type=Issues).
+
+#### Pinning issues {#pinning-issues}
+
+You can [pin up to 3 issues by repository](https://docs.github.com/en/articles/pinning-an-issue-to-your-repository) that will then appear at the top of your issue tracker as nice issue cards.
+It can help advertise what your priorities are.
+
+#### Milestones {#milestones}
+
+You can [create milestones](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones) and assign issues to them, which help see what you plan for the next version of your package for instance.
+
+### Communication with users {#communication-with-users}
+
+You can point users to rOpenSci forum if you monitor it, or enable [GitHub Discussions](https://docs.github.com/en/discussions) for your package repository.
+Each GitHub discussion can be converted to an issue if needed (and the other way round, issues can be converted to discussions).
+
+## Working with collaborators {#workingcollaborators}
+
+First thing first: keep in touch with your GitHub repository!
+
+- do not forget to [**watch your GitHub repository**](https://docs.github.com/en/github/managing-subscriptions-and-notifications-on-github/managing-subscriptions-for-activity-on-github) to be notified of issues or pull requests (alternatively, if you work in bursts, maybe add the information to the contributing guide).
+
+- do not forget to push updates you have locally.
+
+- disable failing tests if you cannot fix them as they create noise in PRs that can puzzle new contributors.
+
+### Onboarding collaborators {#onboarding-collaborators}
+
+There's no general rOpenSci rule as to how you should onboard collaborators. You should increase their rights to the repo as you gain trust, and you should definitely acknowledge contributions (see [this section](#attributions)).
+
+You can ask a new collaborator to make PRs (see following section for assessing a PR locally, i.e. beyond CI checks) to dev/main and assess them before merging, and after a while let them push to main, although you might want to keep a system of PR reviews... even for yourself once you have team mates!
+
+A possible model for onboarding collaborators is provided by Jim Hester in [his `lintr` repo](https://github.com/jimhester/lintr/issues/318).
+
+If your problem is *recruiting* collaborators, you can post an open call like Jim Hester's [on Twitter](https://twitter.com/jimhester_/status/997109466674819074), [GitHub](https://github.com/jimhester/lintr/issues/318), and as an rOpenSci package author, you can ask for help in rOpenSci slack and ask rOpenSci team for ideas for recruiting new collaborators.
+
+### Working with collaborators (including yourself) {#git-workflow}
+
+[Branches](https://happygitwithr.com/git-branches.html) are cheap. Use them extensively when developing features, testing out new ideas, fixing problems.
+
+One of the branches is the default / main branch, where, if you follow [trunk-based development](https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development), you "merge small, frequent updates".
+See also [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) and [GitLab flow](https://docs.gitlab.com/ee/topics/gitlab_flow.html) docs.
+You might want to frequently increment version numbers (in `DESCRIPTION`).
+One particular aspect of working with collaborators is reviewing pull requests, with some useful guidance in:
+
+- [The Art of Giving and Receiving Code Reviews (Gracefully), by Alex Hill](https://www.alexandra-hill.com/2018/06/25/the-art-of-giving-and-receiving-code-reviews/);
+- [GitHub documentation about PR reviews](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews).
+
+You might want to tinker with your GitHub repository settings to, for instance, [require pull request reviews before merging](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging=).
+See also GitHub docs about ["code owners"](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).
+
+For making and reviewing pull requests we recommend [exploring usethis functions](https://usethis.r-lib.org/articles/pr-functions.html).
+
+For your "git remote" setup refer to [happy git with r](https://happygitwithr.com/common-remote-setups.html).
+See also [Useful Git patterns for real life](https://happygitwithr.com/workflows-intro.html) in the same book.
+
+### Be generous with attributions {#attributions}
+
+If someone contributes to your repository consider adding them in DESCRIPTION, as contributor ("ctb") for small contributions, author ("aut") for bigger contributions. Traditionally when citing a package in a scientific publication only "aut" authors are listed, not "ctb" contributors; and on `pkgdown` websites only "aut" names are listed on the homepage, all authors being listed on the authors/ page.
+
+At a minimum consider adding the name of contributors near the feature/bug fix line in [NEWS.md](#news).
+
+We recommend your being generous with such acknowledgements, because it is a nice thing to do and because it will make folks more likely to contribute again to your package or other repos of the organization.
+
+As a reminder from [our packaging guidelines](#building) if your package was reviewed and you feel that your reviewers have made a substantial contribution to the development of your package, you may list them in the `Authors@R` field with a Reviewer contributor type (`"rev"`), like so:
+
+```
+    person("Bea", "Hernández", role = "rev",
+    comment = "Bea reviewed the package (v. X.X.XX) for rOpenSci, see <https://github.com/ropensci/software-review/issues/116>"),
+```
+
+Only include reviewers after asking for their consent. Read more in [this blog post "Thanking Your Reviewers: Gratitude through Semantic Metadata"](https://ropensci.org/blog/2018/03/16/thanking-reviewers-in-metadata/). Note that 'rev' will raise a CRAN NOTE unless the package is built using R v3.5. Make sure you use `roxygen2`'s latest CRAN version.
+
+Please do not list editors as contributors. Your participation in and contribution to rOpenSci is thanks enough!
+
+### Welcoming collaborators to rOpenSci {#welcoming-collaborators-to-ropensci}
+
+If you give someone write permissions to the repository,
+
+- please contact a [staff member](https://ropensci.org/about#team) so that this new contributor might get **invited to rOpenSci's "ropensci" GitHub organization** (instead of being [an outside collaborator](https://help.github.com/articles/repository-permission-levels-for-an-organization/#outside-collaborators))
+
+- please contact rOpenSci's [community manager or another staff member](https://ropensci.org/about#team) so that this new contributor might get get **invited to rOpenSci Slack workspace**.
+
+## Further resources {#further-resources}
+
+- rOpenSci community call [Set Up Your Package to Foster a Community](https://ropensci.org/commcalls/apr2021-pkg-community/).
+- For re-using kind and usual answers, consider GitHub's [saved replies](https://docs.github.com/en/github/writing-on-github/working-with-saved-replies/using-saved-replies).
+
+
diff --git a/maintenance_contributing.pt.Rmd b/maintenance_contributing.pt.Rmd
new file mode 100644
index 000000000..54d40814f
--- /dev/null
+++ b/maintenance_contributing.pt.Rmd
@@ -0,0 +1,34 @@
+---
+repo-actions: true
+aliases:
+  - contributingguide.html
+---
+
+# Contributing Guide {#contributingguide}
+
+```{block, type="summaryblock"}
+This chapter describes our Contributing Guide that outlines how you can make code and non-code contributions to the rOpenSci project.
+
+```
+
+So you want to contribute to rOpenSci? Fantastic! We developed the [rOpenSci Community Contributing Guide](https://contributing.ropensci.org/) to welcome you to rOpenSci and help you recognize yourself as a potential contributor. It will help you figure out what you might gain by giving your time, expertise, and experience, match your needs with things that will help rOpenSci's mission, and connect you with resources to help you along the way.
+
+Our staff and community actively foster a welcoming environment where users and developers from different backgrounds and skill levels learn, share ideas and innovate together openly through shared norms and shared software. Participation in all rOpenSci activities is supported by [our Code of Conduct](https://ropensci.org/code-of-conduct).
+
+We welcome code and non-code contributions from new and seasoned coders at any career stage, and in any sector. You don't have to be a developer! Maybe you want to **spend 30 minutes** sharing your package use case in our public forum or reporting a bug, **one hour** learning by attending a Community Call, **five hours** reviewing an R package submitted for open peer review, **or maybe you want to make an ongoing commitment** to help maintain a package.
+
+What are some benefits of contributing?
+
+- Connect with a community  who shares your interest in making science more open
+- Learn from people outside your domain who use R with challenges similar to yours
+- Ask and answer new research questions by getting to know new software tools and allies
+- Feel confident and supported in your efforts to write code and develop software
+- Gain visibility for your open source work
+- Improve the software you use or build
+- Level up your R skills and help others level up theirs
+- Level up your writing skills
+- Get more exposure for your package
+
+Consult our [Contributing Guide](https://contributing.ropensci.org/) and browse "What brings you here?" to find which *I want to …* statements fit you best and choose your path! To help you recognize yourself, we've grouped these into: Discover; Connect; Learn; Build; Help. For each category, we list examples of what those contributions might look like and we link to our resources for the details you need.
+
+
diff --git a/pkg_building.Rmd b/pkg_building.Rmd
index 6a8a70115..70b683fb4 100644
--- a/pkg_building.Rmd
+++ b/pkg_building.Rmd
@@ -18,11 +18,12 @@ We strongly recommend that package developers read Hadley Wickham and Jenny Brya
 
 ### Naming your package {#naming-your-package}
 
-* We strongly recommend short, descriptive names in lower case. If your package deals with one or more commercial services, please make sure the name does not violate branding guidelines. You can check if your package name is available, informative and not offensive by using the [`available` package](https://github.com/ropenscilabs/available). In particular, do _not_ choose a package name that's already used on CRAN or Bioconductor.
-* 
-* There is a trade-off between the advantages of a unique package name and a less original package name. 
-    - A more unique package name might be easier to track (for you and us to assess package use for instance, less false positives when typing its name in GitHub code search) and search (for users to ask "how to use package blah" in a search engine). 
-    - On the other hand a _too_ unique package name might make the package less discoverable (that is to say, to find it by searching "how to do this-thing in R"). It might be an argument for naming your package something very close to its topic such as [geojson](https://github.com/ropensci/geojson)).
+- We strongly recommend short, descriptive names in lower case. If your package deals with one or more commercial services, please make sure the name does not violate branding guidelines. You can check if your package name is available, informative and not offensive by using the [`available` package](https://github.com/ropenscilabs/available). In particular, do *not* choose a package name that's already used on CRAN or Bioconductor.
+
+- There is a trade-off between the advantages of a unique package name and a less original package name.
+  
+  - A more unique package name might be easier to track (for you and us to assess package use for instance, less false positives when typing its name in GitHub code search) and search (for users to ask "how to use package blah" in a search engine).
+  - On the other hand a *too* unique package name might make the package less discoverable (that is to say, to find it by searching "how to do this-thing in R"). It might be an argument for naming your package something very close to its topic such as [geojson](https://github.com/ropensci/geojson)).
 
 - Find other interesting aspects of naming your package [in this blog post by Nick Tierney](https://www.njtierney.com/post/2018/06/20/naming-things/), and in case you change your mind, find out [how to rename your package in this other blog post of Nick's](https://www.njtierney.com/post/2017/10/27/change-pkg-name/).
 
@@ -62,6 +63,23 @@ If providing graphical user interface (GUI) (such as a Shiny app), to facilitate
 
 The [`tabulizer` package](https://github.com/ropensci/tabulizer) e.g. has an interactive workflow to extract tables, but can also only extract coordinates so one can re-run things as a script. Besides, two examples of shiny apps that do code generation are [https://gdancik.shinyapps.io/shinyGEO/](https://gdancik.shinyapps.io/shinyGEO/), and [https://github.com/wallaceEcoMod/wallace/](https://github.com/wallaceEcoMod/wallace/).
 
+### Input checking
+
+We recommend your package use a consistent method of your choice for [checking inputs](https://blog.r-hub.io/2022/03/10/input-checking/) -- either base R, an R package, or custom helpers.
+
+### Packages wrapping web resources (API clients)
+
+If your package accesses a web API or another web resource,
+
+- Make sure requests send an [user agent](https://httr2.r-lib.org/articles/wrapping-apis.html#user-agent), that is, a way to identify what (your package) or who sent the request. The users should be able to override the package's default user agent. Ideally the user agent should be different on continuous integration services, and in development (based on, for instance, the GitHub usernames of the developers).
+- You might choose different (better) defaults than the API, in which case you should document them.
+- Your package should help with pagination, by allowing the users to not worry about it at all since your package does all necessary requests.
+- Your package should help with rate limiting according to the API rules.
+- Your package should reproduce API errors, and possibly explain them in informative error messages.
+- Your package could export high-level functions and low-level functions, the latter allowing users to call API endpoints directly with more control (like `gh::gh()`).
+
+For more information refer to the blog post [Why You Should (or Shouldn't) Build an API Client](https://ropensci.org/blog/2022/06/16/publicize-api-client-yes-no).
+
 ## Code Style {#code-style}
 
 - For more information on how to style your code, name functions, and R scripts inside the `R/` folder, we recommend reading the [code chapter in The R Packages book](https://r-pkgs.org/Code.html). We recommend the [`styler` package](https://github.com/r-lib/styler) for automating part of the code styling. We suggest reading the [Tidyverse style guide](https://style.tidyverse.org/).
@@ -75,7 +93,9 @@ The [`tabulizer` package](https://github.com/ropensci/tabulizer) e.g. has an int
 - CRAN requires CITATION files to be declared as [`bibentry` items](https://stat.ethz.ch/R-manual/R-devel/library/utils/html/bibentry.html), and not in the previously-accepted form of [`citEntry()`](https://stat.ethz.ch/R-manual/R-devel/library/utils/html/citEntry.html).
 
 - If you archive each release of your GitHub repo on Zenodo, add the [Zenodo top-level DOI](https://help.zenodo.org/#versioning) to the CITATION file.
+
 - If one day [**after** review at rOpenSci](#authors-guide) you publish a software publication about your package, add it to the CITATION file.
+
 - Less related to your package itself but to what supports it: if your package wraps a particular resource such as data source or, say, statistical algorithm, remind users of how to cite that resource via e.g. `citHeader()`. [Maybe even add the reference for the resource](https://discuss.ropensci.org/t/citation-of-original-article-when-implementing-specific-methods/2312).
 
 As an example see [the dynamite CITATION file](https://github.com/ropensci/dynamite/blob/main/inst/CITATION) which refers to the R manual as well as other associated publications.
@@ -424,13 +444,13 @@ For more explanations around licensing, refer to the [R packages book](https://r
 
 ## Recommended scaffolding {#recommended-scaffolding}
 
-- For HTTP requests we recommend using [curl], [crul], [httr] or [httr2] over [RCurl]. If you like low level clients for HTTP, [curl] is best, whereas [crul] or [httr] are better for higher level access. [crul] is maintained by rOpenSci. We recommend the rOpenSci maintained packages [webmockr] for mocking HTTP requests, and [vcr] for caching HTTP requests in package tests.
+- For HTTP requests we recommend using [curl](https://github.com/jeroen/curl/), [crul](http://docs.ropensci.org/crul/), [httr](https://httr.r-lib.org) or [httr2](https://httr2.r-lib.org) over [RCurl](https://cran.rstudio.com/web/packages/RCurl/). If you like low level clients for HTTP, [curl] is best, whereas [crul] or [httr](https://httr.r-lib.org) are better for higher level access. [crul](http://docs.ropensci.org/crul/) is maintained by rOpenSci. We recommend the rOpenSci maintained packages [webmockr](https://docs.ropensci.org/webmockr/) for mocking HTTP requests, and [vcr](https://docs.ropensci.org/vcr/) for caching HTTP requests in package tests.
 
-- For parsing JSON, use [jsonlite] instead of [rjson] or [RJSONIO].
+- For parsing JSON, use [jsonlite](https://github.com/jeroen/jsonlite) instead of [rjson](https://cran.rstudio.com/web/packages/rjson/) or [RJSONIO](https://cran.rstudio.com/web/packages/RJSONIO/).
 
-- For parsing, creating, and manipulating XML, we strongly recommend [xml2] for most cases. [You can refer to Daniel Nüst's notes about migration from XML to xml2](https://gist.github.com/nuest/3ed3b0057713eb4f4d75d11bb62f2d66).
+- For parsing, creating, and manipulating XML, we strongly recommend [xml2](https://cran.rstudio.com/web/packages/xml2/) for most cases. [You can refer to Daniel Nüst's notes about migration from XML to xml2](https://gist.github.com/nuest/3ed3b0057713eb4f4d75d11bb62f2d66).
 
-- For spatial data, the [sp] package should be considered deprecated in favor of [sf], and the packages [rgdal], [maptools], and [rgeos] will be retired by the end of 2023. We recommend use of the spatial suites developed by the [r-spatial](https://github.com/r-spatial) and [rspatial](https://github.com/rspatial) communities. See [this GitHub issue](https://github.com/ropensci/software-review-meta/issues/47) for relevant discussions.
+- For spatial data, the [sp](https://github.com/edzer/sp/) package should be considered deprecated in favor of [sf](https://r-spatial.github.io/sf/), and the packages rgdal, rgdal, and rgdal will be retired by the end of 2023. We recommend use of the spatial suites developed by the [r-spatial](https://github.com/r-spatial) and [rspatial](https://github.com/rspatial) communities. See [this GitHub issue](https://github.com/ropensci/software-review-meta/issues/47) for relevant discussions.
 
 ## Version Control {#version-control}
 
@@ -506,23 +526,4 @@ If you intend your package to be submitted to, or if your package is on, Biocond
 #### MOOCs {#moo-cs}
 
 There is a [Coursera specialization corresponding to the book by Roger Peng, Sean Kross and Brooke Anderson](https://fr.coursera.org/specializations/r), with a course specifically about R packages.
-
-[curl]: https://github.com/jeroen/curl/
-[crul]: https://github.com/ropensci/crul/
-[httr]: https://httr.r-lib.org
-[httr2]: https://httr2.r-lib.org
-[RCurl]: https://cran.rstudio.com/web/packages/RCurl/
-[webmockr]: https://github.com/ropensci/webmockr/
-[vcr]: https://github.com/ropensci/vcr/
-[jsonlite]: https://github.com/jeroen/jsonlite
-[rjson]: https://cran.rstudio.com/web/packages/rjson/
-[RJSONIO]: https://cran.rstudio.com/web/packages/RJSONIO/
-[xml2]: https://cran.rstudio.com/web/packages/xml2/
-[sp]: https://github.com/edzer/sp/
-[sf]: https://r-spatial.github.io/sf/
-[rgdal]: https://cran.r-project.org/web/packages/rgdal/index.html
-[maptools]: https://cran.r-project.org/web/packages/maptools/index.html
-[rgeos]: https://cran.r-project.org/web/packages/rgeos/index.html
-
-
-
+ 
diff --git a/pkg_building.es.Rmd b/pkg_building.es.Rmd
index a7d117920..83bface42 100644
--- a/pkg_building.es.Rmd
+++ b/pkg_building.es.Rmd
@@ -18,10 +18,9 @@ Para leer por qué vale la pena enviar un paquete a rOpenSci siguiendo las recom
   Puedes comprobar si el nombre de tu paquete está disponible, es informativo y no es ofensivo utilizando el [paquete `available`](https://github.com/ropenscilabs/available).
   En particular, *no* elijas un nombre de paquete que no esté disponible en CRAN o en Bioconductor.
 
-- Un nombre poco común tiene la ventaja de que su uso es más fácil de detectar (habrá menos falsos positivos al buscar el nombre en la búsqueda de código de GitHub para que tú o rOpenSci evalúen su uso) y de buscar (para que quienes lo usen puedan buscar "cómo usar el paquete \<nombre\_paquete>?" en internet).
-
-- Por otro lado, un nombre *demasiado* único puede hacer que el paquete sea más difícil de descubrir (es decir, difícil de que aparezca como resultado de la búsqueda "cómo hago esto en R").
-  Es un argumento para que el nombre de tu paquete sea algo muy cercano al tema, como [geojson](https://github.com/ropensci/geojson).
+- Existe un equilibrio entre las ventajas de un nombre de paquete único y un nombre de paquete menos original.
+    - Un nombre poco común tiene la ventaja de que su uso es más fácil de detectar (habrá menos falsos positivos al buscar el nombre en la búsqueda de código de GitHub para que tú o rOpenSci evalúen su uso) y de buscar (para que quienes lo usen puedan buscar "cómo usar el paquete \<nombre\_paquete>?" en internet).
+    - Por otro lado, un nombre *demasiado* único puede hacer que el paquete sea más difícil de descubrir (es decir, difícil de que aparezca como resultado de la búsqueda "cómo hago esto en R"). Es un argumento para que el nombre de tu paquete sea algo muy cercano al tema, como [geojson](https://github.com/ropensci/geojson).
 
 - [Este artículo de Nick Tierney (en inglés)](https://www.njtierney.com/post/2018/06/20/naming-things/) lista otras consideraciones interesantes a tener en cuenta al nombrar paquetes de R.
   En caso de que cambies de opinión sobre el nombre de tu paquete, este segundo artículo de Nick explica [cómo cambiar el nombre de tu paquete](https://www.njtierney.com/post/2017/10/27/change-pkg-name/).
@@ -68,6 +67,23 @@ Esto puede incluir la generación automática del código necesario para reprodu
 El paquete [`tabulizer`](https://github.com/ropensci/tabulizer) por ejemplo, tiene un flujo de trabajo interactivo para extraer tablas, pero también puede extraer sólo coordenadas, por lo que se pueden volver a ejecutar los mismos pasos como un script.
 Otros dos ejemplos de aplicaciones shiny que generan código son [https://gdancik.shinyapps.io/shinyGEO/](https://gdancik.shinyapps.io/shinyGEO/)y [https://github.com/wallaceEcoMod/wallace/](https://github.com/wallaceEcoMod/wallace/).
 
+### Comprobación de entradas
+
+Recomendamos que tu paquete utilice un método coherente de tu elección para [comprobar las entradas](https://blog.r-hub.io/2022/03/10/input-checking/) -- ya sea R base, un paquete de R o ayudantes personalizados.
+
+### Paquetes que envuelven recursos web (clientes API)
+
+Si tu paquete accede a una API web o a otro recurso web,
+
+- asegúrate de que las peticiones envían un [agente de usuario](https://httr2.r-lib.org/articles/wrapping-apis.html#user-agent) es decir, una forma de identificar qué (tu paquete) o quién envió la solicitud. Se debe poder anular el agente de usuario por defecto del paquete. Lo ideal sería que el agente de usuario fuera diferente en los servicios de integración continua y en los de desarrollo (basándose, por ejemplo, en los nombres de usuario de GitHub de quienes desarrollan).
+- Puede que elijas valores por defecto diferentes (mejores) que los de la API, en cuyo caso deberías documentarlos.
+- Tu paquete debería ayudar con la paginación, permitiendo que quienes lo usen no se preocupen en absoluto de ella, ya que tu paquete realiza todas las peticiones necesarias.
+- Tu paquete debe ayudar a limitar la tasa de acuerdo con las normas de la API.
+- Tu paquete debe reproducir los errores de la API, y posiblemente explicarlos en mensajes de error informativos.
+- Tu paquete podría exportar funciones de alto nivel y funciones de bajo nivel, estas últimas permitiendo a las personas que lo usen llamar directamente a los puntos finales de la API con más control (como `gh::gh()`).
+
+Para más información, consulta el artículo del blog [Por qué deberías (o no) crear un cliente API](https://ropensci.org/blog/2022/06/16/publicize-api-client-yes-no).
+
 ## Estilo del código {#code-style}
 
 - Para más información sobre cómo dar estilo a tu código, nombrar funciones y scripts de R dentro de la carpeta `R` te recomendamos que leas el [capítulo "Code" (Código) del libro R Packages](https://r-pkgs.org/Code.html).
diff --git a/pkg_ci.Rmd b/pkg_ci.Rmd
index 89470d073..4b22bc007 100644
--- a/pkg_ci.Rmd
+++ b/pkg_ci.Rmd
@@ -68,6 +68,10 @@ You can use these tips to minimize build time on CI:
 
 - Cache installation of packages. The default [r-lib/actions workflows](https://github.com/r-lib/actions) do this.
 
+#### System dependencies {#sysdeps-ci}
+
+You might find Hugo Gruson's post [System Dependencies in R Packages & Automatic Testing](https://blog.r-hub.io/2023/09/26/system-dependency/) useful.
+
 ### Travis CI (Linux and Mac OSX) {#travis-ci-linux-and-mac-osx}
 
 We recommend [moving away from Travis](https://ropensci.org/technotes/2020/11/19/moving-away-travis/).
@@ -111,6 +115,8 @@ After transfer to rOpenSci's "ropensci" GitHub organization, each push to the re
 
 ## Even more CI: rOpenSci docs {#rodocsci}
 
-After transfer to rOpenSci's "ropensci" GitHub organization, a pkgdown website will be built for your package after each push to the GitHub repo. You can find the status of these builds at `https://ropensci.r-universe.dev/ui#packages` and in the [commit status](https://ropensci.org/blog/2021/09/03/runiverse-docs/#how-it-works). The website build will use your pkgdown config file if you have one, except for the styling that will use the [`rotemplate` package](https://github.com/ropensci-org/rotemplate/). Please report bugs, questions and feature requests about the central builds and about the template at [https://github.com/ropensci-org/rotemplate/](https://github.com/ropensci-org/rotemplate/).
+After transfer to rOpenSci's "ropensci" GitHub organization, a pkgdown website will be built for your package after each push to the GitHub repo. You can find the status of these builds at `https://ropensci.r-universe.dev/ui#packages` and in the [commit status](https://ropensci.org/blog/2021/09/03/runiverse-docs/#how-it-works). The website build will use your pkgdown config file if you have one, except for the styling that will use the [`rotemplate` package](https://github.com/ropensci-org/rotemplate/). 
+
+Please report bugs, questions and feature requests about the central builds and about the template at [https://github.com/ropensci-org/rotemplate/](https://github.com/ropensci-org/rotemplate/).
 
 
diff --git a/pkg_ci.es.Rmd b/pkg_ci.es.Rmd
index 802eae3f9..57fba620d 100644
--- a/pkg_ci.es.Rmd
+++ b/pkg_ci.es.Rmd
@@ -1,3 +1,8 @@
+---
+aliases:
+  - ci.html
+---
+
 # Buenas prácticas de integración continua  {#ci}
 
 ```{block, type="summaryblock"}
@@ -35,7 +40,7 @@ Los paquetes de R deben tener CI para todos los sistemas operativos (Linux, Mac
 
 - Procesamiento de texto, por ejemplo obtener nombres de personas (para encontrar problemas de codificación).
 
-- Cualquier cosa que incluya llamadas al sistema de archivos / rutas de acceso
+- Cualquier cosa que incluya llamadas al sistema de archivos / rutas de acceso.
 
 Ante la duda de si estos criterios se aplican a tu paquete, es mejor añadir CI para todos los sistemas operativos.
 La mayoría de los servicios de CI para paquetes de R lo permiten sin mucha complicación utilizando la configuración estándar.
@@ -72,6 +77,10 @@ Puedes utilizar estos consejos para minimizar los tiempos de construcción en CI
 
 - Guardar los paquetes instalados en una caché. La acción [r-lib/actions](https://github.com/r-lib/actions) lo hace por defecto.
 
+#### Dependencias del sistema {#sysdeps-ci}
+
+Puede que encuentres útil el post de Hugo Gruson [Dependencias del sistema en paquetes de R y pruebas automáticas](https://blog.r-hub.io/2023/09/26/system-dependency/).
+
 ### Travis CI (Linux y Mac OSX) {#travis-ci-linux-and-mac-osx}
 
 Recomendamos [dejar de utilizar Travis](https://ropensci.org/technotes/2020/11/19/moving-away-travis/).
diff --git a/softwarereview_author.Rmd b/softwarereview_author.Rmd
index f214865d5..a5a52483a 100644
--- a/softwarereview_author.Rmd
+++ b/softwarereview_author.Rmd
@@ -30,6 +30,7 @@ This concise guide presents the software peer review process for you as a packag
 - Read and follow [our packaging style guide](#building), [reviewer's guide](#preparereview) to ensure your package meets our style and quality criteria.
 - Feel free to ask any questions about the process, or your specific package, in our [Discussion Forum](https://discuss.ropensci.org).
 - All submissions are automatically checked by our [pkgcheck](https://docs.ropensci.org/pkgcheck/) system to ensure packages follow our guidelines. All authors are expected to have run [the main `pkgcheck` function](https://docs.ropensci.org/pkgcheck/reference/pkgcheck.html) locally to confirm that the package is ready to be submitted. Alternatively, an even easier way to ensure a package is ready for submission is to use [the `pkgcheck` GitHub Action](https://github.com/ropensci-review-tools/pkgcheck-action) to run `pkgcheck` as a GitHub Action, as described in [our blog post](https://ropensci.org/blog/2022/02/01/pkgcheck-action/).
+-   If your package requires unusual system dependencies (see [*Packaging Guide*](#pkgdependencies)) for our GitHub Action to pass, please submit a pull request adding them to [our base Dockerfile](https://github.com/ropensci-review-tools/pkgcheck/blob/main/Dockerfile).
 - If there are any aspects of `pkgcheck` which your package is unable to pass, please explain reasons in your submission template.
 - If you feel your package is in scope for the
   [Journal of Open-Source Software](https://joss.theoj.org/) (JOSS), do not submit it to JOSS consideration until after the rOpenSci review process is over: if your package is deemed in scope by JOSS editors, only the accompanying short paper would be reviewed, (not the software that will have been extended reviewed by rOpenSci by that time). Not all rOpenSci packages will meet the criteria for JOSS.
diff --git a/softwarereview_author.es.Rmd b/softwarereview_author.es.Rmd
index 43c596650..2efc48923 100644
--- a/softwarereview_author.es.Rmd
+++ b/softwarereview_author.es.Rmd
@@ -25,6 +25,7 @@ Esta guía condensa el proceso de revisión por pares desde el punto de vista de
 - Lee y sigue nuestra [guía de estilo para paquetes](#building) y nuestra [guía para la revisión](#preparereview) para asegurarte de que tu paquete cumple nuestros criterios de estilo y calidad.
 - No dudes en hacer cualquier pregunta sobre el proceso en general, o sobre tu paquete en particular en nuestro [foro de discusión](https://discuss.ropensci.org).
 - Todos los envíos son revisados automáticamente por nuestro [propio sistema](https://docs.ropensci.org/pkgcheck/) para garantizar que los paquetes sigan nuestras directrices. Se espera que hayas corrido [la función `pkgcheck`](https://docs.ropensci.org/pkgcheck/reference/pkgcheck.html) localmente para confirmar que el paquete está listo para ser enviado. Otra forma aún más fácil de asegurarse de que un paquete está listo para su envío es utilizar [la acción de GitHub `pkgcheck`](https://github.com/ropensci-review-tools/pkgcheck-action) para ejecutar `pkgcheck` como una Acción de GitHub, como se describe en [esta publicación en nuestro blog](https://ropensci.org/blog/2022/02/01/pkgcheck-action/).
+-   Si tu paquete requiere dependencias inusuales del sistema (ver [*Guía de Empaquetado*](#pkgdependencies) para que nuestra Acción de GitHub pase, por favor envíe un _pull request_ añadiéndolas a [nuestro _Dockerfile_ base](https://github.com/ropensci-review-tools/pkgcheck/blob/main/Dockerfile).
 - Si hay algún test de `pkgcheck` que tu paquete no pueda aprobar, explica los motivos en la plantilla de envío.
 - Si crees que tu paquete es relevante para el [Journal of Open Source Software](https://joss.theoj.org/) (JOSS), no lo sometas a consideración de JOSS hasta que haya finalizado el proceso de revisión de rOpenSci: si el equipo de edición de JOSS considera que tu paquete está dentro de su ámbito de aplicación, sólo se revisará el breve artículo que lo acompaña (pero no el software que habrá sido revisado por rOpenSci en ese momento). No todos los paquetes de rOpenSci pueden aplicar a JOSS.
 
diff --git a/softwarereview_editor.Rmd b/softwarereview_editor.Rmd
index 83c27785d..6d3f5f825 100644
--- a/softwarereview_editor.Rmd
+++ b/softwarereview_editor.Rmd
@@ -83,11 +83,13 @@ Your tools for searching reviewers in the Airtable are
 
 ![Screenshot of the Airtable filters interface with a filter on domain expertise that has to include chemistry and technical areas that have to include continuous integration](images/airtable.png)
 
-- creating a duplicated [view](https://support.airtable.com/hc/en-us/articles/202624989-Guide-to-views), depending on your Airtable skills.
+* creating a personal [view](https://support.airtable.com/hc/en-us/articles/202624989-Guide-to-views), depending on your Airtable skills.
 
 Have a look at the `last_time_contacted` and `last_answer` columns before contacting someone!
 If someone recently refused because they were busy, it might be best to abstain, whereas someone who refused because of a COI could be contacted again without waiting too long.
 
+Also, please check if a first-time reviewers have indicated that they `require_mentorship`.  If so, please use the mentorship portion of the email template and be prepared to provide additional guidance.
+
 ##### Storing information from the reviewer search in Airtable {#airtable-info}
 
 For people listed in the Airtable, if you contact them about a review please update the `last_time_contacted` column, and enter the category corresponding to their answer in `last_answer`.
diff --git a/softwarereview_editor.es.Rmd b/softwarereview_editor.es.Rmd
index 4fe2016db..0bbead79f 100644
--- a/softwarereview_editor.es.Rmd
+++ b/softwarereview_editor.es.Rmd
@@ -78,11 +78,13 @@ Tus herramientas para buscar personas para la revisión en *Airtable* son
 
 ![Captura de pantalla de la interfaz de filtros de Airtable con un filtro sobre conocimientos técnicos que tiene que incluir química y en áreas técnicas tienen que incluir integración continua (interfaz y etiquetas en inglés)](images/airtable.png)
 
-- crear una [visualización duplicada](https://support.airtable.com/hc/en-us/articles/202624989-Guide-to-views), dependiendo de tus conocimientos de Airtable.
+- crear una [visualización personalizada](https://support.airtable.com/hc/en-us/articles/202624989-Guide-to-views) dependiendo de tus habilidades en Airtable.
 
 Echa un vistazo a los campos `last_time_contacted` (último contacto) y `last_answer` (última respuesta) antes de ponerte en contacto con alguien.
 Si alguien se ha negado recientemente porque no tenía tiempo, podría ser mejor abstenerse, mientras que no hace falta esperar demasiado para volver a invitar a alguien que se negó debido a conflictos de interés.
 
+Además, comprueba si una persona que es nueva revisando ha indicado que `require_mentorship`.  En caso afirmativo, utiliza la parte de tutoría de la plantilla de correo electrónico y prepárate para proporcionar orientación adicional.
+
 ##### Almacenar la información de la búsqueda en Airtable  {#airtable-info}
 
 Si contactas a alguien desde Airtable, actualiza el campo `last_time_contacted` e introduce la categoría correspondiente a su respuesta en `last_answer`.
diff --git a/softwarereview_policies.Rmd b/softwarereview_policies.Rmd
index 211cce656..58e205852 100644
--- a/softwarereview_policies.Rmd
+++ b/softwarereview_policies.Rmd
@@ -78,7 +78,7 @@ Note that not all rOpenSci projects and packages are in-scope or go through peer
 
 - **citation management and bibliometrics**: Tools that facilitate managing references, such as for writing manuscripts, creating CVs or otherwise attributing scientific contributions, or accessing, manipulating or otherwise working with bibliometric data. (Example: [**RefManageR**](https://github.com/ropensci/software-review/issues/119))
 
-- **scientific software wrappers**: Packages that wrap non-R utility programs used for scientific research. These programs must be specific to research fields, not general computing utilities. Wrappers must be non-trivial, in that there must be significant added value above simple `system()` call or bindings, whether in parsing inputs and outputs, data handling, etc. Improved installation process, or extension of compatibility to more platforms, may constitute added value if installation is complex.  This does not include wrappers of other R packages or C/C++ libraries that can be included in R packages. We strongly encourage wrapping open-source and open-licensed utilities - exceptions will be evaluated case-by-case, considering whether open-source options exist. (Examples: [**babette**](https://github.com/ropensci/software-review/issues/208), [**nlrx**](https://github.com/ropensci/software-review/issues/262))
+- **scientific software wrappers**: Packages that wrap non-R utility programs used for scientific research. These programs must be specific to research fields, not general computing utilities. Wrappers must be non-trivial, in that there must be significant added value above simple `system()` calls or bindings, whether in parsing inputs and outputs, data handling, etc. Improved installation process, or extension of compatibility to more platforms, may constitute added value if installation is complex.  This does not include wrappers of other R packages or C/C++ libraries that can be included in R packages.  It also does not include packages that are clients for web APIs, which must fall into one of the other categories. We strongly encourage wrapping open-source and open-licensed utilities - exceptions will be evaluated case-by-case, considering whether open-source options exist. (Examples: [**babette**](https://github.com/ropensci/software-review/issues/208), [**nlrx**](https://github.com/ropensci/software-review/issues/262))
 
 - **field and laboratory reproducibility tools**: Packages that improve reproducibility of real-world workflows through standardization and automation of field and lab protocols, such as sample tracking and tagging, form and data sheet generation, interfacing with laboratory equipment or information systems, and executing experimental designs. (Example: [**baRcodeR**](https://github.com/ropensci/software-review/issues/336))
 
@@ -88,7 +88,7 @@ In addition, we have some *specialty topics* with a slightly broader scope.
 
 - **geospatial data**: We accept packages focused on accessing geospatial data, manipulating geospatial data, and converting between geospatial data formats. (Examples: [**osmplotr**](https://github.com/ropensci/software-review/issues/27), [**tidync**](https://github.com/ropensci/software-review/issues/174)).
 
-- **text data**: We include packages that process and manage text and language data. This is limited to text processing/munging/management (e.g., tokenization, stemming, conversion to and between structured text formats, text metadata and repository access, etc. ).  Machine-learning and packages implementing NLP analysis algorithms should be submitted under [*statistical* software peer review](https://stats-devguide.ropensci.org/). The scope for this topic is not fully defined, please open a pre-submission inquiry if you are considering submitting a package that falls under this topic. (Example: [**tokenizers**](https://github.com/ropensci/software-review/issues/33))
+- **translation**:  As part of our work in [multilingual publishing](https://ropensci.org/multilingual-publishing/), we have a special interest in packages that facilitate the translation and publication of scientific and programming resources into multiple (human) languages so they are accessible to larger and more diverse audiences. These could include interfaces to automated translation programs, frameworks for managing documentation in multiple languages, or programs accessing specialized linguistic resources.  This is a new and experimental scope, so please open a [pre-submission inquiry](https://github.com/ropensci/software-review/issues/new/choose) if you are interested in submitting a package in this category.
 
 ### Other scope considerations {#other-scope-considerations}
 
diff --git a/softwarereview_policies.es.Rmd b/softwarereview_policies.es.Rmd
index aff13ebd6..88f34412b 100644
--- a/softwarereview_policies.es.Rmd
+++ b/softwarereview_policies.es.Rmd
@@ -116,6 +116,7 @@ Busca la etiqueta de revisión por pares (ver más abajo) para identificar los p
   Las capas deben ser no triviales, en el sentido de que debe haber un valor añadido significativo por encima del uso de `system()` o de vincular el programa, ya sea en darle formato a las entradas entradas y salidas, en el manejo de datos, etc.
   La mejora del proceso de instalación, o la ampliación de la compatibilidad a más plataformas, puede constituir un valor añadido si la instalación es compleja.
   Esto no incluye las capas de interfaz de otros paquetes de R o bibliotecas de C/C++ que puedan incluirse en los paquetes de R.
+    Tampoco se incluyen los paquetes que son clientes de API web, que deben pertenecer a una de las otras categorías.
   Animamos encarecidamente crear capas de interfaz a utilidades de código abierto y de licencia abierta; las excepciones se evaluarán caso por caso, teniendo en cuenta si existen opciones de código abierto.
   (Ejemplos: [**babette**](https://github.com/ropensci/software-review/issues/208), [**nlrx**](https://github.com/ropensci/software-review/issues/262))
 
@@ -130,11 +131,7 @@ Además, tenemos algunos *temas especializados* con un alcance algo más amplio.
 - **datos geoespaciales**: Aceptamos paquetes centrados en el acceso, manipulación y conversión entre formatos de datos geoespaciales.
   (Ejemplos: [**osmplotr**](https://github.com/ropensci/software-review/issues/27), [**tidync**](https://github.com/ropensci/software-review/issues/174)).
 
-- **datos de texto**: Incluimos paquetes que procesan y manejan datos de texto y de lenguaje.
-  Esto se limita al procesamiento, manipulación y/o gestión de textos (por ejemplo, tokenización, origen, conversión a y entre formatos de texto estructurados, metadatos de texto y acceso a repositorios, etc. ).
-  El aprendizaje automático y los paquetes que implementan algoritmos de análisis de Procesamiento del Lenguaje Natural deben presentarse bajo la [revisión por pares de software *estadístico*](https://stats-devguide.ropensci.org/).
-  El alcance de este tema no está totalmente definido, por lo que te rogamos que abras una consulta previa a la presentación si estás pensando en presentar un paquete que entre dentro de este tema.
-  (Ejemplo: [**tokenizers**](https://github.com/ropensci/software-review/issues/33))
+- **traducción**: Como parte de nuestro trabajo en [publicación multilingüe](https://ropensci.org/multilingual-publishing/) tenemos especial interés en paquetes que faciliten la traducción y publicación de recursos científicos y de programación a múltiples lenguages (humanos) para que sean accesibles a públicos más amplios y diversos. Podría tratarse de interfaces para programas de traducción automática, infraestructura para gestionar la documentación en varios lenguages o programas que accedan a recursos lingüísticos especializados.  Se trata de un ámbito nuevo y experimental, por lo que te rogamos que abras un [issue para preguntar si el software está dentro del alcance de rOpenSci](https://github.com/ropensci/software-review/issues/new/choose) si te interesa presentar un paquete en esta categoría.
 
 ### Otras consideraciones sobre el ámbito de aplicación {#other-scope-considerations}
 
diff --git a/templates/request.es.md b/templates/request.es.md
index d2450b2f9..2e4f73786 100644
--- a/templates/request.es.md
+++ b/templates/request.es.md
@@ -13,7 +13,11 @@ Nuestro objetivo es que las revisiones sean abiertas, no conflictivas y centrada
 ¡Sé amable!
 Consulta nuestra guía de revisión y el [código de conducta](https://ropensci.org/code-of-conduct/) para más información.
 
-¿Puedes revisar? Si no puedes, siempre nos sirve si puedes sugerir personas alternativas. Si no tengo noticias tuyas en el plazo de una semana, supondré que no puedes hacer una revisión en este momento.
+[SI SE SOLICITÓ TUTORÍA: Has indicado en tu formulario que te gustaría tener tutoría para tu primera revisión.  
+Sientete libre de contactarme cuando lo necesites durante este proceso, lo que incluye hacer preguntas por correo electrónico y Slack (recibirás una invitación al Slack de rOpenSci), y compartir borradores de revisiones para recibir devoluciones antes de publicarlas. 
+También me encantará hacer una breve videollamada para explicar el proceso. Por favor, házmelo saber en tu respuesta si quieres programar una.]
+
+¿Puedes revisar? Si no puedes, siempre nos sirve si puedes sugerir a otras personas. Si no tengo noticias tuyas en el plazo de una semana, supondré que no puedes hacer una revisión en este momento.
 
 Gracias por tu tiempo.
 
diff --git a/templates/request.md b/templates/request.md
index bdc50f863..d20944781 100644
--- a/templates/request.md
+++ b/templates/request.md
@@ -13,6 +13,11 @@ We aim for reviews to be open, non-adversarial, and focused on improving softwar
 Be respectful and kind! 
 See our reviewers guide and [code of conduct](https://ropensci.org/code-of-conduct/) for more.
 
+[IF MENTORSHIP REQUESTED: You indicated in your form that you'd prefer mentorship for your first review.  
+You are free to use me as a resource during this process, including asking questions by email and Slack (you will receive an invite to the rOpenSci Slack), and sharing draft reviews for feedback before posting. 
+I'm also happy to have a brief videocall to walk through the process.  
+Please let me know in your reply if you would like to schedule one.]
+
 Are you able to review? If you can not, suggestions for alternate reviewers are always helpful. If I don't hear from you within a week, I will assume you are unable to
 review at this time.
 
diff --git a/templates/reviewer-approval.pt.md b/templates/reviewer-approval.pt.md
new file mode 100644
index 000000000..174f2f43d
--- /dev/null
+++ b/templates/reviewer-approval.pt.md
@@ -0,0 +1,11 @@
+
+## Resposta do(a) revisor(a)
+
+#### Aprovação final (pós-revisão)
+
+- [ ] **O(a) autor(a) respondeu à minha revisão e realizou as mudanças requisitadas. Eu recomendo a aprovação deste pacote.**
+
+
+<!--Por favor, preencha a estimativa abaixo.-->
+Estimativa de horas dedicadas à revisão:
+
diff --git a/thanks.md b/thanks.md
index 957cc8406..de50a30a9 100644
--- a/thanks.md
+++ b/thanks.md
@@ -2,4 +2,5 @@
 [Hao Ye](https://github.com/ha0ye),
 [Sébastien Rochette](https://github.com/statnmap),
 [Edward Wallace](https://github.com/ewallace/),
-[Alexander Fischer](https://github.com/s3alfisc/).
+[Alexander Fischer](https://github.com/s3alfisc/),
+[Maxime Jaunatre](https://github.com/gowachin).