Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Thomas Scholz 2:53 pm on 2015/02/11 Permalink | Reply
    Tags:   

    How to get translations programmatically 

    The most important API in MultilingualPress for you is probably the Language API. This API has a method get_translations() that you can use to get a prepared set of translations for posts of any post type, terms of any taxonomy, a search term, the front page or a blog page.

    You can access that API with a filter:

    $mlp_language_api = apply_filters( 'mlp_language_api', NULL );

    MultilingualPress will transform that NULL value now into an instance of the class Mlp_Language_Api. In other words: The variable $mlp_language_api is an object now. But you should still test that, just in case the user has deactivated MultilingualPress:

    $mlp_language_api = apply_filters( 'mlp_language_api', NULL );
    
    if ( ! is_a( $mlp_language_api, 'Mlp_Language_Api_Interface' ) )
    	return;

    As you can see, you should test against the Interface Mlp_Language_Api_Interface, not against the concrete class. This enables other plugins to replace our implementation with a custom translation handler.

    Today, we are looking just at $mlp_language_api->get_translations( $args );

    Arguments for Mlp_Language_Api::get_translations()

    $args is an array, we can pass some options here to tweak the results.

    Name Type Description
    site_id int Base site. Usually the current site.
    content_id int post or term_taxonomy ID, not term ID.
    type string Either post, term, post_type_archive, search or front_page.
    strict bool When TRUE (default) only matching exact translations will be included.
    search_term string If you want to translate a search.
    post_type string For post type archives.
    include_base bool Include the base site in returned list.

    All parameters are optional. MultilingualPress will try to find proper values for them. We recommend to set the content_id for terms and posts though, because that is not always available, at least not in a reliable way.

    Now let’s see how our code could look like:

    $mlp_language_api = apply_filters( 'mlp_language_api', NULL );
    
    if ( ! is_a( $mlp_language_api, 'Mlp_Language_Api_Interface' ) )
    	return;
    
    $args = array (
    	'strict'               => TRUE,
    	'include_base'         => TRUE
    );
    
    /** @var Mlp_Language_Api_Interface $mlp_language_api */
    $translations = $mlp_language_api->get_translations( $args );
    
    if ( empty ( $translations ) )
    	return;

    Note that $mlp_language_api->get_translations( $args ) will return an empty array if there are no translations even when we set include_base to TRUE.

    Now, let’s say the translations are not empty. We get an array of objects, each an instance of Mlp_Translation which implements the Mlp_Translation_Interface. That sounds complicated, but it just means that we have a set of methods on each object to get information about the translation.

    Methods for Mlp_Translation

    Method Return type Description
    get_source_site_id() int The site ID the translation is based on.
    get_target_site_id() int The ID of the site where the translation can be found.
    get_page_type() string Either post, term, post_type_archive, search or front_page.
    get_icon_url() Mlp_Url_Interface An object, an instance of a class implementing the Mlp_Url_Interface. It has a magic method __toString(), so we can cast it to a string and get an escaped URL.
    get_target_title() string The title of the translation, for example the post title or the term name.
    get_target_content_id() int The term_taxonomy_id or the post id. This is empty for other translation types like post type archives or search.
    get_remote_url() string The URL for the translation.
    get_language() Mlp_Language_Interface An object, an instance of a class implementing the Mlp_Language_Interface.

    The Mlp_Translation::get_language() object deserves an explanation. It has three public methods.

    Methods for Mlp_Language

    Method Return type Description
    get_priority() int A number between 0 and 10. See the post about Language negotiation for an explanation.
    is_rtl() bool Whether the translation is in a right-to-left language (like Hebrew) or not.
    get_name( $name ) string Different representations of the language. Default is the language in its native writing, eg. Deutsch for German. We strongly recommend to use that, because that’s most easily to recognize for your readers.
    Other allowed parameters are english to get the English name, http to get the HTTP value (for example de-AT) or custom to get the custom name you have set in the site properties.
    You can also use language_short to get just the first part of a language code with subsets, eg. just de.

    Example: Add translation links to the post content

    Let’s see what we can do with all this code. The following example adds very simple translation links to the post content. It uses the first part of the language code and sets it to uppercase. The images are used too, if they are available.

    add_filter( 'the_content', function( $content ) {
    
        if ( ! is_singular() )
            return $content;
    
        $mlp_language_api = apply_filters( 'mlp_language_api', NULL );
    
        if ( ! is_a( $mlp_language_api, 'Mlp_Language_Api_Interface' ) )
            return $content;
    
        $args = array (
            'strict'               => TRUE,
            'include_base'         => TRUE
        );
    
        /** @var Mlp_Language_Api_Interface $mlp_language_api */
        $translations = $mlp_language_api->get_translations( $args );
    
        if ( empty ( $translations ) )
            return $content;
    
        $links = array();
    
        /** @type Mlp_Translation_Interface $translation */
        foreach ( $translations as $translation ) {
    
            $current = $img = '';
    
            if ( $translation->get_target_site_id() === get_current_blog_id() )
                $current = ' class="current"';
    
            $img_url = $translation->get_icon_url();
    
            if ( '' !== (string) $img_url )
                $img = "<img src='$img_url' alt=''> ";
    
            $text = $translation->get_language()->get_name( 'language_short' );
            $text = mb_strtoupper( $text, 'UTF-8' );
    
            $links[] = sprintf(
                '<a href="%1$s" title="%2$s" %3$s>%4$s</a>',
                $translation->get_remote_url(),
                esc_attr( $translation->get_target_title() ),
                $current,
                $img . $text
            );
        }
    
        $links = '<p class="translations">'
            . join( ' <span class="separator">|</span> ', $links )
            . '</p>';
    
        return $content . $links;
    });

    The result should look like this: Screenshot

    Theme integration

    You can use such a function in other places too, of course. In a theme you should add a custom action wherever you need it and assign a callback handler to that action. This way, your theme will not break when the user deactivates MultilingualPress.

    So in a template file add this line:

    do_action( 'translation_box' );

    And in your functions.php create a callback function and register it for that action:

    add_action( 'translation_box', 'show_mlp_translation' );
    
    function show_mlp_translation() {
        // find and print translation links
    }

    Any questions or suggestions? Or do you have used this tutorial successfully? Please let me know.

     
  • Thomas Scholz 1:17 pm on 2014/10/28 Permalink | Reply  

    How to disable broken save_post callbacks 

    Many plugins are not multisite aware. This is rarely a problem, because each site in a network works almost like a normal site in a single-site installation. But sometimes … things go really wrong.

    There is a hook, the action save_post, that can be called multiple times when a post is saved: one time for each site. Many plugins are not aware of this, they run their own code on every call to save_post without a check for the site context. The result is that they are either deleting user data on the other sites, or they overwrite existing data.

    This happens when MultilingualPress updates the post translations.

    Site A save_post - MultilingualPress {
        creates or updates translations:
        - switch_to_blog( Site B) -> save_post
        - switch_to_blog( Site C) -> save_post
        - switch_to_blog( Site D) -> save_post
        
        return to Site A
    }

    MultilingualPress removes all POST data before the other save_post actions are called, and it restores it when it switches back. Normal plugins use a nonce as a basic security check before they try to save anything. Since we remove the nonce along with the POST data, they will not do anything. So far, so good.

    Unfortunately, some plugin author don’t use nonces. They just try to save their data, without proper context checks. There is nothing we can do about that.

    But you can. You have to find the code (function or class method) that is registered for the save_post action and then remove it earlier. There is another hook that runs right before save_post: the filter wp_insert_post_data. You can hook your own custom callback to that filter, check if the current context is in a switched site and then remove the “evil” callback. Don’t forget to return the filtered value, that’s necessary for filters.

    Here is an example for the Custom Sidebars plugin:

    add_filter( 'wp_insert_post_data', function( $data ) {
    
        if ( is_multisite()
            && ms_is_switched()
            && class_exists( 'CustomSidebarsEditor' )
        ) {
            $cse = CustomSidebarsEditor::instance();
            remove_action( 'save_post', array( $cse, 'store_replacements' ) );
        }
    
        return $data;
    });

    If you are a plugin or theme author and want to be sure that your code is safe to run in a multisite: please contact me. I,or one of my colleagues, will look at it and tell you what needs to be changed.

     
  • Thomas Scholz 8:31 pm on 2014/10/22 Permalink | Reply  

    Manage multisite per command line 

    Sven Hofmann has written a long tutorial in German in which he explains how to use WP CLI to migrate a multisite installation, import content and deal with common problems. I have asked him to split that article into two posts and publish it in English on wpkrauts.com.

    The results are:

    This is incredible useful information. Read it, try it, and speed up your workflow.

     
  • Thomas Scholz 9:37 am on 2014/10/20 Permalink | Reply  

    A basic plugin for MultilingualPress 

    Plugins for MultilingualPress should wait until MultilingualPress is actually loaded. That means they should use a hook provided by the main plugin to be sure that MultilingualPress is running and ready to be used. There are three main entry hooks:

    1. inpsyde_mlp_init: equals to plugins_loaded, 0 plus MultilingualPress loaded. Happens before scripts and stylesheets are registered. The only parameter is an instance of the class Inpsyde_Property_List which holds useful plugin information.
    2. inpsyde_mlp_loaded: Almost the same, but after the scripts are registered.
    3. mlp_and_wp_loaded: equals to wp_loaded, 0 plus MultilingualPress loaded. The first parameter is again the same Inpsyde_Property_List. When in doubt use this action.
      wp_loaded happens after WordPress has checked if the current blog was marked as spam. Unless you want to run your code on spam blogs, wait for this action.

    When we use type hints in our callback function, we should declare the dependency for the first parameter against the interface Inpsyde_Property_List_Interface, not against a concrete class.

    First example

    (All code examples here require at least PHP 5.3.)

    add_action(
        'mlp_and_wp_loaded',
        function( Inpsyde_Property_List_Interface $mlp_data ) {
        // your code here
    });

    The class Inpsyde_Property_List

    This class is very similar to a stdClass from the PHP core: just some key-value pairs. There are two important differences: an Inpsyde_Property_List can be made immutable, and it can have a parent class.

    To make an instance of this class immutable, we call its method freeze(). Once that is done, there is no way to change any data of this class. Any attempt to do that will return an instance of WP_Error. We can test that with the method is_frozen() which returns true or false, depending on the current state.
    The instance we get from MultilingualPress is always frozen. We can rely on its data, because no matter how many plugins access it, they cannot change it.

    What should we do if we want an instance with almost the same data, but some of them with different values? We create a new instance and use the existing one as its parent. Now we can change the values for our internal use and use the other values as if they were properties of our new instance.

    Usage example for Inpsyde_Property_List

    add_action(
        'mlp_and_wp_loaded',
        function( Inpsyde_Property_List_Interface $mlp_data ) {
    
            $ours = new Inpsyde_Property_List;
            $ours->set_parent( $mlp_data );
    
            $ours->plugin_url = plugins_url( '/', __FILE__ );
            $ours->css_url    = "{$ours->plugin_url}css/";
            $ours->js_url     = "{$ours->plugin_url}js/";
            $ours->image_url  = "{$ours->plugin_url}images/";
    
            $ours->freeze();
    });

    This approach avoids common problems with classic inheritance, like the fragile base class and statically linked dependencies. We could call it delayed inheritance. The concept is explained in Steve Yegge’s article The Universal Design Pattern.

    We will look at the various default properties from MultilingualPress in a separate article. For custom code, we need just one important property:

    The autoloader

    The property loader holds an instance of the class Inpsyde_Autoload, a very simple Collection Pipeline for instances of the Inpsyde_Autoload_Rule_Interface which handle the actual class loading. Sounds complicated, but it is dead simple.

    Let’s say our plugin is organized like this:

    - plugin.php // the main file
    - css/ // stylesheets
    - js/ // scripts
    - php/ // PHP classes
        - Plugin_Name_Controller.php
        - Plugin_Name_Model.php
        - Plugin_Name_View.php

    Now we want set up an autoloader to get our classes when we need them. There is one existing class for that, we can reuse it to create a new auto-load rule: Inpsyde_Directory_Load. It takes a path to a directory, and we pass its instance to the Inpsyde_Autoload instance provided by $mlp_data->loader.

    Usage example for Inpsyde_Autoload

    add_action(
        'mlp_and_wp_loaded',
        function( Inpsyde_Property_List_Interface $mlp_data ) {
    
            $load_rule = new Inpsyde_Directory_Load( __DIR__ . '/php' );
            $mlp_data->loader->add_rule( $load_rule );
    
            // We can just use our classes now, no 'require' needed.
            $model      = new Plugin_Name_Model( 'foo' );
            $view       = new Plugin_Name_View( $model );
            $controller = new Plugin_Name_Controller( $model, $view );
            $controller->setup();
    });

    All we have to take care of is that the class names match the file names. This works for interfaces and traits too. Inpsyde_Directory_Load works with flat directories only, it doesn’t search in child directories. It is very fast, because the complete directory is read just once. There is no separate file_exists() check for every class name.

    And that’s all we need for a start: Hook into mlp_and_wp_loaded, register the directory for the auto-loader with the help of the property list – and write awesome code!

     
  • Thomas Scholz 11:03 am on 2014/10/17 Permalink | Reply  

    How to add icons to the language nav menu items 

    By default, our language navigation menus show the language name in its native spelling. This intended: We want to discourage the use of flags for languages. But we do offer the option to use a custom image for each site, and if you want to use that, you can add it to the link text.

    The hook for that is mlp_prepare_nav_menu_item_output. You get two variables as input:

    1. $item: The nav menu item, an instance of the class WP_Post with some extra properties.
    2. $translation: An instance of an implementation of the Mlp_Translation_Interface. If we couldn’t find a translation for some reason, this variable is NULL, so you have to test it before you work with it.

    The $translation has a method get_icon_url() which is again an object: an instance of the Mlp_Url_Interface. It can be casted to a string to get the URL. Another way is calling the method __toString() directly. If there is an icon, the escaped URL is returned. You get an empty string otherwise.

    Here is how you can use it:

    /**
     * Adds an icon to the menu text
     *
     * $item is passed as an object handle, so this function can change it directly
     * and doesn't have to return anything.
     * We still return a string value to make unit tests easier.
     *
     * @link    http://make.marketpress.com/multilingualpress/?p=167
     * @wp-hook mlp_prepare_nav_menu_item_output
     * @param   WP_Post                        $item
     * @param   Mlp_Translation_Interface|NULL $translation Might be NULL
     *                       if there is no translation for the item or
     *                       the other site is not linked to the current
     *                       site.
     * @return  string  When and why we stopped.
     */
    function mlp_add_icons_to_menu( WP_Post $item, $translation = NULL ) {
    
    	if ( ! is_object( $translation ) )
    		return 'no translation object';
    
    	if ( ! class_implements( $translation, 'Mlp_Translation_Interface' ) )
    		return 'invalid translation object';
    
    	if ( FALSE !== strpos( $item->title, '<img' ) )
    		return 'icon already present';
    
    	/* $translation->get_icon_url() returns an instance of
    	 * Mlp_Url_Interface, so we have to cast it to a string
    	 * before we check it with empty().
    	 * @see Mlp_Url_Interface
    	 */
    	$icon_url = (string) $translation->get_icon_url();
    
    	if ( empty ( $icon_url ) )
    		return 'no icon available';
    
    	$item->title = "<img src='$icon_url' alt=''> $item->title";
    
    	return 'success';
    }
    
    add_action(
    	'mlp_prepare_nav_menu_item_output', // hook
    	'mlp_add_icons_to_menu',            // callback
    	10,                                 // priority
    	2                                   // number of accepted arguments
    );

    Download as plugin: MultilingualPress Addon: Nav Menu Icons. Activate it as a network plugin, and it will just work without further configuration.
    You might have to adjust the image position in your stylesheet. Example:

    .mlp-language-nav-item img {
        vertical-align: middle;
    }

    Here is a screenshot of such a changed menu with our built-in flags. Again: please do not use these flags. :)

    Navigation menu with icons

    Always add an alt attribute, but leave its value empty if you still have text, so users with screen readers don’t have to waste their time with it. The item text is good enough.

     
    • Jeroen 9:07 am on 2014/11/11 Permalink | Reply

      Hi Thomas. I posted a question on the plugin support page of MLP. The question was about adding a language button in my menu. They directed me to this post you wrote. I succeeded in installing the plugin. But where in my WordPress dashboard can I edit something to make this work? And what editing is needed? Some help would be awesome ;-).

      • Jeroen 9:14 am on 2014/11/11 Permalink | Reply

        I’m so sorry. I just now see that network activate already did the job! It picks the flag-url from the site settings and adds the image to the top menu without needing to edit anything. Awesome add-on!!!
        Thank you so very much :-)

        • Thomas Scholz 10:17 am on 2014/11/11 Permalink | Reply

          Thanks for the feedback. The activation of the plugin deserved indeed a short explanation. I have added one, plus a suggestion for the theme’s stylesheet.

    • Gus 10:09 pm on 2014/11/20 Permalink | Reply

      Hi

      I am trying to insert the language selector plugin in a template monster header but it seems impossible…

      • Thomas Scholz 1:23 am on 2014/11/21 Permalink | Reply

        Please use our support forum to explain the problem, add your ode and the error messages that you get. I’m sure that we can find a way to solve it. :)

    • roberto 8:51 pm on 2015/02/10 Permalink | Reply

      Hi, i’ve tried many things but i’m getting confused. Please could you help me???. what I’m trying to do is to move both language buttons (with their icons) away from the “Primary Menu”, i would like to put it in the header or somewhere else.

      Here is the URL of my web project: http://vidaurrereisen.com/plasticwebs/

      Sorry if my english is a little poor, please try to explain it as simple as you can.

      thanks

  • Thomas Scholz 7:22 pm on 2014/10/15 Permalink | Reply  

    MultilingualPress 2.1.2 “Edith Fellowes” 

    This release is dedicated to all people who care about ugly things, because that’s what we do too.

    Changes

    • Combine all scripts and stylesheets, separated for frontend and backend.
    • Minify scripts and stylesheets when SCRIPT_DEBUG and MULTILINGUALPRESS_DEBUG are not set.
    • Make the icon/flag for the current site available in nav menus (tutorial follows).
    • Sites with custom name are now returned in Mlp_Language_Api::get_translations().
    • Better updates: Make sure that site relations are not lost and languages are not duplicated.
     
  • Thomas Scholz 10:38 am on 2014/10/01 Permalink | Reply  

    MultilingualPress 2.1.1 “Kris Kelvin” 

    No matter how smart your own tests are – you users are smarter. This release fixes the bugs they found and reported. Thank you all for the feedback!

    I named this release “Kris Kelvin”, because …

    Changes

    • Fixed autoloading with glob() on Solaris systems. This deserves a separate post here.
    • Fixed database error when upgrading from a preview version of the 2.1 branch.
    • Custom flags are now fetched from the correct site.
    • Built-in flag icons are checked on the file system before we return an URL from them.
    • Language switcher widget is now visible for all users.
    • Improved description of the widget options.
    • Search pages are translated correctly.
    • Pro: Table duplicator works with custom tables now. Blog post and new plugin for that will come too.
     
  • deku86 2:34 pm on 2014/09/26 Permalink | Reply  

    Multilingual Press 2.1 is out now! 

    Today we released the final version 2.1 of Multilingual Press. The release includes a lot of improvements and great new features. A full list of all changes you can find in the Changelog. Thanks for all the feedback of the RC!

    Changelog 2.1.0

    • Added links to translations to the head element.
    • Relations between sites are now stored in a separate table mlp_site_relations. This is faster than the previous option call, and it is less error prone, because we don’t have to synchronize these relations between sites. The old options will be imported into the table automatically during the upgrade.
    • You cannot edit trashed translations anymore. If a translation has been moved to trash, you get a notice on the original editor page now, not the post content.
    • Post meta fields in poorly written plugins will not be overwritten anymore. We had many reports about plugins without a check for the current site when they write meta fields. Now we remove all global post data before we synchronize the posts, and we restore them when we are done.
    • The HTTP redirect will respect the visitor’s language preference now correctly.
    • All users who are logged in can disable the automatic redirection in their profile settings now.
    • You can see for which site the HTTP redirect is enabled in the global site table in the network administration in an extra column.
    • Installation and uninstallation are heavily improved now. We catch many more edge cases and switches from Free to Pro.
    • Languages are now synchronized between MultilingualPress and WordPress. When you assign a language in MultilingualPress to a site the first time and the language files are available, we set the site language in the WordPress option to that value.
    • You can add language links to regular navigation menus in the backend now. These links are adjusted automatically on each site: if there is a dedicated translation, the link will be changed to that page. It will point to the other site’s front page otherwise.
    • Users who are not logged in will not get permalinks for non-public sites anymore. You can work on a new site now safely, test all the links while being logged in, and your visitors will never see that until you set the site to public.
    • Post formats are now supported in the post translation page. We offer only formats that you have used on the other site at least once, because that is the onloy way to know that they are actually supported on that site.
    • Post parents are now synchronized when you save a hierarchical post type like a page.
    • You can link existing terms (tags, categories, whatever) now. We will add support for term creation on that page later.
    • There are hundreds of other, minor improvements, too many to list them all.

    Download

    If you own a Pro version, the ZIP archive is already in your download area: English and German. The free version is available on our GitHub repository.

     
  • Thomas Scholz 11:03 pm on 2014/07/14 Permalink | Reply  

    How to get a post from another site in the network 

    Let’s say we have a site id and a post id. The source doesn’t matter, it could be a database, user input, whatever. Now we want to get a WP_Post object from that site.

    A first idea might look like this:

    switch_to_blog( $site_id );
    $post = get_post( $post_id );
    restore_current_blog();

    But this is not necessary, there is already a function in WordPress for that:

    function get_blog_post( $blog_id, $post_id ) {
        switch_to_blog( $blog_id );
        $post = get_post( $post_id );
        restore_current_blog();
    
        return $post;
    }

    Nice, but there is an important, subtle bug in that function: it is using get_post( $post_id ) without a check on the post id. If $post_id is 0, NULL or "", get_post() will use an existing global post object or id. But the current global post is from the source site, not from the target site! The id on site 1 references a completely different post than on site 2.
    WordPress doesn’t care. So we have to do that check:

    $post = NULL;
    
    if ( ! empty ( $post_id ) )
        $post = get_blog_post( $site_id, $post_id );
     
  • Thomas Scholz 6:17 am on 2014/04/02 Permalink | Reply
    Tags: ,   

    Create a custom language switcher 

    We offer a widget and the “quick links” to show links to translations, but many users need a custom solution at other places or in a formatting we just don’t give them (yet).

    There is a handy helper function to get all the links as an array: mlp_get_interlinked_permalinks(). It returns an array with the text (human readable language name), the permalink to the other site’s translation and an entry lang (the language code) – for each single translation.

    You can use that to create your own language switcher. The following function creates a string that might look like this:

    EN | DE | RU

    Add it to your theme’s functions.php.

    /**
     * Create a navigation between translations
     *
     * @param  string $between  Separator between items
     * @param  string $before   HTML before items
     * @param  string $after    HTML after items
     * @return string
     */
    function mlp_navigation(
        $between = ' | ',
        $before  = '<p class="mlp-lang-nav">',
        $after   = '</p>'
    )
    {
        $links = (array) mlp_get_interlinked_permalinks();
    
        if ( empty ( $links ) )
            return '';
    
        $items = array ();
    
        foreach ( $links as $link ) {
            if ( isset ( $link['text'] ) ) {
                $text = $link['text'];
            }
            else {
                // take just the main code
                $first = strtok( $link['lang'], '_' );
                $text  = mb_strtoupper( $first );
            }
    
            $items[] = sprintf(
                '<a href="%1$s" hreflang="%2$s" rel="alternate">%3$s</a>',
                esc_url( $link['permalink'] ),
                esc_attr( $link['lang'] ),
                $text
            );
        }
    
        return $before . join( $between, $items ) . $after;
    }

    Now you can call the function wherever you need it without any arguments:

    echo mlp_navigation();

    Don’t forget the closing semicolon!

    If you want to get a list, you can change the parameters:

    echo mlp_navigation(
        '</li><li>', // between items
        '<ul class="mlp-lang-nav"><li>', // before
        '</li></ul>' // after
    );

    We will add support for custom menus in one of the next versions of Multilingual Press, so you can create your own menus with drag and drop.

     
    • Piet 4:31 am on 2014/07/02 Permalink | Reply

      Thanks for the tutorial, I will try to implement this. I noticed though that although Posts and Pages are perfectly linked together across languages, Categories are not. If I am looking at a Category Archive the language switcher links to the homepage of the resp. languages. Is there a way to fix this?
      Thanks,
      Piet

      • Thomas Scholz 5:47 am on 2014/07/02 Permalink | Reply

        This part is not completed – yet. We will add taxonomy support in version 2.1.

    • Jorge Díaz 11:39 pm on 2014/09/26 Permalink | Reply

      Hi, I think that the answer to this question is going to be pretty obvios, but when you want to print the code in a page you have to write the code using if that is correct I used it but I don’t know what is happening because is not showing the language switcher.

      • Thomas Scholz 12:00 am on 2014/09/27 Permalink | Reply

        Is there something missing in your comment? I’m not sure what exactly you are asking. :)

        • Jorge Díaz 1:20 am on 2014/09/28 Permalink | Reply

          Hi, thanks for your answer, actually yes the PHP tags are missing, but I finally did it, now I have other question. Multilingual Press works with multisite, I have multisite setup and 2 sites the second is cloned from the first one so I have the same data in both (pages and post) Priority of first language (site for first site) is 10 and second language(site) is 9. But how do I create the relationships between the pages from the first language to the pages in second language, because when I click the check button it creates a page in the same site as draft, so I don’t know what I am missing.

          • Thomas Scholz 1:46 am on 2014/09/28 Permalink | Reply

            Use the button Change Relationship to find the other post or page. It is right below the editor for the translation in MultilingualPress Pro. See our docs for screenshots.

            • Jorge Díaz 2:25 am on 2014/09/28 Permalink

              Hi, thanks for you answer, I am using the free version, I think that custom relationships are not available for the free version, now I managed to create a widget are as you can see here http://prntscr.com/4qzg2n it looks like the same widget from social icon, now my question is, is it possible at least to leave the widget as it is (because if I uncheck the “trasnlate this post option” it disappear) but linking to home page, because now it links to a page that doesn’t exist. Sorry to bother you. :(

            • Thomas Scholz 2:05 pm on 2014/09/28 Permalink

              If it links to the wrong page, it’s a bug. You should uncheck the option Show widget for translated content only. in the widget settings to get it on all pages.

              I have extended our language API in version 2.1, so you can create a much more granular language switcher now. I hope to find the time for a post about that next week.

            • Jorge Díaz 7:21 pm on 2014/09/28 Permalink

              Actually that option is unchecked :(

            • Jorge Díaz 7:29 pm on 2014/09/28 Permalink

              I have unchecked “show current site” and “show widget for translated content only” and now it appears just the flag for the other site in both site, but it’s linking to a page that don’t exist :S for example if the page is the home (domain.com) it’s linking to domain.com/lang/home-2/ and if I go to domain.com/about it links to domain.com/lang/about-2 so I don’t really understand what is happening.

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel