This may sound like a lot of unnecessary effort, and it is if your translator sits by your desk and you have the time to answer all of his or her questions on how to translate your UI strings as they arise. This, however, may as well not be the case. Often a vendor does the translating, either in parallel, or after the coding work. Thus, for you to be able to write code while your translator works, you must provide your translator enough information to perform the job well.
In many languages the translation depends very much on the context and surrounding UI elements. For that reason, your translator prefers to see functioning applications or entire dialogs rather than translating individual strings without seeing what they do on the UI. If you cannot supply your translator with at least a UI specification and a demo software or emulator, he or she may not have enough information to provide the correct translation. Note that it can be of crucial importance to the translator to know whether a single word is a noun or a verb, or if the word volume stands for sound volume or disk volume. Rather than skimping on the helpful content, provide a bit too much information to your translators. Often you receive the best translation results if you can sit down with the translator before the translation begins and agree on the scope, exact quality of deliverables, quality of service, deadlines, and your overall ideas concerning the translation. This way the translator is not left in hesitancy about what you want, and you get what you want in a timely fashion.
In addition to the meaning and context of each UI string, include also information on the string default state, and all the possible interaction scenarios and their outcomes if you do not write this kind of information in the UI specifications, or are not able to tutor your translator intensively. This again helps your translator to provide you with better results.