| 2 | ''Transifex is a modern, open-source localization platform. It’s a web system which automates the translation workflow for complex international projects.'' |
| 3 | |
| 4 | Transifex is indeed a nice tool and can be seen as much more attractive for potential translation contributors than having to go through the somewhat complex procedure described in the [[TracL10N]] page, involving svn, Babel, make, etc. |
| 5 | |
| 6 | **However...** |
| 7 | |
| 8 | Things are not so simple, or rather, we should take an extra step to make it really as simple as it looks. |
| 9 | |
| 10 | The problem is that we might have **two** sources of changes, and it will make no good to anyone if the two sources are not in sync: |
| 11 | - a Transifex translator might work on an out-of-date catalog, redoing the work the translator coordinator committed directly in the catalog file in the repository |
| 12 | - worse, pulling updates from Transifex and blindly committing them could lead to regressions |
| 13 | - conversely, a translator coordinator could easily miss the changes done by another translator on Transifex |
| 14 | - here as well there's a risk for him to overwrite changes made by Transifex contributors if he pushes changes carelessly |
| 15 | |
| 16 | In the following, we'll try to present a workflow which avoids those pitfalls and enable changes to flow in both directions. |
| 17 | |
9 | | Once you're familiar with Transifex (they have some very good [http://help.transifex.com/ documentation] on their site), you can apply for membership to one translation team for a language, or create a new team if your language of choice isn't yet represented there (be aware that undertaking a new translation for Trac represents a //lot// of work). |
10 | | |
11 | | Updating translations there is only one part of the story, since you need to get your changes integrated into the source code. For that, you need to inform the translator coordinator for your language (see [..#Translationcoordination tickets for translation coordination]). She will pull the changes from Transifex using the procedure described below, verify them, and commit them. If the translator coordinator doesn't react in due time or is not active anymore, an member of the Trac team will likely notice the activity on the ticket and he could do the same but without the language verification step, obviously. |
12 | | |
13 | | It's even a better idea to contact and discuss with the translator coordinator **before** updating the catalogs on Transifex, as some might not be up to date, and you will risk to duplicate work and make integration harder. |
14 | | |
15 | | == Pulling changes from Transifex |
16 | | |
17 | | You want to update the Trac source code with the latest changes from Transifex, for one or more languages. Typically you'd do this for approving and committing these changes if you're a translation coordinator, or because you want to prepare a patch for submitting those changes for review on a ticket. |
| 25 | == Roles |
| 26 | |
| 27 | Once you're familiar with Transifex (and they have some very good [http://help.transifex.com/ documentation] on their site), you can apply for membership to one translation team for a language, or create a new team if your language of choice isn't yet represented there (be aware that undertaking a new translation for Trac represents a //lot// of work). |
| 28 | |
| 29 | === Translation team coordinator |
| 30 | |
| 31 | It's much better if the translation team coordinator on Transifex is also the committer responsible for that language in the Trac project itself. |
| 32 | |
| 33 | As a committer, he's ultimately in charge of the synchronization work, pulling changes made by members of the translation team on Transifex and pushing back changes made directly to the repository. |
| 34 | |
| 35 | === Translation team member |
| 36 | |
| 37 | Updating translations on Transifex is only one part of the story, since you need to get your changes integrated into the source code. For that, you need to inform the translator coordinator for your language (see [..#Translationcoordination tickets for translation coordination]). She will pull the changes from Transifex using the procedure described below, verify them, and commit them. If the translator coordinator doesn't react in due time or is not active anymore, a member of the Trac team will likely notice the activity on the ticket and he could do the same but without the language verification step, obviously. |
| 38 | |
| 39 | It's even a better idea to contact and discuss with the translator coordinator **before** updating the catalogs on Transifex, as some might not be up to date, and you will risk to duplicate work and make integration harder. Transifex provides all the facilities for smooth communications between team members. There's also the tickets, or plain e-mail on trac-dev@googlegroups.com or directly to the translators. |
| 40 | |
| 41 | |
| 42 | == Synchronization with Transifex |
| 43 | |
| 44 | As discussed above, this is normally the responsibility of the translation team coordinator who has the commit permissions on the catalog files in the Trac subversion repository. |
| 45 | |
| 46 | Typically you'd do this for approving and committing changes if you're a translation coordinator, but even if you're not a committer you could do this if you want to prepare a patch for submitting those changes for review on a ticket. |
| 47 | |
27 | | (or one [http://help.transifex.com/features/client/index.html#getting-the-client variation of the above]) |
28 | | |
29 | | Of course, you also need to have a [TracRepositories checkout of the source], of the branch where you want to work. [source:branches//0.12-stable] will be maintained for the foreseeable future, so you may want to start contributing there, but [source:branches//1.0-stable] is now the official stable release branch, so don't neglect it. [source:trunk] is where the new interesting stuff happen (TracDev/Proposals/ConfigEnumTranslation?). |
| 57 | (or one [http://help.transifex.com/features/client/index.html#getting-the-client variation of the above]). |
| 58 | |
| 59 | If you're on Windows, you'll also need a [https://github.com/cboos/transifex-client/tree/0.8/tx-config-posix-paths-on-windows hack]... |
| 60 | |
| 61 | Of course, you also need to have a [TracRepositories checkout of the source], of the branch where you want to work. [source:branches//0.12-stable] will be maintained for the foreseeable future, so you may want to continue contributing there, but [source:branches//1.0-stable] is now the official stable release branch, so don't neglect it. [source:trunk] is where the new interesting stuff happen (TracDev/Proposals/ConfigEnumTranslation?). |
| 121 | |
| 122 | A very important preparation task that must be done before pulling is to make sure the .po file was updated. Even if you think it must be because there are no local changes, it's a good idea to `make update-..` (`fr` in this example). Perhaps the Babel version you're using at the moment is different from the one which was used before the last version was committed, or a manual change was done at the last minute, etc. |
| 123 | |
| 124 | Doing a catalog update ensures that we have a "normalized" content to compare with the version of the catalog pulled from Transifex, after the latter has been "normalized" as well by another Babel update, as the automatic formatting done by Transifex is completely different. |
| 125 | |
| 126 | Make sure to "freeze" that updated Trac version, by making a commit in a local branch (if you use git or hg) or even a "maintenance" commit in Subversion. |
| 127 | |
| 128 | |
| 129 | === Pulling the French catalogs from Transifex #pull-example |
| 130 | |
224 | | After the commit, if you did any local adaptations like the removal of the spurious metadata changes, you can also push those changes back to Transifex the same way, as Transifex **won't** pick up the changes made to the translated catalogs from the repository (it will do that for the catalog templates though, so the latter are always up-to-date). |
| 269 | After committing changes to the message catalog, it's a good idea to push those changes to Transifex so that other contributors can see these changes. |
| 270 | |
| 271 | Even if you just pulled changes from Transifex (coming from the other example above), you most certainly did local adaptations like the removal of the spurious metadata changes, or small fixes, then you should also push those changes back to Transifex the same way, as Transifex **won't** pick up the changes made to the translated catalogs from the repository (it will do that for the catalog templates though, so the latter are always up-to-date). |
| 272 | |
| 273 | But if you didn't do a pull just before, doing a pull //might// overwrite changes contributed to Transifex, so you should be careful. The safest thing to do is to simply do an update first, normalize the changes by running `make update-..`, compare, and //only then//, if there are no changes but spurious ones in the metadata in the comments in the header, do the push. |