For those of you out there with multi-national deployments and users in countries for whom English is not the primary language...

What's the best strategy for handling multiple language requirements with respect to Data Cards?

Its great that EPDM can be installed in ~13 languages, and fortunately this covers us in all cases but one. So the users can easily install the client in their local language and have their menus easily accessible. But Data Cards will be a challenge for localization.

As we look to expand the use of EPDM beyond North America, we have locations in both Europe and Asia in which it would be preferred to display the text in the Static Text boxes in the local language. Heck, in one, its a legal requirement! Sure, in many of these locations their English is far better than my Mandarin, French, Portuguese, etc. but in many instances you can tell that they would be *much* more comfortable with the "labels" on the fields in the Data Cards to be in their local language.

In an ideal situation, we would have those groups working in our exact same folder structure, using the same document types and same Data Card structure and Variables. We leverage the EPDM database quite heavily for reporting purposes, so keeping the same Variable structure is critical...but that's the easy part.

Has anyone out there tackled this? If so, how did you do it?

Here's what I think my options are:

1) Wouldn't it be awesome if there was some way that when you're building Data Cards, as you're placing Static Text boxes, you could also select what the "alternate" text would be on a per-language basis...then when the user, whose EPDM client was originally installed with a different default language, selects a file and the Data Card is displayed, the system cross-references the client installation language to determine which set of alternate texts to display. I can't find anything remotely associated to such a function or how to even construct such a contraption.

2) At this moment, my File Card for Excel files for several of the upper-level folders (Think:  \Vault_Name\Functional_Unit ) already has four tabs controlled by a Variable, and I'm the process of adding a fifth. The reason we do this is the basic tab is for a "general document" without any significant Variable usage, then another for a "somewhat special" document that gets categorized by a half-dozen selections, and then two "more special" tabs that contain two versions of one document type that utilizes numerous variables, most of which are tied to the Excel file to allow the user to update either/or.

Its those "more special" tabs/types that we need to localize. Piling on to that scenario, I could see creating even *more* Variable-controlled tabs, with the new tabs being duplicates of the English-labeled tabs, just translating the labels in to the localized languages. The downside of this of course is maintenance of an already-complex File Card, and the foreign-language users are stuck with selecting the alternate version of the document type when they create the document. A minor issue is that our back-end reporting system keys on that same Variable that controls which tabs are displayed to determine what data to include in reporting..but that can be tweaked to include the new Variable values where needed.

3) I could create "separate but equal" upper-level \Functional_Unit folders in the vault, one for each required language, and apply the localized File Cards to those folders. The initial concern is everyone not playing in the same sandbox...but we're not entirely sure its the end of the world, as a) the groups don't often work together on the same projects, and b) even if there were some international cooperation, most of the U.S.-based users couldn't read their documents anway. I don't know that I really gain much from an adminstrative standpoint, as (in one instance of our "more special" documents) I'm trading one increasingly complex File Card with tabs for multiple languages for multiple File Cards, one for each language. Typing out loud here, maybe that *would* be better, as when making a change that affects all language-driven versions of a particular File Card set, I can open the multiple Cards at one time, and see them all together to make the edits...with one multi-tab Card, I'm continually switching back-and-forth amongst the tabs to see the changes. Plus, the benefit for the users is when they create the files, the Data Card is already localized for them - I know toggling one pull-down based on language doesn't sound like a big deal, but anything to make it easier for the end-user.

After ponding for a day, #2 and #3 are the only real options that spring to mind. Interested in hearing other's experiences as to how they handle this, and what they would do different if they had it to do over again.

Thanks!