Wolf CMS - Stable Release: 0.7.5-SP1
You are not logged in. Please login or register.
I have decided to do a website in two languages.
Well now, what is the better method for doing so:
1. with page parts
2. or like separate folders www.mysite.com/en and /hr
If someone has some new ideas, please share. I'm opened to all suggestions.
It would be nice to have tuupola's input here -- he has a site up in five languages and it looks very tidy, too! (Nice nav, as well.)
There was a "page-parts" method for this worked out for Frog before the fork. Have you looked at that one? Maybe we should document that approach in the wiki....
If you want my opinion / preferences... see the related issue on multi lingual support.
Tuupola's method is very nice too by the way but it means you'll never be able to have one entry page for all language (there can only be one index.php root)
It also means that if you have a page called "Contact" it might not be translatable. Both in English and in Dutch you'd call the page: "Contact". A perfectly fine name but you can't use it because it is more or less "language neutral" as it were.
Also a thing to keep in mind would be that Tuupola's approach (as far as I can tell) would mean you have a page per language... in his case it isn't a huge problem since much of his content was subdivided in translatable/translated directories... but if you have a very flat site but with lots of languages, you'd drown in Pages.
Just some things to keep in mind.
Thanks guys for reply.
Well David, I have seen that tuupola site, and it is very nice, little complicated on the first view, as he putted the language switch far down. I have looked that post on Frog for page_parts, it's not too complicated but if you put breadcrumbs to show where you are, it will show you always just main language(just thinking, not too sure) but that is not problem.
Martijin, in what upcoming version you think this will be included? If you'll build it in the core, than there is no need to try to make some sort of plugin 
Page parts system is close to something like this http://wordpress.org/extend/plugins/qtranslate/ only this plugin adds eg. /de like folder structure as Martijin is suggesting (if I understood correctly)
Sooo, we need to figure out something between that two versions.
I have looked that post on Frog for page_parts, it's not too complicated but if you put breadcrumbs to show where you are, it will show you always just main language(just thinking, not too sure) but that is not problem.
I still have the test site up where I tried that "page-part" technique. If you used "title" values for your breadcrumbs instead of a dedicated "breadcrumb" (it defaults to the same value anyway), then you could get your unique language data that way, I suspect. (Not 100% sure, though!)
@Martijn - sounds like you have something pretty interesting up your sleeve (again!)!
Martijin, in what upcoming version you think this will be included? If you'll build it in the core, than there is no need to try to make some sort of plugin
I haven't planned it in yet. But I am planning this for the core since I feel multilingual support is important enough to have in the core... after all, we're living in a wonderful world with something like 6912 living languages...
only this plugin adds eg. /de like folder structure as Martijin is suggesting (if I understood correctly)
Sooo, we need to figure out something between that two versions.
You understand correctly.... though its really a two-fold feature... it gives you a choice: if you prefer to put your translations into page parts, you can use those. If you prefer to create a new "subtree" of pages for your translations, you can use that. Just alter a setting in config.php or the admin backend.
Could someone give a detailled description of the two methods to get it work NOW!?
I know this is an issue for coming versions but this cms is so wonderful that this feature should be possible anyway.
Thanks guys.
zalubom
I'll try to make something in upcoming week, as I'm doing a redesign to my site so will do some experimenting with page_parts or copy tree. Didn't decided yet.
But either way that should go into wiki until it's not implemented.
@ David - will try with $this->title() or something else. Good idea, hope will work. BTW, your multisite is working great.
Last edited by jackie (2009-11-03 13:18)
@ David - BTW, your multisite is working great.
Glad to hear it! If there is interest, I could try documenting that technique for Wolf in the Wiki ... what do you think? (Not until the weekend at the earliest, though!)
That would be great. And I'll try that with title, and if it works I'll just update previously wiki article 
I personally think Wolf already has good multilanguage support because:
It enables translating the urls
This is good for Google. This is good for SEO. Having translated url is a small detail which says the developer of this site has paid attention to detail. Consider this example:
http://www.example.com/en/contact
http://www.example.com/fi/yhteystiedot
http://www.example.com/ee/kontakt
is better than
http://www.example.com/en/contact
http://www.example.com/fi/contact
http://www.example.com/ee/contact
It has unique url for each language
Again good for Google. Good for SEO. Makes the url prettier. Of course you could pass the language in query string like:
http://www.example.com/contact?lang=en
but this is pretty damn ugly. Worst thing you can do is pass the language variable in cookie or session and have one url for each language:
http://www.example.com/contact
It enables having different site structure between language versions
When you have multiple language versions it is quite rare that site structure between them is 100% same. If you do language versions using page parts you are forcing each language to have 100% same site structure (or add yet another configuration option somewhere stating This page does not appear in Spanish version)
It does not clutter user interface
Currently multiple languages are supported without adding any extra fields into user interface. Imagine having six different languages and six different versions of each form input in the user interface. That will be a mess.
How to do it tell me tell me!
Just write one language version and then copy the whole tree to create another language version. For example first finish the english version:
When everything is done and approved with client create a chinese version by copying whole tree to:
and start translating.
Last edited by tuupola (2009-11-26 13:58)
Tuupola's method is very nice too by the way but it means you'll never be able to have one entry page for all language (there can only be one index.php root)
What do you mean. If you have six different language versions you want them all to be found at address:
? See my above post why this is bad. It is better have separate frontpage for each language. For example:
http://www.example.com/en/
http://www.example.com/fi/
It also means that if you have a page called "Contact" it might not be translatable. Both in English and in Dutch you'd call the page: "Contact". A perfectly fine name but you can't use it because it is more or less "language neutral" as it were.
This is quite rarely the case. And if you partition each language in separate folder it wont be issue at all. When I did Kinema I did not partition languages. This way the urls are a bit prettier. However it would have been easier to partition languages into separate folders.
but if you have a very flat site but with lots of languages, you'd drown in Pages.
You are correct. But then again if you have flat site with 100 pages you should reconsider your information architecture again.
I personally think Wolf already has good multilanguage support... <snip>
I actually agree with most if not all of your post. :-) I'm not planning to add fields or change the interface for multi language support.
However...
When everything is done and approved with client create a chinese version by copying whole tree to
Chinese is an excellent example since it uses a non-western/non-alphabet script... the following is generally applicable, not just to multi lingual but also for internationalization purposes.
Here is where I'm getting "confused": do we accept URLs with non-alphabet scripts?
This would be technically feasible, but I'm not sure on the one hand whether its fully supported by browsers and the HTTP specs and on the other hand I'm not sure whether we could refuse if we really want Wolf CMS to be international?
What it boils down to is: will Wolf support URLs like http://ヒキワリ.ナットウ.ニホン ?
Chinese is an excellent example since it uses a non-western/non-alphabet script... the following is generally applicable, not just to multi lingual but also for internationalization purposes.
Here is where I'm getting "confused": do we accept URLs with non-alphabet scripts?
...
What it boils down to is: will Wolf support URLs like http://ヒキワリ.ナットウ.ニホン ?
Ok chinese was bad example because of funny letters. But there actually is two options.
1) Modern browsers support chinese (and other funny) characters. Following url's work at least with my FF and Safari (most likely wont work with IE6):
However I personally prefer next method...
2) Transliteration is the method of representing letters or words of one alphabet in the characters of another alphabet or script. For example when russian word По-русски is transliterated it will become Po-russki. Thus the url of the page would become:
http://www.example.com/ru/po-russki
To be exact converting from any random character set to latin character set is called romanization or latinazitation. PHP iconv has transliteration support. Although I remember pulling some hair last time I used it...
Last edited by tuupola (2009-11-26 15:05)
I don't know about the domain name part, but it's ok to use non-western languages in the url right now. Wikipedia does it:
are the same that http://en.wikipedia.org/wiki/Content_management_system
Last edited by Juan (2009-11-26 21:44)
I'm not sure transliteration is really an option... If I type "http://ヒキワリ.ナットウ.ニホン" in my browser address bar, I expect it to stay like that... not get transliterated.
Since its probably the way we'll work in the future anyway, I guess we'll need to support to support native script URLs. Actually, Wolf already supports native script URLs to a large extent. There just some lookup stuff going wrong.
Agreed. Although I was thinking more about page slugs not about domains themselves. For example:
http://www.example.com/По-русски
vs
Understood. I was talking about both. (domain and slug)
I guess we could make it an option? Use the native script for (all of) the URL (UTF-8) except when someone chooses to use transliteration? At least to me, native script seems more logical than transliteration.
Though transliteration/romanization is easier on the eyes. (for me at least 
)
Last edited by mvdkleijn (2009-11-27 13:04)
I think what also rules is how the people are used to regarding URLs.
For example chinese: If i search something on google.cn:
http://www.google.cn/search?hl=zh-CN&am … 0&sa=N
I don't get any results with native URLs, there are just transliterated ones. May i be wrong?
Hmm... I looked at the results displayed in that link and I see lots of date and number based pages (mostly in fact) like:
http://www.example.com/article.aspx?aid=734176
http://www.example.com/2009-10-30/244.htmlThis is not transliteration, it is just a way to circumvent the entire problem.
I *did* find native URLs though, like:
http://www.example.com/wiki/%E9%87%91%E5%AD%97%E5%A1%94%E9%94%80%E5%94%AE%E8%AE%A1%E5%88%92Which I also think are not transliterated... just encoded.
I did find a couple which *could be* transliterated, for example:
http://www.example.com.cn/kc/zhuanti/yingxiao/But the work around by using article numbers or publication dates seems far more prevalent.
I tried adding a hidden page to this site with slug '虹' so the url should be: http://www.wolfcms.org/虹.html but I think its the mod_rewrite rules that can't handle this...?
Last edited by mvdkleijn (2009-11-27 16:32)
First of all, as this is my first post here, thumbs up for this magnificient CMS!
…and a question.
I'm building a multilingual website, so this thread is a great insight on the subject, but I think I don't understant exactly what you guys mean with 'The copy tree function'
I'm building a multilingual website, so this thread is a great insight on the subject, but I think I don't understant exactly what you guys mean with 'The copy tree function'
In the administration backend, on the Pages tab, it says "Page (reorder or copy)". We mean the copy link.
It allows you to copy a page and all of its children by dragging the original page to a new location. Also see the relevant wiki topic.
Last edited by mvdkleijn (2009-12-03 17:56)
In the administration backend, on the Pages tab, it says "Page (reorder or copy)". We mean the copy link.
I knew it was a silly question. Thanks a lot!
Posts [ 23 ]