Big picture workflow - Githubissues

(@MichaelChirico these are the notes I made from our conversation, updated based on my experience with the PRs)

A few scenarios to consider:

Big package with large community (e.g. data.table, tidyverse): few developers, many translators.
Bilingual author who wants to provide messages in English + their native language (e.g. metR): developer = translator
One really passionate user or a language community who contributes to many packages.

Basic workflow

Initial translation:

Updates:

Add tr_() and tr_n() functions.
- Should also have untr_() or similar to declare that you have reviewed a message and have decided not to translate it?
Do whatever is needed on the C side
Run po_report() and pick a function to translate. Repeat.
- This would look at all common messaging functions (cat()/message()/warning()/stop() and rlang equivalents) and check that the first argument is a call to tr_() or tr_n().
Use po_scan() to scan R/ and src/ to generate .pot files

Run po_create("fr")
- Should we track GitHub user name of contributors? Would be nice to be able to ping folks when translations need updating.
Fill in translations
Run po_compile() to build .mo file
- Probably best done with CI --- probably in the pull request or on merge to main. Or maybe because it's a binary, maybe do it on release? (e.g. is \~ 1 meg for data.table). If on release, what's the workflow for prototyping.
- Would be nice to be able to dynamically get just the translations you need.

Use po_report() to make sure all messages have translations, and all languages have translations for message.
- use_release_issue() should add to bullets if po directory exists.
As needed, ping translators to request updates
po_compile() to make sure all up to date