Jean-Noël AVILA <jn.av...@free.fr> 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?
