New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pi multi-language site structure best practices #336

Open
LoneShooter opened this Issue Oct 3, 2013 · 7 comments

Comments

Projects
None yet
4 participants
@LoneShooter
Copy link

LoneShooter commented Oct 3, 2013

I searched through Wiki and all documentation but wasn't able to find any topic related to creating multi-lingual site (except the i18 translation feature).

Having the ability to create and edit content in many languages is the MUST HAVE feature for any CMS. Unfortunately, only few of them are able to achieve this.

What clients actually want is

So far, I've used different ways to create multilingual site in other CMS described bellow. In both cases the url structure is www.somesite.com/EN/page for english language, www.somesite.com/DE/page for German etc. The key point is that the content of a page could be different for different languages, not just translated with i18.

  1. Structure of the site is the same for different language (i.e. pages can't exist independently in each structure), e.g.

/EN
-category_one
-page_one
-category_two
-page_two
/DE
-category_one
-page_one
-category_two
-page_tow

  1. Structure of the site can be different for different languages (i.e. pages can exist independently in each structure), e.g.

/EN
-category_one
-page_one
-category_two
-page_two
/DE
-category_three
-page_three

I think that three CMS could be used as a good example how to properly handle this issue:

  1. SilverStripe (with SilverStripe framework)

  2. Expression Engine (with CodeIgniter framework)

  3. and surprisingly easy and well solved multilingual feature in free shopping cart - OpenCart

What do you guys think about this and what are best practices for creating a site that will support many languages using Pi?

@taiwen

This comment has been minimized.

Copy link
Member

taiwen commented Oct 4, 2013

Very good point. Have been thinking of multilingual content management for long time, years. Haven't got an ideal solution yet...

@LoneShooter

This comment has been minimized.

Copy link

LoneShooter commented Oct 4, 2013

This inspired me to write an article today about multi-lingual site structure approaches. You can read it at: http://www.loneshooter.com/multi-lingual-site-content-structure-best-practices/.

I also suggest that you take a look at SilverStripe CMS and OpenCart because they have very intuitive way for editing multilingual content as well as great database design to support this (nothing special, but one record per language pointing to "master" content"). Working for years for clients that speak different languages I've found this way far the best comparing to other solutions.

@voltan

This comment has been minimized.

Copy link
Member

voltan commented Oct 4, 2013

I saw some CMS have language field in content DB , All contents modules have it.
By one admin side they control all languages and able to add new languages .

But I don't like this method. I think multi-site system is better. If we can install new Pi for each language ( usr and lib folder is Common ) and Share some tables to all websites ( like user )

@LoneShooter

This comment has been minimized.

Copy link

LoneShooter commented Oct 4, 2013

Voltan,

If I understood correctly, you would like to have separate Pi installation for each language sharing only "common" data, right?

If so, I have to say that it will lead to a lot of troubles. I have been working with similar in-house built-in solutions for clients and believe me it's a pain in the brain. You have to take care of themes, uploaded contents, especially the cache mechanism and valid paths, then permission system and many other "small" things.

I'm not sure what would stay of the current Pi Engine code if we go this way, so I believe that we need to take care only of content structure in the database itself.

@taiwen

This comment has been minimized.

Copy link
Member

taiwen commented Oct 5, 2013

@LoneShooter You are talking about two different use cases: A. Content-first, or multilingual content; B. Structure-first, or multilingual structure.

For multilingual structure, I think @voltan has given the right solution: each language has its own Pi deployment while they share same user base and authentication/authorization, for which the current github branch user, oauth does the job.

For multilingual content, we need formulate or canonize some standard data schema and management interface.

@ghost ghost assigned taiwen Oct 5, 2013

@Marc-pi

This comment has been minimized.

Copy link
Member

Marc-pi commented Oct 5, 2013

about multi-lingual content, could it be a sort of wide category?
e.g. i've a travel agency, i sell flights, hotels, train trips.
i can have a wide cat for FR, one for CN.
i have a wide subcat flights, one for hotels, on for train tickets
i mean a selector in the admin to swipe from one language to another, so it changes the form fields?
you can associate a theme to a wide cat, and deacitivate some modules per wide cat.

i don"t know if Pi-Engine, permits this. if i remember well, Drupal permits this

@LoneShooter

This comment has been minimized.

Copy link

LoneShooter commented Oct 6, 2013

@MarcoXoops, that's exactlly what I want to achieve, but it seems that for now it's not possible. I'm not sure about Drupal, but SilverStripe has all this feature at once.

@taiwen, I'm affraid that I don't really understand differences between: A (content-first) and B (structure first). Could you please provide more information or an example?

I assumed content and structure as the same thing, i.e. the structure is not a subsite (see NOTE section below), but only different site content tree for different languages.

Let's look the following scenario:

I would like to have my site in english and german languages, but some content will be available for both languages, while some other content will be available in german or english only. So the urls will be as follows:

// English lang
mysite.com/en/
mysite.com/en/category-one <--available in both languages
mysite.com/en/category-english-only <-- exists for english site only
mysite.com/en/page-one <-- the same page as for german but with english content
mysite.com/en/page-english-only <-- exists for english site only

// German lang
mysite.com/de/
mysite.com/en/category-one <--available in both languages
mysite.com/en/category-german-only <-- exists for german site only
mysite.com/de/page-one <-- the same page as for english, but with german content
mysite.com/de/page-german-only <-- exists only for german site

So, for this situation I don't want to have two Pi instances (neither my clients do in 100% of their requests!). What we actually want is:

  • to have two site trees for two languages (not installation instances!)
  • to change between these site trees (i.e. languages) in admin panel (e.g. site tree for different languages can be available as a drop-down list, see attached screenshot below)
  • to be able to have different as well as the same content for different languages at the same time (e.g. page-one can exist both in english and german site tree, but page-enlish-only exists in english site only. Important thing here is the ability to make page-english-only available for german site if we want to with a simple editing of it in german language content tree.
  • admin panel labels will not be changed when content language is changed. Admin panel labels are part of the language pack for CMS itself.

It sounds complicate but it's actually very easy and simple to solve. Just look how SilverStripe CMS implemented all these requests without any problems and duplicated files and instances etc. The screenshot represents language tree switcher in admin panel for a client of mine:

silverstripe-language-tree-switcher

NOTE:

I'm not talking here about subsites (subsite definition: "A subdirectory of a Web site that is a complete site."). In the scenario above the site in english and german languages is THE SAME site just with different content and tree structure, and NOT separated websites. If a user want to have completely different logic for different sites together with different content types and basically completely different site as a part of existing site then the new instance or partial instance files need to be used.

I hope that I was clear in explanation what I would like to achieve for my clients and myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment