Add "[skip ci]" to MantisBT commit messages

I don't understand where you're coming from. MantisBT translations have been managed like this, without any issues, for at least as long as I've been part of the project (i.e. since 2010), so I see absolutely no reason to change our workflow.

As for

I don't see how adding a "[skip ci]" tag on TWN would avoid rebuilding the whole project in the main bracnh on GitHub after each message import.

This is just how TravisCI works; if this string is present in the HEAD commit's message, then the build is not triggered. See https://docs.travis-ci.com/user/customizing-the-build/#skipping-a-build

Also, to clarify, the TravisCI "build" process I'm talking about just runs our PHPUnit tests, it does not actually "build" anything.

Yes but this filter only appliues to commits in the "HEAD" branch in GitHub.

You are not required to import every incoming translations from TWN directly to the HEAD: there can be intermediate branches, and the final commit of these intermediate/progressive branches (which could include many minor updates, rapid reverts, typo fixes, and in many languages...) to the HEAD can then be delayed (e.g. once a week, if they pass the minimal test of format). These weekly integration of these branches to the HEAD won't even need that filter in that case.

I think it is a bad idea to apply imports applied by automated import bots directly into the HEAD of any Git project, when these translations were not made by developers but by translators that may not be aware of all possible problems (that may still need to be fixed, and possibly better documented in "/qqq" message subpages in TWN, so that these bugs won't be repeated). Remember that TWN will not necessarily detect all problems, your TWN import tools should problably perform additional validation, and this is easier to do in a separate branch, instead of just the HEAD used for all the rest of the development of supported versions.

I really appreciate the time you are spending to offer advice, but as mentioned before, we are not going to change our process for the time being. We like to have translations committed automatically to master, we are aware of the risks, and we accept them.

Note that pushing l10n changes to a separate branch is not going to solve my original problem, which is the unnecessary waste of TravisCI credits, since the builds would be triggered just the same as if they were committed to master.

So, can you, or can you not, add **[skip ci]** to the TWN commit messages ?

Commits on TWN do not add any tags. It's up to the tool used to importing these translations into your GitHub project to request the export of data from TWN, format the file as needed, and upload the update to GitHub, using any convenient message in the import commit made **in GitHub** by the user controling that import and using his own account credentials for Git (or for any other external repository). User account and their rights are distinct, managed in separate realms (anyone can instantly read and export data at any time from TWN, but specific user accounts with appropriate rights are needed to import into your development repository).

Note that I do not reject or oppose your demand. This is just a suggestion that you can still use an an alternate solution, which would then not depend on changes to be made on this wiki by its local admins or developers, and that your project can manage itself (this wiki cannot manage usages made on external sites like GitHub, where translated messages will be uploaded and integrated at their own rate and in their own development and support branches).