Localization

Localization consists of two or three steps to perform, depending on what features of the library you use.

General Parameters

The dialog page has some general properties that require localization, in particular the page title and the default group that is generated when you are using options without explicitly configuring group names (the latter one does not apply if all your options
have group names specified). The OptionsConfiguration class allows you to specify different values for these parameters, and you can put localized values there, depending on the current culture settings on the phone, for example:

Options

Every option has at least the following properties that can and need to be localized:

DisplayName

Description

GroupName

Special option types may have additional localizable properties. For more details, please consult the documentation on the supported data types.

To localize these values, each option type has a property ResourceType that allows you to specify the type of resource where the actual value should be retrieved from. The values of the above mentioned string properties then are treated as keys to obtain
the resource entries.

Sample

With this configuration, the options page shows the literal values in the UI, no matter what culture the phone actually uses. To support localized strings, create a resource file (for example named "MyResources.resx"), and add entries for all of the
string values. Then, add additional resource files for each additional culture you want to support (for example "MyResources.de-DE.resx" for German translations). All of this is the standard .NET localization mechanism and not specific to YLOD or
even Windows Phone.

Note: To make this work, you absolutely need to change the access modifier for your resources to "Public". Also, the normal Windows Phone procedure applies: that is, you need to edit the project file of your Windows Phone project and add each
additional culture you support to the list of "SupportedCultures".

Now you can simply change the configuration of the above boolean value to:

Now the values of properties like DisplayName are not used as literals, but the engine tries to retrieve the actual (localized) entry in
MyResources, using the given string as key. That way you can effectively localize all the string values of any option to your supported cultures.

Special Case: Enumerations

As described e.g. in the walkthrough, for enumerations the default System.ComponentModel.DescriptionAttribute is used to provide a descriptive text for each enumeration value:

using System.ComponentModel;
// [...]publicenum FeatureChoice
{
[Description("The first flavor")]
One,
[Description("Flavor number two")]
Two,
[Description("Last but not least")]
Three
}

This attribute type has no built-in features for localization. However, extending it to support this is not difficult at all. You can add a custom attribute that derives from the standard
DescriptionAttribute like this: