It depends.
Usually if you just place all your "UI strings" into a resources.resx you can then generate a different resx for each culture en-GB or en-US or fr-FR for example. A rough overview can be found here although there are probably better resources to be found on Google.
Basically the premise is that the user will set the device to their own culture (for example fr-FR for French) and then when your app loads if there are .resx files for fr-FR these will be loaded instead.
A couple of issues to be aware of:
To manage these strings effectively it's best to wrap them all into a base .dll. This means you need to edit the tool that generates the code. By default it lists the resources as internal and you need these to be public instead. Otherwise you end up with a number of .resx files all over the place which is hard to manage.
It's all or nothing. So if you want someone to have french text when they set their culture this will modify all items pertaining to the culture including formatting and clock orientation
You CANNOT change the culture on WinCE at run-time. So if you have an app that needs to change cultures (as I once did with a bus application that moved between Ireland and Northern Ireland) then using .resx is no good at all and you have to roll your own system.
The other option is to roll your own localisation.
If you are going to be providing extensive culture specific localisation then consider your formatting of dates, currencies and text comparisons. Read up on the Turkey test to see what kind of things you need to bear in mind.