You can start by defining many thing.
Define how to identify the culture in your API (ISO-639, LS-2012, ...)
This choice will change the way you store resources and access them.
Also, decide how to fallback through regions and neutral cultures.
Some languages have a very specific way to fallback between different cultures, some books would give you a great insight.
As you're going ASP.NET to choice is simple.
Define how to store each data type (strings, pictures, currencies...)
You will have to consider different access ways. Do you want to stay mobile and use simple files? Or can you afford keeping a database in a single place to handle everything?
Centralizing can become a problem is clients and consultants have to deal with translation. Using a text-file-based solution goes into source control revision easily, providing the good portable tool and libraries is great but isn't easy for non-techies.
Define access formats for all kinds of application
- need to export for a specific technology (.resx, .po, .lang, xliff...)?
- need random access from a server app via a (web)service?
- need a unitary access to do translation?
In all cases, being able to export translations in a well-known format will give you the ability to use translation services. You will then need to be able to merge new translations with your existing ones.
Define how to deal with currencies
This is more a code concern which your API will not have to deal with entirely. But setting-up rules for all developers is a good thing.
Finally, make sure the API you will create can be ported to as many languages/technologies as needed. Using standard formats will be a essential choice because of the existing libraries (gettext, xliff) and tools.
Don't forget to handle plural forms (no items, one item, x items) and translation remarks (contextual information for each resource) which will solve a lot of problems.
Write everything you decided in a shared document to make sure everyone understands the why and how. If you're writing an API, documentation is... important.
I would accept duplication whenever you cannot be absolutely sure the meaning is exactly the same in all cases a certain string is used.
Even if two labels always contain the same string in English (or your native tongue) they will not necessarily be the same in all languages. Accepting duplication may give you (or rather the translators) the flexibility needed to handle such situations.
As an example: Consider a label "Condition", which - depending on context - might get translated to "Zustand" or "Bedingung" in German (among lots of other possible translations).
Best Answer
We used to work with a translation agency which did the translation for our enterprise product on a continuous basis.
To go there you would need some sort of a tracking and reporting system for all of your textual resources. New texts should automatically go to the translation queue so that it is easy to keep track of what is pending translation. Reporting wrong or low quality translations must be there too. If you have it you could either build a simple web interface for the agency to access the stream of the pending work continuously or have a technical possibility to export the next bulk of resource items, send them to the agency then import the result.
It's not really feasible to entrust this task to a random bunch. The quality and predictability will largely vary. Even with a trusted and experienced agency there are often issues:
They do miss the usage context if they see a single short string. You should definitely have additional attributes to allow commenting each textual resource to help them understand the environment but it naturally means more work for you as a developer.
They lack industry knowledge and translations unfortunately suffer from this. There is hardly any solution short of looking for an agency with certain industry knowledge (hard) or perhaps employing and educating a person in-house.
They have little understanding of
<html>or<xml>tags in resources as well as of{variablePlaceholders}therefore they regularly break the software. It is either out of lack of attention or perhaps because the people are changing there continuously and the knowledge of these things is not transferred to the next executor.