I only recently discovered that the .NET framework supports custom cultures. A custom culture is most likely to be a variant of an existing culture, for a particular professional group (doctors, lawyers) or for a specific client.
Of course, after creating a custom culture, my first step was to try to use it in the Add-In. It was only then that I discovered that there was going to be a problem.
All custom cultures have the LocaleID, or LCID, 0x1000. On reflection, this is a reasonable design decision. The framework cannot possibly assign a guaranteed unique LCID to a custom culture, so why not give them all the same ID.
Any culture can be identified by its name, otherwise know an IETF (Internet Engineering Task Force) tag. Whereas LocaleIDs are defined by Microsoft, Language Tags are standardised by RFC 4646 (if I am not mistaken). This standard allows custom tags, which (again if I am not mistaken) must start with "x-".
It seems fairly clear, that the IETF language tag is a better way to identify a language, than a Locale ID.
However, the Multi-Language Add-In uses the Locale ID to identify languages. It uses the Locale ID in the project database, and also in the global database (translation memory). It also assumes that the same IDs will be used in both databases.
My medium term solution is to assign private IDs to custom cultures, which are used in the project database and the global database. Since I can't guarantee always being able to generate the same ID for both databases, I deliberately generate different IDs. I have extended the database schemas to store the language tag, with a unique constraint, but not as the primary key.
This is more or less finished for VS 2005 and 2008, but still needs some more testing. I will then make the same changes to the version for VS 2003.
In a second step, I will modify the Excel and OpenDocument export format, to use the language tag instead of the Locald ID. For import, I will make it accept either of them.
The long term solution may be to stop using numeric IDs for languages altogether. This would be consistent, but it might be a lot of work, for no tangible benifit!
8th April 2008