Feature Request: Multilingual

PatrickPoney commented 10 years ago

Making pagekit natively multilingual would be great.

Eventually, setting up a dedicated language manager extension would be interesting so it would give us the possibility to manage translatable content.

Also if do not need it, we could remove the extension and fallback to a monolingual site.

cbeier commented 10 years ago

Yes, multilingual ist a important feature in these days, also for smaller sites.

tups commented 10 years ago

Meanwhile, it is possible to create a language file for themes ? I tried " ./pagekit theme:translate mytheme " but : [InvalidArgumentException] Command "theme:translate" is not defined.

tastymousehub commented 10 years ago

I agree making pagekit natively multilingual is essential. It would be an extra reason to replace Wordpress by Pagekit.

MacWordPress commented 10 years ago

+1

chrispecoraro commented 10 years ago

I'll take a look at the code and see if it is easily implemented. I'd like this feature, too.

huglester commented 10 years ago

Would be really neat thing to be integrated. Without this, CMS'es are more like "US ONLY" thing for me.

So I +1 for this :)

markushausammann commented 10 years ago

A CMS without multilanguage support is not a CMS.

chrispecoraro commented 10 years ago

I'm taking a look at what would be required to make this happen. Is anybody else working on this? I'm not familiar with Symfony, but I use Laravel so it's shouldn't be too bad. Should we open up a new branch for this?

chrispecoraro commented 10 years ago

To make this happen, several things need to happen:

Visitor side:

The locale (buttons, controls, etc) should switch for the visitor based on the language settings.
The content should be loaded into the correct language, based on the browser settings.

CMS side:

Creating versions of the post/articles/pages in another language should be possible.
There should be a fallback language.

markushausammann commented 10 years ago

User friendly language negotiation:

check client language and serve content automatically in that language if available
if client language can't be detected or is not available, serve fallback language (configurable)
let user always select another language (overrides automatic detection) and permanently store it in DB for registered users, in cookie for guests, nothing is more annoying than a site that forgets what language I chose.

chrispecoraro commented 10 years ago

Markus,

I agree, the only correction is that the client language/locale list is an array:

check client language(s) and serve content automatically in that language if available

Now, let me figure out what type of effort it would be. Do you have any tips? I'm new with Symfony, but not with PHP so I'll just start hacking into my fork.

markushausammann commented 10 years ago

Storing of translations:

choose adapter wisely, you might need/want to provide online translation tools for crowd sourced CMS translations, handle plurals, etc.
break project down in to translation domains that are handled independently from each other (even if that means duplicate translations) e. g. cms-public-end, cms-admin-end
provide translations interface for plugin developers so they can hook into the infrastructure

markushausammann commented 10 years ago

Chris, I'm using Symfony very rarely but I'm sure the translation infrastructure isn't very different from other frameworks. Personally I prefer using the gettext adapter.

Introducing i18n / translatability into a whole CMS is not a small task. Subtasks IMO are:

