|
|
|
|
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
|
|
|
|
| |
|
|
www.piyosailing.com Joined: 8/1/2005
Posts: 34
|
|
|
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"
|
|
|
|
| |
|
|
www.piyosailing.com Joined: 8/1/2005
Posts: 34
|
|
|
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:
- the tabs names, portal names, module names and this general things are localized inside the core
- 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"
|
|
|
|
| |
|
|
|
simonech wroteJust 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:
- the tabs names, portal names, module names and this general things are localized inside the core
- 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.
|
|
|
|
| |
|
|
|
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
|
|
|
|
| |