What are the issues in supporting different cultures?

This is a place to discuss how to adapt mojoPortal to the needs of different cultures. Before asking questions here please first review the localization documentation.

This thread is closed to new posts. You must sign in to post in the forums.
2/24/2005 12:21:49 AM
Gravatar
Total Posts 18439

Re: What are the issues in supporting different cultures?


>1. Calm down Joe, I didn't mean to insult you. I told you to learn a lot didn't mean that I insulted you that you're a newbie. Please Don't take emotion with my suggestion, I didn't force you right? Actually, the sentence learn a lot is a high philosophy of life. I especially learn it from a respective Software Architect who always said that he's still a newbie and have a lot to learn because a newbie may think to enough to learn whilst an expert always thinks has a lot to learn.
If you don't like with this philosophy then just throw it away, but don't take negative thinking when someone says you to learn a lot .

-- OK , if you say no insult intended, then I accept that as a misunderstanding on my part. No hard feelings.


>2. I know taht you're aware of Rainbow Portal but  I did think you're not aware of it's localization feature. I mentioned Rainbow as an example of good Localization portal which supports multiple culture in one site. I didn't mention that you're not aware of Rainbow portal, did I?

-- you said it in the same sentence with "I think you have a lot to learn" so I took it this way.


>date time and number formats have not been part of our discussion. don't assume I don't understand those issues just because we have not discussed them.

3. Actually, It's part of main discussion because It's one of the most important part of the .NET localization so I think mojoPortal missed the point here.

-- we did not discuss it, if you have a specific problem with how mojoportal handles it I'm glad to hear about it as long is it doesn't involve storing anything in resource files


>4. No, I think I'm not overly enamoured with guidelines, I've already built and architected web sites with this guideline and everything works and is easy. So I speak with my experience not just in theory.

-- I don't doubt you have been successful with it but perhaps your requirements are not the same. I don't think storing anything in resource files makes it easy to change for people who are not developers, that is a requirement for mojoportal that is not met by using the .NET localization guidlines. I won't throw away my requirement just because msdn says thats how you do localization. Throughout our duscussion I have read a lot of the localization articles and I still say that I am doing localization with mojoportal without using the guidelines. The definition of localization is supporting any single culture.  What I am not doing is internationalization which means supporting multiple cultures in one site.  My view is that everthing visible in a web site is content including what is in the database and in labels and buttons. That is the essential difference with a web application and other types and I think this is the essential difference in how we look at the problem.   The content stakeholders must be able to change anything easily.

> Last but not least, take it easy and be happy

-- Thanks, same to you!
2/24/2005 9:01:11 PM
Gravatar
Total Posts 6

Re: What are the issues in supporting different cultures?

> we did not discuss it, if you have a specific problem with how mojoportal handles it I'm glad to hear about it as long is it doesn't involve storing anything in resource files

1. I had thought you've already known that Localization is not only related to translation of text and label. Yup, I'd suggest that you can put a culture info key in the web.config then for each page request you set the CurrentCulture in the CurrentThread object based on that key from the web.config, you can do that in the Application_BeginRequest event in the global.asax. I think this is a good workaround for MojoPortal.

>My view is that everthing visible in a web site is content including what is in the database and in labels and buttons. That is the essential difference with a web application and other types and I think this is the essential difference in how we look at the problem

2. Yup, you're 100% correct, this is the essential gap between your concept of Localization and mine.  You took "everything visible" including the data in the database as part of the localization while I just concern to the Presentation Layer elements (label, buttons, etc), so the data in the database isn't actually part of the Localization. That's my opinion. No problem Joe, I do respect your own concept.

3. Anyway Joe, from your previous post you said like this:
>I say its works for Winforms and console apps but falls miserably short in web applications.

I always thought that all localization is same for whatever projects because they use the same Framework libraries except that as I said in my previous post that VS.NET 2003 has lack supporting tool to the web project so it's not available in design time compared to the WinForm project. Other than this, everything's the same.

I'm really curious how you do localization with your concept in the WinForm project. How can you make your concept work for the WinForm project?  If you dont' mind then you can explain it here or somewhere else so that I and others can learn a lot from your experience.

Ok Joe, This will be my last posting here as I've got something to do with my job. It's nice talking to you, Keep up your good work and see you next time

Kind Regards,

Hendry


2/25/2005 12:43:55 AM
Gravatar
Total Posts 18439

Re: What are the issues in supporting different cultures?

>I'm really curious how you do localization with your concept in the WinForm project. How can you make your concept work for the WinForm project?  If you dont' mind then you can explain it here or somewhere else so that I and others can learn a lot from your experience.

I have already said that the .NET localization guidelines seems an adequate solution for WinForms apps.  Unlike web apps, with WinForms apps the boundaries between the data and the UI are usually very clear and obvious. The look and feel of WinForms apps are usually not subject to constant tuning and/or total face lifts after deployment.  You might have skinning with a WinForms app but not ad hoc changes to the look and feel as you do with web applications.

My approach is different for web apps because of the different nature of web apps, as I said before everything you see in a web app is content and subject to the whims of the content stakeholders and therefore my requirement is that it must all be very easy to change.  I haven't seen this same issue with WinForms myself, but I would always have to consider the specific requirements of the project.

I have appreciated your input and enjoyed this discussion. Feel free to post on any topic whenever you like.

Kind Regards,

Joe
6/2/2006 12:21:58 PM
Gravatar
Total Posts 18439

Re: What are the issues in supporting different cultures?

The new localization features in 2.0 .NET are much improved over the 1.1 .NET implementation that this discussion was originally based on.

It is now much more feasible to have the benefits of localizing based on the language preference of the browser while still keeping the resource strings in xml.resx files easily editable with a text editor. Keeping this ease of editing has been my main concern and the old satelite assembly approach did not lend itself to ease of editing.

Scott Guthrie has a great post in his blog with a link to a nice tutorial video and several good articles on localization in 2.0 .NET

These new advantages I think are worth pursuing though it will be substantial work to make this change. I'm definitely adding this to the to do list but not yet sure on a timeline or where it fits in the priorties.
You must sign in to post in the forums. This thread is closed to new posts.