In most cases, the localization of software UI occurs during the software development process. This means that as areas of the software become ready, they are bundled and sent for localization. But as some areas of the software change during the development process, this updates must take the changed areas into account. Thus there is a fair amount of management overhead required to keep a software localization project on track

A typical cycle for a single UI bundle goes like this:

1. The bundle is delivered to you by the developers. Depending on how you and your developers work together, and depending on which tools you are using, you may need to do some work on the bundle to ensure/confirm that the bundle is ready for translation.

1. You send the bundle to the vendor for estimate. You could make your own estimate using one of the tools that allows word counts and counts of repetitions. This way you can ensure that the vendor is dealing with you fairly. Make sure that you give the vendor a deadline for delivering the estimate to you.

1. The estimate comes back from the vendor. Examine it carefully. It is hard to think of a vendor that would blatantly cheat you (but it has been known) but they do make mistakes. Sometimes they will use the wrong per-word rate by mistake. Sometimes there will be charges of whose origin you cannot be sure. Make sure you are happy with every part. Your company will have its own approval process. As soon as the spending is approved, tell the vendor to start work.
3. The vendor translates the material. The vendor has their own process which is discussed in Vendor Processes.
5. The translated material is delivered to you by the vendor, and, after whatever bookkeeping processing you use to track the progress of your bundles, you pass it on to your developer.
7. On the arrival of a particular batch or after several batches, the engineers make a build. This is for functional testing and/or linguistic testing. With some translation tools (for example, Passolo, which allows you to see the dialog boxes without actually making a build) there may be a linguistic test cycle without a build.
9. The test cycle commences. Whatever part you test (and quite often you may not test all of the material that was in the batch), and whatever you test for, your testers will need some method of reporting bugs and communicating them to the vendor. This is critical.
11. Bug fixing. When the test is completed, the update resources need to be sent to the vendor, together with the list of bugs, and any other special instructions, so that those bugs can be repaired. Again, delivery times in both directions should be specified. The vendor fixes the bugs that have been reported to them.
13. Bug fix verification. As previously, the translated/corrected material is delivered to you, and incorporated into another build by your engineers. This is now sent to the testers again and they test specifically to ensure that the bugs reported are now fixed. They may also do some regression testing to ensure that no further problems were created by the new translated bundle.