Jiang Xin [off-list ref] writes:

From: Ævar Arnfjörð Bjarmason <redacted>

Before commit fc0fd5b23b (Makefile: help gettext tools to cope with our
custom PRItime format, 2017-07-20) we'd consider source files as-is

", we'd consider".

with gettext, but because we need to understand PRItime in the same way
that gettext itself understands PRIuMAX we'd first check if we had a

"PRIuMAX, we'd first"

clean checkout, then munge all of the processed files in-place with
"sed", generate "po/git.pot", and then finally "reset --hard" to undo
our changes.

By generating "pot" snippets in ".build/pot/po" for each source file
and rewriting certain source files with PRItime macros to temporary
files in ".build/pot/po", we can avoid running "make pot" by altering
files in place and doing a "reset --hard" afterwards.

Good.

This speed of "make pot" is slower than before on an initial run,
because we run "xgettext" many times (once per source file), but it
can be boosted by parallelization. It is *much* faster for incremental
runs, and will allow us to implement related targets in subsequent
commits.

This is to show my ignorance, but is there any downside, other than
increased overhead coming from runing many instances of the program,
in the "one file at a time" approach?  I was wondering if two or
more identical translatable strings appear in multiple source files,
where they are coalesced into a single entry in the resulting .pot
file, and if xgettext having visibility into all these files would
somehow help the process, but presumably we'd use msgcat to unify
them into one entry so there wouldn't be such a downside there.  But
are there others?

Thanks.