[CLOSED] Multi-language with Ext.Net

Hi,

I wondering if there is already a best practice for multi language usage.
Specially for the WebParts. Because, most of them are filled within the Tags (FieldLabel, Title, Text, etc.)

This aims of course also the text parts in the Javascript Code and variables within the Text (different gramar).

With ASP.NET you can only change them proberly from Codebehind by ID.Text = "xyz".
Using

Code:

---

<%=XYZ%>

---

or

Code:

---

<%#XYZ%>

---

won't work right in some cases. Using these in XScript/JS is also a problem.

In our solution we abstract every Page from a basePage which loops the Ext.Net Controls and
replaces labelIDs in the Tags. For Javascript, we have a hidden asp.net text field dynamically added in Init() with json array which holds labels with strings. In JS we use them like

Code:

---

#{errorMsg}.setText(getLang("StyleInput",#{language}.getValue()));

---

basically a port to JS from C#

Code:

---

string.format("Some Text {0}, with this two {1}","Sample","Variables");

---

Quite abstract language layer. For LabelIDs in C# we also have enums for VS2010 intelisense.

Before I post the basics of my solution on my blog, I just want to ask if you already have a even better
solution for multilanguage usage.

Cheers.

Hi,

I'm not sure an approach better than yours exists. Note - in case without reloading page.

But lets wait Dev team's opinion. Maybe I missed something.

Hi,

As I understood you want to change a language without the page reloading. Right? If yes then why do you need such limitation (without page reloading)? Is it high usage operation?

In mostly systems the choosing language requires page reloading. I think that using classic ASP.NET localization is good choice (just need to reload the page after the language choosing).

If you want to update the language for already rendered controls then it is not good idea because a control can has many localization properties (and can be properties which cannot be changed after rendering), also you need full list of controls in your browser.

Therefore I think ASP.NET localization + page reloading for language switching is good choice

Right, thanks.

Of course we use the standard ASP.NET

Code:

---

Thread.CurrentThread.CurrentCulture

---

and the Language String are loaded one time from DB to Session. (we don't like compiled resource files) Controls are only filled one time on PageLoad from the Session.

On monday I write a sample how we solved it. I think it should meet the multi language requirement of most developers.

Hi,
as promised here the example of how I apply multi language all over Ext.Net

http://ext-net.blogspot.com/2010/11/...uage-with.html

Cheers.

Thank you for sharing the link.

Hi,
from my point of view it is also be beneficial to use the existing translations of Ext.Js, located in the <Ext.Net basedirectory>\Ext.Net\Build\Ext.Net\extjs\src\loc ale folder. There you find standard translations for all Ext.Net Controls as javascript files.

I am just not sure how to best dynamically load the specific Javascript files as includes according to the language switch. Is there a predefined method in Ext.Net to dynamically include and run these .js files?

Cheers.

Hi,

You could add these files dynamically but it won't make sense because widgets are rendered. All (or, at least, the vast majority) of properties in "locale" files make sense during rendering. The best way to apply "locale" files is a page's reloading.

I totally agree, it is good practice to include the complete locale javascript, because all of the controls are covered.

Unfortunately I found that some properties were not working by using the prototype approach. I'm not sure if this is an Ext.net or Ext.Js problem. It should not come from our code.

The properties that are not working were "beforePageText, firstText, prevText, nextText, lastText", all from the PagingToolbar prototype. Others (afterPageText,emptyMsg) are working as expected..

As a workaround, I was able to set the values in for the control instance, but that is just a workaround ;-|.

Cheers,

It would be best to start a new forum thread with a sample to reproduce.