Paul W. Frields wrote:
Just to be clear here, I agree 100%. But in the same way, without
tighter process on translation notices I would be more worried that a
maintainer would *inadvertently* leave someone out, which creates a
bad situation without anyone meaning harm.
Absolutely! So what's required
here is that before creating a new
version of a book, the maintainer must review the git log for new
translations committed since the last version was published and credit
any new translators. The same would apply whenever we refresh POT files.
Translators can help out by sending an email to the maintainer or to
docs-list if they notice that we've missed anyone (exactly like Domingo
did recently). In this particular case, I was already aware of the new
Spanish translators who were to be added (along with new translators in
other languages and some changes in the book text itself) to the next
refresh of the POT files. It certainly didn't hurt to be reminded though.
By the very nature of our docs/l10n process, it's unavoidable that new
translators who assisted with *this* version (or build) of a document
won't receive credit in the text until the *next* version (or build).
Maintainers are free to
help with the maintenance of a colophon but we should always seek to
make the load spreadable. That's what it means to be scalable! ;-)
To achieve full scalability on this, translators would need to have the
ability to commit changes to the English XML files that make up the
document; whether the Contributors section was a single XML file or a
separate XML file per language. Failing that, they're still relying on a
docs maintainer as the "middle man".
Perhaps Transifex's file filter can be set so that it allows translators
access to the Contributors XML file(s) in the master branch of the
document (as well as the PO files)?
Cheers
Ruediger