potools::translate_package(languages = "sv") with existing "custom_translation_functions"?

[HenrikBengtsson]

Background

After creating the main po/R-<pkg>.pot file for a package using custom translation functions;

potools::translate_package(custom_translation_functions = list(R = c("stopf:fmt|1", "warnf:fmt|1"))

I was "surprised" that:

potools::translate_package(languages = "sv")

replaced my existing po/R-<pkg>.pot file.

It looks like one would have to specify custom_translation_functions also for translations:

potools::translate_package(languages = "sv", custom_translation_functions = list(R = c("stopf:fmt|1", "warnf:fmt|1"))

Wish

Could potools::translate_package() with argument languages specified use po/R-<pkg>.pot to decide which messages to translate, instead of, what I think happens right now, parse the code again to identify what needs to be translated?

This would avoid having to provide specific custom_translation_functions instructions on how to translate one's package.

[hadley]

See my workflow proposal in #242; I think translate_package() currently tries to do too much. I have implemented po_compile() (.po -> .mo) in #234, and po_create()/po_update() (.pot -> .po) in #235.

I don't want to put words in @MichaelChirico, but I had a video chat with him, and I think we're basically aligned on what needs to happen, it's just a matter of everyone finding the time.

[MichaelChirico]

translate_package() may survive as a one-stop-shop, but absolutely agree the process needs to be more modular to allow more custom workflows/more general use cases.