locked
Localization of workflow designer RRS feed

  • Question

  • Hi,

    Is there any guidance (best practices), samples, etc that anyone at Microsoft can point me to for localizing the workflow designer?  What is done for the built in (Microsoft implemented) activities, in terms of localization?  What about parts of the workflow designer that are not related to any given activity, such as the expand all/collapse all hyperlinks, the items on the shellbar, etc - can these be localized?  If so, how?

    Thank you,
    Notre
    Thursday, January 14, 2010 12:23 AM

All replies

  • Hi Notre,

    May I ask in what language do you plan to localize? Our product does come in languages other than English.

    Thanks!
    Thursday, January 14, 2010 10:26 AM
  • Hi Cecilia,

    We will likely be localizing to French, Spanish, German, Japanese, and Simplified Chinese.  There may be a few more languages.  We currently have only very limited support for right to left languages, but may add more support in the future.

    When you say the product comes in languages other than English, do you mean that the product's localization comes as part of the .NET Framework language packs, as described here?  If not, what is being done?  If not using the .NET framework language packs, is there support for having multiple languages installed on the same machine, as is the case with the .NET Framework language packs?

    How does the workflow product decide what language should be used in the user interface? Is it based on the "language" of windows that is installed?  Is it based on window's regional settings, as it says is the case for the .NET Framework during installation?  Does it respect the Thread.CurrentUICulture property (in the System.Threading namespace)?

    The above points largely deal with parts of the UI that is not specific to any given activity (such as 'expand all'/'collapse all' hyperlinks, items on the shellbar).  But there are also the activities that Microsoft provides as part of workflow foundation 4, that surface UI in various activity designers and the property grid.  How are these activities localized; does they use the same approach as the non-activity specific UI?

    Finally, as an author of custom activities, many ISVs like myself will likely wish to support globalization and localization for these activities.  We need to concern ourselves with globalization & localization of all of the activities' UI; typically the activity designer, property grid content, error messages, context menus, etc.  Is there any guidance or best practice for authors of custom activities in terms of localization?

    Thanks,
    Notre
    Thursday, January 14, 2010 5:37 PM
  • Hi, I'll ask around about how to get the language packs and also the specific mechanism for respecting your culture.

    I can answer a couple of your other questions:
    1. When we did the localization in the workflow designer, we localized everything that doesn't correspond explicitly to a property name in the .NET framework. So your shell buttons, etc were localized.
    2. There is no real standard for writing localizable WPF applications. It all depends on the toolchain you are using for localizing (and there are many wonderful and exotic versions of these things floating around). Step one is ask your loc guys what they like. If they have no real preferences, you have two options:
        - in your activity designers, set the Localization.Attributes to Readable Modifiable for stuff you want localized. This way you can sprinkle strings through XAML with impunity OR
        - have all your activity designers set up to use strings centralized in a single XAML file, access them as a DynamicResource from your custom activity designers (better approach since this centralizes your strings therefore reducing cost) 
    3. Our language support for RTL has some quirks too (esp Arabic), so you may want to hold off on those expansion plans. The Unicode standards for XML and XAML are a bit different, and right now XAML thinks characters are valid that XML does not. Because of that, in some narrow scenarios, you may see serialization issues. If you need to check if characters are valid letters in a given sequences, use XML APIs and not XAML APIs. Also IDEs don't work as you expect in a RTL world. General editor behaviour is LTR, but identifiers are RTL. We saw this caused some funky behaviours in the expression editor (the static UI would display differently than the IDE), so now we ignore the FlowDirection attribute when it is set on the ExpressionTextBox.

    • Proposed as answer by Amadeo Casas - MSFT Wednesday, January 20, 2010 7:10 PM
    • Unproposed as answer by Notre Wednesday, January 20, 2010 10:00 PM
    Thursday, January 14, 2010 7:39 PM
  • Hi Cathy,

    Thank you very much for your reply (including the warning regarding RTL support!), and your offer to look into getting the language packs and the specific mechanism for respecting the culture.

    A few follow up questions:

    1. I assume by your offer to provide information about language packs, the various parts of the workflow designer are localized as part of the .NET framework language packs.  Is that correct?

    2. I was getting the same impression about the lack of a standard for writing localizable WPF applications.  Is the .NET framework language pack used for localizable content on the 'built in' Microsoft activities as well, or do these follow a different strategy, such as one of the two you outlined?

    Thank you,
    Notre
    Thursday, January 14, 2010 8:17 PM
  • To be clear, I am not providing any info about language packs, what is in the language packs, and what is the distribution mechanism for them, I will leave those details to somebody more informed than I am (and I'll try to track them down).

    Thanks
    • Proposed as answer by Amadeo Casas - MSFT Friday, January 22, 2010 6:31 PM
    • Unproposed as answer by Notre Friday, January 22, 2010 9:50 PM
    Monday, January 18, 2010 7:14 PM
  • Thank you Cathy; I understand and appreciate any facilitation you can provide in getting the right person to take a look at this forum post.

    Notre
    Tuesday, January 19, 2010 5:41 PM