I will start this forum by explaining my current very simple approach to supporting  localization with mojoPortal.  I have only tackled problems that I understand and I doubt that I know all the issues that people will face in adapting mojoPortal to their own culture.

The issues I do understand are the need to be able to easily change the text in the  labels and buttons and the images for icons within the site and I know a little about character encoding differences and string formatting of dates and numbers.

Other than that I plead ignorance and hope you can tell me any difficulties you are having in adapting mojoPortal to your culture.

The approach I took to solve the label and button problem is to store the labels in configuration files that can easily be edited in a text editor.  I view all text and images within a site as content and believe content should be easily editable and not require any recompile to change.  Content varies by who is authorized to edit it and the frequency at which it will be changed.  Those factors influence whether I store it in text files or in a database. If you store content in the database, you have to have or build an interface to edit it, where in text files, everyone has an editor.  Since label and button content doesn't change very often and probably only by a web administrator or developer I chose to store the labels and icon settings in a .config text file.  All other content is editable using the content management features of mojoPortal and the data is stored in the database.

If I were running sites for a company that needed web content adapted to different languages, I would not run different languages within one site, I would have a different site for each language even if they were on the same server.  I might have something like spain.mojoportal.com or www.mojoportal.de, but they would be different host names and I would expect that other than initial label setup, the content would be maintained by the users of the site with permission to edit content not by a web server administrator or developer.

I also think that no matter what your culture, all buttons and labels need to be easily editable even if they don't change often.  The Marketing person will come to you after lunch and say they decided at the executive meeting that the button on the "x" page needs to be changed to say "y" even though its said "z" for 5 years.

So what I'm hoping others will help me with is what am I missing? What are the other issues? What else do we mean when we speak of localization? And if I'm missing something, what are the possible solutions?

The problem I see with using resource files is that they do get compiled.  If this were a forms application I would agree with you 100% but with a web application I don't think it is wise to store any content in a compiled format because it requires a someone to be able to compile it again to make changes.  Its not so much about ease of distribution as ease of editing when maintaining a web site.  If images or labels are stored in a compiled resource, it will be very frustrating to the people who are in charge of the content. They usually are not developers and don't have the ability to easily compile anything.

The advantage of my current approach is that you can easily make changes to labels and images with a text editor.

>Joe, I think you misunderstood the meaning of resource compilation and missed the point of .NET localization.
>Compiling a resource is not exatcly the same as compiling an assembly.
Compiling a resource is actually embedding a resource file to produce a satellite assembly.
Wheras compiling a code is producing an assembly. The difference between satellite assembly from
assembly is that it doesn't have any code inside it, but it's just a resource embedded in assembly
(with IL code) yeah just that's it.

--No I don't think I misunderstand that, you still have to compile a .NET Satellite assembly to change a label or image if you store them in a Satellite assembly.
That is a problem for content authors and in my view, labels and images are just content and you should not need a developer to compile anything to make a change.

>Your current approach has the following disadvantages:

>1.  It doesn't support resource fallback. Can you support a scenario like this: First your site is localized
in US English but later a new boss from Australia doens't like some English American he prefers in Australian.
Another boss from Singapore needs Singaporean English style. However some words have got similarities between
them. With resource fallback you just need to create a neutral English Culture to store all the similar English
words and you just add the specific words in Australian Culture and Singaporean Culture. If the code can't find
the words in specific culture, it will automatically look it up in the neutral culture and voila, you make the
job easier for site admin who wants to support a specific culture. Later, If thre's a need to support culture from
Bristish or XYZ English, the admin just add another assembly. So the main advantage here is it's easier to support
specific culture and the most important is This approach is more extensible and reduce redundancy whilst yours is not.

--I am not trying to support multiple cultures in one site installation,
I am only trying to make a mojoportal site configurable to support any single culture.

Microsoft's documentation about localization talks as if it is possible to support many cultures with one site installation, but in actual practice I have never seen a site that does it effectively.  I do not know of a single big player (yahoo, amazon, etc) that doesn't use a different site to support a different culture.
They don't try to do it all in one site.
For example www.yahoo.com supports english culture and fr.yahoo.com to supports french culture.

You typically have different content authors for each site creating content in their native language.
If an english speaking author writes an article in english using the content management features of
mojoportal and a spanish user visits the site, what good is it for labels on buttons to be in spanish
when the content is in english.  If I want to support spanish content I will have a different site with spanish authors so that all of my content is in spanish including the labels and buttons.
In other words I have no fallback for the content in the database so why do I want fallback for the buttons, its all just content and the most important thing is to be able to change it easily.


>2. Can you store anykind of object in config file? As I said, a resource file can be used to store any thing as long as there's a corrensponding MIME type!

-- I only store text in config files. I might store the name of an image file but the image file is stored on disk which is customary for web applications. What other objects do I need besides text and images? If I really need some other kinds of objects perhaps I could see the benefit of storing them in assemblies but with text and images I don't see any benefit and only problems.

>3. Your approach doens't adhere .NET design guideline

--Guidelines are  merely guidelines. I follow them when I agree with them, in this case I don't.
The difference between theory and practice is greater in practice than it is in theory.  I have a lot of experience maintaining large high traffic web sites. Its nice to read guidelines but experience and critical thinking are important too.

>4. Here you missed the point: If you change anything in the config file, ASP.NET will actually recompile the web application, whereas if you just add a satellite assembly the web application doesn't get compiled!

There is a difference between compiling into IL code which produces a .NET assembly and compiling IL code to native code which is done automatically by the JIT compiler.  Changing the web.conf file does require the JIT to re-compile, but this is not a problem because the JIT compiler does this for you automatically and web.config settings are changed infrequently.  It would be a problem if I had to re-compile after making a change to the web.config but I don't.
If I want to change a label and its stored in a Satellite Assembly I must re-compile the dll for the Satellite Assembly. That is a problem.

>So no matter you build Windows Form or Web Form, By adhering localization to .NET design guideline, you take benefits to your application to the max.

--If I were building a WinForms app or even a commercial web app where I wanted to have tight control over the labels and images I would agree, but mojoportal is open source and meant to be easily customized.

I still don't see the benefit of making it difficult for non-programmers to change labels or images.
The problem goes beyond just localization, mojoportal needs to be easily customizable.
In my blog module for example there is a label for the number of blog entries, my label says "Entries" but someone else might want it to say "Posts".  That is not a culture issue just a preference. It really doesn't matter why someone wants to change a label or image, it needs to be easy.

Hendry, no matter if we disagree, I very much appreciate your input and the time you take to provide it.

>1.  You gave an example of translating from English to Spanish.
In this case, of course resource fallback  has no use and it's also designed not for that case.
Resource fallback has advantage in my scenario above (English, Australian English, British English, etc).  
It reduces redundancy in doing localization.

-- Supporting sub cultures within a language is not as important to me as easy customization.
If a site is in english and you speak english, you can read it.


>2. You gave an example of Yahoo/Amazon, yup they're doing localization still in traditional way and they don't use
.NET, do they? If you said you're not trying to support multiple cultures in one site installation then I think
you dont' take advantage of .NET feature.
This is like you do VB.NET programming but still you use On Error Resume Next.
It works but not the .NET way

-- the .NET way as you put it, does not truly support multiple cultures on one site, it only solves one small problem
of images and labels being localized, but the rest of the content comes from the database and is not translated automatically
to the culture of the user who is browsing the site. you speak as if it solves this problem and I am missing out on the solution
but that is simply not true. I don't see the benefit of the site labels and images changing to a different culture if the rest of
the content does not. I am not willing to give up ease of customization to gain that.

>3.  You said in practice you'd never seen multiple cultures in one site. I think you still have to learn alot.
Please have a look at rainbow portal (www.rainbowportal.net).

-- What I said was I have never seen a site that solves this effectively.
As a matter of fact I have used rainbow portal for several years and am a contributor to the project.
If you go to this page on the rainbow site you will see my name as the author of the blog module for rainbow.
http://www.rainbowportal.net/portal/alias__Rainbow/lang__en-US/tabID__3361/DesktopDefault.aspx
It does implement localization "the .NET way" which does not truly support more than one language in a single site.
Yes the labels and images adapt to the culture passed in the headers by the browser, but again the rest of the content
is in whatever language it was entered into the db by the author. If you have a browser cionfigured with spanish
and you visit http://www.rainbowportal.net, all the content except maybe a few labels will still be in english.
If you look at the list of sites running on rainbow there are quite a few using languages other than english,
when I visit those sites they may have a few labels in english but the rest of the content is not in english so
what good does it do me. examples:
http://www.xpas.net/
http://web.olioboeri.com/



>4.  Regarding the compilation, I think I made a wrong reply so you still misunderstood .  In my previous reply,
I discussed about  the disadvantage of config file. Because every changes in config file your site will get
recompiled and I think this is not a good design since many disadvantages come from recompilation process such as
slow startup, lost of session, etc.

-- again, the labels in the web.config are not changed often so this is not an issue of concern