language negotiation (pretty easy, probably just something like a controller plugin)
language switcher (GUI, pretty easy, one typical mistake is to translate the selectable languages with the rest of the page which is BS, any language in a language switcher should always stay in that language, English, Deutsch, Italiano, etc. otherwise I might need to look for my language in a language I don't understand at all.)
translation adapter (hard choise and lots of work because you basically have to touch every single language string in the whole software, this will give you a good idea about the quality of your DI infrastructure and code readability, it will also force you to use sprintf in case you find stuff like $text . ' - and - ' . $anotherText in your code.
translatability of text stored in DB these are CMS content texts and I guess also a lot of other texts used in the GUI. Here it's important to create an infrastructure that centralizes all translations into one table so lookups can be optimized.

That's all I can think of at the moment. Just a brainstorm because I like the idea of pagekit and I have some experience with translating large infrastructures.

chrispecoraro commented 10 years ago

Markus,

I agree that it is not a small task. I want to tackle one subtask, if possible. I just need to find out where to start.

The translation adapter is already in the code from what I can see, although I've created a issue regarding date formatting fallback.

kamov commented 10 years ago

I can't understand this feature request...

On pagekit already exist localization and content are translatable using what mark said "gettext", using .po files which exist many po editor like poedit or online https://localise.biz/free/poedit

the function name is _() and there is @trans() function for view files.

Which part of pagekit should be translatable?

Content of pages and blogs?

Not sure if this is required by cms core, also WordPress does not support a bilingual or multilingual blog out-of-the-box. There are however Plugins developed by the WordPress community which will allow you to create a multilingual blog easily.

This can be the same for pagekit.

Maybe there is something other that is not translatable which I missing?

tastymousehub commented 10 years ago

Yes, I want translated content and I think it is a mayor shortcoming of Wordpress that it is not native multi-lingual. I don't use it any longer for multi-language sites. The plugins are either not user-friendly or they make the pages load slow. If Pagekit gets multi-lingual and gets post ordering in the blog I intend to stop using Wordpress.

chrispecoraro commented 10 years ago

It should also do browser locale detection and serve up the proper language of the content. To do this, we would need to add a locale code field for the posts.

huglester commented 10 years ago

In our experience, yes it is good to detect users language, but for example in my country 60% users use browser in english, but language is lithuanian. so we separate language by slug.

ALso in-core multi-language would be good because of search modules or something like this. We currently are using PyroCMS with custom multi-lang support.

For us multi-language is not only the translated cms buttons or something. We need to wrtie news for example in differnet languages, pages are in different languge, then search involves searches only in specific language etc...

Thanks Jaroslav

kamov commented 10 years ago

@tastymousehub I understand now.

I found this topic on roadmap here: http://www.pagekit.com/roadmap

They seem integrate this feature but only in Future, after releasing 1.0.0 in first quartar of 2015.

For now maybe someone will prepare an extension for this.

I agree with mark who suggest how to handle this:

check client language and serve content automatically in that language if available

if client language can't be detected or is not available, serve fallback language (configurable)

let user always select another language (overrides automatic detection) and permanently store it in DB for registered users, in cookie for guests

88kbbq commented 9 years ago

Guys, you really need to prioritize multi-language functionality. Like nearly all other platforms, you've left it as an afterthought, and it's gonna get messy. While I'm here, I also want to share that your URL structure needs to steer clear of filler words like "page," "post," "category," etc. These are really a nuisance for SEOs and site owners who want to migrate to a new platform but retain the organic ranking they've worked so hard and spent so much money to achieve. I wouldn't even look at yet another CMS that doesn't support custom URLs and multi-language functionality.

fabianmarz commented 9 years ago

:+1:

lenovouser commented 9 years ago

:+1:

rbarilani commented 9 years ago

:+1:

vizo commented 9 years ago

@88kbbq you are right! :+1

saschadube commented 9 years ago

We released the Pagekit Beta today. I close this issue because the code base completely changed. Please open a new issue if it still exists.

88kbbq commented 9 years ago

Great news Sascha, I'll check it out.

Cheers!

Kevin

On Thu, Sep 10, 2015 at 11:47 PM, Sascha notifications@github.com wrote:

We released the Pagekit Beta http://www.pagekit.com/blog/2015/09/10/pagekit-beta-released today. I close this issue because the code base completely changed. Please open a new issue if it still exists.

— Reply to this email directly or view it on GitHub https://github.com/pagekit/pagekit/issues/173#issuecomment-139287342.

markushausammann commented 9 years ago

But does the new pagekit support multilingual sites?

saschadube commented 9 years ago

No, sorry, this is on the roadmap.

88kbbq commented 9 years ago

Disappointed.

Sent from my iPhone

On 2015年9月11日, at 19:42, Sascha notifications@github.com wrote:

Sorry, this is on the roadmap.

— Reply to this email directly or view it on GitHub.

pepperstreet commented 9 years ago

+1 must-have IMHO

piffpaffpuff commented 9 years ago

+1

it would be awesome, if pagekit gets native multilingual support for the content. this is an absolute must have feature in many countries of europe.

greenweb73 commented 9 years ago

+1

stsepelin commented 9 years ago

+1

MacWordPress commented 8 years ago

+1

Sternly commented 8 years ago

Yeap. I want multilanguage too! Please, please, please))

