Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsLanguage PacksLanguage PacksContent Localization: PeterContent Localization: Peter's approach
Previous
 
Next
New Post
9/24/2005 3:41 AM
 

Hi All,

This is to discuss the proposal I've put forward on http://www.bring2mind.net/Company/DNNCoreProposals/DynamicLocalization/tabid/150/Default.aspx for content localization. The pros are (IMHO) that (1) it is very generic (single API call), (2) simple, (3) cascading is done in db. Let me explain the latter: in static localization the cascading is done in code: English is loaded, the portal language is loaded over it, the user's after that, and everytime something overlaps, it is overwritten. My hunch is that this is quite expensive and not feasible for on-the-fly text finding. So I've done it in an SQL procedure which takes as input the desired language and the portal default language.

Cons are that you need a call for every single text. So if you have a table with 10 records with 10 localizable entries, you need 100 calls to the db. In reality you won't have this off course, but it highlights the scaling issue.

I have implemented this in a test environment and will be making it available soon.

Peter


Peter Donker
Bring2mind http://www.bring2mind.net
Home of the Document Exchange,
the professional document management solution for DNN
 
New Post
10/1/2005 4:12 PM
 
Peter,
I like your approach because it's very easy to implement like an API, but will need that, even in the admin pages, the user stores all value in a common table: each "public" text (html/text, links, downloads, forum, contacts, and so on) will be stored in the same table.

My idea is that a better solution will be to have the core support localization of the "general" text (tab name, portal name and desc, and so on) and then each module will have to handle the localization itself, implementing a (ILocalizable) interface.

This way each module developer can decide the best way to dynamically localize its contents.

that's my 2 cents...

I was trying the 3 localizer available (tiendaboliviana, apollo, GR)...
for the moment the winner is the one from tiendaboliviana, but it localize only the "general" texts, but not the contents...

If I find enough spare time I'll try and lay out a more formal document with my thoughts...

Simone

Any sufficiently advanced technology is indistinguishable from magic
"Life is short, play hard"
 
New Post
10/1/2005 5:29 PM
 
Just came back from a saturday evening, and while eating my icecream (yeah, I know it's weird to eat icecream in october with 10°C) I was thinking about my previous post...
and I found out an even easier solution for dynamic localization:
  1. the tabs names, portal names, module names and this general things are localized inside the core
  2. the contents are not localized, but just replicated one for each language, and then displayed to the user with a method similar to the one used for roles
Let me explain:
the important thing is that if a user clicks on a link, he is taken to same page whichever language he speaks, so it's important the the tab with id 698 always takes to the core team page.
But this page can include as many modules as are the locales of the site, and each module shown just to people using that locale.
User reading en will see module with id 1903, users from italy will see module 1904, and from spain will see 1905.
The only drawback is modules with an interaction with the user, like the download (this way, to count the number of downloads, you should sum up all download from each locale) or like the forum (but generally forum are 1 for all language, or 1 for language, so the separation is a good idea).

I came out with this solution becuase it will work without the need to modify all existing modules... this way you can just use the same modules as you are using now.. so this can lead to a better transition from the no-localization to the all-localization.

What do you think?
Simo

Any sufficiently advanced technology is indistinguishable from magic
"Life is short, play hard"
 
New Post
10/2/2005 3:32 AM
 
simonech wrote
Just came back from a saturday evening, and while eating my icecream (yeah, I know it's weird to eat icecream in october with 10°C) I was thinking about my previous post...
and I found out an even easier solution for dynamic localization:
  1. the tabs names, portal names, module names and this general things are localized inside the core
  2. the contents are not localized, but just replicated one for each language, and then displayed to the user with a method similar to the one used for roles

Let me explain:
the important thing is that if a user clicks on a link, he is taken to same page whichever language he speaks, so it's important the the tab with id 698 always takes to the core team page.
But this page can include as many modules as are the locales of the site, and each module shown just to people using that locale.
User reading en will see module with id 1903, users from italy will see module 1904, and from spain will see 1905.
The only drawback is modules with an interaction with the user, like the download (this way, to count the number of downloads, you should sum up all download from each locale) or like the forum (but generally forum are 1 for all language, or 1 for language, so the separation is a good idea).

I came out with this solution becuase it will work without the need to modify all existing modules... this way you can just use the same modules as you are using now.. so this can lead to a better transition from the no-localization to the all-localization.

What do you think?
Simo

Simo,

Your approach would work for relatively simple modules like the ones included in the core. More complicated modules will be left stranded without a localization solution. Let me explain:

My document management system offers content based in its own hierarchy. Documents uploaded can be tied to a specific locale. I would then decide whether or not to show the document based on locale. This would not require a localization API from the core, agreed. BUT ... then we still need to localize the collections  (folders). Now, my point is that my module needs localization in its own internal working and has its own intelligence with regard to locales. It is not an option to hide or show multiple versions of it on screen as this removes this ability from my module.

So you see: the challenge is to come up with a generic solution that goes all the way, if you like.

Peter

PS. This thread is for discussing the merits of the solution I posted. If you have any more ideas, please post them in another thread, so we accumulate a nice set of separate threads for various ideas. Give it some meaningful name and we'll all happily discuss it. Thanks for your contribution.


Peter Donker
Bring2mind http://www.bring2mind.net
Home of the Document Exchange,
the professional document management solution for DNN
 
New Post
10/2/2005 3:48 AM
 

simonech wrote
I like your approach because it's very easy to implement like an API, but will need that, even in the admin pages, the user stores all value in a common table: each "public" text (html/text, links, downloads, forum, contacts, and so on) will be stored in the same table.

I'm not sure what you mean by 'even in the admin pages', but static texts will still be localized as they are now. My point is exactly that everything is stored in the same table. I consider this not the weakness, but the strength of the proposal. Maybe you could elaborate on why you think this is worse.

simonech wrote
My idea is that a better solution will be to have the core support localization of the "general" text (tab name, portal name and desc, and so on) and then each module will have to handle the localization itself, implementing a (ILocalizable) interface.

This way each module developer can decide the best way to dynamically localize its contents.

The goal of the content localization effort is to provide module developers with a generic API that they can easily use to implement content localization. What you're proposing is to separate core from module in this respect and 'each do their own thing'. I strongly disagree with that as I believe this will lead to (a) a multitude of localization solutions with each their own performance penalty, and (b) probably a great number of extra tables in SQL as module developers create shadow tables with localized content. The latter is personal taste, as I prefer to keep the number of tables to a minimum. As an extra note to the objection made: have a core API does not prevent module developers from creating their own localization solutions, it is just there for them to use.

Peter

 


Peter Donker
Bring2mind http://www.bring2mind.net
Home of the Document Exchange,
the professional document management solution for DNN
 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsLanguage PacksLanguage PacksContent Localization: PeterContent Localization: Peter's approach


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out