DNNDev_Blog

Localization for Your DotNetNuke Solutions Made Easier With XMod Pro

kford@knowbetter.com — Tue, 23 Feb 2010 16:08:00 GMT

It’s the holy grail of multi-language websites. If you’re running a French and English website, you want to present your French visitors with text in their language and your English visitors with text in their language. So, if you have built a real estate listing for your site, not only should labels (“Address”, “City”, “Number of Bedrooms”, etc.) be translated, but the actual data should be as well – like the description of the home.

Content localization is a tricky thing to implement. While DotNetNuke (DNN) provides an architecture for dynamically changing the static text in your website, there historically hasn’t been a way to localize the data in your site. XMod Pro’s 2.1 release adds a host of options that should make localization much easier. As of this writing, version 2.1 is in beta and available for download for XMod Pro users to download from the Clients section on the site.

Let’s start with the simple things:

Getting the Current Locale ID

To render the locale ID of the currently selected culture out to your form or view (template), use the [[Request:Locale]] token. If the user has selected Spanish from Mexico, the token will render "es-MX"; For English in Great Britain, it will be "en-GB"; for French spoken in France, it will be "fr-FR". You can use this in your Javascript, pass it around in URL’s, and store it in your database.

Formatting Dates and Values in Templates

While not new to version 2.1, XMod Pro provides the “format” tag which allows you to specify an Input culture and an Output culture – useful when converting dates and values to and from different cultures.

Localizing Dates in Forms

The DateInput control has a Culture property that enables you to accept dates in the specified culture’s format.

Localizing Static Text

If you just need to change the text that is displayed on your forms and views such as form labels or other text, you can use the [[Localize:keyName]] token in combination with resource files (.resx). The Localize token function like the other XMod Pro tokens. At run-time, it will be replaced with the translated text for the currently selected culture.

How it Works

First, you need to create a Resource File for each culture for which you have translations. Resource files follow the standard format for localization resource files in DotNetNuke. Files should be named using the following form:

FormName.ascx.localeID.resx for forms or
TemplateName.ascx.localeID.resx for templates

Some examples:

ContactUs.ascx.es-MX.resx (Spanish-Mexico resource file)
EmployeeList.ascx.fr-FR.resx (French-France resource file)

The resource file's base name must match the name of the form/templat to with which it is associated followed by ".ascx". This is then followed by "." plus the locale ID and ".resx".

Resource File Example:

The format of the resource file should follow that outlined for standard localization resource files in DotNetNuke. A sample file is provided below. The first section and the closing tag at the end, in gray, are boilerplate code and can be copied and pasted directly into your file. The highlighted section is the area you customize with your own text.


  
    
    
      
        
          
            
              
                
              
              
              
              
              
            
          
          
            
              
              
            
          
          
            
              
                
                
              
              
              
              
              
            
          
          
            
              
                
              
              
            
          
        
      
    
  
  
    text/microsoft-resx
  
  
    2.0
  
  
    System.Resources.ResXResourceReader, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
  
  
    System.Resources.ResXResourceWriter, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
  
  
    Nombre
  
  
    Dirección
  
  
    Ciudad

In the example above, we've created a small translation file for Spanish/Mexico. You can create one or more resource files for each language you need to provide translations for. Note that you should also provide a default resource file for your fallback language. Additionally, for the default/fallback language to be loaded properly, you should define a fallback language for each language you install in your DNN website.

Within each file, for each block of text you want to translate, you must specify a tag. This tag has a name property which contains the key name that XMod Pro will use to look up the translation. This name should be in the form "keyName.Text". The .Text portion is required for each of your names. The tag also contains a tag that contains the text you want to inject into the form or template.

Where to Place the Resource File

Once you've created your resource file, save it in the same directory in which your form/template is stored. For forms, this is: /Portals/_default/XModPro/Forms/XX where "XX" is the Portal ID. For templates, the folder is: /Portals/_default/XModPro/Templates/XX where "XX" is the portal's ID.

Linking Your Form/Template to the Resource File

In your form/template, you would simply add a localization token wherever it was needed - like so:

At run-time, if the user has selected es-MX as his/her culture, then those tokens will be replaced by: Nombre, Dirección, Ciudad.

Content Localization Using Multiple Forms/Templates

