Jiang Xin <worldhello.net@xxxxxxxxx> writes: > From: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> > > 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.
