Hi all,
Looking at some of the posts in this forum, I thought it might be
worthwhile to talk about the Multi-Language support that the company I
work for has been working on, considering it has been a very important
focus for us.
We decided to approach the dynamic content localization in three
distinct steps. Portal, Page, Module. For a language to be supported by
each step it must be supported by the step before it. The portal must
support a particular language (added in the standard way) before a page
can support a language, and a page must support a particular language
before a module can support it. At the same time all modules on a
particular page do not have to support all the languages that the page
supports (and the same for page to portal).
This creates a very flexible multi language site in that a page may
support Chinese for example, but a particular module (say an image
module) that does not need to be localized or a module that does the
localization smarts itself only need be created once for all supported
languages.
As the majority of the people that view our site do not login, we
needed to approach the multi-language support from someone with no
access. The idea is that through the url and cookies that a user will
choose their desired language (simply using common concepts used by
many other companies - a dropdownlist with all supported languages for
that portal for example). This then sets the thread culture meaning
that any static content localization within the modules is supported as
well. A fallback mechanism much like what is available in the static
localization is implemented as well, whereby if a user goes to a page
that does not support their language it will be attempted to display
the page in as close a language as possible - until eventually settling
on the portal default language.
HOW WE IMPLEMENTED IT
The main aim of our Multi-Language support, was to be able to support
all modules regardless of type, and regardless of whether we had the
source code or not for these modules. We also needed to provide
localization support for some page settings as well.
To localize the modules we looked at how they were supported and
created within the database. What we came up with was to support
localization at the base level. Each time a module has a new language
added a "New Module" is created with a reference back to its native
module and the language it supports. From here whenever the module is
edited or displayed PortalModuleBase is given the correct ModuleID for
the currently selected language. The advantage of this is two fold. The
module itself has no idea of the language that it is currently in, only
its ModuleID. This means that without doubt the module will work as the
module creator intended, regardless of what language is select. All
localized module information is also kept in the modules table, with
only two column changes (nativeID and languageCode) and there is only
ever one database call per language request (as long as you remain in
the same language throughout your browsing - there is absolutely no
difference database call wise compared to a non localized site). This
flexibility of course also means that you are not tied to the content
of one language for a particular module. If I have a certain TEXT/HTML
module in English that has "this is a porcupine", there is nothing
stopping me from adding German support with text that has "this is a
spiky thing".
As Module Settings are also tied to the ModuleID - localized modules
can also have different settings (currently not implemented yet - we
use the nativeID to generate the settings - meaning all languages of
the module have the same settings. The idea however is to offer the
flexibility of both these choices).
At a page level - a simple xml file defines what can be localized of
the pages settings. These are then simply added to a new table in the
database, and when a request for a page comes through values are
overwritten in a fallback fashion again.
FUTURE PLANS
Our project is still very much in its infancy, and we are wanting to
add many new features. For example fully localized support for all page
and module settings (including user permissions - person A can edit
German but can only view English for example), as well as an interface
for those modules that do want to know what language it is currently in
to be able to implement. This would allow such things as export/import
sheets for languages (of particular use for HTML/Text modules) where
translation may occur externally. Export sheet -> get text
translated -> import sheet. Voila one translated module. Also a
notification system, where if a content in a particular module is
changed for a certain language - a user or role can be notified - to
let them know that other languages may need to be changed.
WHAT WE WANT
Nothing! I haven't come here to try and sell you a product at the
expense of this project. Rather this is very important for our company
as we have offices and customers worldwide. We want to provide what we
have worked on completely open source if you desire, and to offer our
assistance in getting this project up and running, as it is in our best
interest as well :D. I have provided a few screenshots of the
multi-language support working on our development site here :
http://www.altium.com/files/images.zip . I apologise for the skin
control, it has been created for the sole purpose of adding content to
the site - and has not been prettied up. If anyone is interested we can
set up a demo site with it working as well, It is currently operating
with DNN 3.11, and will have to be reeingineered to fit in with the
projects of 3.2/4.0. Regardless we look forward to helping with the
creation of this project whichever way it goes.
Cheers
Richard Young
Software Engineer
Altium Limited