ghost commented 8 years ago

Should be number 1 priority, IMO.

azakyk commented 8 years ago

+1

lexplatt commented 8 years ago

would be a very advantageous features regarding to other cms; +1

KevinSupertramp commented 8 years ago

Hello,

What do you think about creating an extension that "bridge" multiple PageKit installation ? So you have one PageKit installation for each language ?

88kbbq commented 8 years ago

I could live with that, sure. I do that now for Wordpress. This just creates more work for robots.txt, multi-lingual sitemaps, language switchers, resource caching, and translation work. But honestly, I've given up on CMSs after a stent with MODX. I've moved to straight HTML for nearly all my static sites. E-commerce still Magento, but I'm looking into Ecwid now. Seems they've fixed the SEO problems from a few years back, and I could use Ecwid with PageKit. Anyway, PageKit--too little to late. Failed install 3 times and gave up. If I can install and configure a Magento site and Odoo site in a few hours, this means there are serious issue with PageKit install or the documentation. Anyway, love YooThemes so I just thought I'd share from my experience. Honestly though, if PageKit team can't build a multilingual CMS in 2016, it has no future. Sorry.

On Mon, Jan 4, 2016 at 6:56 PM, Kevin notifications@github.com wrote:

Hello,

What do you think about creating an extension that "bridge" multiple PageKit installation ? So you have one PageKit installation for each language ?

— Reply to this email directly or view it on GitHub https://github.com/pagekit/pagekit/issues/173#issuecomment-168644625.

desvu commented 8 years ago

The programm is useless until it has multilingual function

p4t5h3 commented 8 years ago

Has somebody started working on this? I am asking because otherwise I would evaluate how I could solve it. Just want to avoid duplicate work.

nbpalomino commented 8 years ago

TL;DR: Multilingual feature is in the , so calm down and keep hacking.

So much blah blah blah blah ... from Users who don't even help with this Open Source Project.

People, you have all the source code available, If you cannot make a work-around for multilingual support, then PAY someone else for do it for you.

This is Open Source Software, and not demand-any-feature-asap Software. This is about collaboration, support and in-community growth. It's very sad to see people, demanding a feature, that is in progress, The YOOtheme's team is working very hard for giving us, the community; a beautyful and useful CMS, And some people are behaving so mean.

Anyways, Rome was not build completely in version 0.10.2.

88kbbq commented 8 years ago

My request for multilingual support was made over a year ago, and it's just a shame the awesome people at YOOTheme didn't have the foresight to include multilingual functionality in the original roadmap. Adding extensions and "hacking" page kit won't guarantee multilingual support in extensions/add-ons, so it's really up to the Pagekit team to deliver on this. By no means is this a demand, it's just simply a response to YOOTheme to let them know this new project doesn't solve this age-old problem found in near every other CMS. I've tried RespondCMS and OctoberCMS, both great new CMSs with multilingual support in their core.

stefanpkc commented 8 years ago

:+1: just a thought: when changing the language on the frontend, we could use vue.js to load the language strings. Show a spinner while the ajax request is still loading. On the server side the language settings is changed for that particular user. When he browses to a new page, vue.js isn't needed of course. For this to work, the language strings should be saved in the $data var. Difficulty is perhaps the content, how's that going to be updated by vue.js?

Maybe make a feature branch for this?

huglester commented 8 years ago

@alomvar hello. do you have anything to share maybe?

p4t5h3 commented 8 years ago

@huglester Sadly not. After further evaluation I concluded that I will not utilize PageKit (for now) and thus only keep an eye on the development of the project. However "make it multilingual" is not a trivial task. There needs to be put some thought into answers of the following questions:

How to handle multiple languages in the front-end? Subdomains (in example de.example.org)? Top-level domains (example.co.uk)? URL prefixes (example.org/hu/)?
How to handle multiple languages in the back-end? Have different pages (and site structures) for different languages (more complex management) or have one structure which just gets translated (no language specific structure possible)? Or leave the choice to the user?
How to handle missing translations? Display the content in another language? Just go 404 Not Found? Redirect to front page?
Where to draw the line between complexity and flexibility? Cover every use case or have a more opinionated approach (which stays in line with the elegant simplicity of PageKit)? In example: the first question. Make everything available through configuration or just go with URL prefixes? As far as I know dedicated top-level domains are best in the matter of search engine optimization but apparently only larger companies go that way.
How to enable extensions for localization? I did not look into this but somehow extensions must have a bearable and uniform way of managing their localized content, too. Maintaining them gets awful otherwise.
Multiple languages or locales? In example British English is not equal to American English.
Who is going to decide that? Since we are all interested in a solution that actually makes it into the product it would also be interesting what the maintainer (YOOtheme) think. After all these are also design choices with no clear "that's the only way to go!" answers.

My personal opinion would be to tie translations to content elements like pages. When I worked in PrestaShop in the past it was a nice experience that you can switch easily between the translations right in the editing view. Combine that with a redirect to other translations (by priority list) with an appropriate notification in case of missing translations. In example: redirect to English page, if German translation is not available and display something like "Sorry, only available in English!". The effortful language handling in Joomla! or TYPO3 would not fit PageKit.

stefanpkc commented 8 years ago

@saschadube, not sure who's attention to get from YOOtheme.. It seems there's a lot of people interested in this. For me, I want to use Pagekit for a lot of projects. Only problem is, it's not multilingual and I don't want to "hack" it in. @alomvar and some others have put time in it to raise some questions how this should be done. I think what we lack is some insight in the wishes from the maintainer. Maybe YOOtheme can spend an hour or 2 on brainstorming at the office: shoot some ideas out of the sky or perhaps back some. When there's an idea where we want to end up, we can start a feature branch and people can work together on it. Baby steps people!

Sooner or later almost all of us will end up in the same situation: your project extends to a neighboring country with a different language. For a simple blog it's fine. But for people who want to use Pagekit for a business, or pitch it to their clients.. it's almost impossible. For multilingual you need to change to a different CMS.

What I would like to see is a solution for Pagekit. How do we put this in the core? I like @alomvar's ideas. There should be a method that developers can use to simply add the multilingual feature in their extension or theme.

What's perhaps easy:

the language switcher widget

What's difficult:

Saving multiple versions of content in different languages. What's the best way?

The difficult part (thinking about extensions and themes here): will we have for every page multiple pages in the backend in different languages and link them together. Like Joomla in the main menu? (please don't). Could cause a problem for when people make an instance that's unique and the translated instance is not the same. For example if someone makes a product extension.. which instance will hold the SKU? Or will we have a method where we can add for every language a new textbox on-demand? Something like ZOOlingual. But then nicer (sorry ZOOlanders :smile_cat: )

Pro's and con's anyone?

store in the same table but different record (copy for every language)?
store in a different table (search for other than default language)?
store in same record as array or search in the DataModelTrait?

maybe make a Trait for it? I've no idea :sweat_smile: I want to know what YOOtheme would do

p4t5h3 commented 8 years ago

@stefanpkc I think it is no the time yet to talk about technical implementation details. However storing it in the same table with an additional localization identifier is as liable as having a separate table for the localizable fields (in example hurr_durr_lang localization table for hurr_durr table). However that is technical detail that should be abstracted away by the common base layer. That one could also automatically get the current localization by examining global scope and resolve the appropriate translation of whatever you request (unless locale is defined manually to retrieve other translations).

floriandotpy commented 8 years ago

Thanks for the active discussion and good suggestions! We think that @alomvar has pretty much outlined all the important questions.

In general, we also see two fundamentally different approaches:

Have different pages (and site structures) for different languages (more complex management) or have one structure which just gets translated (no language specific structure possible)

We would currently prefer to allow for different site structures.

For example you would be able to mount a menu to a language prefix in the Site tree. This means you can create different url structures and different content per language, but you could also reuse content across languages, i.e. by linking the blog from different menus. At the same time, it is not exactly clear how and if two items from the different languages would be connected in that solution.

We are currently discussing about this in the team (taking into consideration what has been said in the discussion before) and will get back to you with our ideas in the next couple of days.

pagekit / pagekit

Feature Request: Multilingual #173