Content localization is a tricky issue. It is potentially more complicated when an application like XMod Pro, does not have control over the data. To keep things as simple and flexible as possible, we have implemented the ability to use multiple forms and/or templates for this purpose. At run-time, XMod Pro will look to see if a form/template has been defined for the currently selected culture. If found, that file will be loaded. If not, XMod Pro will load the 'default' file.

This method has many benefits:

You can avoid having to create Resource Files and use [[Localize:keyName]] tokens.
You can create the forms/templates just as you do standard forms and templates
You have the opportunity to define distinct data commands for each culture. You could even write/read from distinct culture-specific database tables.
You can have a completely different layout and even completely different controls for each culture.
You can send notification emails to different addresses based on the culture.

How It Works

First, define the form/template that will be your 'default' or 'fallback' file using the tools within XMod Pro.

Second, either create another form/template from scratch or simply copy your form/template to act as a starting point. This second file must follow the following naming convetion:

BaseName.localeID

Where "BaseName" is the name of your 'default' form/template and "localeID" is the ID of the culture (es-MX, fr-FR, en-GB, etc.)

So, for a form called "ContactUs", you might create the following forms:

ContactUs (the default form)
ContactUs.es-MX (Spanish in Mexico)
ContactUs.fr-FR (French in France)
ContactUs.en-GB (English in Great Britain)

The default file is always required. You can create as many or as few localized files as you need. Simply define your localized forms/templates as you would any other form/template, making changes as needed to accommodate the language

Configuring Your Module to Use Localized Forms/Templates

There is nothing special that you need to do when configuring your XMod Pro modules to use the localized forms and templates. Simply select the BASE form/template. If a localized version of the form/template exists and it matches the user's currently selected culture, that form/template will be loaded automatically. You can also force a certain localized file to be loaded by selecting it specifically on the configuration page.

That's all there is to it.

Our Pro DotNetNuke Forms Module Just Got A Whole Lot Better

kford@knowbetter.com — Tue, 26 Jan 2010 05:13:00 GMT

Have you heard the news? We've just released XMod Pro 2.0. Just like we've done with XMod, we are letting our customers guide XMod Pro's development. In this release, you will see dramatic improvements in your ability to quickly create forms and views from your DotNetNuke databases. The best news is that, because of our policy of providing a year of upgrade protection to our customers, all XMod Pro 1.x owners get 2.0 for FREE. Read on for a list of new features

More...

New Editor Highlights XMod Pro 1.4 Release

kford@knowbetter.com — Mon, 26 Oct 2009 13:00:00 GMT

Since it's initial release, XMod Pro (XMP) for DotNetNuke (DNN) has been keeping to a pretty regular schedule of a significant release every month – in addition to more frequent maintenance releases. Since all XMod Pro owners automatically have upgrade protection for one full year, all our customers and their clients have been enjoying the latest new features for free. This month is our biggest feature release yet.

More...

Extending XMod Pro Part 1: Custom Form Controls

kford@knowbetter.com — Tue, 13 Oct 2009 17:20:00 GMT

Now that XMod Pro (XMP) for DotNetNuke (DNN) has been out for a few months, I'm starting to get a few questions about leveraging it's extensibility. Thus far, I've been responding to requests directly and haven't yet created any documentation for wider distribution. This series will help rectify that. We'll start with the most popular extension – custom form controls.

More...

MaxLength for TextArea in XMod Pro and XMod

kford@knowbetter.com — Fri, 09 Oct 2009 17:34:00 GMT

With XMod Pro and XMod, you can limit the length of the text entered through a (< input > for XMod). However, you cannot limit the length of text in a < textarea >. The reason stems from the underlying TEXTAREA HTML tag that is ultimately rendered for the control which has no maxlength property unlike the HTML INPUT tag which does. Fortunately, both XMod Pro and XMod provide a way for you to implement a maximum length for the control.

More...

XMod Pro Problem Solving – Edit Form Always Edits Last Record In Table

kford@knowbetter.com — Wed, 30 Sep 2009 13:07:00 GMT

No matter what application we're using, when we run into a problem, it becomes necessary to do a little fact-finding, trying to discover what is causing the problem. XMod Pro is no different in this regard. Knowing where to look can greatly speed up the amount of time it takes to resolve an issue.

I received this question from a customer and not only wanted to post the solution but also provide a couple of things to look for should you encounter similar problems:

