|
1 | 1 | # reactifex |
2 | 2 |
|
| 3 | +Helper utility designed to make it easy to upload react-intl extracted messages to transifex, with support for ICU plurals and translator comments. |
| 4 | + |
3 | 5 | [](reactifex) |
4 | 6 | [](reactifex) |
5 | 7 | [](reactifex) |
6 | 8 | [](https://travis-ci.org/efischer19/reactifex) |
7 | 9 |
|
8 | | -Helper utility designed to make it easy to upload react-intl extracted messages to transifex, with support for ICU plurals and translator comments. |
| 10 | + |
| 11 | +There are two modes of usage - compilation and comment pushing. |
| 12 | + |
| 13 | +## Compilation mode |
| 14 | + |
| 15 | +In this mode, messages that have been extracted by `babel-plugin-react-intl` (into individual files) are combined. The resulting json is suitable to upload to Transifex and matches their specified `KEYVALUEJSON` format. |
9 | 16 |
|
10 | 17 | usage: `$(npm bin)/reactifex <input_folder> <output_file>` |
11 | 18 | - `input_folder` corresponds to the `messagesDir` option used by `babel-plugin-react-intl` |
12 | 19 | - note that reactifex assumes folder structure based on this default |
13 | 20 | - `output_file` will be suitable for upload to transifex |
| 21 | + |
| 22 | +## Comment pushing |
| 23 | + |
| 24 | +This mode is why I wrote this library in the first place - I wanted the ability to use comments as `PO` files do, but none of the tools I found to convert react-intl messages to `PO` files were able to properly handle ICU pluralization. By keeping everything in a js context with `KEYVALUEJSON`, plurals work correctly *and* we now have comment support for translators (by default, Transifex's `KEYVALUEJSON` file format does not allow for comments to be included with strings for translation). |
| 25 | + |
| 26 | +Note that tests for this mode aren't included, as it relies on Transifex's API being up and responsive. |
| 27 | + |
| 28 | +Usage is a little complicated, I'm sorry about that; you're going to be running this server-side as a series of bash commands. Do note that I assume `$SECRET_USER` and `$SECRET_PWD` env vars exist for basic auth purposes. See [Transifex's API Introduction](https://docs.transifex.com/api/introduction) for more details on authentication. Here's an example, written as it would be in the Makefile of a project that makes use of reactifex: |
| 29 | + |
| 30 | +``` |
| 31 | +tx_url1 = https://www.transifex.com/api/2/project/<project>/resource/<resource>/translation/<default_language_code>/strings/ |
| 32 | +tx_url2 = https://www.transifex.com/api/2/project/<project>/resource/<resource>/source/ |
| 33 | +push_translations: |
| 34 | + ./node_modules/reactifex/bash_scripts/get_hashed_strings.sh $(tx_url1) |
| 35 | + $$(npm bin)/reactifex <input_folder> --comments |
| 36 | + ./node_modules/reactifex/bash_scripts/put_comments.sh $(tx_url2) |
| 37 | +``` |
| 38 | + |
| 39 | + - [tx_url1](https://docs.transifex.com/api/translation-strings#identifying-strings-using-hashes) and [tx_url2](https://docs.transifex.com/api/resource-strings) are just variables as defined by the Transifex API documentation, extracted for readability. |
| 40 | + |
| 41 | + - First, `bash_scripts/get_hashed_strings.sh` is called with a url argument. This will populate `bash_scripts/hashmap.json` with data about the strings in your resource, including the all-important `string_hash`. |
| 42 | + |
| 43 | + - Next, the main reactifex script (node js) runs with an additional `--comments` flag, and no output file. This has the effect of gathering up all your `babel-plugin-react-intl` extracted messages *with* their comments attached. From there, it's simple enough to match up each message with its `string_hash`, and makes it possible to generate `bash_scripts/put_comments.sh` (a series of curl requests, one per message) |
| 44 | + |
| 45 | + - Finally, `bash_scripts/put_comments.sh` is run with the base PUT url as an argument (we generated the specific `string_hash` portion in the previous step), updating translator comments for each message on Transifex via their API. |
0 commit comments