| 14 | | 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. |
| 15 | | |
| 16 | | |
| 17 | | |
| 18 | | **However...** |
| 19 | | |
| 20 | | Things are not so simple, or rather, we should take an extra step to make it really as simple as it looks. |
| 21 | | |
| 22 | | 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: |
| | 13 | The key is to keep all sources in sync, if there is more than one: |
| 240 | | - for [#group2] there's nothing to do (besides "normal" maintenance, of course), as long as there's no activity on Transifex |
| 241 | | - for [#group3], the translation team coordinators are invited to ask for commit privileges (and integrate [#group1]) |
| 242 | | - for [#group4] the translations will be "promoted" to [#group3] (i.e. integrated in the repository) as soon as a decent coverage is reached (say > 50%) |
| | 225 | - for [#group2], there is only "normal" maintenance to do |
| | 226 | - for [#group3], the translation team coordinators are invited to ask for commit privileges and integrate [#group1] |
| | 227 | - for [#group4] the translations will be "promoted" to [#group3], ie integrated in the repository, as soon as a decent coverage is reached (say > 50%) |
| 250 | | 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. |
| 251 | | |
| 252 | | 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. |
| 253 | | |
| | 235 | 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]. The translator coordinator 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. |
| | 236 | |
| | 237 | 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 duplicating work and making integration harder. Transifex provides all the facilities for communication between team members. There are also the tickets, or plain e-mail on trac-dev@googlegroups.com or directly to the translators. |
| 270 | | (or one [http://help.transifex.com/features/client/index.html#getting-the-client variation of the above]). |
| 271 | | |
| 272 | | 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]... |
| 273 | | |
| 274 | | 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?). |
| 275 | | |
| 276 | | |
| 277 | | Now let's go through a complete example. I made one update to the resource corresponding to the messages catalog on 0.12 for the [Transifex:language/fr/ French translation] (more specifically, on that page: Transifex:resource/0_12-stable-messages-pot/l/fr/). |
| | 251 | or a [http://help.transifex.com/features/client/index.html#getting-the-client variation of the above]. |
| | 252 | |
| | 253 | 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]. |
| | 254 | |
| | 255 | Of course, you also need to have a [TracRepositories checkout of the source] of the branch you want to work on. [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. [source:trunk] is where the new interesting stuff happen (TracDev/Proposals/ConfigEnumTranslation?). |
| | 256 | |
| | 257 | Now let's go through a complete example, starting from one update to the resource corresponding to the messages catalog on 0.12 for the [Transifex:language/fr/ French translation], more specifically, on that page: Transifex:resource/0_12-stable-messages-pot/l/fr/. |
| 281 | | As I tried to emphasize in the previous sections, what is really important is to not **lose** translations, in one direction or the other. Well, at least on the Trac side we have version control, which doesn't seem to be the case on the Transifex side... |
| 282 | | |
| 283 | | Back to the command line, for checking the status. |
| 284 | | First thing to do is to verify that everything is correctly configured: |
| | 261 | The key is to not **lose** translations, in one direction or the other. Unlike Trac, Transifex does not support version control. |
| | 262 | |
| | 263 | In the command line, verify that everything is correctly configured: |
| 341 | | |
| 342 | | === Pulling the French catalogs from Transifex #pull-example |
| 343 | | |
| 344 | | Now, before pulling changes from Transifex, **make sure you have no local modifications to the catalogs you're about to update**. Otherwise, those local modifications will be lost (well, on Windows at least; seems that on Linux it manages to make better checks with the timestamps between the local file and the file on the server). |
| | 319 | === Pulling the catalogs from Transifex #pull-example |
| | 320 | |
| | 321 | Now, before pulling changes from Transifex, **make sure you have no local modifications to the catalogs you're about to update**. Otherwise, those local modifications will be lost, on Windows at least; seems that on Linux it manages to make better checks with the timestamps between the local file and the file on the server. |
| 468 | | Note that you can also do `make diff` for a more up-to-the-point output (`make diff vc=git` if you're working in a git checkout). |
| 469 | | |
| 470 | | ==== Do something with those changes... |
| 471 | | |
| 472 | | ... do whatever you wish, for example commit the changes to the source with an appropriate log message, **but**, please!, before that: |
| 473 | | - remember to check your catalog with `make check` (here, `make check-fr`) |
| 474 | | - remember to check your catalog by compiling it (here, `make compile-fr`) |
| 475 | | |
| 476 | | Once you're done, make sure you **push back** the changes to Transifex. |
| 477 | | See the other example below. |
| 478 | | |
| 479 | | === Pushing local modifications of the French catalogs to Transifex #push-example |
| | 444 | Note that you can also do `make diff` for a more up-to-the-point output: `make diff vc=git` if you're working in a git checkout. |
| | 445 | |
| | 446 | ==== Do something with those changes |
| | 447 | |
| | 448 | You can do whatever you wish, for example commit the changes to the source with an appropriate log message, **but**, please!, before that: |
| | 449 | - remember to check your catalog with `make check`, here: `make check-fr` |
| | 450 | - remember to check your catalog by compiling it, here: `make compile-fr` |
| | 451 | |
| | 452 | Once you're done, make sure you **push back** the changes to Transifex. See the other example below. |
| | 453 | |
| | 454 | === Pushing local modifications of the catalogs to Transifex #push-example |
| 483 | | 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). |
| | 458 | 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. |
| 527 | | Transifex is not exactly clear if a release should be a line of development (branch) or a given released version. It supports both and let you choose to organize you the way wish. |
| 528 | | |
| 529 | | I opted to make the "releases" match our maintenance branches, and not individual releases (well, we still have a [Transifex:r/012-stable-3/ few of these], as apparently you can't delete a release). |
| 530 | | |
| 531 | | The downside is that string freeze periods and release dates will need to be adjusted constantly on the same release. The alternative, creating a new "release" for each actual version we release bears as much overhead (more even, are there's no //copy// operation) and doesn't bring any benefit besides keeping a record of the versions we made, record that we obviously maintain here anyway in the [/roadmap]. |
| 532 | | |
| 533 | | OTOH, the big benefit is that all the links from t.e.o to Tx won't need to be updated after each minor release. The only updates needed will be at the occasion of introducing a new major release (i.e. for 1.2). |
| | 502 | |
| | 503 | Transifex is not exactly clear if a release should be a line of development (branch) or a given released version. It supports both and let you choose to organize the way you wish. |
| | 504 | |
| | 505 | I opted to make the "releases" match our maintenance branches, and not individual releases; well, we still have a [Transifex:r/012-stable-3/ few of these], as apparently you can't delete a release. |
| | 506 | |
| | 507 | The downside is that string freeze periods and release dates will need to be adjusted constantly on the same release. The alternative, creating a new "release" for each actual version we release bears as much overhead (moreover, are there's no //copy// operation) and doesn't bring any benefit besides keeping a record of the versions we made, record that we obviously maintain here anyway in the [/roadmap]. |
| | 508 | |
| | 509 | On the other hand, the big benefit is that all the links from t.e.o to Tx won't need to be updated after each minor release. The only updates needed will be when introducing a new major release (i.e. for 1.2). |