>Now, Back to the compilation that I mean you misunderstood is that you always
thought that .NET resource have to be compiled. It is actually not, .NET offers you many choices to do localization.
If you prefer not to compile, you can use the resource file directly, using ResourceManager class you call static
method CreateFileBasedResourceManager. The best thing here is that you can still take advantage of resource fallback
and no need to change your config file. Most of newbie will think this is easy (similar to your thinking) as one make
the change directly without compilation. However, in practice this way is not popular as the web server locks the file
based resource so to make your changes take in affect, one has to restart/recompile the web (the same as changes in
config but this one isn't automatically happen)

-- Yes I have read that if you don't want to compile you can use .resx files, but as you say there are locking problems with this approach so I don't use it. Also .resx files cannot be easily edited with a text editor at least if images are stored in them so this would not solve my primary concern of easy editing.


>5. The way mojoPortal does Localization actually isn't easy and extensible (see the case in 1)

-- You place more value on supporting sub cultures within a language than I do.
I disagree, mojoportal is quite easy to customize with a text editor and I am trying to preserve that.


>6.  You'll never know until in the future, of course we don't have to think much for the future, so the matter
here is your design extensible or not. If your design is extensible then anything can be handled without much ado
and changes.

-- Yes I cannot solve problems until I know about them so I don't pretend to. If you can identify a specific problem
I will try to think of a solution. I can think of lots of other files that might be part of the content,
.mp3, .swf etc, but they should all be stored in the file system, not in resource files.

-- If I really need some other kinds of objects perhaps I could see the benefit of storing them in assemblies
>7.  If you think that way then you dont' undertand the concept of separating the content from code. I prefer to
store any objects related to Presentation Layer (UI) off the assembly, I choose .NET resource file to store them.

-- my content including labels and images is definitely separated because it is not stored in an assembly

>As I noted above, you can see how Rainbow portal does localization and takes benefit of .NET localization to the max.
They even made a special project (Esperantus) to make the localization easy. We must admit that current version of VS.NET doesn't support much localization in WebProject compared to the WinForm Project which is much easier. The complication of localization (as what you always said) due to lack support of VS.NET but not because of .NET Localization architecture which is very great and flexible. Because of this many 3rd party tools arise to make localization easy for VS.NET  web projects. The Rainbow localization engine (Esperantus) is also made to support easy localization for Rainbow portal.
BTW, you can also use this engine if you prefer it since it's open source (sf.net/esperantus), however, I think it's
a brandmark for the Rainbow portal.

-- as I said before, rainbow does not truly solve multiple language with one site, you can't just change labels and images
and say it supports a different language when the rest of the content is still in the original language.

>Ok, Joe as I said no matter you like localization the .NET way or not, it's up to you where you want mojoPortal goes
for localization. You can choose the traditional way as what Yahoo/Amazon site does or you can choose the .NET way
which is the modern yet easy way

-- yes I choose a traditional way because the .NET way doesn't really solve the problem, only a small part of it.

In spite of not agreeing with you, I have found this discussion very beneficial and very much appreciate your time.

Kind Regards,

Joe

I think we both would agree that someone here needs a paradigm shift, we just disagree about which one.
 

> Yup, but you're not the author of the rainbow core. If you've got some time you can have some chit chat
with the core team to discuss about localization

-- I only mentioned rainbow because you threw it out there as if I was not aware of it.
The fact that I did not write the core in no way diminishes my arguments.
If you think rainbow is the pinnacle of good design then use it.


>yes I choose a traditional way because the .NET way doesn't really solve the problem, only a small part of it.
3. Please learn alot, have some .NET articles would be good for you.
You can read this one to open your eyes:  
http://msdn.microsoft.com/asp.net/community/authors/mlb/default.aspx?pull=/library/en-us/dnaspp/html/aspnet-globalarchi.asp

-- that article is more of the same and does not address my points



> The way you think you do localization is actually not a localization, it's actually a string/text customization.
Localization actually beyond just changing label or text , it also affects Number format, Date Time Format,
Currency format ,etc.

-- 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.




>Based on that, Rainbow  definitely supports localization while MojoPortal only supports string customization so
I'd suggest you that you can change the localization in the MojoPortal feature list in the HomePage with easy text
customization feature which I think more appropriate for MojoPortal now.

-- your opinion is duly noted here for all to see and make their own determination, I will keep my own counsel on this.



In my arguments I have stuck to the specific issues while you have thrown in subtle little insults such as suggesting
my thinking is like a "newby" and telling me I have a lot to learn.
You are free to think what you want as am I.
Everyone can always learn more including you.

I think you are overly enamoured with the .NET localization guidelines as are many others.
I say its works for Winforms and console apps but falls miserably short in web applications.
I follow the KISS principle and know from experience that anything you want to be able to change easily for a web application
should not be stored in a resource file.

>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!