Hi dear @spi,
We already have an article regarding the implementation recommendation and you already commented and gave your insight there.
Sure thing as our development team mentioned in the article they are doing their best.
Rest assured that we will announce the ETA as soon as we have more information from our development team.
Thank you for your follow up.
Kyle chimed in recently on this point over on that thread.
Hi Alexander, as I understood correctly the same issues apply to X as well? If not I’d formally request a license change from Pro to X. We are heading into October now and no update has been released yet. The issue has been put forward (but has been existing already longer) on the 2nd of August. So, enough, I need to get on with my business. Thnx
Hi there,
The WPML works correctly if you set the language mode in WPML from parameter mode to directory mode.
Using that workaround you can translate whatever you have in the content and Pro Builder.
The one that is in question is the Header/Footer Builder and how to implement the WPML functionality there.
If you still need to change the license kindly open up a separate thread and we will follow up the case with you.
Thank you.
Well, at least with me it is not. Having made two pages they aren’t visible whatsoever. I’ll open a separate thread for the license change.
We’ll be happy to assist you with that @Zilchbiz. For anyone else who is curious about the direction things are taking, make sure to read through this thread:
Hi guys,
Updated support for WPML in the new content builder. The “Edit {post type}” links now route you to the correct language of a post.
Does that mean that the content builder is now “fully” compatible with WPML? or are there still bugs to fix?
Thanks.
Yes, the content builder is fully compatible.
It is maybe compatible with WPML, but still not with Polylang.
Rad had told me that once the permalink problem solved, it would also solve the problem with Polylang, but it doesn’t.
Worse, I had found a solution by changing all my pages URL from domain/en/page_name to domain/page_name which worked ok with previous version, but doesn’t anymore.
Now I have to disable Polylang each time I have to edit a page… !!!
Is anything planned about this? Any ETA? Should I do another post?
Updated with latest version Cornerstone 2.1.2 and Theme X 5.2.2 = Still NOT working
I’m sorry you’re having trouble here. We’ve not made any changes in regard to Polylang. We officially integrate with WPML, so that’s taken priority. I don’t have an ETA on when things will work with Polylang but we will investigate what’s possible from our end.
@alexander This is something that we talked about right when PRO was released, and you pointed us in the right direction for us to create a solution for it. It’s similar to #1, and it works by hooking into the Filter that you already have in place in the architecture (cs_match_header_assignment). Here is the code to review for anyone interested, in full plugin form,and can be copied and pasted should anyone want to use it.
This solution is so that we could have multilingual headers for the taxonomy pages, but this should work for any page. To make it more “user friendly” you could use WPMLs “get langauges” api functionality, create a drop down box in each header or footer, and assign an existing language. But, despite no WYSIWYG interface, the naming convention works quite well. Note that our solution allows for headers to be localized not just translated. This is huge in that different content, including layout, message, images, etc, can be served per language and not just translated content.
<?php
/*
Plugin Name: Tourism Builder Custom Archive Pages
Plugin URI: http://tourismbuilder.com
Description: Dynamically generated taxonomy pages
Version: 1.0
Author: Blue Presley
Author URI: http://tourismbuilder.com
Text Domain: tb_custom_archive_pages
Domain Path: /languages
License: GPL-2.0+
*/
// https://codex.wordpress.org/Function_Reference/get_queried_object
function tb_category_header_assignment($match, $assignments, $post) {
if (is_archive()) {
$term = get_queried_object();
//var_dump($term);
// get posts of type cs_header
$args = array(
'posts_per_page' => -1,
'offset' => 0,
'orderby' => 'date',
'order' => 'DESC',
'post_type' => 'cs_header',
'post_status' => 'tco-data' // <-- IMPORTANT - custom post status!!
);
$cs_headers = get_posts($args);
//var_dump($cs_headers);
// First check to see if there is an exact match for the header
// If so, this allows for a header to be "localized" rather than
// just translated; meaning, it's possible to deliver completely
// different header content on a per language basis, including even images and layout.
//
// This is not for just multilingual capability. This funtionality
// allows category pages to also have custom headers created via the
// wysiwyg editor
foreach ($cs_headers as $key => $header) {
// print $header->post_title;
if (strtolower($header->post_title) == strtolower($term->name)) {
//print $term->name;
$match = $header->ID;
return $match;
}
}
// If a match is NOT found, then check to see if a header already exists
// in any language (most likely the source language). If so, use that
// header. This eliminates the need to duplicate headers for each language
// Also, this function should not fire if WPML is not enabled
// get a list of all currently active languages
// We're looking for the Key here since WPML returns the lang as the
// key.
$langauges = apply_filters('wpml_active_languages', NULL);
global $sitepress;
foreach ($langauges as $key => $language) {
// for each language check to see if a translation is available
// if so, use it as the match and return
// https://codex.wordpress.org/Function_Reference/get_category
// watch out for gotcha: https://wpml.org/forums/topic/how-to-get-the-translated-taxonomy-object/
$foreign_cat_id = apply_filters('wpml_object_id', $term->term_id, 'category', TRUE, $key);
//echo "$foreign_cat_id, ";
remove_filter('get_term', array($sitepress, 'get_term_adjust_id'), 1, 1);
$category_object = get_category($foreign_cat_id);
add_filter('get_term', array($sitepress, 'get_term_adjust_id'), 1, 1);
//var_dump($category_object);
foreach ($cs_headers as $key => $header) {
//print $header->post_title;
if (strtolower($header->post_title) == strtolower($category_object->name)) {
//print $category_object->name;
$match = $header->ID;
return $match;
}
}
}
add_filter('get_term', array($sitepress, 'get_term_adjust_id'), 1, 1);
}
return $match;
}
add_filter('cs_match_header_assignment', 'tb_category_header_assignment', 10, 3);
With that said PLEASE code functionality into PRO architecture that allows assignment of headers to category pages!! :slight_smile 
Getting multilingual headers to work was pretty simple for simple applications. You can see it in action here with PRO http://dev.bluepresley.com/ozora/category/accommodations/
What has been a problem, and what ultimately has led us to have to advise clients to stick with X is the lack of translation support for the new WYSWYG interface. Also, in places where there were text boxes, these were not coded in a way that WPML could detect. (that may have changed though since this install is a few months old.) Hope this helps let me know if you have any questions. We’ve played with quite a few hacks to try to get ready to transition our clients from X to PRO.
I really appreciate you sharing this. We’ve been working on something similar (option #1 from here: https://theme.co/apex/forum/t/wpml-update-talk-to-us-about-translating-headers-footers/8756) and are hoping to make it available soon. I’ll take a look at what you’ve done with your code as it may help that official feature move a little faster.
I have 2 languages: english & german
I could just use the english header for now on the german page. Does this work?
Right now when switching to german I have no header or footer.
Hey, thank you for posting this. Since i’m not that much of a programmer I’m trying to find out how your solution works. I just pasted your code into my functions.php.
How do I go on now?
I basically just have a simple header with a menu which has to be german. For now I would also be satisfied if it would just show me the english header & footer when switching to german.
Hi there,
whatever function it will be at the moment it will not be the official one. I strongly suggest that you wait for the official release which will support WPML.
The code is suggested by one of our fellow customers and both us and they will not maintain the code or give further official suggestions till the upcoming major release which will be available soon.
Thank you for your understanding and patience.
Well - my problem is, that I really have to get this website up and running. All I need for now is the header also to appear if i switch the language - I don’t even care right now if it’s english. Since officially everything is compatible with WPML I, of course, wasn’t expecting something like this to happen. So how can I at least quick-fix this?
Since you guys aren’t able to give an exact date for the fix I don’t have anything I can tell my client and have to keep him waiting wich really puts me in a bad situation.
Hi @PhilTone I don’t have an ETA, but it will be solved in the next release that we’re working on right now. The best way to get things working would be to use a classic header until the update is out.
@alexander Sorry for the late reply, but a project is keeping me from being as active as I’d like to be in this thread, as it is of particular interest.
I do have feedback concerning a HUGE problem we have with X / Pro multilingual capabilities. When editing a page, Cornerstone elements are on the left; the page view is on the right. 
The problem is Wordpress treats this entire page as a front end page meaning that the only time the elements on the left are in the language of the user is when the front end langauge of that user is chosen.
What needs to happen is that those elements on the left need to be in the language chosen as the users language in the admin profile (in other words it needs to also be in the langauge they would normally see if they were in wp-admin) This page, for example, all of the CS elements on the left should be in Japanese regardless of the page language that’s being edited on the right.
We’ve experimented with some hacks to enforce this, but it’s buggy at best. CS Editor elements need their own admin text domain that keeps them in sync with the admin language as chosen in the users language preferences on the profile screen. (Like Visual Composer does - see screenshot) If a person speaks Japanese, then that left sidebar should always be in Japanese regardless of what the language is of the page their are editing 
Otherwise, in my opinion, it won’t matter how how well X / Pro supports WPML or is multilingual - a person will never be able to edit a foreign page in his or her native language with the way it’s designed now.
Does that make sense? Hope that helps.
No problem! Thank you so much for taking the time to get that written up and demonstrated for us. It makes total sense. I’ve added a summary of this problem with your notes to our issue tracker. I can’t at this moment give an ETA on when it will be in, but it’s on our radar now.