Once you have reached this point, your work is essentially done! The translators can now go to work, converting all of your marked strings into their own language and putting the results back into the application.
You may wish to run intltool-update -r from time to time to get a report on how much of the application is translated in each language. There is really little you can do about the results of this report, however, so it is purely for informational purposes.
Typically, the interaction between developer and the translators will proceed something like the following.
A translator will create a new file for their language. This will be called XX.po, where XX is replaced by the locale name (there is a recognised list of language and country codes used in these names).
After translating some or all of the messages in the new file, the translator will commit the file in the po directory and update the ChangeLog in that directory. They will also add the new language code to the ALL_LINGUAS variable in configure.in.
Before making a release, you (the developer) should give all the translators a bit of notice so that they can update and commit their translations. Typically, a week is not an unreasonable amount of time.
Right before tagging the CVS tree for the release, you should commit any language (.po) files that your build process changes. You should do this only when you are releasing in order to avoid creating unnecessary conflicts for the translators. In general, you should leave the language files alone, but a release is the time when you synchronise what is in the CVS tree with what is in the code.
Aside from the release process, the only other responsibility you, as a developer, has with respect to internationalisation, is to ensure that any new strings you add are marked for translation. From time to time, it is worth running your application in one of the fully translated languages (if you have any), just to see if any English words appear as you move through the various states.