Support for multilanguage sites, Internationalization (I18N)

[mvlcek]

But if it's a single language site (where I18N is used just because of its non-language-related features like the advanced navigation/multilevel structure/etc.), there's not a wrong language - there's only one. So the lang parameter could be suppressed.

You are right. But using the get_i18n_available_languages function might slow down the site, if it is called often.
In one of the last releases I added a check for constant I18N_SINGLE_LANGUAGE: if set to true, no languages are shown on the pages view. I will add the check to the URL functions, too. Thus you will be able to get this behaviour by adding the constant (with value true) to your gsconfig.php.

[mvlcek]

I18N version 3.2.2:

• fixes the problem that for some fancy URLs the homepage was shown like http://.../.html (@Strong, @Belletage)
  
• includes a polish translation (thanks to @Everyone)
  

[marrco]

I'm doing a few tests with purecss.io to build responsive sites. Those small responsive moduels offer support to menus too: http://purecss.io/menus/

what's the best way to integrate that with i18N? Maybe i'm missing something obvious here, but purecss ad many other menuing systems need specific class names for active pages etc. Could it be an improvement for future i18n plugin to allow custom classnames?

EDIT: i just noticed that 3.0+ has a new feature, so i guess I have to test with http://mvlcek.bplaced.net/get-simple/mul...-rendering but i'm not sure it's the right option.

[yojoe]

Mvlcek: is there something wrong with i18_search (v.2.11), or does the call have to contain a special directive to get proper links in search results ?
Because using %nondefaultlanguage%/%parents%/%slug% url structure leads to links like http://website/%parents%/testslug , where 'parents' isn't being parsed at all/

[mvlcek]

Mvlcek: is there something wrong with i18_search (v.2.11), or does the call have to contain a special directive to get proper links in search results ?
Because using %nondefaultlanguage%/%parents%/%slug% url structure leads to links like http://website/%parents%/testslug , where 'parents' isn't being parsed at all/

Works for me, see http://mvlcek.bplaced.net/search?tags=&w...rch=Search.
Does it also happen without %nondefaultlanguage%?
Are you using the newest I18N plugin?

[yojoe]

Works for me, see http://mvlcek.bplaced.net/search?tags=&w...rch=Search.
Does it also happen without %nondefaultlanguage%?
Are you using the newest I18N plugin?

I'm using latest versions of i18n plugins family GS 3.2.1) , and I think I found the reason.
Search results were shown using

Code:

(% searchresults i18n=0 %)

i18n=0 which should remove language indicators is the cause of the problem.
A bare (% searchresults %) call works fine, and links are properly parsed.
It's a bit weird, because using GS native %parent% in url structure worked fine.

As a workaround, showing results in a specific language and hiding indicator with css works pretty fine
example:

Code:

(% searchresults lang=de %)

[mvlcek]

I'm using latest versions of i18n plugins family GS 3.2.1) , and I think I found the reason.
Search results were shown using

Code:

(% searchresults i18n=0 %)

i18n=0 which should remove language indicators is the cause of the problem.

The main functionality of i18n=0 is to remove the language from the links, if there is only one language, but the I18N plugin is installed. This causes I18N Search to call find_url (which does not support %parents%) instead of find_i18n_url.

You should not use it if you have multiple languages. The correct way to hide the language is either by CSS or by custom rendering.

[yojoe]

The main functionality of i18n=0 is to remove the language from the links, if there is only one language, but the I18N plugin is installed. This causes I18N Search to call find_url (which does not support %parents%) instead of find_i18n_url.

You should not use it if you have multiple languages. The correct way to hide the language is either by CSS or by custom rendering.

Thx for great info!
Everything's clearly explained.

[hameau]

In order to use some 'sliding door' menu features, it is necessary to have an additional html tag surrounding the text of a menu entry (see: two examples at the references below).

This is easily achievable with I18N, with a minor change to the code that renders the menu. There is no impact (as far as I can see) on menus where no sliding door effect is required, so there is no disadvantage or limitation if this change is 'always on'. In fact, it may allow more customisation of menu rendering in other cases, too.

Changes required are to the file i18n_navigation/frontend.class.php, lines 298 and 300 (in I18N version 3.2.2).

Existing lines 298-300:

PHP Code:

$html .= '<li class="' . $classes . '"><a href="' . $href . '" >' . $title . '</a>';
  } else {
$html .= '<li class="' . $classes . '"><a href="' . $href . '" title="' . 
    htmlspecialchars(html_entity_decode($title, ENT_QUOTES, 'UTF-8')) . '
    ">' . $text . '</a>'; 


(Line 300 has been manually wrapped for forum display purposes.)

Enhanced lines 298-300:

PHP Code:

$html .= '<li class="' . $classes . '"><a href="' . $href . '" ><span>' . $title . '</span></a>';
  } else {
$html .= '<li class="' . $classes . '"><a href="' . $href . '" title="' . 
    htmlspecialchars(html_entity_decode($title, ENT_QUOTES, 'UTF-8')) . '
    "><span>' . $text . '</span></a>'; 


The $title and $text are wrapped with <span> ... </span> tags to allow the sliding door graphics to be positioned correctly.

References:
Sliding Door using single image (uses <span> tags)
Glossy Horizontal Menu (uses <b> tags, which can be changed in the css for <span>)

[mvlcek]

In order to use some 'sliding door' menu features, it is necessary to have an additional html tag surrounding the text of a menu entry (see: two examples at the references below).

This is easily achievable with I18N, with a minor change to the code that renders the menu. There is no impact (as far as I can see) on menus where no sliding door effect is required, so there is no disadvantage or limitation if this change is 'always on'. In fact, it may allow more customisation of menu rendering in other cases, too.

Instead of patching the plugin, you should rather use Custom Rendering.

[hameau]

Instead of patching the plugin, you should rather ...

That's a good idea ... :embarrassed:

I looked at that page when I was trying to get it working, but didn't understand its significance.

Thanks for your help and sorry for the noise.

[ohayo]

Hi there.
I've go some strange issue with my site:
My homepage on Chrome is always displayed in english, but default lang should be polish. It works just fine in sub-pages and I can switch languages with no problem. On FF/IE/Opera homepage works normally.

I've tried changing the favicon path to root and even removing it completely but it doesn't work.
I'm using pretty urls:

%nondefaultlanguage%/%parent%/%slug%/

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(en)/(.*?/)?([A-Za-z0-9-]+)/?$ index.php?id=$3&lang=$1 [QSA,L]
RewriteRule ^(en)/?$ index.php?lang=$1 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*?/)?([A-Za-z0-9-]+)/?$ index.php?id=$2&lang=pl [QSA,L]

and homepage template looks like this:

PHP Code:

<?php if(!defined('IN_GS')){ die('you cannot load this page directly.'); }
?><?php include('inc/doctype_'.$language.'.inc.php'); ?>

<title><?php get_site_name(); ?> / <?php get_custom_field('pagetitle'); ?></title>

<?php include('inc/fonts.inc.php'); ?>
<?php include('inc/styles.inc.php'); ?>
<?php include('inc/analytics.inc.php'); ?>
<?php include('inc/social_'.$language.'.inc.php'); ?>

</head>
<body>
<div id="container">
<?php include('inc/header.inc.php'); ?>
<!-- QUOTE -->
<div id="quote_holder">
    <div class="quote">
    <?php get_i18n_component('quote-1'); ?>
    </div>
</div>
<!-- QUOTE END-->
<!-- WRAPPER -->
<div id="wrapper">
    <div class="wrapperbg">
        <div class="wrapperact">
        <div class="title">
        <h5><?php get_i18n_component('main-haslo'); ?></h5><div class="myButton wycena"><?php get_i18n_component('wycena'); ?></div>
        </div>
        <br class="clear" />
        <div id="content">
            <div id="realizacje">
               <?php include('inc/mainfolio.inc.php'); ?>
            <div class="spacer2"></div>
            <?php get_i18n_component('main-qualities'); ?>
            </div>
        </div>
        </div>
    </div>
</div>
<!-- WRAPPER END -->
<?php include('inc/footer_first.inc.php'); ?>
<div id="tags">
<?php get_i18n_component('tags-1'); ?>
</div>
<?php include('inc/footer_second.inc.php'); ?>
</div>
<!-- CONTAINER END -->
</body>
</html> 


[mvlcek]

I've go some strange issue with my site:
My homepage on Chrome is always displayed in english, but default lang should be polish. It works just fine in sub-pages and I can switch languages with no problem. On FF/IE/Opera homepage works normally.

I've tried changing the favicon path to root and even removing it completely but it doesn't work.

I think you need to include an icon file favicon.ico in the root of your site.

[ohayo]

I've done that and it doesn't solve the problem. Now I have:

PHP Code:

<link rel="icon" href="/favicon.ico" />
<link rel="shortcut icon" href="/favicon.ico" /> 


Any ideas?

[shawn_a]

What would a favicon have to do with language ?

[mvlcek]

What would a favicon have to do with language ?

Not sure about the reason, and it seems I didn't understand it back then either.

But it seems that a request to the favicon.ico, which is rerouted to the 404 page and happens simultaneously to the page request, produces problems when setting cookies or starting sessions.

[shawn_a]

No clue about that, but I do know that cookies cannot be used until the next page request, unless you manually set the global yourself. Might be part of the problem.

[Draxeiro]

Lately I've had various projects needing multi-language functionality and I'm starting to run into some snags concerning the workings of the i18n plugin.

Please correct me if I am wrong here but right now creation of pages in one of the additional languages is basically linked to the default language. If the page is not there in the default language it will not show in navigation of the additional language. Correct?

Either that or I am doing something wrong.

If I create a page to appear only in the 2nd language (say, German) by entering an url and adding _de the page will be added in the page manager but will not appear on the website. Only if I also create one in the default language, then it shows.

However, in every day practise the need is definitely there to be able to create pages exclusively in the non-default language. So in other words for the languages to have separate content.

I hope this is functionality you are willing to add to your plugin. As it would make it just about perfect.

If you can also make creating a page in the non-default easier by adding a button or something that can be used instead of the add _language code that would be even greater.

I am very much willing to make a donation if that helps

[mvlcek]

Lately I've had various projects needing multi-language functionality and I'm starting to run into some snags concerning the workings of the i18n plugin.

Please correct me if I am wrong here but right now creation of pages in one of the additional languages is basically linked to the default language. If the page is not there in the default language it will not show in navigation of the additional language. Correct?
[quote='Draxeiro' pid='37538' dateline='1371801503']

Yes, the default language page is always required, e.g. parent and menu order are only defined there. The idea behind the initial version of the plugin was simply

• there are no special language links
  
• if the user's language settings list any other than the default language, check if the page exists in one of these languages and display it, otherwise display the default language.
  

[quote='Draxeiro' pid='37538' dateline='1371801503']
...
However, in every day practise the need is definitely there to be able to create pages exclusively in the non-default language. So in other words for the languages to have separate content.

I hope this is functionality you are willing to add to your plugin. As it would make it just about perfect.

I fear this would mean rewriting most of the plugin - especially the navigation part. I'll look into it, when I have some time.

[shawn_a]

Seems somewhat outside of the scope of the plugin, if you have different pages you have a different site, not nearly alternate languages.

[Draxeiro]

Lately I've had various projects needing multi-language functionality and I'm starting to run into some snags concerning the workings of the i18n plugin.

Please correct me if I am wrong here but right now creation of pages in one of the additional languages is basically linked to the default language. If the page is not there in the default language it will not show in navigation of the additional language. Correct?

Yes, the default language page is always required, e.g. parent and menu order are only defined there. The idea behind the initial version of the plugin was simply

• there are no special language links
  
• if the user's language settings list any other than the default language, check if the page exists in one of these languages and display it, otherwise display the default language.
  

In my opinion your plugin is one that is absolutely 100% essential for Get Simple. Even when not using the multi-language functionality it's the navigation part makes things so much more flexible.

Basically the way this plugin is set up with regards to multi-language sites things are functional and the logic behind it is sound. But at the same time it also does tend to make things more complicated. As it happens more often than not that people will have differences between languages. Which happens especially in combination with your special pages plugin (think of news and differences between products offered to different markets).

And where one way it will work (default language has more pages than the additional language) vice versa it currently will not.

...
However, in every day practise the need is definitely there to be able to create pages exclusively in the non-default language. So in other words for the languages to have separate content.

I hope this is functionality you are willing to add to your plugin. As it would make it just about perfect.

I fear this would mean rewriting most of the plugin - especially the navigation part. I'll look into it, when I have some time.

It would be a marvellous extension in any case, I am happy that you're at least willing to look into it.

Seems somewhat outside of the scope of the plugin, if you have different pages you have a different site, not nearly alternate languages.

I beg to differ. See my examples above, e.g. a news item meant for only that particular audience. Same thing with regular pages, it will happen often enough.

And while yes it may be somewhat out of the scope of the plugin, this plugin IS what gives GS it's much needed functionality for multi-language sites (especially here in Europe, with all the different languages, you will often get requests for multi-language sites).

And at the same time this would also be the most logical plugin to be further extended this way.

To solve things with different sites would seem to be a bit counter-productive from a user-perspective to be quite honest. Also when compared to other CMS scripts.

[Carlos]

As a workaround, you could just create the default page (no suffix) with the same content as your preferred language page (with suffix). Only snag is if you have to update it (them).

---

I suppose this solution is not very good for you, it's not easy for users, requires extra work...

[Draxeiro]

As a workaround, you could just create the default page (no suffix) with the same content as your preferred language page (with suffix). Only snag is if you have to update it (them).

---

I suppose this solution is not very good for you, it's not easy for users, requires extra work...

Would be troublesome to explain to users and make things needlessly complex, whereas for the end user it should be as simple as possible. Imagine having to explain that to have a page just for the 2nd language they would need to create it on the default language too, even though they don't need it there.

At the same time it wouldn't realistically work if you ask me. As it would mean that the pages are basically included on the default website too. Maybe not in the menu (if you don't select that option) but they are still there.

Setting them to private in the default language would at the same time mean they are set to private in the non-default language(s).

At the same time, as opposed to an extensive rewrite of the plugin, it could perhaps also be possible to follow this route somewhat.

Create a new page, select a box stating for which language it is and then, in the case of the default language not being selected, have a sort of empty placeholder be used in the admin for the default language. So that it would work as per the functionality of the plugin but at the same time doesn't result in an actual page on the website of the default language.

Something to that extent.

Mind you, I am not a programmer so I am just throwing some things in the air which might not at all be feasible but who knows maybe a 'simpler' option like this would in fact be possible.

[yojoe]

Draxeiro: maybe you need to change navigation's logic ? Instead of using multilang function of i18n plugin , just go with couple different menu trees and show branch dependant on chosen, frontend language.

[Draxeiro]

Draxeiro: maybe you need to change navigation's logic ? Instead of using multilang function of i18n plugin , just go with couple different menu trees and show branch dependant on chosen, frontend language.

I look at it from a different perspective I guess. For me solving this with an easy to use plugin would always be the preferred route. As it brings it within grasp of every user.

Compare your suggested solution to an extended i18n plugin. While it will probably work great yours would be beyond the scope of quite a few GS users, whereas with the i18n plugin it would be vice versa.

If the i18n plugin could be extended this way it would basically cater to just about any multi-lingual scenario.

Having said that I AM very interested how you would go about creating your multi-language/language independent setup. Maybe a tutorial somewhere on the forum (or in the wiki) could be a good idea? After all it is always good to have multiple solutions