| View previous topic :: View next topic |
| Author |
Message |
jens
Administrator
Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany
|
 Posted: Wed 12 Mar, 2008 10:38 Post subject: about i18n for the cms page contents... |
 |
|
In v0.9 i would like to add a support for multi language cms page contents: http://trac.pylucid.net/ticket/131
But how to do this?
I found the TransDB project: http://code.google.com/p/transdb/ It's very simple:
| TransDB wrote: | Techincal information
Internally data is stored in database as a string in dictionary format, for example:
u'{u'en': u'This is english', u'ca': u'Això és català'}'
Field uses a subclass of unicode class, adding a raw_data attribute to store the string with all languages, and implementing the get_in_language(language) method to allow access to a diferent language (diferent from the user's current language). |
TransDB are only two files, see: http://transdb.googlecode.com/svn/trunk/
But i think it's not a relay good idea to make it in this way...
We must split "Page" table into text content and meta data.
From the old forum tread "Page History...": http://pylucid.org/phpBB2/viewtopic.php?t=194
| Jens wrote: | All continuous data remain in the PAGE table. All language specific data went into a separated model.
The language specific data are: "content", "name", "title", "keywords" and "description"
Some open questions is the menu. I would like to have a language specific menu. But whats about pages, how aren't exist in the current language? Or should we store the page name in always in the "default" language? |
_________________
http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de
|
|
| Back to top |
|
 |
rantaaho
Joined: 09 Jan 2008
Posts: 47
Location: Kuopio, Finland
|
| Posted: Wed 12 Mar, 2008 21:42 Post subject: |
|
|
I don't think that TransDB could be a solution.
Separating page context and meta data requires more work but I believe that it will lead to better end results. I think we can require a default language for the site, and every page must exist in that default/primary language, at least name and shortcut(?). If the page context is empty in requested language, a page with links to available languages could then be provided automaticly.
That way menu would always work, at least, with default language. Menu might contain mixed languages in case of secondary languages. I don't now if it should be configurable option that pages without translation would not be shown in menu at all. It might lead to quite confusing end results... |
|
| Back to top |
|
|
jens
Administrator
Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany
|
| Posted: Thu 13 Mar, 2008 10:25 Post subject: |
|
|
Good questions.
First of all 1: All i18n stuff should be easy to use and it should not be too much work it to implement  I think, too much to configure works against "easy to use". So we should try to give the user a straight workflow.
How we can use the django ORM for this?
I tried to build a model for this, look here:
http://paste.pocoo.org/show/33260/
or
http://dpaste.com/hold/39224/
Don't know if the relationship between PageContent and Page is the optimum.
In this model the idea is: The user gives the page name always in the primary language. The shortcut of the page is also always in the primary language. The main-/sub-menu and sitemap can use this information.
On the other side: Its boring if the menu points are always displayed in the primary language, isn't it? It cooler, if the menu change the language, too. If we like to do this, we must move "name" and "shortcut" also into PageContent. Disadvantage: Building a menu/sidemap makes more database traffic, or not?
btw. How should permalinks work? I prefer to language independent. A permalink goes to the page, but the page content language dependents on the browser information. The problem is, a permalink contains the page shortcut: http://pylucid.org/_goto/125/internal-links/
If the shortcut dependents on the current language, we have not only one permalink to the page.
One solution: We split Page.name and Page.shortcut -> Page.name stored into PageContent, but the Page.shortcut are generated only from the primary language Page.name...
So every Page has only one shortcut. On the other side: the mainmenu/sitemap can display the language dependents page name...
confused?
_________________
http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de
|
|
| Back to top |
|
|
rantaaho
Joined: 09 Jan 2008
Posts: 47
Location: Kuopio, Finland
|
| Posted: Fri 14 Mar, 2008 08:56 Post subject: |
|
|
| jens wrote: |
First of all 1: All i18n stuff should be easy to use and it should not be too much work it to implement I think, too much to configure works against "easy to use". So we should try to give the user a straight workflow.
|
Agree. That's a priority.
It is really close to the one I had in my mine, so it is good.  What makes you doubt the optimality? There will be two joins but I think it is inevitable.
We could add a timestamp or version number for PageContent in order to have a cheap history.
And then we need this same language separation for templates too.
| jens wrote: |
In this model the idea is: The user gives the page name always in the primary language. The shortcut of the page is also always in the primary language. The main-/sub-menu and sitemap can use this information.
On the other side: Its boring if the menu points are always displayed in the primary language, isn't it? It cooler, if the menu change the language, too. If we like to do this, we must move "name" and "shortcut" also into PageContent. Disadvantage: Building a menu/sidemap makes more database traffic, or not?
|
Yes menu/sitemap must change language. My previous comment was about pages which don't have name/content in requested language, should they show up in menu with name in default language or just be skipped. I think mixed language menu is the most obvious solution from the user's point of view. Although it may require more database traffic.
Thus, page.name should be language dependent, but to have unique shortcuts the page.shortcut must be language independent. If we require that every page must exist in default language (even though it may be just an empty place holder), it is not too bad to require shortcut in default language, is it?
| jens wrote: |
btw. How should permalinks work? I prefer to language independent. A permalink goes to the page, but the page content language dependents on the browser information. The problem is, a permalink contains the page shortcut: http://pylucid.org/_goto/125/internal-links/
If the shortcut dependents on the current language, we have not only one permalink to the page.
|
Other solution would be to drop page shortcut from permalink, it is only there to have nicer looking url, right? |
|
| Back to top |
|
|
jens
Administrator
Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany
|
| Posted: Fri 14 Mar, 2008 10:26 Post subject: |
|
|
| rantaaho wrote: | | jens wrote: | | I tried to build a model for this, look here: |
It is really close to the one I had in my mine, so it is good. What makes you doubt the optimality? There will be two joins but I think it is inevitable. |
Don't know if we can join the tables in a other way, to get a better API to the page and page content data. I'm not a django ORM specialist
| rantaaho wrote: | | We could add a timestamp or version number for PageContent in order to have a cheap history. |
Hm! That makes the page archives redundant. I should not start to implement the page archive yet 
| rantaaho wrote: | | And then we need this same language separation for templates too. |
I have not yet thought of... This make sense if the user has some text in the template.
| rantaaho wrote: | | ...pages which don't have name/content in requested language, should they show up in menu with name in default language |
Agree, there displayed in the default language.
| rantaaho wrote: | Thus, page.name should be language dependent, but to have unique shortcuts the page.shortcut must be language independent. If we require that every page must exist in default language (even though it may be just an empty place holder), it is not too bad to require shortcut in default language, is it?
Other solution would be to drop page shortcut from permalink, it is only there to have nicer looking url, right? |
We use the shortcuts to build the URL line and we append it to the permalink.
In the permalink the shortcuts are only for a nicer look, yes. But a permalink without a shortcut are boring. Only with the ID, the user can't see, if it is the right link.
We have two solutions:
1. Build shortcuts/permalinks only in the default language: The URL line and every permalink is always the same
2. use the requested/existing language: URL line/permalinks exists in different language.
The Question is: What like search engines?
PyLucid used only the page ID from the permalink. The shortcut will be ignored. We can keep this behavior: PyLucid gets the page via the ID, but looks after the page content in the Client preferred language.
To collecting some facts, i start a Wiki page, here: http://trac.pylucid.net/wiki/MultiLanguagePages
Please edit the wiki page and add you mind
I commit a test file with the new models. So we can both edit the file and commit the changes: http://trac.pylucid.net/browser/trunk/pylucid/PyLucid/new_v09_models.py
_________________
http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de
|
|
| Back to top |
|
|
rantaaho
Joined: 09 Jan 2008
Posts: 47
Location: Kuopio, Finland
|
| Posted: Fri 14 Mar, 2008 11:37 Post subject: |
|
|
Just a couple of quick comment:
| jens wrote: |
Don't know if we can join the tables in a other way, to get a better API to the page and page content data. I'm not a django ORM specialist |
The first tricky part which comes to my mind is the use of default language as fallback when building menus. I have some ideas how to do it, and I hope to find time to test them...
| jens wrote: |
| rantaaho wrote: | | And then we need this same language separation for templates too. |
I have not yet thought of... This make sense if the user has some text in the template.
|
Or language specific images. |
|
| Back to top |
|
|
rantaaho
Joined: 09 Jan 2008
Posts: 47
Location: Kuopio, Finland
|
| Posted: Fri 14 Mar, 2008 21:25 Post subject: |
|
|
I read more django-users and came into conclusion that http://code.google.com/p/django-multilingual/ might be a solution.
Should we have a separate branch for i18n testing and development? |
|
| Back to top |
|
|
jens
Administrator
Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany
|
| Posted: Fri 14 Mar, 2008 22:05 Post subject: |
|
|
IMHO it's a problem to use any other django "sub" projects. We add a very big dependence.
Many things duplicate:
* two documentation to check
* finding bugs: It could contain in PyLucid, django or the other project.
* Backwards-incompatible changes in two projects
The other project must be stable and must quick update to the django trunk.
IMHO it can cost more work to use django-multilingual than we implement it self. Don't known if PyLucid is a little to special for django-multilingual...
You can play and test django-multilingual and give more feedback or you can play with the new model file.
btw. We can create a new branch, but on the other side: v0.8.1 is not finished. We should spend our time in the current trunk After v0.8.1 released we can really start.
EDIT: See here: http://code.google.com/p/django-multilingual/wiki/RelevantDjangoBugs
_________________
http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de
|
|
| Back to top |
|
|
rantaaho
Joined: 09 Jan 2008
Posts: 47
Location: Kuopio, Finland
|
| Posted: Tue 18 Mar, 2008 20:38 Post subject: |
|
|
| jens wrote: | IMHO it's a problem to use any other django "sub" projects. We add a very big dependence.
|
You are right.
| jens wrote: | I
You can play and test django-multilingual and give more feedback or you can play with the new model file.
|
I will, at least, check the code. After all general class structure is similar to one we planned. |
|
| Back to top |
|
|
jens
Administrator
Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany
|
| Posted: Tue 15 Apr, 2008 07:36 Post subject: |
|
|
One Problem i found: The page cache and i18n...
We have two i18n things:
* The page content
* gettext strings in templates/plugin output
Now, we have only one page content language. But e.g. the "login" text would be translatet from the django i18n. So if a japan user request a page, the japan version of "login" would be cached and all other request gets the japan version...
A bad idea ist to make this: | Code: | | cache_key = url + cms_page_lang + client_lang |
So we has too many cache variantions...
One idea: connect the page content language with the client language. This is good for the cache system, we must only cache the existing page variants. But the bad thing: We lost many translations gettext translations that is done in django.
On the other side: We can break up the connection if the user log in.
edit: the ticket: http://trac.pylucid.net/ticket/181
_________________
http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de
|
|
| Back to top |
|
|
sepharim
Joined: 27 Dec 2007
Posts: 180
Location: Germany
|
| Posted: Sun 09 Nov, 2008 23:12 Post subject: |
|
|
I want to know how much work is done in this direction.
I have a lot of ideas how to make the ORM. But first i want to know how far you got. |
|
| Back to top |
|
|
jens
Administrator
Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany
|
|
| Back to top |
|
|
sepharim
Joined: 27 Dec 2007
Posts: 180
Location: Germany
|
| Posted: Wed 12 Nov, 2008 10:01 Post subject: |
|
|
as far as I see, django-cms has i18n support. And it has better editing Forms than PyLucid, in my opinion
I like the idea of merging these too, because I had a look at django-cms yesterday, and it is partly clearer structered than PyLucid, perhaps because it is a new design, and isn't as old as PyLucid, but I also like some of the features in PyLucid, so if we merge we get both.
I would like to see more of the PyLucid editing stuff to be in django-admin interface style. That would be also easier to support i18n then.
But that is another point. If the other things I need to get working in PyLucid (Gallery News....) are ready, then I will have a look at that.
But you say, django-cms developer has little time, we have little time, so perhaps we all would profit if we take the two implementation and make some sort of re/newdesign with both Implementations in mind, and then we put the same time in one Project instead of two. I think we would all profit about that. |
|
| Back to top |
|
|
sepharim
Joined: 27 Dec 2007
Posts: 180
Location: Germany
|
| Posted: Sat 22 Nov, 2008 17:39 Post subject: |
|
|
| are you in contact with the main developer of django-cms? because you talked about the idea of merging with them. |
|
| Back to top |
|
|
jens
Administrator
Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany
|
| Posted: Sat 22 Nov, 2008 19:51 Post subject: |
|
|
Yes i have talked with tom. He is generally interested, too. But he has no time
The models in django-cms should be refactored and in PyLucid i need a refactored models, too for the next big release. So it's the best time to merge the two projects.
I have propose a new name, something like: "PyLucid a django-cms." or "PyLucid the django-cms."
_________________
http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
