Le dimanche 26 mars 2017, 15:56:55 CEST Junio C Hamano a écrit : > Jean-Noël AVILA <jn.avila@xxxxxxx> writes: > > ... So I would > > think the other way around: for those interested in translated the > > documentation, some script would allow to checkout the git project inside > > the gitman-l10n project (like a kind of library). > > > > This would be mainly transparent for the git developers. > > As long as the resulting layout would help all groups (1) developers > who do not worry about documentation l10n (2) documentation i18n > coordinator and transltors (3) those who build and ship binary > packages, I personally am OK either way. > > Having said that, I am not sure if I understand your "translators do > not have a fixed version of git.git to work with and po4a cannot > work well" as a real concern. Wouldn't the l10n of documentation > use a similar workflow as used for the translation of in-code > strings we do in po/? Namely, *.pot files are *NOT* updated by > individual translators by picking up a random version of git.git and > running xgettext. Instead, i18n coordinator is the only person who > runs xgettext to update *.pot for the upcoming release of Git being > prepared, and then translators work off of that *.pot file. Which > means they do not have to worry about in-code strings that gets > updated in the meantime; instead they work on a stable known > snapshot of *.pot and wait for the next sync with i18n coordinator > whose running of xgettext would update *.pot files with updated > in-code strings. Doesn't that workflow apply equally well for the > documentation l10n? Theoretically, this workflow should apply to the documentation, so that a version of the documentation can be cut at each release of git. I still have to convince po4a not to update the *.pot and *.po files each time it is run, while at the same time allow translators to produce the output file for proofreading.