How to organize localization string resources

Why should non-Anglos have to decode dates, numbers, etc. while Anglos can just read them? Numerical and date localization is absolutely necessary if you want non-Anglos to feel, you know, welcome as users and customers. Why should a German user have to work out what your number is instead of, you know, getting it in his or her own language's format?

Further, your view of number formats (and dates: q.v. below) is hopelessly simplistic. For example undoubtedly you'd find numbers like 1,234,567 "natural" and "obvious" and "logical" ... but what about people who come from cultures with myriad-based numbering schemes? My students (Chinese), for example, are always confused about numbers over 1000 because they group numbers differently. A more "natural" grouping for their thought processes (which include a myriad above the thousand point) is 123,4567. Further there are many contexts in which the European number systems in general are simply not suited. It would be nice in those circumstances to be able to write the all-Chinese 一百二十三万四千五百六十七 or even various hybrid systems that are in common use here.

Your idea for dates is wrong-headed too. You've correctly pointed out how 01/02/03 is ambiguous (if only because Americans refuse to comply with standards on dates) and suggest instead that Feb 3 2001 is unambiguous. I'm not sure, however, if you've noticed something there. It's unambiguous and unambiguously English. Going back to my students, I'm pretty damned certain that they'd far prefer to see 2001年2月3日 (or even 二〇〇一年二月三日) which is both unambiguous and, get this, something they can read without having to decode.

The bottom line on i18n and l10n: Do you want money and/or users? You make what your users want. Your users want things in their own language, not in yours. End of story.

edited to add

It gets even worse than myriad-based systems. Take a look at Indian numbering for this lovely progression:

1
10
100
1000
10,000
1,00,000
10,00,000
1,00,00,000

...and so on up to:

100,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,000

See that grouping by three at the end? See that grouping by two after the grouping by three? See the sudden reintroduction of a group by three again?

further edited to add (I just can't keep off this subject it seems!)

Even the assumption of decimal number systems being universal is wrong. There are native numbering systems that are 4-based, 5-based, 8-base (octal), 10-based (decimal), 12-based, 20-based and even 60-based. These are all systems which have been in active use by real people (as in not made up for science fiction stories). Not all of these are still living (although we can see, for example, vestiges of 12-, 60-based numerical systems in English terminology).

As for dates, let us not forget the lunar calendars still in active use in much of the world. The Muslim world tends to use a lunar calendar where the dates can drift throughout the whole year while the Chinese use one with a complicated system that keeps the dates never more than a month away from true. (And that's just naming two off the top of my head.)

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.