After having migrated our project (FreeIPA) I thought I would share some info which might help others. We were already hosted on transifex.net but the project was created prior to the Transifex 1.0 roll out. For some reason we didn't have a resource although we previously did have a .pot file and translators had provided .po's. I had to create a resource using the tx client. I presume resources are a Transifex 1.0 concept. We keep our pot file and po's under source code control so the fact there was no transifex resource was a non-issue, I just needed to recreate them on the TX server from our source code system. Snag 1: My first snag was understanding what a resource was and how to name it. For those used to GNU gettext a resource is a pot file and the po files associated with it. If you have more than one translatable entity (e.g. your runtime translations and man pages) each would be a TX resource. The source file for a TX resource is typically a pot file. You should name your resource accordingly. Snag 2: The auto-local feature of tx set makes some assumptions about your tree, for instance it seems to assume there is a po directory in the top level directory of your project. If that's not the case for your project you need to indicate where to find your resources source file (i.e. the pot file) and the po files associated with it. Here is an example: tx set --auto-local -r $PROJECT_NAME.$RESOUCE_NAME $PO_DIRECTORY/<lang>.po --source-lang en --source-file $PO_DIRECTORY/$RESOUCE_NAME.pot where: PROJECT_NAME = the name of your project in Transifex RESOUCE_NAME = the name of your resource PO_DIRECTORY = the location in your source tree for your pot and po files Note: there is no requirement for your pot file name to match your resource name, but the consistency might benefit others who come along later. Snag 3: Since we already had an existing pot file and associated po files the next step was to push them to our TX resource. This is done with 'tx push -s -t' and that's where I hit my next snag. The tx client reported it was "Skipping XXX.po" and didn't push it. Huh? Why? It turns out the decision to whether to push a file is based on the timestamp of the file on the server and the timestamp of the file in your tree. If the timestamp on the server is newer it won't push it. I have no clue how the server got a timestamp for a file that didn't exist prior to being pushed, but it did (see speculation about translation teams below). The solution is to touch all your po's prior to pushing so it's timestamp is newer. But because the server's clock is not synced with your clock you might have to wait until your "touched" timestamps are newer than what the server has. I'm a bit dubious about using file modification timestamps like this because of the clock sync issue but I'll let the TX folks sort that one out. Just be aware, the tx client won't report why it's skipping a file or if the server rejects it (see Snag 4). Snag 4: After having pushed all our po files from our SCM up to TX I looked at our resource on TX and discovered there was a discrepancy between the po files I pushed and what the server reported. Some of the po files I pushed were absent. Moreover the tx client reported those po files had been pushed. Why did these po files apparently go into a black hole bit bucket and not show up on the TX server? It turns out if you have a po file with no translations in it (i.e. a "stub" file for a language that no translator has contributed to yet) then TX will ignore it. The missing po files were those in which every msgstr was empty. But wait, the new created resource on the TX server contained po files which weren't in our SCM and which I did not push to the server. Where did these po files come from? I didn't push them. Apparently when creating a resource TX will examine the existing set of translation teams for your project. It will create a po file for every translation team. We had a few translation teams which had never provided a po file to us, thus we never had a po file to push, but TX happily created a po file for us in the resource. I presume it did this because it assumed if there was translation team there had to be po file for the team. I suspect it was the existence of the project translation teams which caused a po to appear on the server with a newer timestamp than the timestamp on the po file in our source tree which subsequently caused the po file to be "Skipped" when it was pushed, even though as far as I could figure out the TX server's copy of the po file would have been empty. This seems to me like a TX bug. Any way, hope this helps others who follow, some of this should probably be on a wiki page and/or FAQ. -- John Dennis <jdennis@xxxxxxxxxx> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
