Multilingual support customization

[mike_f]

Hi,

We recently committed to AC7 as we found it to be overall a really nice product, even though we knew that out-of-the-box it lacked the multilingual support we absolutely need it to have. After some conversation with AC representatives who willingly pointed out a couple of helpful threads in the forum that would help us in our effort of localizing the system we decided to go this route and started work.

Now, only shortly after commiting to AC, we've run into a bunch of problems making parts of the system multilingual. One really big issue are the scriptlets, that also need to be localized and be made multilingual. This requires us to be able to edit them for each setup language in the system, as well as to display them in the clients desired language. The scriptlets themselves are saved to disc/file, and not to DB as we had hoped, which makes it a bit more complicated. Also the component responsible for fetching them is in an obfuscated part of the core that we do not have access to (datasource object) so we cannot easily change the way they are loaded.

It worries me a bit that we've run into such big problems, so relatively early on in the development process, especially since it had been indicated that adding multilingual support would not be such a major endeavour as it had "been done before"...

So, i would really appreciate if anyon of the AC-team, or any other developer that has already done this, would help in pointing out a way to do this, giving a hint or suggestion of how to go about incorporating this multilingual support for the scriptlets...

And, to clarify, to translate the majority of the texts in the system (static texts like in .aspx and .cs files) is fairly straightforward, although time-consuming, and that is not what we are having problems with right now.

Please help me, we are really caught between a rock and a hard place right now, as we've already put down quite a few man-hours into other customizations, so we cannot very well decide to go with any other product right now (and we would not want to either, as AC actually excel in many other areas) ...

/Mike

[jmestep]

I don't know if this would help, but different themes can have their own scriplets in an App_Data folder under the theme in 7.0.3.

[mike_f]

I don't know if this would help, but different themes can have their own scriplets in an App_Data folder under the theme in 7.0.3.

Thanks. That is indeed interesting and a possibility worth investigating. I will leave any feedback on this issue when, or if, we solve it.

[jmestep]

Can you post an example of what you are trying to customize? I know there are quite a few places where Able switched to using <asp:Localize> tags. I've done a little research on localization and would like to find out more.

[mihkeltt]

I'm working on the same project as mike_f so i can shed further light on our intentions. We're not trying to merely translate the Able Commerce application but to add per-user multilanguage support. I've already extracted all the UI texts and moved them to resources and created a new control in ConLib that allows the user to change the UI language (like any other normal website would have).

Now we are trying to solve the issue of allowing scriptlets to have multiple translations and being dynamically loaded. This would be accomplished by storing all the scriptlets for each language in a subfolder called e.g. /Scriptlets/Translations/sv-SE/Header etc. Scriptlets would then be loaded based on the current thread UI culture. What this means is we'd have to rewrite the scriptlets loading and saving mechanism. As we don't have access to the CommerceBuilder source code we can't directly edit it. I was thinking of using something along the lines of Castle IoC but such method implementation replacement is out of scope of that framework.

Has anyone successfully managed to complete what we're trying to achieve? Or if anyone has any words of wisdom, they'd be greatly appreciated.

thnx
Mihkel

[mazhar]

Give a try to NVelocity. Put some NVeclocity IF/ELSE structure to show proper language, with this technique you need to have only one scriptlet with all languages but separated in different if else blocks. Once some once visits the page system will execute and display information from suitable logic block.

For example consider following case where lets suppose that each user contains a user settings called language which specifies user's local language then Home Page scriptlet would be something like

Code: Select all

#set($lang = $user.Settings.GetValueByKey("lang"))
#if($lang = "de")
text info in German
[[ConLib:FeatureProductsGrid-DE]]
#elseif($lang = "fr")
text info in French
[[ConLib:FeatureProductsGrid-FR]]
#else
text info in English
[[ConLib:FeatureProductsGrid-EN]]
#end

[mike_f]

Give a try to NVelocity. Put some NVeclocity IF/ELSE structure to show proper language, with this technique you need to have only one scriptlet with all languages but separated in different if else blocks. Once some once visits the page system will execute and display information from suitable logic block.

For example consider following case where lets suppose that each user contains a user settings called language which specifies user's local language then Home Page scriptlet would be something like

Code: Select all

#set($lang = $user.Settings.GetValueByKey("lang"))
#if($lang = "de")
text info in German
[[ConLib:FeatureProductsGrid-DE]]
#elseif($lang = "fr")
text info in French
[[ConLib:FeatureProductsGrid-FR]]
#else
text info in English
[[ConLib:FeatureProductsGrid-EN]]
#end

Hi Mazhar,

Thanks for the suggestion. For some reason, that option had actually passed me by completely. I was completely focused on using separate datasources (files or DB) for each language... The solution you propose, albeit perhaps not be the most elegant solution from a development view ( ), is simple, quick to implement and will certainly do the trick... Brilliant!

Thanks!!!

/Mike

[keats76]

Any hope of joining forces and migrating this solution to the core product? I toyed with localization a while back but I kept running into problems. A localized product with a standard set of resource bundles would be Awesome!

If not able to merge into core, mike_f, would you be willing to share/sell your solution to others?

Thanks,
Mike

[ZLA]

Code: Select all

#set($lang = $user.Settings.GetValueByKey("lang"))
#if($lang = "de")
text info in German
[[ConLib:FeatureProductsGrid-DE]]
#elseif($lang = "fr")
text info in French
[[ConLib:FeatureProductsGrid-FR]]
#else
text info in English
[[ConLib:FeatureProductsGrid-EN]]
#end

Can you use nVelocity parameters inside a conlib? If so, couldn't you just do the following:

Code: Select all

[[ConLib:Custom/LocalizedFeatureProductsGrid lang="$user.Settings.GetValueByKey("lang")"]]

[nickc]

Our solution for this was to remove all text from scriptlet files. Easy enough to put text in controls only, and make sure all static text is wrapped in <asp:Localize> tags. For edge cases where text had to appear directly in the scriptlet, we built a simple control that takes the meta:resourcekey as an argument: [[ConLib:Utility/LocalizedText ResourceId="SampleWebPageTitle.Text"]].

Other comments:

Rick Strahl has a great database provider for moving localized text out of .resx files and into the database. Very helpful for us as we refactored to a web project and localization resources are generated at compile time. Now we can update and review text without rebuilding the site. This utility also has a drop-in control that exposes localized resources directly in the UI - perfect for your localizer to edit the site knowing the exact context of each string and not having to rely on resource id names. See http://www.west-wind.com/WestwindWebToo ... fault.aspx

If you are switching locales via dropdown control, user setting, browser setting, etc., the best place to do that is by overriding Page.InitializeCulture() in ALL .aspx files:

Code: Select all

        protected override void InitializeCulture()
        {
            string _UserCulture = MethodThatGetsLocale(); // can return either form, e.g. "en-us", "es-es", "de", "fr"
            Thread.CurrentThread.CurrentUICulture = new CultureInfo(_UserCulture);
            Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(_UserCulture);
            base.InitializeCulture();
        }

[mskurnik]

How many hours did this take you? I need to estimate this for a client.