(2013-05-06, 15:48:55)Draxeiro Wrote: [ -> ]Just gave it a test run on a site in development (which is still using GS 3.2.0, haven't updated yet to 3.2.1.) but when selecting an link to a local page in the editor %language% or %nondefaultlanguage% (depending on which of the two solutions is used) is still shown in the link instead of the language code (say 'en' or 'de').
Weird, for me it works both in GS 3.1.2 and (I think) 3.2.1.
Do you get a hierarchical view in the select-page-dropdown as shown in the attachment?
(2013-05-06, 16:41:17)mvlcek Wrote: [ -> ] (2013-05-06, 15:48:55)Draxeiro Wrote: [ -> ]Just gave it a test run on a site in development (which is still using GS 3.2.0, haven't updated yet to 3.2.1.) but when selecting an link to a local page in the editor %language% or %nondefaultlanguage% (depending on which of the two solutions is used) is still shown in the link instead of the language code (say 'en' or 'de').
Weird, for me it works both in GS 3.1.2 and (I think) 3.2.1.
Do you get a hierarchical view in the select-page-dropdown as shown in the attachment?
See my attachment, not really a hierarchical view. Though only some pages have children (site still filled with dummy content), but it does look differently.
For the record, my permalink structure is this: %language%/%parent%/%slug%/
My .htaccess file contains this:
Code:
AddDefaultCharset UTF-8
Options -Indexes
# blocks direct access to the XML files - they hold all the data!
<Files ~ "\.xml$">
Order allow,deny
Deny from all
Satisfy All
</Files>
<Files sitemap.xml>
Order allow,deny
Allow from all
Satisfy All
</Files>
RewriteEngine on
# Usually it RewriteBase is just '/', but
# replace it with your subdirectory path
RewriteBase /
RewriteRule ^/?$ nl/ [R,L] # optional
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(nl|en)/(.*?/)?([A-Za-z0-9-]+)/?$ index.php?id=$3&lang=$1 [QSA,L]
RewriteRule ^(nl|en)/?$ index.php?lang=$1 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule /?([A-Za-z0-9-]+)/?$ index.php?id=$1 [QSA,L]
As said GS is on 3.2.0 and the plugin updated to 3.2.
(2013-05-06, 17:09:28)Draxeiro Wrote: [ -> ]See my attachment, not really a hierarchical view. Though only some pages have children (site still filled with dummy content), but it does look differently.
Seems that the plugin's code to change the drop down (correct links and hierarchical view) is not executed. Please try GS 3.2.1 - version 3.2.0 is not even available for download anymore - maybe it has some CKEditor problems.
(2013-05-06, 03:21:19)mvlcek Wrote: [ -> ]I18N version 3.2:- supports a new placeholder in fancy URLs: %parents% to output parent, grandparent, etc. (@Kida, @bandrzej and others)
- finally supports all placeholders also when selecting a page link in the editor
I was hoping that %parents% would translate the URL at least a bit, never mind.
But I don't really understand what's new? What the %parents% does differently than the %parent% without "s"? Does that mean that it shows the whole structure of an URL even with more levels of a menu?
I understand the second point, that's just correcting the error in the link.
By the way, the thing mentioned by Draxeiro is kinda wierd, it works well to me, see the attachment. It works in both site version pages.
I'm using now %nondefaultlanguage%/%parents%/%slug%/
Edit://
I have just found that...
... using %parents% breaks working News Manager down. I use this .htaccess.
Code:
# News Manager setup:
# for Czech (default language - that's important, it's without /cs/ in the url)
RewriteRule ^clanky/tag/([^/.]+)/?$ index.php?id=clanky&tag=$1&lang=cs [L]
RewriteRule ^clanky/post/([^/.]+)/?$ index.php?id=clanky&post=$1&lang=cs [L]
RewriteRule ^clanky/page/([^/.]+)/?$ index.php?id=clanky&page=$1&lang=cs [L]
RewriteRule ^clanky/archive/([^/.]+)/?$ index.php?id=clanky&archive=$1&lang=cs [L]
# for English (secondary language)
RewriteRule ^en/clanky/tag/([^/.]+)/?$ index.php?id=clanky&tag=$1&lang=en [L]
RewriteRule ^en/clanky/post/([^/.]+)/?$ index.php?id=clanky&post=$1&lang=en [L]
RewriteRule ^en/clanky/page/([^/.]+)/?$ index.php?id=clanky&page=$1&lang=en [L]
RewriteRule ^en/clanky/archive/([^/.]+)/?$ index.php?id=clanky&archive=$1&lang=en [L]
# end News Manager
# To make custom permalinks work with the secondary language in the address only :) Permalink structure: %nondefaultlanguage%/%parent%/%slug%/
RewriteRule ^/?$ cs/ [R,L] # optional
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(cs|en)/(.*?/)?([A-Za-z0-9-]+)/?$ index.php?id=$3&lang=$1 [QSA,L]
RewriteRule ^(cs|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=cs [QSA,L]
(2013-05-06, 17:18:57)mvlcek Wrote: [ -> ] (2013-05-06, 17:09:28)Draxeiro Wrote: [ -> ]See my attachment, not really a hierarchical view. Though only some pages have children (site still filled with dummy content), but it does look differently.
Seems that the plugin's code to change the drop down (correct links and hierarchical view) is not executed. Please try GS 3.2.1 - version 3.2.0 is not even available for download anymore - maybe it has some CKEditor problems.
I just updated to 3.2.1. however that doesn't seem to change a thing. I also disabled all other plugins to see if that made a difference. Doesn't change a thing either.
I am at a bit of a loss here. Plugin is updated, GS updated too, what else could cause this?
Draxeiro: make sure you have javascript enabled and all JS libraries like jquery loads properly in GS.
It's required, otherwise page view won't be properly rendered when you use custom url structure for multilanguage website based on i18n 3.2
Try to also clear GS cache (settings tab).
ps. v3.2 covers everything you have quoted from my old post
edit: what's your rewrite rules for i18n ?
Try also with disabled fancy urls.
(2013-05-06, 18:10:12)yojoe Wrote: [ -> ]Draxeiro: make sure you have javascript enabled and all JS libraries like jquery loads properly in GS.
It's required, otherwise page view won't be properly rendered when you use custom url structure for multilanguage website based on i18n 3.2
Try to also clear GS cache (settings tab).
ps. v3.2 covers everything you have quoted from my old post
edit: what's your rewrite rules for i18n ?
Try also with disabled fancy urls.
JS enabled and the libraries load properly by the looks of things. GS cache cleared.
Rewrite rules as follows:
Code:
AddDefaultCharset UTF-8
Options -Indexes
# blocks direct access to the XML files - they hold all the data!
<Files ~ "\.xml$">
Order allow,deny
Deny from all
Satisfy All
</Files>
<Files sitemap.xml>
Order allow,deny
Allow from all
Satisfy All
</Files>
RewriteEngine on
# Usually it RewriteBase is just '/', but
# replace it with your subdirectory path
RewriteBase /
RewriteRule ^/?$ nl/ [R,L] # optional
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(nl|en)/(.*?/)?([A-Za-z0-9-]+)/?$ index.php?id=$3&lang=$1 [QSA,L]
RewriteRule ^(nl|en)/?$ index.php?lang=$1 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule /?([A-Za-z0-9-]+)/?$ index.php?id=$1 [QSA,L]
Also tried disabling the fancy urls but it keeps showing the fancy urls. Tried in multiple browsers and refreshing until the cows come home.
(2013-05-06, 17:25:34)TeeJay Wrote: [ -> ]I was hoping that %parents% would translate the URL at least a bit, never mind.
I don't understand, what should be translated?
(2013-05-06, 17:25:34)TeeJay Wrote: [ -> ]But I don't really understand what's new? What the %parents% does differently than the %parent% without "s"? Does that mean that it shows the whole structure of an URL even with more levels of a menu?
Yes, it includes the whole structure even for deeper menu levels. See e.g. my
site, which is currently switched to use
%parents% (see the generated URLs in the menu).
(2013-05-06, 18:25:14)Draxeiro Wrote: [ -> ]JS enabled and the libraries load properly by the looks of things. GS cache cleared.
hmm...hover the mouse cursor on the view page button and see where the link is pointing to.
Try to disable JS in browser and compare this button between backend with enabled and disabled JS.
Try also to resave on of the pages, to recreate whole i18n menu structure and page's cache.
(2013-05-06, 18:25:14)Draxeiro Wrote: [ -> ]Rewrite rules as follows:
Code:
RewriteRule ^(nl|en)/(.*?/)?([A-Za-z0-9-]+)/?$ index.php?id=$3&lang=$1 [QSA,L]
RewriteRule ^(nl|en)/?$ index.php?lang=$1 [QSA,L]
Also tried disabling the fancy urls but it keeps showing the fancy urls. Tried in multiple browsers and refreshing until the cows come home.
Delete QSA from above lines, leaving only [L] at the end of lines.
You'd also need to clear custom url structure when you disable fancy urls.
I wonder if your webhost doesn't utilise any sort of caching system.
Do you have any possibility to migrate temporarily your site to another host ?
If not, try a fresh GS instance with only i18n plugin.
Mvlcek: does using %parents% fix (redirect automatically or point to 404) the GS "feature" with deeply nested slugs, where on default setup (no custom url structure), example page available under
website.tld/sampleslug
was also available under
website.tld/anything/before/sampleslug ?
Can't find the proper threads about this matter :\
(2013-05-06, 18:52:56)yojoe Wrote: [ -> ]Mvlcek: does using %parents% fix (redirect automatically or point to 404) the GS "feature" with deeply nested slugs, where on default setup (no custom url structure), example page available under
website.tld/sampleslug
was also available under website.tld/anything/before/sampleslug ?
No, it just generates multi-level hierarchical URLs, but
website.tld/anything/before/sampleslug will still show the page referenced by
sampleslug.
(2013-05-06, 18:32:03)mvlcek Wrote: [ -> ] (2013-05-06, 17:25:34)TeeJay Wrote: [ -> ]I was hoping that %parents% would translate the URL at least a bit, never mind.
I don't understand, what should be translated?
The URL according to the page title.
For instance, let's say we have a page called "Company Offers" on companydomain.com domain. It's slug is "company-offers" in default language which is English. So the URL is companydomain.com/company-offers ... the problem is that this URL doesn't change with the language. In German language, it's still compananydomain.com/company-offers as it is in every language. But it's not critical, it would be just better for SEO as the Fancy URLs are.
Are you planning to do multilingual URLs?
Thanks for your time, I see you're quite busy.
Hello,
I implemented your plugin I18N in my GS-Site and got that error:
Warning: copy(C:\xampp\htdocs\getsimple/plugins/i18n_common/loadext.php): failed to open stream: No such file or directory in C:\xampp\htdocs\getsimple\plugins\i18n_common\common.php on line 62
EDIT: Solved in V3.2.1 !! .. common was obsolete.
LG Wolfgang
(2013-05-06, 18:52:56)yojoe Wrote: [ -> ]hmm...hover the mouse cursor on the view page button and see where the link is pointing to.
Try to disable JS in browser and compare this button between backend with enabled and disabled JS.
Try also to resave on of the pages, to recreate whole i18n menu structure and page's cache.
Delete QSA from above lines, leaving only [L] at the end of lines.
You'd also need to clear custom url structure when you disable fancy urls.
I wonder if your webhost doesn't utilise any sort of caching system.
Do you have any possibility to migrate temporarily your site to another host ?
If not, try a fresh GS instance with only i18n plugin.
Truth be told, I have no idea what it was. Whatever I did the changes wouldn't show. Tried it on multiple browsers since cache can be quite persistent in some of them (especially Firefox).
In the end I went for a fresh install, instead of an upgrade. Then I ran into the same errors as graphiclunch described earlier, after enabling the v3.2 i18n plugin.
Re-installed the previous version of the plugin, problem was gone. Then uploaded the files again overwriting the previous version and all of a sudden it worked fine!
In the meantime I reinstated the custom permalink structure and updated the .htaccess file again. Tested that and clicking through the site it seems to work fine.
Going to the link to local page menu it shows the hierarchical view as it now should but it doesn't show the pages of the non-default language.
See attached screenshot.
I created some Dutch dummy pages and their English dummy counterparts but it only shows the Dutch pages (Dutch is set as default).
Functionality is correct in that it now includes the language abbreviation when selecting a dutch page (just as advertised for v3.2), however the english pages are nowhere to be found. Even though they absolutely exist.
Any thoughts?
(2013-05-07, 01:17:02)Draxeiro Wrote: [ -> ]Going to the link to local page menu it shows the hierarchical view as it now should but it doesn't show the pages of the non-default language.
...
Functionality is correct in that it now includes the language abbreviation when selecting a dutch page (just as advertised for v3.2), however the english pages are nowhere to be found. Even though they absolutely exist.
It is intentional that only links for the language of the currently edited page are generated, as it is highly unlikely that you want to link from one language to another. However, I currently always show the titel in the default language, even if the link is to a non-default language. And I show all pages, even if they don't exist in this language.
I suppose the correct way is to show only those pages which exist in the language of the currently edited page - and show the title in the correct language.
(2013-05-07, 03:32:32)mvlcek Wrote: [ -> ] (2013-05-07, 01:17:02)Draxeiro Wrote: [ -> ]Going to the link to local page menu it shows the hierarchical view as it now should but it doesn't show the pages of the non-default language.
...
Functionality is correct in that it now includes the language abbreviation when selecting a dutch page (just as advertised for v3.2), however the english pages are nowhere to be found. Even though they absolutely exist.
It is intentional that only links for the language of the currently edited page are generated, as it is highly unlikely that you want to link from one language to another. However, I currently always show the titel in the default language, even if the link is to a non-default language. And I show all pages, even if they don't exist in this language.
I suppose the correct way is to show only those pages which exist in the language of the currently edited page - and show the title in the correct language.
Generating only links for the language of the currently edited page is fine and makes things easier to manage, so I am all for that.
But having the title in the default language will put people on the wrong footing. Same thing with showing all pages even if hey don't exist in this language... non-technical users will not necessarily understand this logic.
So I totally agree that the correct and
best way is to only show those pages which exist in the language of the currently edited page. Plus to show the title in the correct language.
If you can change that one of these days it would be a very good addition indeed. So by all means, please do.
Next to this, something which might be a nice future addition is to make it easier to enable users to create a page for a non-default language. It happens quite a lot that different language versions of a site will have different pages. Right now people should either remember to put a _en (or whatever their language code is) behind the slug or first create a page in the default language, hit the + sign and fill the page (plus deleting it again in the default language).
If functionality could be enabled to easily create a page for the respective language column that would make things a bit easier for end-users.
Same thing for your special pages plugin. If you now for instance create a news item with the _en method it will not be automatically sorted below its parent as it normally would. So if functionality like this would be included it would be very interesting in my opinion.
If I set the visibility of a page to private, I can't see it in the local page menu dropdown whenever I want to create a local link.
I bet if I make a small modification at the php files it would work like a charm but this isn't the way which makes this awesome CMS so smple and unique. So, any other solutions available?
CHANGING LANGUAGE
I have a web with two languages: ES and EN.
The default language is ES, but I have made some links to allow users to change the languaje easily adding ?lang=en to the url.
It works fine and allow switch language, but when the user clic on a menu entry (or any internal link), the ?lang=en dissapears and the languaje return to the default one.
There are any way to switch the language and mantain it during entire session?.
I have see about the favicon trick and I have added this line to the template, but the bug persist:
PHP Code:
<link href="/data/uploads/imagenes/favicon.ico" rel="shortcut icon" />
Thank you for your help.
(2013-05-08, 23:02:44)jesusda Wrote: [ -> ]CHANGING LANGUAGE
I have a web with two languages: ES and EN.
The default language is ES, but I have made some links to allow users to change the languaje easily adding ?lang=en to the url.
It works fine and allow switch language, but when the user clic on a menu entry (or any internal link), the ?lang=en dissapears and the languaje return to the default one.
?lang=en is used to temporarily change the language for this page. If you want to set the language for the current session, use
?setlang=en.
This will only work, if you don't include the language in your fancy URL.
Hello,
At present, the 'View All Pages (I18N)' tab shows the list of existing pages by their title. A page title may be quite long and specific (e.g., for SEO) and is often different to the menu text for that page.
I have found it useful to have the pages listed by menu text, where it exists, in preference to the page title. This approach is also much easier for a casual user when selecting a page to be edited.
I have been using the following changes to i18n_base/pages.php and find it useful:
Code:
--- I18Nv3.2.1/i18n_base/pages.php
+++ Modified_show-menu-text/i18n_base/pages.php
@@ -50,6 +50,7 @@
$pages[$url]['exists'] = true;
$pages[$url]['parent'] = (string) $data->parent;
$pages[$url]['title'] = (string) $data->title;
+ $pages[$url]['menu'] = (string) $data->menu;
$pages[$url]['metak'] = (string) $data->meta;
$pages[$url]['metad'] = (string) $data->metad;
$pages[$url]['menuStatus'] = (string) $data->menuStatus;
@@ -157,7 +158,7 @@
<input type="hidden" name="tags" value="<?php echo stripslashes($page['metak']); ?>"/>
<input type="hidden" name="title" value="<?php echo stripslashes($page['title']); ?>"/>
<?php if (@$page['hasChildren']) echo '<a href="#" style="text-decoration:none" class="dirtoggle">'.(@$page['open'] && !@$page['invisible'] ? '⊟' : '⊞').'</a> '; ?>
- <a title="<?php echo i18n_r('EDITPAGE_TITLE').': '.stripslashes($page['title']).' - '.shtDate($page['date']); ?>" href="edit.php?id=<?php echo $page['url']; ?>" class="title"><?php echo stripslashes($page['title']); ?></a>
+ <a title="<?php echo i18n_r('EDITPAGE_TITLE').': '.stripslashes($page['title']).' - '.shtDate($page['date']); ?>" href="edit.php?id=<?php echo $page['url']; ?>" class="title"><?php echo (stripslashes($page['menu']) != '') ? stripslashes($page['menu']) : stripslashes($page['title']); ?></a>
<span class="showstatus toggle"><?php echo $status; ?></span>
</td>
<td class="secondarylink">
(The code box renders the two characters ⊟ and ⊞ – final semicolons omitted here.)
This also gives 'View All Pages' the same look as 'Edit Navigation Structure', which I find helpful.
While testing I18N with a one-language site I've found that in the backend, links to pages have the lang=xx parameter ('#' in page manager, 'view' when editing, 'Link to local page' in CKeditor...).
Is this the normal behaviour or am I doing something wrong?
(2013-05-26, 06:28:16)Carlos Wrote: [ -> ]While testing I18N with a one-language site I've found that in the backend, links to pages have the lang=xx parameter ('#' in page manager, 'view' when editing, 'Link to local page' in CKeditor...).
Is this the normal behaviour or am I doing something wrong?
For the links in the backend ('#', 'view') the language must be included in the URL as otherwise you might see the wrong language (depending on your browser settings).
For the links within pages it is necessary only for some special cases, but probably could be removed. However, by now I18N supports so many case of including the language in the URL (or determining it on-the-fly from the browser's languages) that it is difficult to determine the side effects.
Currently the only time no language is included in the URL is when your fancy URL includes %PARENTS%, but not %LANGUAGE% or %NONDEFAULTLANGUAGE% - and that's a bug ;-)
(2013-05-26, 19:43:12)mvlcek Wrote: [ -> ]For the links in the backend ('#', 'view') the language must be included in the URL as otherwise you might see the wrong language (depending on your browser settings).
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.
It's not a big issue anyway.
I'm just reporting because I found this while testing News Manager 2.4+ support for I18N permalink structures in the backend (NM's own '#', 'view' links for posts)
This is how I'm currently doing:
Code:
if (function_exists('find_i18n_url')) // I18N?
$url = find_i18n_url($NMPAGEURL, nm_get_parent(), return_i18n_default_language());
// ... else find_url is used
which works fine for %language% or %nondefaultlanguage% structures.
When I found that with normal structures (only %parent% %slug% or non-fancy) the lang parameter was added (as I say, only in backend) I was going to fix it like this:
Code:
if (function_exists('find_i18n_url') &&
count(return_i18n_available_languages()) > 1) // I18N multilanguage?
$url = find_i18n_url($NMPAGEURL, nm_get_parent(), return_i18n_default_language());
// ... else find_url is used
Before doing it, I decided to ask. :-) But maybe I'll leave like it is - no big issue.