"When I attempt to edit any record in my list, the edit form always shows the last record in the table. I followed the examples in creating the forms and templates and have checked my work many times over."

The customer then supplied me with the form and template that was being used. The first thing I did was scan the Template for the Edit button. I wanted to ensure the Edit button (in this case it was an control) was properly formed:


  ...
  
    
  
...

The customer was also using the Alternating template so I checked that as well:


  ...
  
    
  
  ...

Both of the tags look fine. They're well-formed with no syntax issues. The value attribute of the tag is using a Field Token and that is properly delimited by single quotes. More importantly, it provides us with vital information we can use in the rest of our debugging. The tags are passing a parameter to the EditForm called "ContractorID". The value of the parameter is set to the "ID" column of the current record.

The customer isn't reporting any errors being thrown when trying to edit the record. In fact, a record seems to be retrieved - it's just the last record each time. So, this step probably isn't required but since we're looking at the template, let's just check the to ensure the "ID" column is being retrieved:

Well, since the customer is calling a stored procedure, there's no immediate confirmation that the "ID" column is being retrieved. The next step would be to look at the stored procedure and verify "ID" is being returned from the procedure. Since the ID retrieval doesn't appear to be a problem in our case, we can move on and look at the EditForm.

Specifically, we need to look at the 's . This is the command that is executed when the EditForm is loaded. It's job in an edit form is to retrieve a single record for editing.


  ...
  
  ...

Now we see the problem. This command does not limit the records being retrieved. It simply pulls every record from the Contractor table. Instead, it should be using the information passed from the Edit button in the template. So, let's rewrite the SelectCommand:

The only change I made is highlighted above. This uses the same name as the parameter in the that we saw earlier in this article.

To sum up, here are the key items to look at:

The Edit button (or image or link) in your template that you're clicking to call up the edit form
The Edit button must contain a parameter that will be used by your 's SelectCommand.
Verify the value of the Edit button is actually being retrieved in the template.
Look at the 's tag. The CommandText should use the Edit button's parameter to limit the records being returned (usually via a WHERE clause)
The parameter name in the SelectCommand's CommandText must match the parameter name in the Edit button.

Technorati Tags: XMod Pro,DotNetNuke,DNN,Blog

Opening A Compiled Help File

kford@knowbetter.com — Tue, 29 Sep 2009 18:18:00 GMT

I still create compiled help files for most of DNNDev.com's modules, including XMod and XMod Pro. The primary reason for this is to provide a single-file solution that has a clickable table-of-contents and topics that can link to one another. However, security changes at Microsoft make compiled help files tricky to open for some people. Here's how to open them

More...

XMod Pro 1.3 Released

kford@knowbetter.com — Mon, 28 Sep 2009 13:00:00 GMT

A new week and a new version of XMod Pro for your DNN'ing pleasure. What's new and changed for the 1.3 version of XMod Pro for DotNetNuke (DNN)? Read On…

More...

XMod Pro 1.3 Status Update

kford@knowbetter.com — Thu, 24 Sep 2009 17:04:00 GMT

This is just a quick note to give you the current status of the upcoming release of XMod Pro 1.3. I had originally hoped to have the version release by today. However, I wasn't happy with the syntax for using data from the within your forms. I'm currently working to simplify it. I have also found a way to catch more of those elusive errors and am working on that implementation. Assuming all goes well, I'm still looking to release sometime this week.

Technorati Tags: DotNetNuke,DNN,XMod Pro

Blogging From My Desktop, Laptop and iPhone

kford@knowbetter.com — Tue, 22 Sep 2009 21:49:00 GMT

With the recent upgrade of DNNDev.com to DNN 5, I've updated a number of modules – among them the DNN Blog module. I've been blogging very irregularly for a couple of years on the site. Previously I limited my missives to just product and site news and announcements mostly. The main reason for this is that the Blog module historically has not been quite up-to-snuff. It was OK for very basic blogging, but since my blogging involved a lot of source code, the module's editor caused more than a few frustrated episodes as it blew up my painstakingly formatted code snippets. Since I didn't have time to write my own module to overcome the limitations of the Blog module, I ended up only posting when it was required or when I had a LOT of time to properly craft my posts. All that (well, most of that) has changed with the recent upgrades.

More...