Add "[skip ci]" to MantisBT commit messages

You could also reschedule the pushes to GitHub to occur less often (I.e. give a few days of delay, a time usually needed for reviewing messages and fixing some typos).

You may as well create a separate temporary import branch in GitHub for making this review yourseld and allow fixing them in Translatewiki. Once the basic quality test passes, you can import them from the temporary branch into the main branch for integration and complete tests by just creating a patch directly inside GitHub. As well you can schedule languages from the temporary branch to your main development branch.

Finally if there are new messages in TWN that concerns only a separate branch of MantisBT which is still in development and testing, you may not need all languages at once, but a few needed for your development tests. Identifying messages needed for a beta branch may also be documented in /qqq doc pages. As well you may need to keep a separate import for messages needed for older branches that are still supported (and this can also be documented in /qqq pages).

But in my opinion, TWN should allow messages to be marked with tags identifying versions or branches for which they are needed (this is already a problem as well for Mediawiki messages, whose cleanup requires lot of searches and is for now very complex, so we have now lot of messages in TWN that are no longer relevant for a supported version)

This also requires defining a naming sheme for message identifiers, and make sure that messages that are modified in one version to another remain compatible (notably when there are placeholder variables, and you change the set of variables or sometimes their order, or their meaning or possible values, you need a new distinct message ID to be translated separately: one message will be for one older branch, another for the newer branch, and you need to find a way to manage these version-dependent or branch-dependent message IDs).

Some projects in TWN use an "opaque" MD5 or SHA checksum of the text in the source message but this does not allow tracking versions/branches easily, unless you maintain a database for message signatures needed for each supported version or branch (including those in older releases for longer-term support).

Thanks for your suggestions, but the fact remains that whenever a commit is pushed to Github (even if it's less frequent), an unnecessary build is triggered.

Moreover, we only get translation updates for our master branch, and we don't (need to) validate/review translations so the other comments are not relevant for us.

You need some review: translations may not be compatible if there are missing variables or incorrect formats causing unexpected "breakages" within some UI language. Normally TWN attemtps to make most of the format validation. But still if you've got multiple stable releases maintained, they will need translations (or corrections) in parallel branches, with separate messages (if their format is not compatible, such as changes in placeholder variables or changes in format, such as addition/removal of HTML tags, or addition of support for more plural forms).

But if importing messages in your GitHub project causes a complete rebuild, may be you should split your project by putting translated messages in a separate subproject, where the main project would not depend on it, except when running a script to build a full installation for a release from the core subproject and the i18n subproject.

The core project would then just need the base English messages and no other messages, or just a subset of translations for specific messages and specific languages (such as Arabic or Hebrew to test the Bidi layout, or Pseudo-Arabic actually in English where capital Latin letters are treated as RTL, and lowercase are in normal English, like in examples used for the CLDR documentation and tests)

Building the whole application package with all i18n can then be scheduled at a lower rate (only manually). i18n message can be updated frequently (without causing unnecessary rebuilds of the core project or the complete app apackage, and you also no longer have a limit on the rate of edits for the core project in English.

As well you should verify your "makefiles" (or building rules): it probably has incorrect dependencies not correctly tuned, so that any change anywhere (not just in 18n messages) causes the complete rebuild. And 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.

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).