Forum Replies Created

Viewing 15 replies - 136 through 150 (of 150 total)
  • Hello,
    You need to go in the Sublanguage settings, check “Navigation Menu Items” checkbox and save. Now you have a new submenu: Sublanguage>Navigation Menu Items where you can translate your custom links.
    Got it?

    Hello,

    I’d say it’s rather a problem from WordPress core…

    I think you can fix it by adding this in your theme’s function.php:

    
    add_filter('woocommerce_cart_item_product', function($product) {
      $product->post->post_title = apply_filters('sublanguage_translate_post_field', $product->post->post_title, $product->post, 'post_title');
      return $product;
    });
    

    Actually, this works only if you use the “custom” language switch. You’re probably using the switch into the wordpress menu.

    Hello,

    I think you’re almost there:

    #1:

    
    <?php
    global $sublanguage;
    $name = $sublanguage->current_language->post_name;
    if($name == 'en'){
    
           print "english text";
        }
          print "german text";
    } ?> 
    

    #3:

    
    <?php
    function my_custom_translation($original_text, $current_language) {
    
        if ($current_language->post_name == 'eng') {
    
            return 'english test';
        }
        return $original_text;
    
    } 
    
    echo apply_filters('sublanguage_custom_translate', 'text to translate', 'my_custom_translation');
    
    ?>
    

    Forget about the #2. I think the #3 is better, even if it looks a bit more complex, because it will still work if you uninstall Sublanguage. The solution #1 will crash as soon as you remove sublanguage.

    Please try this in the function.php of your theme:

    
    add_filter('pum_popup_content', function($content, $id) {
    		
      return apply_filters('sublanguage_translate_post_field', $content, get_post($id), 'post_content');
    		
    }, 10, 2);
    

    Sorry but there is no way to fix it right now: it is not really a bug, it is actually supposed to work like this.

    But I will try to find a solution for this problem in a future version of this plugin. Thank you for reporting this issue!

    Hello,

    The function.php I am referring of is in /wp_content/themes/your_theme_name/function.php. But if you don’t have any PHP knowledge, I strongly advise you against editing this. In place, you can either append the language switch in your theme’s menu or use a widget. Please read the faq for more details.

    Hello,

    First you need to go to sublanguage > languages, select “english” and verify the “locale” box has “en_US” (or add it).

    Now Sublanguage is only considering url to determine the language of a page (it doesn’t use cookies or something). If you enable “autodetect language”, it will check every / url and redirect to /en/ in case it detects the browser language to be english. So if you try somehow to redirect back to /, it may cause a redirect loop.

    The problem is when a user has the browser set to english (or more precisely “en_US”), he won’t be able to read the site in turkish anymore. He will be redirected to english every times.

    The alternative is either to have both english and turkish slug in urls (/en/ and /tr/) or disable the “autodetect language”.

    Does it help you?

    • This reply was modified 8 years, 4 months ago by maxime. Reason: improve formating

    Hello,

    Thank you for your suggestion. Yes that’s right: 404’s are redirected to front page when one try to change the language. It would make sense to redirect to another 404 with the corresponding language instead. So www.example.com/asdfadsfafd would link to www.example.com/it/asdfadsfafd. Is that what you’re suggesting?

    So instead of returning a null link, let’s try to return a translated link, with something like this:

    
    [...]
    } else if(is_404()) { 
      $uri = rtrim($_SERVER['REQUEST_URI'], '/');
      $requested_string = substr($uri, strrpos($uri, '/'));
      $link = home_url(esc_url($requested_string));
    }else{
      $link = home_url('/');
    }
    [...]
    

    How does it sound?

    I thing an important thing for a multilanguage solution is to be able to handle language inheritance. In Sublanguage, you can define what is translatable and what is not. For example, in a product post type, you want the title and the description to be translatable but not the price, nor the feature image.

    If you don’t care about this language inheritance, you may try Polylang, which is free and popular. It separates clearly translations in different posts.

    In sublanguage, translations are more interconnected. Technically translations are separated in different posts, but they are not independant, they are actually dependant of their “main” language post.

    And this is not going to change in the next (major) version. The overall interface will not change, and I plan the migration to be just as trivial for users as any plugin update. The only change that (hopefully) will be perceptible is the gain in performance and speed. It won’t be closer to q/xTranslate than it is now, and slugs are going to work exactly the same. I just advise users against customizing the admin interface of the plugin right now. This update should be launched around the begin of 2017.

    Hello,

    Just 2 things:
    First I am working on a new version where I will probably drop these post types and store everything in post meta, in order to improve compatibility and optimize resources (less database queries). So allowing these post types in dashboard may not be a long term solution.

    Secondly, there is actually no way to do this by filters, you need to edit the source code. If it’s okay, here is how you can do this:

    In sublanguage/sublanguage.php, line 1510, set 'show_in_menu' => true,

    Then in sublanguage/include/admin-post.php, you need to remove all code between lines 68 and 89.

    Just out of curiosity, may I ask you why you want to do this?

    Hello,

    Sorry but the solution I gave only work when the language switch is custom or in a widget, but not inside menu. I’ll try to improve this in the future.

    Hello,

    Please don’t use the translation page ID: I’m going to change the system in the next major release, and this will break everything!

    Unfortunately I have no solution to make it work with this plugin.

    Alternatively you can create your own shortcode, with something like this:

    
    add_shortcode( 'my-include', 'my_include_shortcode' );
    
    function my_include_shortcode( $atts, $content = null ) {
    
      $include_posts = get_posts(array(
        'name' => $atts['slug'], // or 'p' => $atts['id']
        'post_type' => 'any',
        'suppress_filters' => false
      ));
      
      foreach ($include_posts as $include_post) {
        
        $output = '<h2>'.$include_post->post_title.'</h2>';
        $output .= $include_post->post_content;
        
        return $output;
        
      }
      
    }
    

    … using [my-include slug="original-page-slug"] as a shortcode.

    • This reply was modified 8 years, 6 months ago by maxime. Reason: Mistakes in the code

    In this topic you found I showed how to do this when your language switch is not inside the menu, which is much easier to customize. You would need to move the language elsewhere, like in a widget or customize your template.

    Hello,

    Sorry, currently there is no easy way to use an icon instead of text in language links in menu. I’ll try to improve that in the next releases.

Viewing 15 replies - 136 through 150 (of 150 total)