Three simple steps to localize
Your first consideration is most likely the language. At the very least, you must think about how to translate all strings in the application user interface. Usually, these are strings for menu entries, dialog boxes, message boxes, the status bar, and error messages.
If you want to send all strings to a translator, you must consistently separate strings from source code. Don't hard-code strings! If you did, convert these strings to string resources. Start this process now. Don't wait until you are under pressure to meet a deadline.
All major development languages for Windows support resource files. You have no excuse! You can easily read strings from resources, such as in classic Visual Basic with LoadResString or LoadStr in a VCL application.
Store all strings in Windows standard resource files; or, if you develop with Microsoft .Net, use ResX. In .Net applications make sure you set the localizable property to True!
Sisulizer supports localization of resource files. It is perfect in binary localization of executables (.exe, .dll, .ocx) with embedded resources, or linked resource DLLs, .Net ResX files, and assemblies.
And the clue: You localize in a WYSIWYG environment. Your translator sees the dialogs, and menus he is translating, visually and in context! This speeds up translation process by reducing the questions that otherwise would arise; and maximizes localization quality!