 |
|
|
dnn.tiendaboliviana.com
Joined: 5/5/2003
Posts: 1126
|
|
|
Peter, thanks for the info. I saw your proposal
I want to comment that my first try to get localization to work was something similar, but I came into the following problems:
- Text sizes: All day a receive suggestions about making titles, comments and other small fields more customizable by letting people to use the rich text box editor. So, small texts need to stores in a nvarchar(xx), but big text, medium text and others.....??? well,maybe we can create a table for each type.
- Localized content: It is know that text is the main content type on each site, but there is a lot of other types of data that need localization too. With my DSLocalizator, I was requested to change the skin, align, etc based on the selected locale. We must think on more complex types of data which need localization (.
Conclusion IMHO: Having a core localization for text is a really good feature, but most modules will need to localize its own proprietary data. So, the core need to help with language detection, search index helpers for localized text and a lot of this kind of functions, but the final complete localization will depend of each module (Content align, RTL specific content for that module, mathematical expressions based on locale, formats ,etc).
My current implementation uses a localekey column in each table I want to localize. Until now, I have two kind of behavior:
- Using a default row for default data and hierarchically connected rows of data with the locale column
- Using only the table that includes the locale column and setting the default locale in the module settings.
Hope this comment to be constructive. Most of you know how desperate I am about content localization, and I will be more than happy to help.
B.T.W. Most data types can be serialized into strings, so this kind of implementation could be taken that way.
Locopon
Free modules: E-commerce, Complete localization (Portal, page, module settings, skins, etc.), Secure Login, and more
http://dnn.tiendaboliviana.com
|
| |
|
|
 | |
|
|
dnn.tiendaboliviana.com
Joined: 5/5/2003
Posts: 1126
|
|
|
locopon wrote
B.T.W. Most data types can be serialized into strings, so this kind of implementation could be taken that way.
Thinking better. If we take every data field and store its localized data in a string field, we can lose some database specific features like normalization, etc.
At this time, the core code don't worry about the kind of data stored in each module's tables. It only provides with functions to make this work easier and some standardization like the moduleid, itemid, etc.
Again, hope this helps.
Locopon
Free modules: E-commerce, Complete localization (Portal, page, module settings, skins, etc.), Secure Login, and more
http://dnn.tiendaboliviana.com
|
| |
|
|
| |
|
|
|
locopon wrote
Conclusion IMHO: Having a core localization for text is a really good feature, but most modules will need to localize its own proprietary data.
So, the core need to help with language detection, search index helpers
for localized text and a lot of this kind of functions, but the final
complete localization will depend of each module (Content align, RTL specific content for that module, mathematical expressions based on locale, formats ,etc).
Yes, but let's not "throw out the child with the bathwater". I would
solve the particularities of maths, dates in code, but text I'd like to
do centrally so that we might even centralize the searching of it. Just
a thought .. So my argument is that while I recognize that modules
might have to do some stuff in their own way, a centralized
localization could take care of lets say 90%.
My current implementation uses a localekey column in each table I want to localize. Until now, I have two kind of behavior:
- Using a default row for default data and hierarchically connected rows of data with the locale column
- Using only the table that includes the locale column and setting the default locale in the module settings.
Hope this comment to be constructive. Most of you know how desperate
I am about content localization, and I will be more than happy to help.
B.T.W. Most data types can be serialized into strings, so this kind of implementation could be taken that way.
Some of my tables are too big and the application too complex to do "shadow rows". I'd have a major headache to do it this way.
It's great this thing is so well discussed now and I more than value your opinions on what I came up with. Hope everything is well in Bolivia ...
Peter
|
| |
|
|
| |
|
|
dnn.tiendaboliviana.com
Joined: 5/5/2003
Posts: 1126
|
|
|
donker wrote
Yes, but let's not "throw out the child with the bathwater".
Its is not my intention. I just want to let you know some ideas in my mind about thing we need to take in consideration when going forward on this..
I'll be the happiest man on the web if DNN goes with content localization. I always take any ideas in these forums in consideration.
At the moment, I see only a few talking about this, but in the other hand many people are using some kind of solution and this forum is so quiet.
We need more people talking about experiences, so core team will have a lot of input.
Can't wait to see your proposal. Count me in as a tester.
Locopon
Free modules: E-commerce, Complete localization (Portal, page, module settings, skins, etc.), Secure Login, and more
http://dnn.tiendaboliviana.com
|
| |
|
|
| |