Last post Apr 15, 2007 09:35 PM by RTernier
Apr 12, 2007 08:14 PM|RTernier|LINK
I'm new to this stuff so bare with me please.
Our system architecture is quite different than normal applications, and on top of that, we need customer specific localization.
We might have a Label with the text "ACTION" in British Columbia. A Quebec Customer with English Language might have the word "TASK", where in the USA they might have the english word "ACTION/TASK".
Because of this, each of our customers require their own XML files for their own language. French in Quebec is different than French in the States, just as Spanish in Texas is different from Spanish in Mexico and Spain.
Our main application is split into 12 different WAP's. Each Customer (Customer1.mysite.org, customer2.mysite.org) have their own Website, and inside that website there are the virtual directories for our application.
Each Customer's root needs to hold the XML files for localization.
What is the best way of accomplishing this? I can't use resx files because there is only 1 code source, but many instances of a customer.
Apr 13, 2007 05:51 AM|vivek_iit|LINK
You can use locale specific resources files, for e.g. you can use fr-CA for canadian French and fr-Be for Belgium french, and name each resource file accordingly, like MyResources.fr-CA.resx etc.
If that does not help you can create your own custom culture as shown in this article:
Hope this helps,
Apr 13, 2007 11:00 AM|RTernier|LINK
Thanks for the link.
What I "was" looking for (It's probably not this simple) is instead of using a .resx per page, you have a .Resx / global XML file for the entire solution that is kept in the cache. Then I would just do something like:
literal1.text = SomeFunctionOnSomeObject("ItemListHeaderText");
I Guess that would be custom though eh?
I did some searching and watched a few video's and after brain storming a bit I figured out the best way of doing it, however, I can't seem to even get anything from my Resource files.
Our MasterPage is stored in the GAC along with the CSS files so we don't need to duplicate all our code for that, but here's the layout of my site (The one WAP i'm working on)
The FieldDefinitions is a control that is placed inside the FieldData.aspx page. It's pretty much pure text, but It's easier to work with as a control. I have my FieldDefinitions resource fiels set up, and I'm trying to access them like this:
<dt><asp:Literal ID="litTextBox" runat="server" Text="test" meta:resourceKey="litTextBox" /></dt>
<dd><asp:literal ID="litTextBoxD" runat="server" Text="Test" meta:resourceKey="litTextBoxD" /></dd>
Inside the Resource files I have (Local resource files):
Canadian example (en-CA):
Value: Textbox eh?
And I can't get anything. Any thoughts / help would rock.
Apr 15, 2007 02:38 PM|vivek_iit|LINK
>What I "was" looking for (It's probably not this simple) is instead of using a .resx per page, you have a .Resx / global XML file for the entire solution that is kept in the cache. Then I would just do >something like:
>literal1.text = SomeFunctionOnSomeObject("ItemListHeaderText");
No, you can use global resource files for the same. But the decision to use global vs local files needs more thought after weighing all pros and cons.
Regarding your issue, I think what you have done fine and things should work if you are setting your culture properly. Just debug to see if the thread has the culture set as expected.
Apr 15, 2007 09:35 PM|RTernier|LINK
I did a lot of thinking the other day about this, and local files would be the most efficient way I decided to scrap it all together.
There are a few things about the built in localization (using resx) files that I don`t like. I`d like to edit the languages without recompiling, and allowing different customers to have a different word for ITEM regardless of their culture.
So Instead I built my own GlobalizationManager for the language portion. IT works perfect and once the languages are cached it adds hardly any overhead at all.
Thanks for the help, and it did help me... now I just have to figure out why my IIS7 will not hold session values any more haha.